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

New Cog & Spur VMs available

by Eliot Miranda

in http://www.mirandabanda.org/files/Cog/VM/VM.r3003/. Apologies for the non-Spur VMs in r3000 which should have had the "relocating call to invalid address" bug fixed but I made a mistake. It is fixed in 3003. Further, those who got crashes running the test suite due to the Aio tests should now find the VM does not crash. CogVM source as per VMMaker.oscog-eem.774/r3003 Remember to regenerate the cogit.c's from the non-Spur configurations to fix the "relocating call to invalid address" bug. Add a hack to link the XDisplayControlPlugin against vm-display-X11 (a hack because it assumes paths etc). But at least the plugin works. Add an initial revision of platforms/unix/plugins/UUIDPlugin/acinclude.m4 to search for uuid.h in either /usr/include/uuid or /usr/include and use either uuidgenerate or uuidgen. -- best, Eliot

June 16, 2014

Re: [Pharo-dev] [Moose-dev] [ann] beacon - a slim announcement-based logging engine

by Alexandre Bergel

Well written, as always :-) Alexandre On Jun 15, 2014, at 9:04 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > I like very much the new energy people are putting into creating the SystemLogger engine for Pharo. I think this is a specifically important area for which we have to have a solution out of the box. At the same time, I also think that Pharo provides an infrastructure that makes room for ideas that are otherwise hard to reach in other languages or environments. > > Stef asked for collaborations around this project, so here is my literally small contribution: a rather different logging engine. It is called Beacon, it is based entirely on Announcements, it has ~200 lines of code, it has no tags or levels, and in my opinion it is fully functional. > > You can see a detailed description here including some informal comparisons with SystemLogger: > http://www.humane-assessment.com/blog/beacon > > Please let me know what you think. I would be happy to join forces to reach a mature solution that is both versatile and that can show how Pharo is different. > > Cheers, > Doru > > -- > www.tudorgirba.com > > "Every thing has its own flow" > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

June 15, 2014

Re: [Pharo-dev] [Moose-dev] [ann] beacon - a slim announcement-based logging engine

by Johan Fabry

That looks very cool! I agree that logging objects is the way to go, and now that we have all this infrastructure we should be able to better make use of object-based logs. I was just thinking about this issue a couple of weeks ago, and beacon might just be the solution for me. I hope to find the time in a few weeks to start using it! On Jun 15, 2014, at 9:04 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > I like very much the new energy people are putting into creating the SystemLogger engine for Pharo. I think this is a specifically important area for which we have to have a solution out of the box. At the same time, I also think that Pharo provides an infrastructure that makes room for ideas that are otherwise hard to reach in other languages or environments. > > Stef asked for collaborations around this project, so here is my literally small contribution: a rather different logging engine. It is called Beacon, it is based entirely on Announcements, it has ~200 lines of code, it has no tags or levels, and in my opinion it is fully functional. > > You can see a detailed description here including some informal comparisons with SystemLogger: > http://www.humane-assessment.com/blog/beacon > > Please let me know what you think. I would be happy to join forces to reach a mature solution that is both versatile and that can show how Pharo is different. > > Cheers, > Doru > > -- > www.tudorgirba.com > > "Every thing has its own flow" > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile

June 15, 2014

Announcer>>#when:send:to:

by Sven Van Caekenberghe

The method Announcer>>#when:send:to: seems new in Pharo 3 (it does exist in Pharo 2, but inherited from Object, doing something else), while the older equivalent Announcer>>#on:send:to: does exist in Pharo 2, but is deprecated in Pharo 3. This poses a problem for x-platform code targeting both platforms. Could Announcer>>#when:send:to: not be backported/added to Pharo 2 ? It is not a major problem, but it is annoying. Sven

June 15, 2014

Re: [Pharo-dev] Survey - needing Protocol Chooser when creating methods from the debugger

by Gabriel Cotelli

I vote for just letting the method unclassified and a test case detecting unclassified methods to not forget classifying the method later On Jun 15, 2014 10:04 AM, "Ben Coman" <btc(a)openinworld.com> wrote: > Just surveying opinion, when pressing the 'Create' (method) button in the > debugger, how critical do people consider the need for the Protocol Chooser > at that time? Personally I find it interrupts my flow, since often I don't > feel comfortable with the conventions to choose which protocol it should go > in. It makes me go searching in another browser to try to determine the > convention from other existing methods. A few options to start with: > 1. Like it just the way it is. > 2. Dump the new method in unclassified and clean up later (plus a protocol > sorting refactoring tool) > 3. Having Protocol Chooser provide a short list of suggestions, perhaps > somehow indicating the rule used and weighting. For example: "accessors > (100 methods matching instance variables)" ; "testing (20 items match 'is' > prefix)"". > btw, In 2.0 the Protocol Chooser came up with a massive list (actually > where this survey question stems from) but in 3.0 the Protocol Chooser > comes up empty for my use cases. Can anyone suggest an example in 3.0 that > populates the Protocol Chooser? > > cheers -ben > > >

June 15, 2014

Re: [Pharo-dev] Brainstorming Pharo4

by Serge Stinckwich

