May 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] thanks for pharoconf

by Usman Bhatti

On Sun, May 27, 2012 at 12:58 PM, phil(a)highoctane.be <phil(a)highoctane.be>wrote: > Yes, very interesting, motivating, and results producing! > > Thanks a ton for making it a reality. > > Two blog posts of mine just in case you are interested: > > http://philippeback.be/2012/05/first-day-of-pharoconf-in-lille/ > http://philippeback.be/2012/05/second-day-at-pharoconf-in-lille/ > Thanx for the post, Phil. It was nice talking to you and other people at Pharo conf. Igor rightly mentioned that the conference was a moral booster for all of us... Now back to work. Usman Bhatti (I hope you dont forget my name anymore :-) > > Thanks again! > > Philippe Back > > 2012/5/27 Norbert Hartl <norbert(a)hartl.name> > >> Yes, >> >> was fun to see a lot of you. And I could add some new faces to my >> inventory. Great! >> >> Norbert >> >> Am 27.05.2012 um 00:12 schrieb Tudor Girba: >> >> > Hi, >> > >> > I had a good time at PharoConf. >> > >> > Thanks for organizing it. >> > >> > Cheers, >> > Doru >> > >> > >> > -- >> > www.tudorgirba.com >> > >> > "Beauty is where we see it." >> > >> > >> > >> > >> >> >> > > > -- > Philippe Back > "Helping you hit the top 3 outcomes you really want to achieve" > > Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail: phil(a)highoctane.be| Web: > http://philippeback.eu | Blog: > http://philippeback.be > > High Octane SPRL > rue cour Boisacq 101 > 1301 Bierges > >

May 27, 2012

Re: [Pharo-project] class message

by Igor Stasenko

On 27 May 2012 21:04, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > >> >> >> So questions: >> >> >> Is ProtoObject should implement #class? >> >> >> Can we move #class method from Object to ProtoObject? >> >> >> >> >> > >> >> > ups....good catch! indeed, we should move it to ProtoObject. >> >> > >> >> mm.. why? >> > >> > >> > Because ALL objects do have a class. Right? if you want to change the >> > semantics of #class then just subclass and change it. >> >> mmm.. no. >> IMO, in pure sense, all objects having behavior. but behavior is not a >> class (and we can even have >> two classes to discriminate between them). >> yes, it is _almost_ a class.. but much more obscure.. i doesn't needs to >> be compatible with Class protocol.. You should know pretty well, what >> requirements VM side puts >> for a valid behavior: - superclass, methoddict, format. >> which enables VM to do method lookup and creating an instances. >> >> now, if you make ProtoObject to answer message #class, one will assume >> that >> the object it answers should conform to a full-fledged Class protocol. >> But of course it should not. >> >> Maybe i nitpicking about terminology.. but i think at that level we >> should make it clear: >> - all objects having behavior! >> - some object's behaviors are Classes >> - some object's behaviors are Metaclasses >> - but there could be any other. >> > > I agree with all that. But as you said, I think you are going too low level > in details. > For example, I would call class to all your previous list. All objects have > a class, which can be Class, Metaclass, whatever. > In addition, if we don't add #class in ProtoObject, then there are some of > broken messages like #cannotInterpret: and #pointsTo since they send #class > to self. > okay i agree. i just don't like that in case of ProtoObject the name of a message is a bit misleading, while perfectly ok for Object. Maybe we should state that in method comment, that only instances of Object and its subclasses are guarantee that answer of #class message are Class.. for ProtoObject (or its direct descendant) is can be anything. > > -- > Mariano > http://marianopeck.wordpress.com > -- Best regards, Igor Stasenko.

May 27, 2012

Re: [Pharo-project] [Pharo-users] Zinc/Zodiac Documentation

by StÃ©phane Ducasse

thanks Sven. I have nearly finish to read the zinc chapter. Great contents. I would like to create diagram and others for the book version but no time right now. Stef On May 27, 2012, at 7:34 PM, Sven Van Caekenberghe wrote: > Hi, > > > Now that I have recovered from the intensive Pharo Conference, I found the time to publish the Zinc and Zodiac documentation. > > The two main websites have been updated: > > http://zn.stfx.eu > http://zdc.stfx.eu > > My slides are here > > http://zn.stfx.eu/zn/zn-talk-pharo-conference.pdf > http://zdc.stfx.eu/zdc-talk-pharo-conference.pdf > > The documentation (as Pharo Conference paper and draft chapter for Pharo By Example 2) are here > > http://zn.stfx.eu/zn/zinc-http-components-paper.html > http://zdc.stfx.eu/zodiac-paper.html > > For some inexplicable reason, Google Chrome is extremely slow doing the syntax highlighting on the long Zn paper/chapter, so here is an alternative version > > http://zn.stfx.eu/zn/zinc-http-components-paper.no-js.html > > > Enjoy! > > > Sven > > > -- > Sven Van Caekenberghe > http://stfx.eu > Smalltalk is the Red Pill > > > > >

