September 2009 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] one click distribution

by StÃ©phane Ducasse

On Sep 15, 2009, at 4:49 PM, Marcus Denker wrote: > > On 14.09.2009, at 12:28, Torsten Bergmann wrote: > >> Marcus wrote: >>> ...Pharo1.0-10440-BETAdev09.09ONECLICK.4.zip >> >> But Damien already has a 10451 image, so shouldnt >> we update to that for the one click too? > > I wonder if it makes sense to update the one-click independed of the > Dev zip. frankly I do not like the one click for my own use because I have to go inside the package system so one click is for newbie. Besides that we should get a sources image/changes and image/changes tar ball I hate to duplicate the source on my disc and the one click is always doing that then when I save my package the cache is in the one click.... Stef > > Marcus > > > > > -- > Marcus Denker - http://marcusdenker.de > PLEIAD Lab - Computer Science Department (DCC) - University of Chile > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 15, 2009

Re: [Pharo-project] Object serialization in Pharo

by StÃ©phane Ducasse

Ok good to know Stef On Sep 15, 2009, at 4:48 PM, Henrik Johansen wrote: > > On Sep 15, 2009, at 4:16 46PM, Schwab,Wilhelm K wrote: > >> Simon, >> >> I wish you well and will be eager to hear progress reports. Long >> ago, I looked at ReferenceStream (or maybe SmartReferenceStream), >> and did not like what I found. IIRC, the output for simple examples >> was much larger (of course, it might not continue to scale so >> unfavorably) compared that that produced by Dolphin's binary filer. >> Another concern was schema changes. >> >> Dolphin has an orderly conversion process that will raise an error >> if it is not prepared for what it finds; Squeak seemed to want to >> fix it itself with the aid of the user (not gonna fly in an end-user >> app or a server process, which is pretty much everything). >> >> Dolphin locates conversion methods in the class of the object being >> converted or in the class of a proxy for it (that sounded scary to >> me when I read about it, but it is exactly what one would want in >> practice). > Sounds alot like BOSS in VisualWorks :) > The only annoying thing I've found using that, is the fact you never > get prompted to update the conversion method when you modify a class > which already contains a binaryReadBlockFrom: method. (Kind of hard to > know if you store objects of the kind to disk if it doesn't have one > already) > Believe it or not, but it's quite easy to forget when doing some > change, and you have no tests importing old variations of all the > objects you file to disk in your project. > >> In contrast, Squeak puts the conversion methods in ReferenceStream. >> Yuk!!! Sorry, don't know what just came over me :) Of course one >> can always modify ReferenceStream[*], but imagine the chaos if >> ReferenceStream were to become widely used. > IIRC from looking briefly at it when reviewing some removal patch > which touched it, it checks first if class has conversion method, THEN > it tries to autoconvert (silently if it considers itself > "successful", yay). > Also, if I read the code correctly, it only checks for class structure > differences, so if you've, say, switched the order of two instvars > since you stored an old object to disk, it'll file in just fine, but > with the data in incorrect places... > In short, I imagine using ReferenceStream could lead to some _very_ > frustrating debugging sessions later on in the project, consider > yourself warned :) > > Cheers, > Henry > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 15, 2009

Re: [Pharo-project] Object serialization in Pharo

by StÃ©phane Ducasse

On Sep 15, 2009, at 4:16 PM, Schwab,Wilhelm K wrote: > Simon, > > I wish you well and will be eager to hear progress reports. Long > ago, I looked at ReferenceStream (or maybe SmartReferenceStream), > and did not like what I found. IIRC, the output for simple examples > was much larger (of course, it might not continue to scale so > unfavorably) compared that that produced by Dolphin's binary filer. > Another concern was schema changes. > > Dolphin has an orderly conversion process that will raise an error > if it is not prepared for what it finds; Squeak seemed to want to > fix it itself with the aid of the user (not gonna fly in an end-user > app or a server process, which is pretty much everything). > > Dolphin locates conversion methods in the class of the object being > converted or in the class of a proxy for it (that sounded scary to > me when I read about it, but it is exactly what one would want in > practice). In contrast, Squeak puts the conversion methods in > ReferenceStream. Yuk!!! Sorry, don't know what just came over > me :) Of course one can always modify ReferenceStream[*], but > imagine the chaos if ReferenceStream were to become widely used. > > I have used serializers to good effect and would like to continue > doing so. At the moment, I would look again, but would lean away > from ReferenceStream. I started to write some tests in the PharoTaskForces. If people want to join effort because before changing I would like to know what is there. > SIXX (an XML serializer) is a possibility. As I recall, its output > was not terse (but might compress nicely??). There originally was > minimal to no support for shape changes, but that has been > addressed; I cannot speak for how well it has been done because I > have not had time to look. It is on my todo list and might float to > the surface soon, though initially I would not need to care about > shape changes. > > HTH > > Bill > > > [*] I think we recently discussed a Squeak fork that would not allow > touching base classes due to packaging limitations. really? > Not good. I am not defending the ReferenceStream example, but it > would be a big problem on that system, if I understood that thread. I would like to fix that We need a good object serializer. > > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr > ] On Behalf Of Simon Denier > Sent: Tuesday, September 15, 2009 8:32 AM > To: Pharo Development > Subject: [Pharo-project] Object serialization in Pharo > > Hi folks > > I'm looking at the code and comments of ReferenceStream for object > serialization and I wonder what is the best strategy to serialize a > partial model. I mean, I want to store all elements found while > traversing the graph of the model, but I dont want to store some > attributes of those elements (i.e., transient attributes). > > Any sample? > > -- > Simon > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 15, 2009