and copy-paste that in playground and CTRL-O will open the Browser ;-) On Sun, Jun 15, 2014 at 2:17 PM, stepharo <stepharo(a)free.fr> wrote: > Soon soon :) > but in this form > > MyClass>>myMethod > [ > ^ 1 + 3 > ] > > ;) > >> >> MyClass>>myMethod "in accessors" >> ^ 1 + 3 >> >> The current System Browser my also be switched to that method at the same >> time, or a new System Browser opened if this is entered from Workspace. I >> see some advantages for this for tutorials, where methods are presented >> using the ">>" convention, and readers might copy-paste the whole code. >> >> cheers -ben >> >> > > -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/

June 15, 2014

Re: [Pharo-dev] Brainstorming Pharo4

by Ben Coman

stepharo wrote: > Soon soon :) > but in this form > > MyClass>>myMethod > [ > ^ 1 + 3 > ] > Glad to hear it. Can you consider some _optional_ way to also specify the protocol. Some random ideas... 1. MyClass>>accessors>>myMethod: anObject 2. MyClass>>'accessors'>>myMethod: anObject 3. MyClass(acccessors)>>myMethod: anObject 4. MyClass"accessors">>myMethod: anObject 5. MyClass^accessors>>myMethod: anObject cheers -ben > ;) >> >> MyClass>>myMethod "in accessors" >> ^ 1 + 3 >> >> The current System Browser my also be switched to that method at the >> same time, or a new System Browser opened if this is entered from >> Workspace. I see some advantages for this for tutorials, where >> methods are presented using the ">>" convention, and readers might >> copy-paste the whole code. >> >> cheers -ben >> >> > > >

June 15, 2014

[experimental/in-progress] Framework agnostic pure object logging for Zinc

by Sven Van Caekenberghe

Hi, Since years, Zinc has been using its own Announcements-based logging mechanism for client and server logging. The payload of the Announcements used was still essentially text based though. In some discussions months ago with Norbert Hartl in the context of his work on SystemLogger, the concept of pure object logging as an alternative to text based logging became an interesting alternative for me. In an internal project that I did earlier this year I tried out this concept for myself and was quite happy with the result. Doru Girba had indicated several times to me that he was also interested in thinking about logging, so when he started talking about Beacon, I decided to write down my ideas a bit in a quick draft: https://github.com/svenvc/docs/blob/master/draft/logging-with-objects.md And to make this even clearer, I had to change Zinc logging to work along these principles. The current #bleedingEdge experimental/in-progress version of Zinc now contains a first working version of 'framework agnostic pure object logging'. The conversion is not yet finished - there is still much to learn here - but it already looks quite nice I think. Monitoring logging output can be done by opening an Announcement Spy. ZnNewLogEvent open. Next you run some code (start a server, do one request, stop the server). (ZnServer defaultOn: 1701) route: #server1; start. ZnClient new clientId: #client1; beOneShot; get: 'http://localhost:1701/random'. ZnServer stopDefault. Which give the following output (using the standard string representation). However, each line is a rich object containing tons of information. Here is the highlighted line in the Explorer. As you can see, all information from during the client and the server's execution is preserved, ready to be used for logging and/or debugging, right now or later on. Nowhere in the main ZnClient or ZnServer logging code is there simple string or text logging, everything being logged by announcing a log event object. I hope that this plays well with both SystemLogger, Beacon and maybe other logging frameworks out there. When I bring this approach more and more in production use, it will most probably evolve further. In the meantime, have a look: I would love feedback. Sven

June 15, 2014

Re: [Pharo-dev] Survey - needing Protocol Chooser when creating methods from the debugger

by Attila Magyar

+1 organization of the protocols is part of refactoring EstebanLM wrote > For me, having to choose a protocol before creating the method is contrary > to TDD spirit of âgo to the green as fast as you can, clean laterâ. > So yes, instead enhance it, I would directly remove the protocol chooser > in that workflowâ¦ -- View this message in context: http://forum.world.st/Survey-needing-Protocol-Chooser-when-creating-methods… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

June 15, 2014

Re: [Pharo-dev] Survey - needing Protocol Chooser when creating methods from the debugger

by Esteban Lorenzano

For me, having to choose a protocol before creating the method is contrary to TDD spirit of âgo to the green as fast as you can, clean laterâ. So yes, instead enhance it, I would directly remove the protocol chooser in that workflowâ¦ Esteban On 15 Jun 2014, at 10:11, Ben Coman <btc(a)openInWorld.com> wrote: > Ben Coman wrote: >> Just surveying opinion, when pressing the 'Create' (method) button in the debugger, how critical do people consider the need for the Protocol Chooser at that time? Personally I find it interrupts my flow, since often I don't feel comfortable with the conventions to choose which protocol it should go in. It makes me go searching in another browser to try to determine the convention from other existing methods. A few options to start with: >> 1. Like it just the way it is. >> 2. Dump the new method in unclassified and clean up later (plus a protocol sorting refactoring tool) >> 3. Having Protocol Chooser provide a short list of suggestions, perhaps somehow indicating the rule used and weighting. For example: "accessors (100 methods matching instance variables)" ; "testing (20 items match 'is' prefix)"". >> btw, In 2.0 the Protocol Chooser came up with a massive list (actually where this survey question stems from) but in 3.0 the Protocol Chooser comes up empty for my use cases. Can anyone suggest an example in 3.0 that populates the Protocol Chooser? > doh! I only needed to start typing to populate the Protocol Chooser. Now it still presents too many choices for my sensibilities. > cheers -ben >

June 15, 2014