May 27, 2012

Re: [Pharo-project] [Pharo-users] [ANN] Fuel Release Version 1.8

by Mariano Martinez Peck

Fuel works out of the box in Pharo from 1.1 up to 2.0 (checked at > #20094). Please check our documentation [2] for complete installation > and use guides Martin told me something by private email that I think is worth to mention. Not sure if you read it carefully, but Fuel is working from Pharo version 1.1 up to 2.0!!! One of reasons is to help people migrate to new Pharo versions by using Fuel as a way of moving data. Cheers . > > Below, there are some remarkable changes. > > - Much more complete user guides. > - Improved API for customizing how graph is traced. > - FuelMetalevel: serialization of stuff like classes and compiled > methods moved to an optional package. > - Customize objects to be treated as globals. > - Migrations: declare at materialization time class and variables renames. > - Weak references properly managed. Thanks to Juan Vuletich and Levente. > - Thanks Pavel for helping us improving FuelPackageLoader with > wonderful ideas and bug reports. > - Serialization speed up on large graphs by using specialized > collections. Thanks Levente. > - Encoder and Decoder: new reifications that clarify the design. > Thanks Colin Putney. > - Optimized serialization of "clean" BlockClosures, which don't need > the whole stack of contexts. Thanks Juan Vuletich and Eliot Miranda. > - Added a clear error hierarchy. > - Debug facilities, including graph visualization using Roassal. > Thanks Alexandre and Doru. > - Many more new tests. Including those from extension packages, we > have almost 600 tests. > - Repository moved from 'http://www.squeaksource.com/Fuel' to > 'http://ss3.gemstone.com/ss/Fuel'. > > If you are a Fuel user we are not aware of, please let us know! > > Best regards, > Martin and Mariano > > [1]: http://rmod.lille.inria.fr/web/pier/software/Fuel > [2]: > http://rmod.lille.inria.fr/web/pier/software/Fuel/Version1.8/Documentation > > -- Mariano http://marianopeck.wordpress.com

May 27, 2012

Re: [Pharo-project] class message

by Mariano Martinez Peck

> >> >> So questions: > >> >> Is ProtoObject should implement #class? > >> >> Can we move #class method from Object to ProtoObject? > >> >> > >> > > >> > ups....good catch! indeed, we should move it to ProtoObject. > >> > > >> mm.. why? > > > > > > Because ALL objects do have a class. Right? if you want to change the > > semantics of #class then just subclass and change it. > > mmm.. no. > IMO, in pure sense, all objects having behavior. but behavior is not a > class (and we can even have > two classes to discriminate between them). > yes, it is _almost_ a class.. but much more obscure.. i doesn't needs to > be compatible with Class protocol.. You should know pretty well, what > requirements VM side puts > for a valid behavior: - superclass, methoddict, format. > which enables VM to do method lookup and creating an instances. > > now, if you make ProtoObject to answer message #class, one will assume that > the object it answers should conform to a full-fledged Class protocol. > But of course it should not. > > Maybe i nitpicking about terminology.. but i think at that level we > should make it clear: > - all objects having behavior! > - some object's behaviors are Classes > - some object's behaviors are Metaclasses > - but there could be any other. > > I agree with all that. But as you said, I think you are going too low level in details. For example, I would call class to all your previous list. All objects have a class, which can be Class, Metaclass, whatever. In addition, if we don't add #class in ProtoObject, then there are some of broken messages like #cannotInterpret: and #pointsTo since they send #class to self. -- Mariano http://marianopeck.wordpress.com

May 27, 2012

Re: [Pharo-project] Halt using UnhandledError: bad idea

by Igor Stasenko

On 27 May 2012 19:16, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>> >>> >>>> hi, i just discovered that Halt signals the exception as unhandled one.. >>>> >>>> which, in own turn makes announcers who using on:fork: to _fork_ the process, >>>> so when debugger opens you don't see who sent the announcement since >>>> the bottom stack frame is #on:fork: >>> >>> Excellent this would also explains some strange behavior we got when putting halt in repackage tests. >>> >>>> Now if you change >>>> >>>> Halt>>defaultAction >>>> >>>> Â Â Â ^ UIManager default unhandledErrorDefaultAction: self >>>> >>>> " Â Â UnhandledError signalForException: self " >>>> >>>> things is much better, since i can see whole stackâ¦ >>> >>> Can you open a bug entry? and I will handle it once I authorize myself to hack. >>> >> ok > > > clearly a bug fix for 20 an 1.4 > i added the bug entry > > -- Best regards, Igor Stasenko.

May 27, 2012

[Pharo-project] Zinc/Zodiac Documentation

by Sven Van Caekenberghe

Hi, Now that I have recovered from the intensive Pharo Conference, I found the time to publish the Zinc and Zodiac documentation. The two main websites have been updated: http://zn.stfx.eu http://zdc.stfx.eu My slides are here http://zn.stfx.eu/zn/zn-talk-pharo-conference.pdf http://zdc.stfx.eu/zdc-talk-pharo-conference.pdf The documentation (as Pharo Conference paper and draft chapter for Pharo By Example 2) are here http://zn.stfx.eu/zn/zinc-http-components-paper.html http://zdc.stfx.eu/zodiac-paper.html For some inexplicable reason, Google Chrome is extremely slow doing the syntax highlighting on the long Zn paper/chapter, so here is an alternative version http://zn.stfx.eu/zn/zinc-http-components-paper.no-js.html Enjoy! Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

May 27, 2012

Re: [Pharo-project] Halt using UnhandledError: bad idea

by StÃ©phane Ducasse

>> >> >>> hi, i just discovered that Halt signals the exception as unhandled one.. >>> >>> which, in own turn makes announcers who using on:fork: to _fork_ the process, >>> so when debugger opens you don't see who sent the announcement since >>> the bottom stack frame is #on:fork: >> >> Excellent this would also explains some strange behavior we got when putting halt in repackage tests. >> >>> Now if you change >>> >>> Halt>>defaultAction >>> >>> ^ UIManager default unhandledErrorDefaultAction: self >>> >>> " UnhandledError signalForException: self " >>> >>> things is much better, since i can see whole stackâ¦ >> >> Can you open a bug entry? and I will handle it once I authorize myself to hack. >> > ok clearly a bug fix for 20 an 1.4

May 27, 2012

Re: [Pharo-project] Halt using UnhandledError: bad idea

by StÃ©phane Ducasse

Ok I got it and we agree :) >> hi, i just discovered that Halt signals the exception as unhandled one.. >> >> which, in own turn makes announcers who using on:fork: to _fork_ the process, >> so when debugger opens you don't see who sent the announcement since >> the bottom stack frame is #on:fork: > > Excellent this would also explains some strange behavior we got when putting halt in repackage tests. > >> Now if you change >> >> Halt>>defaultAction >> >> ^ UIManager default unhandledErrorDefaultAction: self >> >> " UnhandledError signalForException: self " >> >> things is much better, since i can see whole stackâ¦ > > Can you open a bug entry? and I will handle it once I authorize myself to hack. > > >> >> I find it strange, why to open debugger with halt, one must signal >> other exception (which is UnhandledError)? > > I did not get the previous sentence but you will explain it to me. > When I put halt in the code I want to get a chance to open a debugger? > >> UnhandledError ~~ Halt!!! > > >

