- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] vm over android

by Esteban A. Maringolo

Jean, Can you share what is the intended use of the android vm that you're building? Regards! Esteban A. Maringolo 2014-06-18 9:56 GMT-03:00 Jean Baptiste Arnaud <jbaptiste.arnaud(a)gmail.com>: > I am really close to finish the android VM, only based on the Unix source > (just decorate with less than 20 lines of codes, > I need a entry point for the interpreter loop and some convention that > cannot change via the android builder). > + one graphical plugin and a C file for communicate between C and Java. > > CogDroid, project is not maintain since 3 or 4 years. > But still seems work (just have a completely separated source). > Peoples give me all the key to revive it. > I take the source of Cogdroid for understand what they do and redo it > changing less thing possible in unix source. > > My VM run without the graphics and with a subset of plugin (file, socket and > some of them I cannot remember). > Road map: > - Full compiling and packaging process: Done. > - Fix interpreter headless: Done. > - be able to generate and load external lib on the fly from android: done > - Graphical plugin: In progress. > - reintroduce slowly and fix all the removed plugins: todo. > - Nice android connectivity: todo. (all event manage, list of image, > blablabla) > - Create a CMakeGenerator extension to have a really nice way to generate > project. > > Once a graphical version come out I promise some picture and a website. > But again I do that on my free time :-).

June 18, 2014

Re: [Pharo-dev] vm over android

by Ben Coman

June 18, 2014

Re: [Pharo-dev] Complaints about Spec

by Yuriy Tymchuk

On 18 Jun 2014, at 12:31, Benjamin <Benjamin.VanRyseghem.Pharo(a)gmail.com> wrote: > I understand your frustration, but writing doc takes time. :) > > I have a more industry oriented example in polishing mode Cool, Iâm looking forward for that. Uko > > Ben > > On 18 Jun 2014, at 11:40, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > >> Hi guys, >> >> I was very frustrated, but as usually complaints are useless, Iâll try to be constructive. Maybe the problem is not about Spec itself but all the UI related tool-chain. >> >> I find UI very fragile part in software design. And by now Iâve seen only 2 very nice documentations on how to develop UI (with MVC). One was for Ruby on Rails, and another was for iOS applications. Documentation was straightforward: 1) this is how your model, view and controller should look like, 2) this is how they have to talk, 3) other useful cases. >> >> Now, there is description about how to do something with Spec, and itâs cool, but for example I always get myself caught in initialisation stuff. Spec intends that I provide some default solution if itâs not initialised with proper data. And I even cannot initialise some variables, because initialisation of superclass initialises widgets and they need default behaviour. I can move to sort of lazy initialisation stuff, but maybe there is some reason in making some calculator example tutorial that will show how mvc apps should be developed in Pharo? >> >> Uko >> >> >

June 18, 2014

Re: [Pharo-dev] UserManager hierarchy

by Marcus Denker

On 18 Jun 2014, at 14:43, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > Hi, > > most of issues with shrinking to the basic headless image are related to UserManager. Currently UserManager is subclass of DummyUserManager and I really think that we should change it to use the similar approach as the UIManager. > > UserManager (abstract class) > - DummyUserManager (for no real users management) > - KeyChainUserManager (or some other name, current UserManager class) > > The second option is to avoid the next strange "Dummy" class and make UserManager as concrete class with void functionality. > > It will be called using UserManager default or UserManager current instead of current Smalltalk tools userManager that makes unwelcome dependency of the kernel on tools. > BTW I think that the message #current would be much better for UIManager too because it should be possible to use multiple UIs for the same image at once (e.g. Morphic and web-based UI) > > What do you think? > Yes, sounds good. The "Smalltalk tools userManagerâ is really not good as it is not a tool in the sense of âSmalltalk toolsâ. Marcus

June 18, 2014

Re: [Pharo-dev] vm over android

by Jean Baptiste Arnaud

