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

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

Re: [Pharo-project] thanks for pharoconf

by Mariano Martinez Peck

On Sun, May 27, 2012 at 6:01 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 27 May 2012 12:58, 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/ > > > > nice posts :) > Hehe.. Sorry for killing your brain, Phil :) > > I hope someday to work on something which everyone can understand and > follow. > hahahah great quote. > But before that, we should build an infrastructure, good enough to > make things simple.. > > +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!" :) > > > Thanks again! > > > > Philippe Back > > > > > -- > Best regards, > Igor Stasenko. > > -- Mariano http://marianopeck.wordpress.com

May 27, 2012

Re: [Pharo-project] [Vm-dev] Re: VM problem?

by Mariano Martinez Peck

> More than that, since CompiledMethod redefines #=, it is strange that > it's not redefines #hash as well, > because it is one of requirements to make sure they are always in sync. > > indeed! > > > Two conclusions: > > > > The solution is to define CompiledMethod>hash such that it does not > access bytes < initialPC. The hash it is inheriting from ByteArray is fine > for ByteArray but not at all OK for CompiledMethod. > > > Yes, i would just do > > self methodClass hash bitXor: self selector hash > > that's one possibility. If we want to continue with the previous kind of hash we also could do something like: CompiledMethod >> hash "#hash is implemented, because #= is implemented" ^self class hashBytes: self bytecodes startingWith: self species hash CompiledMethod >> bytecodes | initialPC endPC bytecodes | initialPC := self initialPC. endPC := self endPC. bytecodes := ByteArray new: (endPC - initialPC + 1). initialPC to: endPC do: [:index | bytecodes at: (index - initialPC + 1) put: (self at: index) ]. ^ bytecodes I am not a hashing expert. What do you think? which impl should we do? -- Mariano http://marianopeck.wordpress.com

May 27, 2012

Re: [Pharo-project] class message

by StÃ©phane Ducasse

excellent! I love milestones (metacello) just for that. On May 27, 2012, at 5:25 PM, Denis Kudriashov wrote: > Ok. > > Now I just fix SMock by adding #class method. > And I publish new ConfigurationOfMocketry to squeaksource/MetacelloRepository. > All tests green >

May 27, 2012

Re: [Pharo-project] thanks for pharoconf

by Igor Stasenko

On 27 May 2012 12:58, 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/ > Hehe.. Sorry for killing your brain, Phil :) I hope someday to work on something which everyone can understand and follow. But before that, we should build an infrastructure, good enough to make things simple.. > Thanks again! > > Philippe Back > -- Best regards, Igor Stasenko.

May 27, 2012

[Pharo-project] Halt using UnhandledError: bad idea

by Igor Stasenko

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: Now if you change Halt>>defaultAction ^ UIManager default unhandledErrorDefaultAction: self " UnhandledError signalForException: self " things is much better, since i can see whole stack... I find it strange, why to open debugger with halt, one must signal other exception (which is UnhandledError)? UnhandledError ~~ Halt!!! -- Best regards, Igor Stasenko.

May 27, 2012

Re: [Pharo-project] class message

by Denis Kudriashov

Ok. Now I just fix SMock by adding #class method. And I publish new ConfigurationOfMocketry to squeaksource/MetacelloRepository. All tests green

May 27, 2012