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

Re: [Pharo-project] We crossed 5000 closed issues!

by StÃ©phane Ducasse

> Today the bug tracker: > > http://code.google.com/p/pharo/issues/list > > says 436 open out of 5437 issues. > > Thise means we crossed the line of 5000 reports being closed today. We underestimate the amount of work we put in the system :) And this is great to have a way to get reminded that we should just continue. The future is bright :) Stef > > With the first report from damien.cassou, Jun 5, 2008, this translates > to 3.65 reports being taken care of *every* day. > > Marcus > > -- > Marcus Denker -- http://marcusdenker.de > >

March 7, 2012

Re: [Pharo-project] Fuel - class loading issue when superclass changed inst vars

by StÃ©phane Ducasse

I was in another live a CLOS mop expert so I know this hook. Now we should really build a new class builder (and with first class slot) and a nice protocol so that we can think about such issues. This is on my roadmap, I'm just too busy and slow. Stef

March 7, 2012

[Pharo-project] Mouse move and button down events

by Hilaire Fernandes

Hello, I have two embedded morphs: a parent and a child. On the child I want to handle mouse down event, Child>>handlesMouseDown: event ^true On parent I want to handle mouse down+move event: There are not distinct handlesMouseMove, only Parent>>handlesMouseDown: event ^true Now, events received by child handlesMouseDown are always MouseButtonEvent, never MouveMoveEvent, so no chance to answer true or false accordingly. I guess MouseButtonEvent is catched first, then other mouseMove event discarded What I want is the child to received clic events, but the parent move events. It does not seem possible, am I wrong? -- Dr. Geo -- http://www.drgeo.eu

March 7, 2012

Re: [Pharo-project] Fuel - class loading issue when superclass changed inst vars

by Frank Shearar