I am really close to finish the android VM, only based on the Unix source (just decorate with less than 20 lines of codes, I need a entry point for the interpreter loop and some convention that cannot change via the android builder). + one graphical plugin and a C file for communicate between C and Java. CogDroid, project is not maintain since 3 or 4 years. But still seems work (just have a completely separated source). Peoples give me all the key to revive it. I take the source of Cogdroid for understand what they do and redo it changing less thing possible in unix source. My VM run without the graphics and with a subset of plugin (file, socket and some of them I cannot remember). Road map: - Full compiling and packaging process: Done. - Fix interpreter headless: Done. - be able to generate and load external lib on the fly from android: done - Graphical plugin: In progress. - reintroduce slowly and fix all the removed plugins: todo. - Nice android connectivity: todo. (all event manage, list of image, blablabla) - Create a CMakeGenerator extension to have a really nice way to generate project. Once a graphical version come out I promise some picture and a website. But again I do that on my free time :-). On 09 Jun 2014, at 18:27, Hilaire Fernandes <hilaire.fernandes(a)gmail.com> wrote: > I have been using it for DrGeo > https://code.google.com/p/squeakvm-tablet/wiki/JenkinsBuilds > > Hilaire > > Le 09/06/2014 16:50, Pablo R. Digonzelli a Ã©crit : >> Hi all, i want to know if it is planning develop a vm over android? >> Time frame ? >> >> TIA >> >> **** >> ------------------------------------------------------------------------ >> *Ing. Pablo Digonzelli* >> Software Solutions >> IP-Solutiones SRL >> Metrotec SRL >> 25 de Mayo 521 >> Email: pdigonzelli(a)softsargentina.com >> pdigonzelli(a)gmail.com >> Cel: 5493815982714 >> > > -- > Dr. Geo http://drgeo.eu > iStoa - https://launchpad.net/istoa > > Best Regards Dr Arnaud jbaptiste.arnaud(a)gmail.com

June 18, 2014

UserManager hierarchy

by Pavel Krivanek

Hi, most of issues with shrinking to the basic headless image are related to UserManager. Currently UserManager is subclass of DummyUserManager and I really think that we should change it to use the similar approach as the UIManager. UserManager (abstract class) - DummyUserManager (for no real users management) - KeyChainUserManager (or some other name, current UserManager class) The second option is to avoid the next strange "Dummy" class and make UserManager as concrete class with void functionality. It will be called using UserManager default or UserManager current instead of current Smalltalk tools userManager that makes unwelcome dependency of the kernel on tools. BTW I think that the message #current would be much better for UIManager too because it should be possible to use multiple UIs for the same image at once (e.g. Morphic and web-based UI) What do you think? Cheers, -- Pavel

June 18, 2014

Vm on Mac OS 7.5 no cairo

by Stephan Eggermont

There is a significant difference in loaded modules. Smalltalk vm listLoadedModules (12 dec 2013 vm) #('SocketPlugin VMMaker-oscog-LucFabresse.306 (i)' 'Matrix2x3Plugin VMMaker-oscog-LucFabresse.306 (i)' 'FloatArrayPlugin VMMaker-oscog-LucFabresse.306 (i)' 'ClipboardExtendedPlugin VMMaker-oscog-LucFabresse.306 (i)' 'SurfacePlugin Dec 12 2013 (i)' 'libcairo.2.dylib' 'B2DPlugin VMMaker-oscog-LucFabresse.306 (i)' 'ZipPlugin VMMaker-oscog-LucFabresse.306 (i)' 'NativeBoostPlugin NativeBoost-CogPlugin-GuillermoPolito.19 (i)' 'BitBltPlugin VMMaker-oscog-LucFabresse.306 (i)' 'FT2Plugin Freetype-Plugin-IgorStasenko.64 (e)' 'UnixOSProcessPlugin VMConstruction-Plugins-OSProcessPlugin.oscog-EstebanLorenzano.43 (i)' 'SecurityPlugin VMMaker-oscog-LucFabresse.306 (i)' 'FilePlugin VMMaker-oscog-LucFabresse.306 (i)' 'MiscPrimitivePlugin VMMaker-oscog-LucFabresse.306 (i)' 'LargeIntegers v1.5 VMMaker-oscog-LucFabresse.306 (i)' 'LocalePlugin VMMaker-oscog-LucFabresse.306 (e)') (350 vm) #('FT2Plugin Freetype-Plugin-IgorStasenko.64 (e)' 'B2DPlugin VMMaker.oscog-jeanbaptistearnaud.769 (i)' 'BitBltPlugin VMMaker.oscog-jeanbaptistearnaud.769 (i)' 'ZipPlugin VMMaker.oscog-jeanbaptistearnaud.769 (i)' 'NativeBoostPlugin NativeBoost-CogPlugin-EstebanLorenzano.20 (i)' 'SocketPlugin VMMaker.oscog-jeanbaptistearnaud.769 (i)' 'UnixOSProcessPlugin VMConstruction-Plugins-OSProcessPlugin.oscog-EstebanLorenzano.43 (i)' 'SecurityPlugin VMMaker.oscog-jeanbaptistearnaud.769 (i)' 'FilePlugin VMMaker.oscog-jeanbaptistearnaud.769 (i)' 'MiscPrimitivePlugin VMMaker.oscog-jeanbaptistearnaud.769 (i)' 'LargeIntegers v1.5 VMMaker.oscog-jeanbaptistearnaud.769 (i)' 'LocalePlugin VMMaker.oscog-jeanbaptistearnaud.769 (e)')