Re: [Pharo-project] Unable to type some czech characters

by "M. PolÃ¡k"

This looks like Windows-related or Windows VM related problem. Here on Mac OSX 10.5 works everything OK, even those chars, you mentioned. Cheers, Martin

Sept. 15, 2009

[Pharo-project] Startup/shutdown anecdote

by Schwab,Wilhelm K

I just had an experience that fuels my session manager fire. I loaded Pharo, and it was totally unresponsive. Why? I can't be absolutely certain, but here's my story: last night, I had an open connection to a system visible only with a vpn. With the vpn not in use, either Pharo (or more likely ODBC) went nuts because it could not find the server, and I finally killed the process, started the vpn, and all was well on the next startup. IMHO, hanging like that is one of the worst things software can do, and I think we can do a lot to fix it with a few simple changes. Linux ODBC is probably partly to blame, but it should not have been invoked so early in statup. Someone recently argued against lazy connections, but this would not have happened if they were part of the design. The image would have become helpless once I did something that triggered database activity, but that is where overlapped calls enter the picture. Even without the, at least I would have been able to use the image. Note that if I had taken the offending image to another machine, it could have been useless - not good. Bill

Sept. 15, 2009

Re: [Pharo-project] one click distribution

by Marcus Denker

On 14.09.2009, at 12:28, Torsten Bergmann wrote: > Marcus wrote: >> ...Pharo1.0-10440-BETAdev09.09ONECLICK.4.zip > > But Damien already has a 10451 image, so shouldnt > we update to that for the one click too? I wonder if it makes sense to update the one-click independed of the Dev zip. Marcus -- Marcus Denker - http://marcusdenker.de PLEIAD Lab - Computer Science Department (DCC) - University of Chile

Sept. 15, 2009

Re: [Pharo-project] Object serialization in Pharo

by Simon Denier

On 15 sept. 09, at 16:08, Chris Muller wrote: > "Ma object serialization" was designed for this purpose. You simply > override #maTransientVariables to answer an array of the variable > names that are transient. That part of the graph will not be > traversed during serialization and nil will be stored in its place. OK thanks, the wiki offering the doc is down for the moment, but the seaside book offers a few hints about the subject. > > > > On Tue, Sep 15, 2009 at 8:31 AM, Simon Denier > <Simon.Denier(a)inria.fr> wrote: >> Hi folks >> >> I'm looking at the code and comments of ReferenceStream for object >> serialization and I wonder what is the best strategy to serialize a >> partial model. I mean, I want to store all elements found while >> traversing the graph of the model, but I dont want to store some >> attributes of those elements (i.e., transient attributes). >> >> Any sample? >> >> -- >> Simon >> >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Simon

Sept. 15, 2009

Re: [Pharo-project] Object serialization in Pharo

by Henrik Johansen

