June 2014 - Pharo-dev - lists.pharo.org

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

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

by Tudor Girba

Hi, On Wed, Jun 18, 2014 at 12:20 PM, Norbert Hartl <norbert(a)hartl.name> wrote: > Sven, > Am 18.06.2014 um 11:15 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: > > > 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. > > > You can do that. Iâd prefer using âeach asLogâ instead of âBasicLog > message: eachâ. This way each can specify its desired wrapper class. I like it that each Object can define its log event representation. In Beacon I have the same (asBeaconSignal), but I did not really considered the idea of using it for having other types of events choose the type of log events. > > 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. > > The wrapping does two things. It adds additional state to form a log > object and it adds the behaviour for simplifying the use of a log object > (e.g. have a look at BasicLog>>#emit) . To me the timestamp in a log is > mandatory. That is IMHO what it makes a log. I agree that we should decide on a way to specify time. I also find it to be essential to the logging domain. I like the timestamp proposal. See below. > Without I would call it âan objectâ. Actually, I would call it an announcement because I consider logging to made of two things: - announcing the event - at a given moment in time > > 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. > I was intrigued by this the first time Sven mentioned this, but I made peace with it in the meantime :). > A timestamp might seem like a good idea for both properties, but it is > not. > I agree that the timestamp is not for ordering, but for managing time. Of course, we could see time as being relative, which in distributed systems makes even more sense, but log events are events in time, but I still consider that a time representation is an essential thing in this domain. I think the only disagreement is on how to model time (see below). > 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. > Agreed. > I donât see a problem here. The timestamp is either a visual help here or > if it is more important you need to make sure the precision does cope with > your use case. A timestamp might be just a grouping thing to focus more > easy on the entries of interest. Iâm not sure it is definable for all use > cases. If the order is important than we need to make sure the order is > preserved. To pull out an edge case to proof it is of no value is nothing I > can submit to. That is indeed an interesting point of view, see below. > > 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. > > > That is a good point. In the beginning there was only one Log class. It > contained all the stuff like levels, tag and such. That is understandable > because logging is done this way (expected by people) usually and we need > to break free from that (what we do at the moment by introducing object > oriented logging). In my mission to break free from (sys)log I divided the > class in BasicLog and Log. BasicLog is what makes a Log: an object and a > timestamp. The Log class resembles the other fields like level etc. You can > argue that level, tag etc are not needed but a lot of people will need them > so why not support them? > What if you donât need level, tag etc. but you want to have an id and use > another class for timestamp? Thatâs easy just subclass BasicLog, add an id > instVar, initialize timestamp with your own class and then overwrite your > business objects class side method logClass to return your own decorating > class. Thatâs how we always do it, right? And still you could use the stuff > from the workspace by doing > > (SpecialEvent new > foo: âbarâ; > id: 10000 atRandom) asLog emit > > > 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). > > Thatâs basically how it is. We should define the protocol the logger needs > internally. If there needs to be some access to #timestamp it is part of > the interface. So that way we expect an log event object to respond to > #timestamp. And the BasicLog is a wrapper that has a default implementation > for it. I donât understand what we need to define except the interface that > is needed which is obvious? > So letâs take the three use cases: subclassing, wrapping and forced duck > typing. If it works I would support all of them because people have > different ideas how things should work. If that is too much we need to > choose. I personally donât like to have to subclass a framework class > because Iâd like to preserve the inheritance chain for my own stuff. I think that this does not apply well here. I think that what applies for Exceptions and Announcements applies for logging as well. Subclassing makes sense there, and I think it makes sense here, too. You will be unlikely to want to mix events with your domain. > I also donât like forced duck typing because a framework that forces me > to implement a method in every class I want to log is cumbersome to me. I agree as well. > So I like wrapping the most because I can add log specific stuff to any > object and by being able to supply a wrapping class Iâm free to adapt any > object to be a log compatible object. I would not favor wrapping. Doru > > Norbert > > > > > -- www.tudorgirba.com "Every thing has its own flow"

June 18, 2014

Re: [Pharo-dev] Complaints about Spec

by Yuriy Tymchuk

Sent from my iPhone > On 18 Jun 2014, at 12:04, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > Hi Yuriy, > > I can't really comment on the overal questions you are asking. But please keep in mind that Apple's Cocoa has had a little bit more resource behind it, for many decades, of course they have a nice design and excellent documentation. I'm not telling that Spec is bad. In fact I like it. I'm just telling than maybe we should write a tutorial on how to develop UI in Pharo. Uko > > I actually have a calculator project which contains a Spec GUI and Seaside GUI on the same model ready, with shared unit tests at the model and both GUI levels. I even use some kind of meta spec to generate both GUIs automatically. My goal is to write a Pharo tutorial about that. But I need more time (I haven't started yet). I'll see what I can do. > > Overall, although Spec is new to me, I found it acceptable for building functional GUIs. > > Sven > >> 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] Connecting ZnLogEvents to SystemLogger or Beacon

by Norbert Hartl

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. > > 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. So this is a lot of discussion for a single aspect. 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 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. The custom logger takes events converts them to json and transmits them to another image via http. 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. 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"

June 18, 2014