June 18, 2014

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/40024 Home: https://github.com/pharo-project/pharo-core

June 18, 2014

[pharo-project/pharo-core] 60e080: 40024

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: 60e08071c4cbaa6cfd9652ec4b02fa44e8a9f736 https://github.com/pharo-project/pharo-core/commit/60e08071c4cbaa6cfd9652ec… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-06-18 (Wed, 18 Jun 2014) Changed paths: A Files.package/AsyncFile.class/instance/accessing/fileHandle.st R Files.package/AsyncFile.class/instance/as yet unclassified/close.st R Files.package/AsyncFile.class/instance/as yet unclassified/fileHandle.st R Files.package/AsyncFile.class/instance/as yet unclassified/open_forWrite_.st R Files.package/AsyncFile.class/instance/as yet unclassified/test_fileName_.st A Files.package/AsyncFile.class/instance/open%2Fclose/close.st A Files.package/AsyncFile.class/instance/open%2Fclose/open_forWrite_.st A Files.package/AsyncFile.class/instance/tests/test_fileName_.st A FontChooser.package/AbstractFontSelectorDialogWindow.class/instance/accessing/familyName.st A FontChooser.package/AbstractFontSelectorDialogWindow.class/instance/actions/newContentMorph.st R FontChooser.package/AbstractFontSelectorDialogWindow.class/instance/as yet unclassified/familyName.st R FontChooser.package/AbstractFontSelectorDialogWindow.class/instance/as yet unclassified/fontSize.st R FontChooser.package/AbstractFontSelectorDialogWindow.class/instance/as yet unclassified/newBoldButtonMorph.st R FontChooser.package/AbstractFontSelectorDialogWindow.class/instance/as yet unclassified/newContentMorph.st R FontChooser.package/AbstractFontSelectorDialogWindow.class/instance/as yet unclassified/newFontFamilyMorph.st R FontChooser.package/AbstractFontSelectorDialogWindow.class/instance/as yet unclassified/newFontSizeMorph.st R FontChooser.package/AbstractFontSelectorDialogWindow.class/instance/as yet unclassified/newFontStyleButtonRowMorph.st R FontChooser.package/AbstractFontSelectorDialogWindow.class/instance/as yet unclassified/newItalicButtonMorph.st R FontChooser.package/AbstractFontSelectorDialogWindow.class/instance/as yet unclassified/newStruckOutButtonMorph.st R FontChooser.package/AbstractFontSelectorDialogWindow.class/instance/as yet unclassified/newTextPreviewMorph.st R FontChooser.package/AbstractFontSelectorDialogWindow.class/instance/as yet unclassified/newUnderlinedButtonMorph.st A FontChooser.package/AbstractFontSelectorDialogWindow.class/instance/font description/fontSize.st A FontChooser.package/AbstractFontSelectorDialogWindow.class/instance/instance creation/newBoldButtonMorph.st A FontChooser.package/AbstractFontSelectorDialogWindow.class/instance/instance creation/newFontFamilyMorph.st A FontChooser.package/AbstractFontSelectorDialogWindow.class/instance/instance creation/newFontSizeMorph.st A FontChooser.package/AbstractFontSelectorDialogWindow.class/instance/instance creation/newFontStyleButtonRowMorph.st A FontChooser.package/AbstractFontSelectorDialogWindow.class/instance/instance creation/newItalicButtonMorph.st A FontChooser.package/AbstractFontSelectorDialogWindow.class/instance/instance creation/newStruckOutButtonMorph.st A FontChooser.package/AbstractFontSelectorDialogWindow.class/instance/instance creation/newTextPreviewMorph.st A FontChooser.package/AbstractFontSelectorDialogWindow.class/instance/instance creation/newUnderlinedButtonMorph.st R FontChooser.package/FreeTypeFontSelectorDialogWindow.class/instance/as yet unclassified/newFontStyleButtonRowMorph.st A FontChooser.package/FreeTypeFontSelectorDialogWindow.class/instance/instance creation/newFontStyleButtonRowMorph.st A Polymorph-Widgets.package/AboutDialogWindow.class/instance/actions/newButtons.st R Polymorph-Widgets.package/AboutDialogWindow.class/instance/as yet unclassified/newButtons.st A Polymorph-Widgets.package/ColorSelectorDialogWindow.class/instance/accessing/alpha.st A Polymorph-Widgets.package/ColorSelectorDialogWindow.class/instance/accessing/alpha_.st A Polymorph-Widgets.package/ColorSelectorDialogWindow.class/instance/accessing/brightness.st A Polymorph-Widgets.package/ColorSelectorDialogWindow.class/instance/accessing/brightness_.st A Polymorph-Widgets.package/ColorSelectorDialogWindow.class/instance/accessing/colorSelected_.st A Polymorph-Widgets.package/ColorSelectorDialogWindow.class/instance/accessing/hue.st A Polymorph-Widgets.package/ColorSelectorDialogWindow.class/instance/accessing/hue_.st A Polymorph-Widgets.package/ColorSelectorDialogWindow.class/instance/accessing/saturation.st A Polymorph-Widgets.package/ColorSelectorDialogWindow.class/instance/accessing/saturation_.st A Polymorph-Widgets.package/ColorSelectorDialogWindow.class/instance/actions/defaultLabel.st A Polymorph-Widgets.package/ColorSelectorDialogWindow.class/instance/actions/newColorComponentFieldMorph_.st A Polymorph-Widgets.package/ColorSelectorDialogWindow.class/instance/actions/newColorPickerButtonMorph.st A Polymorph-Widgets.package/ColorSelectorDialogWindow.class/instance/actions/newColorPresenterMorph.st A Polymorph-Widgets.package/ColorSelectorDialogWindow.class/instance/actions/newContentMorph.st A Polymorph-Widgets.package/ColorSelectorDialogWindow.class/instance/actions/newHSVAColorSelectorMorph.st A Polymorph-Widgets.package/ColorSelectorDialogWindow.class/instance/actions/pickColor.st R Polymorph-Widgets.package/ColorSelectorDialogWindow.class/instance/as yet unclassified/alpha.st R Polymorph-Widgets.package/ColorSelectorDialogWindow.class/instance/as yet unclassified/alpha_.st R Polymorph-Widgets.package/ColorSelectorDialogWindow.class/instance/as yet unclassified/blue.st R Polymorph-Widgets.package/ColorSelectorDialogWindow.class/instance/as yet unclassified/blue_.st R Polymorph-Widgets.package/ColorSelectorDialogWindow.class/instance/as yet unclassified/brightness.st R Polymorph-Widgets.package/ColorSelectorDialogWindow.class/instance/as yet unclassified/brightness_.st R Polymorph-Widgets.package/ColorSelectorDialogWindow.class/instance/as yet unclassified/colorSelected_.st R Polymorph-Widgets.package/ColorSelectorDialogWindow.class/instance/as yet unclassified/defaultLabel.st R Polymorph-Widgets.package/ColorSelectorDialogWindow.class/instance/as yet unclassified/green.st R Polymorph-Widgets.package/ColorSelectorDialogWindow.class/instance/as yet unclassified/green_.st R Polymorph-Widgets.package/ColorSelectorDialogWindow.class/instance/as yet unclassified/hue.st R Polymorph-Widgets.package/ColorSelectorDialogWindow.class/instance/as yet unclassified/hue_.st R Polymorph-Widgets.package/ColorSelectorDialogWindow.class/instance/as yet unclassified/newColorComponentFieldMorph_.st R Polymorph-Widgets.package/ColorSelectorDialogWindow.class/instance/as yet unclassified/newColorPickerButtonMorph.st R Polymorph-Widgets.package/ColorSelectorDialogWindow.class/instance/as yet unclassified/newColorPresenterMorph.st R Polymorph-Widgets.package/ColorSelectorDialogWindow.class/instance/as yet unclassified/newContentMorph.st R Polymorph-Widgets.package/ColorSelectorDialogWindow.class/instance/as yet unclassified/newHSVAColorSelectorMorph.st R Polymorph-Widgets.package/ColorSelectorDialogWindow.class/instance/as yet unclassified/pickColor.st R Polymorph-Widgets.package/ColorSelectorDialogWindow.class/instance/as yet unclassified/red.st R Polymorph-Widgets.package/ColorSelectorDialogWindow.class/instance/as yet unclassified/red_.st R Polymorph-Widgets.package/ColorSelectorDialogWindow.class/instance/as yet unclassified/saturation.st R Polymorph-Widgets.package/ColorSelectorDialogWindow.class/instance/as yet unclassified/saturation_.st A Polymorph-Widgets.package/ColorSelectorDialogWindow.class/instance/coloring/blue_.st A Polymorph-Widgets.package/ColorSelectorDialogWindow.class/instance/coloring/green_.st A Polymorph-Widgets.package/ColorSelectorDialogWindow.class/instance/coloring/red_.st A Polymorph-Widgets.package/ColorSelectorDialogWindow.class/instance/constants/blue.st A Polymorph-Widgets.package/ColorSelectorDialogWindow.class/instance/constants/green.st A Polymorph-Widgets.package/ColorSelectorDialogWindow.class/instance/constants/red.st R Polymorph-Widgets.package/DenyDialogWindow.class/instance/as yet unclassified/icon.st A Polymorph-Widgets.package/DenyDialogWindow.class/instance/visual properties/icon.st A SUnit-Core.package/TestResult.class/class/exceptions/warning.st M SUnit-Core.package/TestResult.class/instance/running/runCase_.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script24.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40024.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Spec-Inspector.package/EyeAbstractInspector.class/definition.st A Spec-Inspector.package/EyeAbstractInspector.class/instance/accessing/text.st M Spec-Inspector.package/EyeInspector.class/definition.st R Spec-Inspector.package/EyeInspector.class/instance/accessing/text.st M Spec-Inspector.package/EyeMethodEditor.class/definition.st R Spec-Inspector.package/EyeMethodEditor.class/instance/accessing/text.st M Spec-Inspector.package/EyeMorphViewer.class/class/spec/inspectorSpec.st M Spec-Inspector.package/EyeMorphViewer.class/instance/event-handling/objectChanged.st M Spec-Inspector.package/EyeTreeInspector.class/definition.st R Spec-Inspector.package/EyeTreeInspector.class/instance/accessing/text.st Log Message: ----------- 40024 13308 MNU in EyeMorphViewer https://pharo.fogbugz.com/f/cases/13308 13242 SUnit shows wrong test result when Warning subclass signals on a test case method https://pharo.fogbugz.com/f/cases/13242 13340 tiny recategorization of uncategorised methods https://pharo.fogbugz.com/f/cases/13340 http://files.pharo.org/image/40/40024.zip