May 27, 2012

Re: [Pharo-project] Halt using UnhandledError: bad idea

by Igor Stasenko

On 27 May 2012 18:18, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > >> hi, i just discovered that Halt signals the exception as unhandled one.. >> >> which, in own turn makes announcers who using on:fork: to _fork_ the process, >> so when debugger opens you don't see who sent the announcement since >> the bottom stack frame is #on:fork: > > Excellent this would also explains some strange behavior we got when putting halt in repackage tests. > >> Now if you change >> >> Halt>>defaultAction >> >> Â Â Â ^ UIManager default unhandledErrorDefaultAction: self >> >> " Â Â UnhandledError signalForException: self " >> >> things is much better, since i can see whole stackâ¦ > > Can you open a bug entry? and I will handle it once I authorize myself to hack. > ok > >> >> I find it strange, why to open debugger with halt, one must signal >> other exception (which is UnhandledError)? > > I did not get the previous sentence but you will explain it to me. > When I put halt in the code I want to get a chance to open a debugger? > right. But Halt is separate exception by own, so why wrapping it with UnhandledError, instead of passing it straightly to debugger? You know, when i found that putting halt forcing #on:fork: to cut the stack, i was thinking that Halt is a subclass of Error but its not, which is right. The following code should not answer true: err := false. [ self halt ] on: UnhandledError do: [ :ex | err := true ]. err it should halt instead. Because otherwise you cannot debug a code which has an UnhandledError handler. -- Best regards, Igor Stasenko.

May 27, 2012