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

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

by Igor Stasenko

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... -- Best regards, Igor Stasenko.

March 7, 2012

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

by GermÃ¡n Arduino

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*). 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. BTW, very very good code on Zinc, well factored, using patterns, easy to understand, very good job Sven. Cheers. 2012/2/22 Sven Van Caekenberghe <sven(a)beta9.be> > > -- > Sven Van Caekenberghe > http://stfx.eu > Smalltalk is the Red Pill > > > > > On 22 Feb 2012, at 22:04, StÃ©phane Ducasse wrote: > > >> Hi Norbert! > >> > >> Yes, I know that the situation is better with Zinc (I checked the code > and really look nice and simple to understand). I only mentioned XMLRPC as > a mere example of how the things become unusable so fast. > >> > >> Talking about this what you guys consider best, migrate XMLRPC to 1.3 > or directly to 1.4 ? > > > > > > There should be not that much difference for XML and Zinc API between > 1.3 and 1.4 (even if Zinc changes much more than XML. > > > > Now I code in 1.4 most of my time. > > > >> > >> GermÃ¡n. > >> > > > > Normally you would write XMLRPC against Zinc HTTP Components and XML > Support, both are working fine on 1.3 and 1.4. Pharo 1.3 is released and in > that sense more stable (as in predictable and not changing as much), but > 1.4 has much more of the latest features/fixes and is generally more fun > (but you'll be living on the edge). > > Here is an XMLRPC call without the infrastructure of generating/parsing > the proper XML: > > | call | > call := '<?xml version="1.0"?> > <methodCall> > <methodName>examples.getStateName</methodName> > <params> > <param> > <value><i4>41</i4></value> > </param> > </params> > </methodCall>'. > ZnClient new > url: 'http://www.cookcomputing.com/xmlrpcsamples/RPC2.ashx'; > entity: (ZnEntity with: call type: ZnMimeType applicationXml); > post. > > Regards, > > Sven > > > > > -- ============================================ GermÃ¡n S. Arduino <gsa @ arsol.net> Twitter: garduino Arduino Software http://www.arduinosoftware.com PasswordsPro http://www.passwordspro.com greensecure.blogspot.com germanarduino.blogpost.com ============================================

March 6, 2012

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

by Igor Stasenko

On 6 March 2012 23:30, Craig Latta <craig(a)netjam.org> wrote: > >> 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? > > -C > > -- > Craig Latta > www.netjam.org/resume > +31 6 2757 7177 > + 1 415 287 3547 > > > -- Best regards, Igor Stasenko.

March 6, 2012

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

by Noury Bouraqadi

Thanks Marcus for all what you do! Noury On 6 mars 2012, at 14:08, Marcus Denker wrote: > > 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. > > 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 > > -- http://twitter.com/#!/NouryBouraqadi http://www.kroobe.com/profile/noury

March 6, 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... -C -- Craig Latta www.netjam.org/resume +31 6 2757 7177 + 1 415 287 3547

March 6, 2012

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

by Eliot Miranda

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). > (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. > 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 6, 2012

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

by Frank Shearar

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. (For instance, for "purely functional" objects, you really don't want to use reflection to initialise new instvars from outside the object.) 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 >

March 6, 2012

[Pharo-project] Pharo-Kernel Gofer broken

by Pavel Krivanek

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

March 6, 2012

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

by Martin Dias

Hi! Mariano, yes, I forgot to say that B is subclass of A. Henry, thanks a lot for sharing your knowledge about BOSS. Following my example, the "backwards-compatability reader method" has to be defined in A, right? Or do you specify it as a parameter to the class loader? I would like to have automatic tolerance to simple layout changes like this. Eliot, thanks for the correction. Rescan the methods seems to be a nice solution, and has not dependency with compiler. The migration service you describe makes me think, because we have recently added migration support to Fuel; it works like: aMaterializer migrateClassNamed: #OldPoint toClass: NewPoint variables: {('x' -> 'posX'). ('y' -> 'posY')}. On one hand, in simple cases it should be more efficient than creating a dictionary for each instance and then become them. On the other hand, in more complex cases it's not enough and the dictionary could be a more uniform solution. For example, if NewPoint has just a variable named "coordinates", which points to an array with x and y as elements. MartÃn On Tue, Mar 6, 2012 at 3:27 PM, 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 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 > >

March 6, 2012

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

by Max Leske

If it wouldn't take so bloody long to run (approx. 9 hours for all Squeak version up to and including Pharo 1.0) and didn't require me to port back all the changes we made to FSGit to Pharogenesis I'd happily do that. I just don't think the effort is worth it (I'll change my mind if people on the list start begging for it :) ) Ah yes, and the fetchingâ¦ That would of course be missing tooâ¦ :p Cheers, Max On 06.03.2012, at 20:05, Camillo Bruni wrote: > max, > > maybe you want to create a test git repos with all the sources back to 1.0 :D > and then we should record all changes into a local git-repos :) > if you want to got back some versions you simply start fetching the missing objects from a central repos somewhere... > > so far dreaming a bit > > best > cami > > On 2012-03-06, at 20:01, Marcus Denker wrote: > >> >> On Mar 6, 2012, at 7:30 PM, Max Leske wrote: >> >>> This may be a stupid questionâ¦ (As far as I understand, condensing the changes is not the same) >>> Why don't you increment the version number of the sources file to 1.1 and use a fresh changes file? >>> >> The sources file does not contain the sources and the changes just the changes. (even though one could think so taking >> the names into account.) >> >> The sources file containes the sources of ages ago (1.0), the .changes is "on top of that". This means that the .sources >> file contains a lot of code from classes and methods that have been removed (like the changes), >> as well as old versions. >> >> The .sources/.changes mechanism merges three responsabilties: >> >> 1) be a log of all edited code in case of a crash >> 2) store the current source of the methods (when you ask a method for code, it reads either from the .sources >> (method not changed since 1.0) or from the .changes (method was changed). >> 3) provide a history for all code >> >> 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. >> >> When you do a #condenseSources (which is sadly broken right now), then it generates a .sources >> file with just the code in the current image. It would be interesting to see how large that is. >> >> Marcus >> >> -- >> Marcus Denker -- http://marcusdenker.de >> >> > >

March 6, 2012