June 18, 2014

Re: [Pharo-dev] Connecting ZnLogEvents to SystemLogger or Beacon

by Tudor Girba

Hi, On Wed, Jun 18, 2014 at 1:38 PM, Norbert Hartl <norbert(a)hartl.name> wrote: > > Am 18.06.2014 um 12:39 schrieb Tudor Girba <tudor(a)tudorgirba.com>: > > Hi Sven, > > Thanks for pushing this. > > For Beacon, you do not need the wrapper because that is meant for other > objects that are not announcements. If you use the Wrapper you lose the > type of the event. So, the integration can be even simpler and more > powerful: > ZnLogEvent announcer > when: ZnLogEvent > do: [ :each | each log ] > for: #beacon. > > Afterwards, we can listen to specific events only by using the > Announcement filtering mechanism. > > Taking a step back, indeed it is easy to write the code to integrate but > it comes at the cost of indirection. Specifically for logging we want the > overhead to be as cheap as possible, and for this reason, we want the > integration to be as tight as possible. > > If we look at it, all these three solutions have identical structure: > - there is an event (Log, Announcement) > - there is something like a broker through which the events are being > triggered (LogDispatcher, Beacon, ZnLogEvent announcer) > - there are bindings that do something concrete with the events (Logger, > BoundedBeacon, AnnouncementSpy) > > In the case of using Announcements, we can just have support for a central > announcer in the image and the integration would be even tighter. For > example, if ZnLogEvent would use this global announcer, rather than its own > global announcer, it would be cheaper. > > > Cheaper in which aspect? Did you test? If you have one central announcer > that has 10 listeners attached what is cheaper than? Every subscription has > to be tested for every event. Listening to you and Sven I got the idea that > localized announcers could be better. I could compose the announcers Iâm > interested in into a central composer and ignore stuff Iâm not interested > in. Itâs about tradeoffs. > Having to send the same announcement twice is certainly worse than sending it only once :). I completely agree that allowing for cheap localized announcers is the way to go. The central one is just a convenience so that I can write "Signal log", nothing more. This is exactly the reason why I argue that going the route of announcers is better because we will have more and more of them, and we will benefit from all the analysis tooling that we can build on top for many different use cases. > So, I think the main thing is just to agree on the transmission mechanism. > As we have Announcements already, the question is why implement another > one? Or, if it is a nail, perhaps a hammer is the right thing to use :) > > The transmission mechanism ist the only thing we are talking about. If you > install an central announcer it isnât much different to the LogDispatcher. > That is what I try to show in the list above (in the parentheses I listed the corresponding concepts in the various implementations). All approaches have the same structure. We are just talking about the transmission :). > So this is a lot of discussion for a single aspect. > This is not a secondary one. As I said, you will get more and more announcers and announcements. We can capitalize on that beautifully. For example, Sven used the AnnouncementSpy for his use case without any cost. This shows that the concepts are the same and we should capitalize on that. I think supporting popular use cases is even more important. I still had no > time to look at all the code but I would be interested how real use cases > are done with your approach. > I would be interested in a list of what people consider popular use cases as well. > I have one LogDispatcher with to Loggers: one syslog logger and one custom > logger. The syslog logger events need a log level and a tag assigned. > I consider that level and tags are not needed. > The custom logger takes events converts them to json and transmits them to > another image via http. > Great. We certainly need this kind of effort. Can you point me to this code so that I can try to implement it in Beacon to see how it looks like? > So I guess the main difficulty lays in the distribution and filtering of > events and not only in the best way to get it out of the own code. > I agree that it is challenging and that we need work there, but I would not dismiss the basics :). Doru > Norbert > > > > Cheers, > Doru > > > > On Wed, Jun 18, 2014 at 11:15 AM, Sven Van Caekenberghe <sven(a)stfx.eu> > wrote: > >> Hi, >> >> I think we are all pretty much on the same page with how we think logging >> has to be done. In any case, here is the code (one, 1, line of code) that >> connects ZnLogEvent with either SystemLogger or Beacon - provided I >> understood everything correctly. >> >> ZnLogEvent announcer >> when: ZnLogEvent >> do: [ :each | BasicLog message: each ] >> for: #systemLogger. >> >> ZnLogEvent announcer >> when: ZnLogEvent >> do: [ :each | WrapperSignal log: each ] >> for: #beacon. >> >> Now this is using a wrapper object, BasicLog and WrapperSignal >> respectively. It even seems to work without the wrapping as well. >> >> ZnLogEvent announcer >> when: ZnLogEvent >> do: [ :each | LogDispatcher current addLog: each ] >> for: #systemLogger. >> >> ZnLogEvent announcer >> when: ZnLogEvent >> do: [ :each | Beacon announce: each ] >> for: #beacon. >> >> Question is, is the wrapping needed ? For the implementation or for the >> user ? Right now, only a timestamp is added. As I indicated before, I don't >> think that even 'forcing' a particular timestamp is a good idea. Here is my >> reasoning. >> >> Log events arrive in a certain order and that order should be maintained. >> Making log events sortable could be nice to have, but it is not 100% >> necessary. The same goes for uniquely identifying log events, nice to have >> but not necessary. >> >> A timestamp might seem like a good idea for both properties, but it is >> not. Consider: >> >> (Array streamContents: [ :set | 1000 timesRepeat: [ set nextPut: >> DateAndTime now ] ]) asSet. >> >> The set will contain only a couple of instances. And this is for the most >> precise timing that we currently have. It is also easy to think of >> alternatives for DateAndTime that some people might prefer: just Time, >> seconds, micro or milliseconds since a reference, ZTimestamp (which I use >> in other code), some class from Chronos, whatever. Features, abstraction, >> performance, precision, memory consumption are all different. >> >> But regardless of clock precision, I think an id is useful as a secondary >> sort or identity criterium, just in case. But again, I would not require it. >> >> On the other hand, we need common protocol. What about the following: >> each log event object should implement #timestamp, which has to return a >> Magnitude compatible object so that increasing values conform with the >> order of the events (but not necessarily vice versa). >> >> Sven >> >> >> >> > > > -- > www.tudorgirba.com > > "Every thing has its own flow" > > > -- www.tudorgirba.com "Every thing has its own flow"

June 18, 2014