- Pharo-dev - lists.pharo.org

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

Re: [Pharo-project] Working directory

by StÃ©phane Ducasse

>> >>> >>> >>> I can hardly see what else can replace a tree/graph-like data >>> organization. >>> >> >> Something entirely unexpected that no one saw coming, no doubt :) >> >> e.g. what does the "current working directory" mean in a system with >> orthogonal persistence? >> > probably nothing. and i don't care. > but if we're working in ecosystem like today, we should make it work right. + 100 make it right and adapt if needed :) > > > > > -- > Best regards, > Igor Stasenko. >

May 27, 2012

Re: [Pharo-project] Working directory

by Igor Stasenko

On 27 May 2012 15:04, Douglas Brebner <squeaklists(a)fang.demon.co.uk> wrote: > On 26/05/2012 23:08, Igor Stasenko wrote: >> >> >> I can hardly see what else can replace a tree/graph-like data >> organization. >> > > Something entirely unexpected that no one saw coming, no doubt :) > > e.g. what does the "current working directory" mean in a system with > orthogonal persistence? > probably nothing. and i don't care. but if we're working in ecosystem like today, we should make it work right. -- Best regards, Igor Stasenko.

May 27, 2012

Re: [Pharo-project] class message

by Mariano Martinez Peck

On Sun, May 27, 2012 at 3:06 PM, Douglas Brebner < squeaklists(a)fang.demon.co.uk> wrote: > On 27/05/2012 13:46, Mariano Martinez Peck wrote: > >> >> Because ALL objects do have a class. Right? >> > > Wasn't one of the reasons for ProtoObject to enable building non-class > (e.g. prototype) object systems? > > I don't know. I though it was for proxies because Object included already too much messages. -- Mariano http://marianopeck.wordpress.com

May 27, 2012

Re: [Pharo-project] class message

by Douglas Brebner

On 27/05/2012 13:46, Mariano Martinez Peck wrote: > > Because ALL objects do have a class. Right? Wasn't one of the reasons for ProtoObject to enable building non-class (e.g. prototype) object systems?

May 27, 2012