On 6 March 2012 22:22, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > Hi Frank, > > On Tue, Mar 6, 2012 at 1:49 PM, Frank Shearar <frank.shearar(a)gmail.com> > wrote: >> >> On 6 March 2012 18:27, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >> > >> > >> > On Tue, Mar 6, 2012 at 3:05 AM, Henrik Johansen >> > <henrik.s.johansen(a)veloxit.no> wrote: >> >> >> >> >> >> On Mar 6, 2012, at 12:03 PM, Henrik Johansen wrote: >> >> >> >> >> >> >> > >> >> > Parcels >> >> > - Check a hash based on class layout vs equivalent hash for the >> >> > stored >> >> > method's class (stored with the method). >> >> > If different: >> >> > 1) check for existence of a backwards-compatability reader method, >> >> > hand >> >> > the old instance to it, and expect the old instance to be #become'd >> >> > into >> >> > something current, >> >> > 2) raise an error if no such method exists. >> >> > >> >> > Now, the main problem with this scheme is it's left as an exercise to >> >> > the user to come up with a procedure to ensure said backwards-compat >> >> > reader >> >> > method stays up to date as additional changes are made. >> >> > >> >> > Is it a big problem? >> >> > Depends on your tests, and programmer diligence at any given day. >> >> > >> >> > Added inst vars are not a big deal, as if you forget them, there will >> >> > usually be a nil #DNU somewhere down the line. (or you use lazy >> >> > initialization, and everything works as expected even for existing >> >> > instances) >> >> > >> >> > Removals/reorderings are a bigger issue, as the detection of failure >> >> > (inst vars in wrong slots) are often far removed from the source of >> >> > problems >> >> > (forgetting to update the reader method), >> >> > If seldomly used, it may even go unnoticed until the instance is next >> >> > saved, at which time you're in real trouble (especially if saved >> >> > alongside >> >> > newly created ones, in which case there is no consistency). >> >> > >> >> > In general I think it's an ok scheme, but would like to see a >> >> > solution >> >> > more resilient to user-error. >> >> > How to achieve that is an interesting topic, which I haven't yet >> >> > found >> >> > time to think through as thoroughly as I had wished/intended some >> >> > months >> >> > ago. :( >> >> >> >> Errr, BOSS, not Parcels. >> > >> > >> > Right. What Parcels do is shape-change instances *and* rescan methods to >> > fix >> > up inst var offsets. Â When a parcel is saved the "signature" of classes >> > of >> > instances there-in are saved so that the parcel contains all the inst >> > var >> > names of the class and its superclass. Â If on load the superclass chain >> > has >> > a different set of inst vars then lost inst vars are omitted and added >> > inst >> > vars are nil in the materialized instances. Â If a Parcel contains a full >> > class (not just instances) that has methods, and the superclass chains >> > inst >> > vars have changed Â then these methods are "rescanned" (disassembled, and >> > reassembled, not using the compiler) and inst var offsets are fixed up, >> > missing inst vars getting changed into undeclared variable references (I >> > think; at least this is what *should* happen; its what happens when one >> > removes an inst var that is still referenced from methods). >> > >> > What's missing in the parcel scheme is any hook to allow the user to >> > process >> > shape-changing instances with the values of lost inst vars in hand. >> > Â Presumably there will be cases when those values are essential to any >> > schema migration. Â Personally I would want to decouple schema migration >> > and >> > add it as a post-processing step, which would imply that the >> > materializer >> > would offer a service (materialize in a special mode) where it >> > constructed a >> > dictionary from materialized and shape-changed instance to in parcel >> > state >> > (e.g. an Array of inst var values as they occurred in the parcel). Â Then >> > the >> > materialized instance could be migrated after the fact, with the default >> > behaviour being analogous to what the system does now on class >> > redefinition >> > (values of deleted inst vars are lost, aded inst vars are nil). >> >> This sounds a bit like CLOS' Â UPDATE-INSTANCE-FOR-REDEFINED-CLASS [1], >> which is a generic function (for our purposes just think "something a >> bit like a method") that you define and is invoked by the machinery >> involved in changing/redefining classes. >> >> A colleague told me about this part of CLOS the other day when >> discussing class-based OO: it's the sort of thing we need in at least >> the Browser, so one can change the shape of existing instances and >> ensure the new class invariants are maintained. > > > But Smalltalk has done without this for 40 years. Â It has supported existing > instance redefinition but no-one has felt the need to provide a scheme for > redefinition in the IDE. Â In any case it is relatively trivial to script it, > e.g.: > > | instanceState | > instanceStateÂ := IdentityDictionary new. > myClass allInstancesDo: [:i|Â instanceState at: i put: ((1 > to:Â myClassÂ instSize) collect: [:ivi| i instVarAt: ivi])]. > myClassÂ superclass subclass:Â myClassÂ name instanceVariableNames: myClass > instVarNamesString, ' theExtraInstVar' [...]. > myClass compile: sourceForupdateToNewFormatFrom. > myClass allInstancesDo: [:i| i updateToNewFormatFrom: (instanceState at: i] > > So if and when you need it you can roll your own (and I've never needed it; > but I have wanted the refactoring browser to preserve inst vars on push > up/push dwn). Indeed, it is trivial. Using #allInstancesDo: is exactly what I used when my colleague and I were discussing the issue. The only difference is that _I_ did the migration, not my tools. > However, collections of persistent objects are a different kettle of fish. > Â It is much more likely to need instance migration on load, especially for > library objects that the user is merely using and whose implementation has > evolved over time (e.g. UI elements such as morphs). > >> >> (For instance, for >> "purely functional" objects, you really don't want to use reflection >> to initialise new instvars from outside the object.) > > > But the class builder uses an unprotected interface (instVarAt: and > instVarAt:put:). Â So this turns out not to be an issue. That's exactly to what I was referring: I lump #instVarAt: in the reflection bucket. I realise its _utility_, but it's strong medicine. Which is pretty much why you're pushing mirrors, right? So that some things - the class builder, as an example - can make use of such a (powerful and dangerous) tool while some random library can't. frank >> So you'd change >> the class definition, supply a way of handling the schema migration, >> and then the image would change the class definition and run the >> migration. >> >> frank >> >> [1] http://clhs.lisp.se/Body/f_upda_1.htm >> >> > This reminds me of a bug with the ClassBuilder/RefactoringBrowser >> > combination. Â If one refactors pushing an inst var up to a superclass or >> > down to subclasses, the values of te inst var in instances are lost >> > because >> > the class change is in fact done as two changes, a deletion followed by >> > an >> > addition. Â This again could be fixed in a wrapper, building a dictionary >> > from instance to values, performing the set of class changes, and then >> > restoring the inst var state from the dictionary. >> > >> > >> >> >> >> My bad. >> >> >> >> Cheers, >> >> Henry >> >> >> >> >> > >> > >> > >> > -- >> > best, >> > Eliot >> > >> > > > > -- > best, > Eliot >

March 7, 2012

Re: [Pharo-project] .changes are now 37MBâ¦.

by Craig Latta

> > > And all that in 2 big files that one can only append to because? > > > No idea, actually... > > > > > > I personally think that it is a mistake today to merge all these > > > into one such basic mechanism. Especialy if > > > you look at how complex the code is in the image... it's actually > > > amazing. > > > > Hear hear. I think it's insane to do it (only) this way at this > > point. Objects everywhere... > > > can you elaborate? do what at which point? To use source code written on files to record history information, at this point in history where we have more than enough processor, network, and disk to just use live distributed object memories. I can see keeping the old stuff around for a while as a redundancy mechanism, but we needn't rely on it alone. -C -- Craig Latta www.netjam.org/resume +31 6 2757 7177 + 1 415 287 3547

