- Pharo-dev - lists.pharo.org

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

Re: [Pharo-project] class message

by Igor Stasenko

On 27 May 2012 14:46, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > > > On Sun, May 27, 2012 at 2:31 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >> On 27 May 2012 11:40, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: >> > >> > >> > On Sun, May 27, 2012 at 11:02 AM, Denis Kudriashov >> > <dionisiydk(a)gmail.com> >> > wrote: >> >> >> >> I found problem. >> >> >> >> Proxy classes in SMock and Mocketry are subclasses of ProtoObject which >> >> not implements #class. >> >> But proxy classes use "self class" in some methods (like #printOn: >> >> implementation). >> >> >> >> I add #class implementation from Object to ProtoObject and all SMock >> >> and >> >> Mocketry tests become green. >> >> >> >> 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. > This is not the real reason, but in addition because since previously #class > used to have a special bytecode, it means it was understood by "everybody". > So at least with this we don't break anything. > For me it does not make sense to get a #dnu for #class when the object > really has a class. > >> >> the more we put to ProtoObject, the more it looks like Object. >> at some point you will see not difference between them, and then >> someone will come >> with a brilliant idea of having one more "clean" class ahead - >> ProtoProtoObject. >> > > You cannot tell that to me ;)Â I was the one who spent 2 days to remove all > the 10 menthods tryNamedPrimitive* from ProtoObject. > yes :) >> >> >> -- >> Best regards, >> Igor Stasenko. >> > > > > -- > Mariano > http://marianopeck.wordpress.com > -- Best regards, Igor Stasenko.

May 27, 2012

Re: [Pharo-project] thanks for pharoconf

by StÃ©phane Ducasse

> +1 > > And thanks to all involved in the conf. I hope that some years in the future I can say "I was present in the first PharoConf!" :) well the second :) The first was organized at Annecy by laurent laffont and herve Verjus. But it was less international :)

May 27, 2012

Re: [Pharo-project] building and installing a morph in the background

by Igor Stasenko

i think there is some mistake in event wiring.. i cannot tell much, because i don't understand the glamour models.. but what i found strange is that i get large pause before i got halt in actOnMatchingPresentationsChanged: it looks like the same event goes twice (or there two kinds of events) and you model tries to update the detal list bypassing (or in addition) to the #actOnMatchingPresentationsChanged: To reproduce my observations try do following: - evaluate the doit which you gave above , so you have two windows open. Now click in a browser list, to set the initial selection. Now go to #actOnMatchingPresentationsChanged and put halt there actOnMatchingPresentationsChanged: anAnnouncement +++ self halt. GLMWatcherWindow uniqueInstance addContent: [ self renderObject: anAnnouncement pane ] Now click on list again to change the selection. You can observe a huge pause before you got halt. So, apparently the logic in #addContent: has nothing to do with the blocking you still observe. (btw in image which you give in link the morph generation is still inside of #addDeferredUIMessage, i , of course moved it outside before trying things). P.S. btw, did i told you that i don't like #suspendAllWhile: in announcer? :) The point is: if you need things like that, then you doing something wrong. -- Best regards, Igor Stasenko.

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. > > 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