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

Re: [Pharo-project] Object serialization in Pharo

by StÃ©phane Ducasse

> Stef, > > Henry's warning tells me I'm not alone in being afraid of Squeak's > serializer. A while ago, I had settled on SIXX as the likely best > option for me, but will certainly consider other options. For the > Dolphin filer, my tests mostly center on loading objects with old > schemas. It was fairly easy to do because I had old data in > abundance, and simply loaded some of it into new images. For Pharo, > we might write tests that compile a class, serialize, make some > changes to the class and reload the "old" data. The details will > probably depend on the serializer(s) we select. > > My plan has been to start out using SIXX for network transport of > data between like images (where schema changes are not a concern) > and then begin to look at archival uses if that goes well. > > Does that answer your question? ok we will evaluate SIXX. Now my point is that we should have good solutions: so if referenceStream can be fix we fix it else we trash it. Half-baked solutions just hinder progress. My goal is this community is to set the cap (fun for a lighthouse) and the cap for 1.2 and other releases. I want a neat nice robust working documented system and each step going in that direction is an important one. Stef > > Bill > > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr > ] On Behalf Of StÃ©phane Ducasse > Sent: Tuesday, September 15, 2009 1:19 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Object serialization in Pharo > >> Stef, >> >> The packaging constraint had nothing to do with Pharo. See the [ANN] >> thread on #readStream replacing ReadStream on: (around 4 Sept). >> SecureSqueak is the system with the apparent limitation; it really >> does have that constraint, it will not be of much use to me. >> >> Unit tests for a serializer would be well-taken, but I will largely >> have to start over. Choosing a filer seems to be the first step. >> Squeak's ReferenceStream did not strike me as a good option; if you >> wish to argue in its favor, please do so. Otherwise, I would like to >> see SIXX get a good evaluation, as well as any other options that >> should be considered. > > I'm sure that I want an XML parser in the way but why not. > I started to write some tests just to learn and document. I would > even have no problem to throw away everything it there is a better > solution. Now what tests will let enable us to change and nothing > what we change. > > Stef >> >> Bill >> >> >> -----Original Message----- >> From: pharo-project-bounces(a)lists.gforge.inria.fr >> [mailto:pharo-project-bounces@lists.gforge.inria.fr >> ] On Behalf Of StÃ©phane Ducasse >> Sent: Tuesday, September 15, 2009 10:06 AM >> To: Pharo-project(a)lists.gforge.inria.fr >> Subject: Re: [Pharo-project] Object serialization in Pharo >> >> >> 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 >> >> >> _______________________________________________ >> 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 > > > _______________________________________________ > 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] Object serialization in Pharo

by Schwab,Wilhelm K

Stef, Henry's warning tells me I'm not alone in being afraid of Squeak's serializer. A while ago, I had settled on SIXX as the likely best option for me, but will certainly consider other options. For the Dolphin filer, my tests mostly center on loading objects with old schemas. It was fairly easy to do because I had old data in abundance, and simply loaded some of it into new images. For Pharo, we might write tests that compile a class, serialize, make some changes to the class and reload the "old" data. The details will probably depend on the serializer(s) we select. My plan has been to start out using SIXX for network transport of data between like images (where schema changes are not a concern) and then begin to look at archival uses if that goes well. Does that answer your question? Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse Sent: Tuesday, September 15, 2009 1:19 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Object serialization in Pharo > Stef, > > The packaging constraint had nothing to do with Pharo. See the [ANN] > thread on #readStream replacing ReadStream on: (around 4 Sept). > SecureSqueak is the system with the apparent limitation; it really > does have that constraint, it will not be of much use to me. > > Unit tests for a serializer would be well-taken, but I will largely > have to start over. Choosing a filer seems to be the first step. > Squeak's ReferenceStream did not strike me as a good option; if you > wish to argue in its favor, please do so. Otherwise, I would like to > see SIXX get a good evaluation, as well as any other options that > should be considered. I'm sure that I want an XML parser in the way but why not. I started to write some tests just to learn and document. I would even have no problem to throw away everything it there is a better solution. Now what tests will let enable us to change and nothing what we change. Stef > > Bill > > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr > [mailto:pharo-project-bounces@lists.gforge.inria.fr > ] On Behalf Of StÃ©phane Ducasse > Sent: Tuesday, September 15, 2009 10:06 AM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Object serialization in Pharo > > > 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 > > > _______________________________________________ > 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 _______________________________________________ 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] Startup/shutdown anecdote

by Schwab,Wilhelm K