March 7, 2012

Re: [Pharo-project] Smalltalk as embedded platform/language?

by Igor Stasenko

On 7 March 2012 08:36, Lawson English <lenglish5(a)cox.net> wrote: > On 3/6/12 5:35 PM, Igor Stasenko wrote: >> >> It is very long post, so i decided to put it on my blog. >> >> http://computeradventures.wordpress.com/ >> >> i more or less realizing the scale of changes in order to achieve it, >> but i also wonder why we do not pay attention to this aspect.. >> maybe i miss something, maybe we don't need it at all. or maybe >> there's less painful alternatives... >> > Igor, you're familiar with f-script? > > http://www.fscript.org/ > not really, why asking? I know there's plenty of alternatives.. And how do you see f-script could help us? It is objective-c (or Mac ) oriented. If you would want to use different platform , then what? > Lawson. -- Best regards, Igor Stasenko.

March 7, 2012

Re: [Pharo-project] Smalltalk as embedded platform/language?

by Lawson English

On 3/6/12 5:35 PM, Igor Stasenko wrote: > It is very long post, so i decided to put it on my blog. > > http://computeradventures.wordpress.com/ > > i more or less realizing the scale of changes in order to achieve it, > but i also wonder why we do not pay attention to this aspect.. > maybe i miss something, maybe we don't need it at all. or maybe > there's less painful alternatives... > Igor, you're familiar with f-script? http://www.fscript.org/ Lawson.

March 7, 2012

Re: [Pharo-project] Pharo-Kernel Gofer broken

by Marcus Denker

On Mar 6, 2012, at 10:11 PM, Pavel Krivanek wrote: > Well, the issue that broke Pharo-Kernel is fixed but in meantime > Pharo-Kernel Gofer is on knees again. The reason is that Monticello is > newly dependent on SystemAnnouncements (that comes together with tests > so it is dependent on SUnit and thus cannot be loaded without the next > remodularization). I will fix that. -- Marcus Denker -- http://marcusdenker.de

March 7, 2012

Re: [Pharo-project] XMLRPC on 1.4 using Zinc

by Sven Van Caekenberghe

GermÃ¡n, On 07 Mar 2012, at 00:20, GermÃ¡n Arduino wrote: > Today I had some free time and tried and really was very simple to adapt the client to Zinc, I think is already working (need still to publish and adapt ConfigurationOf*). Good. Let me know when it loads cleanly in Pharo 1.4 and I will certainly have a look. > Now I'm studying a bit the server to adapt the code to ZnServer and eliminate Kom. Then xmlrpc could be also shipped in the image in case of interest. OK. > BTW, very very good code on Zinc, well factored, using patterns, easy to understand, very good job Sven. Thanks, I am glad you like it. Sven

March 7, 2012

Re: [Pharo-project] Fuel - class loading issue when superclass changed inst vars

by Igor Stasenko