On Sep 15, 2009, at 4:16 46PM, Schwab,Wilhelm K wrote: > Simon, > > I wish you well and will be eager to hear progress reports. Long > ago, I looked at ReferenceStream (or maybe SmartReferenceStream), > and did not like what I found. IIRC, the output for simple examples > was much larger (of course, it might not continue to scale so > unfavorably) compared that that produced by Dolphin's binary filer. > Another concern was schema changes. > > Dolphin has an orderly conversion process that will raise an error > if it is not prepared for what it finds; Squeak seemed to want to > fix it itself with the aid of the user (not gonna fly in an end-user > app or a server process, which is pretty much everything). > > Dolphin locates conversion methods in the class of the object being > converted or in the class of a proxy for it (that sounded scary to > me when I read about it, but it is exactly what one would want in > practice). Sounds alot like BOSS in VisualWorks :) The only annoying thing I've found using that, is the fact you never get prompted to update the conversion method when you modify a class which already contains a binaryReadBlockFrom: method. (Kind of hard to know if you store objects of the kind to disk if it doesn't have one already) Believe it or not, but it's quite easy to forget when doing some change, and you have no tests importing old variations of all the objects you file to disk in your project. > In contrast, Squeak puts the conversion methods in ReferenceStream. > Yuk!!! Sorry, don't know what just came over me :) Of course one > can always modify ReferenceStream[*], but imagine the chaos if > ReferenceStream were to become widely used. IIRC from looking briefly at it when reviewing some removal patch which touched it, it checks first if class has conversion method, THEN it tries to autoconvert (silently if it considers itself "successful", yay). Also, if I read the code correctly, it only checks for class structure differences, so if you've, say, switched the order of two instvars since you stored an old object to disk, it'll file in just fine, but with the data in incorrect places... In short, I imagine using ReferenceStream could lead to some _very_ frustrating debugging sessions later on in the project, consider yourself warned :) Cheers, Henry

Sept. 15, 2009

Re: [Pharo-project] Object serialization in Pharo

by Schwab,Wilhelm K

Simon, I wish you well and will be eager to hear progress reports. Long ago, I looked at ReferenceStream (or maybe SmartReferenceStream), and did not like what I found. IIRC, the output for simple examples was much larger (of course, it might not continue to scale so unfavorably) compared that that produced by Dolphin's binary filer. Another concern was schema changes. Dolphin has an orderly conversion process that will raise an error if it is not prepared for what it finds; Squeak seemed to want to fix it itself with the aid of the user (not gonna fly in an end-user app or a server process, which is pretty much everything). Dolphin locates conversion methods in the class of the object being converted or in the class of a proxy for it (that sounded scary to me when I read about it, but it is exactly what one would want in practice). In contrast, Squeak puts the conversion methods in ReferenceStream. Yuk!!! Sorry, don't know what just came over me :) Of course one can always modify ReferenceStream[*], but imagine the chaos if ReferenceStream were to become widely used. I have used serializers to good effect and would like to continue doing so. At the moment, I would look again, but would lean away from ReferenceStream. SIXX (an XML serializer) is a possibility. As I recall, its output was not terse (but might compress nicely??). There originally was minimal to no support for shape changes, but that has been addressed; I cannot speak for how well it has been done because I have not had time to look. It is on my todo list and might float to the surface soon, though initially I would not need to care about shape changes. HTH Bill [*] I think we recently discussed a Squeak fork that would not allow touching base classes due to packaging limitations. Not good. I am not defending the ReferenceStream example, but it would be a big problem on that system, if I understood that thread. -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Simon Denier Sent: Tuesday, September 15, 2009 8:32 AM To: Pharo Development Subject: [Pharo-project] Object serialization in Pharo Hi folks I'm looking at the code and comments of ReferenceStream for object serialization and I wonder what is the best strategy to serialize a partial model. I mean, I want to store all elements found while traversing the graph of the model, but I dont want to store some attributes of those elements (i.e., transient attributes). Any sample? -- Simon _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 15, 2009

Re: [Pharo-project] Object serialization in Pharo

by Chris Muller

"Ma object serialization" was designed for this purpose. You simply override #maTransientVariables to answer an array of the variable names that are transient. That part of the graph will not be traversed during serialization and nil will be stored in its place. On Tue, Sep 15, 2009 at 8:31 AM, Simon Denier <Simon.Denier(a)inria.fr> wrote: > Hi folks > > I'm looking at the code and comments of ReferenceStream for object > serialization and I wonder what is the best strategy to serialize a > partial model. I mean, I want to store all elements found while > traversing the graph of the model, but I dont want to store some > attributes of those elements (i.e., transient attributes). > > Any sample? > > -- > Â Simon > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 15, 2009