Mariano, I did not have to put anything in the startup/shutdown lists. In keeping with the state of the art in Squeak/Pharo, the ODBC package breaks and reconnects everything across snapshots vs. on shutdown and true starts. Add to that a pre-production vpn (University's fault) and a particularly stubborn odbc driver[*], and Pharo came to a grinding hault. There was no way to tell it to back off on the Sisyphean task. Still being on that machine, I restarted the vpn, loaded the image, and save it again, but a change to session managment would skip the hassle. Bill http://code.google.com/p/pharo/wiki/StartupAndShutdown [*] I assume that is the problem at least. It had no hope of finding the server, and appeared not to recognize same and report it as an error. Ubuntu informed me that the vm was waiting on a connecting socket, so it fits. ________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Mariano Martinez Peck Sent: Tuesday, September 15, 2009 1:52 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Startup/shutdown anecdote On Tue, Sep 15, 2009 at 1:55 PM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu<mailto:bschwab@anest.ufl.edu>> wrote: 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. I don't know if I understood you. What does your ODBc drivers do on startup ? did you put some object in the startup/shutdown list ? best Mariano Bill _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 15, 2009

[Pharo-project] [update] #10453

by StÃ©phane Ducasse

10453 ----- - adding removeAll to collections (missing some of them of course) from nicolas add #removeAll suport to collections This is to solve both http://bugs.squeak.org/view.php?id=7177 http://bugs.squeak.org/view.php?id=6937 Comments about the implementation: The super implementation might be enhanced with a shallowCopy in order to provide a working implementation in more cases: self shallowCopy do: [:each | self remove: each]. I believe much subclasses will override, so I did not even bother. Subclass implementation tries to preserve original capacity. This choice is arbitrary and really depends on application side... CharacterSetComplement use a #become:. This is not efficient, but neither would be the addition of all existing characters to the complement (this set is defined by its complement as the name tells). Collection>>#removeAll: also has been modified to handle case of (self removeAll: self). This extends and supersedes the changes from kwl at http://bugs.squeak.org/view.php?id=6937 The big question is what should (self removeAll: self) return? My answer is simple: it returns self (an empty collection). Beware, this will break some chaining: (b removeAll: (a removeAll: a)) ~= (a removeAll: (b removeAll: a)). Anyway, that is not worse than current implementation which will not lead to the most predictible results.

Sept. 15, 2009

Re: [Pharo-project] New Pharo and pharo-web based on core 10451

by Damien Cassou

On Tue, Sep 15, 2009 at 7:46 PM, nullPointer <epicfan(a)gmail.com> wrote: > I have in the latests dev images ( 10440,10446,10451 ) a error of > "FT2Handle-primitiveFailed" when i try save image. That error dont exists > always. Only appears sometimes. To anybody passed him has the same? Never seen that on my Linux box. What's your OS? -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

Sept. 15, 2009

Re: [Pharo-project] Startup/shutdown anecdote

by Mariano Martinez Peck

On Tue, Sep 15, 2009 at 1:55 PM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>wrote: > 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. > > I don't know if I understood you. What does your ODBc drivers do on startup ? did you put some object in the startup/shutdown list ? best Mariano > Bill > > > _______________________________________________ > 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

> Stef, > > The packaging constraint had nothing to do with Pharo. See the > [ANN] thread on #readStream replacing ReadStream on: (around 4 > Sept). SecureSqueak is the system with the apparent limitation; it > really does have that constraint, it will not be of much use to me. > > Unit tests for a serializer would be well-taken, but I will largely > have to start over. Choosing a filer seems to be the first step. > Squeak's ReferenceStream did not strike me as a good option; if you > wish to argue in its favor, please do so. Otherwise, I would like > to see SIXX get a good evaluation, as well as any other options that > should be considered. I'm sure that I want an XML parser in the way but why not. I started to write some tests just to learn and document. I would even have no problem to throw away everything it there is a better solution. Now what tests will let enable us to change and nothing what we change. Stef > > Bill > > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr > ] On Behalf Of StÃ©phane Ducasse > Sent: Tuesday, September 15, 2009 10:06 AM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Object serialization in Pharo > > > 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 > > > _______________________________________________ > 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] New Pharo and pharo-web based on core 10451

by nullPointer

I have in the latests dev images ( 10440,10446,10451 ) a error of "FT2Handle-primitiveFailed" when i try save image. That error dont exists always. Only appears sometimes. To anybody passed him has the same? Regards Damien Cassou wrote: > > http://pharo-project.org/pharo-download > > I've added Sound and and MorphExtras. Please test. > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Lambdas are relegated to relative obscurity until Java makes them > popular by not having them." James Iry > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- View this message in context: http://n2.nabble.com/New-Pharo-and-pharo-web-based-on-core-10451-tp3642632p… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Sept. 15, 2009

Re: [Pharo-project] Object serialization in Pharo

by Schwab,Wilhelm K

Stef, The packaging constraint had nothing to do with Pharo. See the [ANN] thread on #readStream replacing ReadStream on: (around 4 Sept). SecureSqueak is the system with the apparent limitation; it really does have that constraint, it will not be of much use to me. Unit tests for a serializer would be well-taken, but I will largely have to start over. Choosing a filer seems to be the first step. Squeak's ReferenceStream did not strike me as a good option; if you wish to argue in its favor, please do so. Otherwise, I would like to see SIXX get a good evaluation, as well as any other options that should be considered. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse Sent: Tuesday, September 15, 2009 10:06 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Object serialization in Pharo 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 _______________________________________________ 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 Miguel Enrique CobÃ¡ Martinez

El mar, 15-09-2009 a las 15:31 +0200, Simon Denier escribiÃ³: > 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? SIXX or JSON are very good options (JSON doens't serialize dates so..) > > -- > Simon > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Miguel CobÃ¡ http://miguel.leugim.com.mx

Sept. 15, 2009