On 6 March 2012 23:22, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > Hi Frank, > > On Tue, Mar 6, 2012 at 1:49 PM, Frank Shearar <frank.shearar(a)gmail.com> > wrote: >> >> On 6 March 2012 18:27, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >> > >> > >> > On Tue, Mar 6, 2012 at 3:05 AM, Henrik Johansen >> > <henrik.s.johansen(a)veloxit.no> wrote: >> >> >> >> >> >> On Mar 6, 2012, at 12:03 PM, Henrik Johansen wrote: >> >> >> >> >> >> >> > >> >> > Parcels >> >> > - Check a hash based on class layout vs equivalent hash for the >> >> > stored >> >> > method's class (stored with the method). >> >> > If different: >> >> > 1) check for existence of a backwards-compatability reader method, >> >> > hand >> >> > the old instance to it, and expect the old instance to be #become'd >> >> > into >> >> > something current, >> >> > 2) raise an error if no such method exists. >> >> > >> >> > Now, the main problem with this scheme is it's left as an exercise to >> >> > the user to come up with a procedure to ensure said backwards-compat >> >> > reader >> >> > method stays up to date as additional changes are made. >> >> > >> >> > Is it a big problem? >> >> > Depends on your tests, and programmer diligence at any given day. >> >> > >> >> > Added inst vars are not a big deal, as if you forget them, there will >> >> > usually be a nil #DNU somewhere down the line. (or you use lazy >> >> > initialization, and everything works as expected even for existing >> >> > instances) >> >> > >> >> > Removals/reorderings are a bigger issue, as the detection of failure >> >> > (inst vars in wrong slots) are often far removed from the source of >> >> > problems >> >> > (forgetting to update the reader method), >> >> > If seldomly used, it may even go unnoticed until the instance is next >> >> > saved, at which time you're in real trouble (especially if saved >> >> > alongside >> >> > newly created ones, in which case there is no consistency). >> >> > >> >> > In general I think it's an ok scheme, but would like to see a >> >> > solution >> >> > more resilient to user-error. >> >> > How to achieve that is an interesting topic, which I haven't yet >> >> > found >> >> > time to think through as thoroughly as I had wished/intended some >> >> > months >> >> > ago. :( >> >> >> >> Errr, BOSS, not Parcels. >> > >> > >> > Right. What Parcels do is shape-change instances *and* rescan methods to >> > fix >> > up inst var offsets. Â When a parcel is saved the "signature" of classes >> > of >> > instances there-in are saved so that the parcel contains all the inst >> > var >> > names of the class and its superclass. Â If on load the superclass chain >> > has >> > a different set of inst vars then lost inst vars are omitted and added >> > inst >> > vars are nil in the materialized instances. Â If a Parcel contains a full >> > class (not just instances) that has methods, and the superclass chains >> > inst >> > vars have changed Â then these methods are "rescanned" (disassembled, and >> > reassembled, not using the compiler) and inst var offsets are fixed up, >> > missing inst vars getting changed into undeclared variable references (I >> > think; at least this is what *should* happen; its what happens when one >> > removes an inst var that is still referenced from methods). >> > >> > What's missing in the parcel scheme is any hook to allow the user to >> > process >> > shape-changing instances with the values of lost inst vars in hand. >> > Â Presumably there will be cases when those values are essential to any >> > schema migration. Â Personally I would want to decouple schema migration >> > and >> > add it as a post-processing step, which would imply that the >> > materializer >> > would offer a service (materialize in a special mode) where it >> > constructed a >> > dictionary from materialized and shape-changed instance to in parcel >> > state >> > (e.g. an Array of inst var values as they occurred in the parcel). Â Then >> > the >> > materialized instance could be migrated after the fact, with the default >> > behaviour being analogous to what the system does now on class >> > redefinition >> > (values of deleted inst vars are lost, aded inst vars are nil). >> >> This sounds a bit like CLOS' Â UPDATE-INSTANCE-FOR-REDEFINED-CLASS [1], >> which is a generic function (for our purposes just think "something a >> bit like a method") that you define and is invoked by the machinery >> involved in changing/redefining classes. >> >> A colleague told me about this part of CLOS the other day when >> discussing class-based OO: it's the sort of thing we need in at least >> the Browser, so one can change the shape of existing instances and >> ensure the new class invariants are maintained. > > > But Smalltalk has done without this for 40 years. Â It has supported existing > instance redefinition but no-one has felt the need to provide a scheme for > redefinition in the IDE. Â In any case it is relatively trivial to script it, > e.g.: > > | instanceState | > instanceStateÂ := IdentityDictionary new. > myClass allInstancesDo: [:i|Â instanceState at: i put: ((1 > to:Â myClassÂ instSize) collect: [:ivi| i instVarAt: ivi])]. > myClassÂ superclass subclass:Â myClassÂ name instanceVariableNames: myClass > instVarNamesString, ' theExtraInstVar' [...]. > myClass compile: sourceForupdateToNewFormatFrom. > myClass allInstancesDo: [:i| i updateToNewFormatFrom: (instanceState at: i] > > So if and when you need it you can roll your own (and I've never needed it; > but I have wanted the refactoring browser to preserve inst vars on push > up/push dwn). > > However, collections of persistent objects are a different kettle of fish. > Â It is much more likely to need instance migration on load, especially for > library objects that the user is merely using and whose implementation has > evolved over time (e.g. UI elements such as morphs). > Well, as long as we're staying in same image, i agree there's little , if none, needed to support sophisticated/automated object migration schemes. And i understand why smalltalk lived well without it for 40 years. But if we start talking about distributed systems, where objects need to be persisted/migrated from system to system, this argument may not hold. Anyways, i think there is no simple (silver bullet) solution to automate migration process, because it involves humans (as developers), who making the changes and system simply cannot predict all side effects of it. Having a system which is clever enough to do an auto-migration correctly is the same as having a system clever enough to do auto-refactoring. These two things are closely related, and i hardly believe we will have self-improving systems in nearest future. >> >> (For instance, for >> "purely functional" objects, you really don't want to use reflection >> to initialise new instvars from outside the object.) > > > But the class builder uses an unprotected interface (instVarAt: and > instVarAt:put:). Â So this turns out not to be an issue. > -- Best regards, Igor Stasenko.

March 7, 2012