- Pharo-dev - lists.pharo.org

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

[Pharo-project] Object serialization in Pharo

by Simon Denier

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

Sept. 15, 2009

[Pharo-project] Problem with pharo1.0-10440-BETAweb09.09.1

by Andreas Wacknitz

I have started to look at Seaside in Pharo. There seems to be a problem with the examples. When I enter http://localhost:8080/seaside/examples/examplebrowser (by clicking on examples and then examplebrowser) I will get a Seaside Walkback: Seaside Walkback MessageNotUnderstood: receiver of "root" is nil Debug Proceed Full Stack Possible Causes the receiver of the message is nil a class extension hasn't been loaded correctly you sent the wrong message Stack Trace thisContext UndefinedObject(Object)>>doesNotUnderstand: #root self nil aMessage root exception MessageNotUnderstood: receiver of "root" is nil resumeValue nil thisContext PRContext class>>kernel: self PRContext aKernel nil thisContext PRPierFrame>>initialRequest: self a PRPierFrame aRequest a WARequest GET /seaside/examples/examplebrowser thisContext [] in WARenderLoopMain>>start: self a WARenderLoopMain aRequest a WARequest GET /seaside/examples/examplebrowser root a WAExampleBrowser each a PRPierFrame thisContext PRPierFrame(WAPresenter)>>withNextPresentersDo: self a PRPierFrame aBlock [closure] in WARenderLoopMain>>start: Regards, Andreas

Sept. 15, 2009

[Pharo-project] [update] #10451

by StÃ©phane Ducasse

10451 ----- - Issue 1220: add #removeAll support to collections - Adding WideStringTests - Issue 1211: Clean up Character >> #asUnicodeChar - Moving Object class>>windowColorSpecification to Morphic - Issue 1219: Left over of uniClasses...in Object Object class>>newUserInstance Object class>>instanceOfUniqueClass Object class>>instanceOfUniqueClassWithInstVarString: instVarString andClassInstVarString: classInstVarString Object class>>categoryForUniclasses Object class>>newUniqueClassInstVars: instVarString classInstVars: classInstVarString I forgot to put the code of collectAll.... soon Stef

Sept. 15, 2009

Re: [Pharo-project] Graphics-Centric UI Capability?

by dmurphy＠infratecture.com

thanks, Igor! it is Morphic-Windows / ScrollPane (even has example use methods on the class side!) delbert -----Original Message----- From: Igor Stasenko [mailto:siguctua@gmail.com] Sent: Saturday, September 12, 2009 03:02 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Graphics-Centric UI Capability? Oops sorry for the dumb post.. (im using my friend laptop and not very handy with keyboard) There is a generic morph, which made specially for scrolling views which not fit fully within display. ScrollPaneMorph or ScrollableMorph (don't remember exactly) the purpose of this morph is provide a scrollers , while you can embed any view within it, having any dimensions and which can be controlled/changed dynamically. 2009/9/12 Igor Stasenko : > t > > 2009/9/12 : >> hello all, > >> i have been nabbling about the list archives, trying to figure out the right >> class to use for providing a scrolling graph pane on which i can draw >> shapes. >> >> suppose i were to take UITheme(class)>>exampleWindowWithToolbars and want to >> turn that into a simple Paint Program. >> >> what would i put in place of the >> StandardWindow>>newTextEditorFor:getText:setText:getEnabled: message send? >> >> are there any simple Paint Program examples i start with? >> >> thanks for any pointers! >> >> delbert >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 14, 2009

Re: [Pharo-project] Graphics-Centric UI Capability?

by dmurphy＠infratecture.com

thanks, Stef, i will check those packages and the original paint in squeak and start building on the PolyMorph application example + Morphic-Windows / ScrollPane example. i will share iterations as i complete them. delbert -----Original Message----- From: St?phane Ducasse [mailto:stephane.ducasse@inria.fr] Sent: Saturday, September 12, 2009 03:01 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Graphics-Centric UI Capability? On Sep 12, 2009, at 12:28 AM, dmurphy(a)infratecture.com wrote: > hello all, > > i have been nabbling about the list archives, trying to figure out > the right class to use for providing a scrolling graph pane on which > i can draw shapes. > > suppose i were to take UITheme(class)>>exampleWindowWithToolbars and > want to turn that into a simple Paint Program. > > what would i put in place of the > StandardWindow>>newTextEditorFor:getText:setText:getEnabled: message > send? > > are there any simple Paint Program examples i start with? did you check the extrapackages available in the project PharoMorphic PharoSound In the past in squeak there was a simple paint editor. Because you have some graphs but they do not use Polymorph. Now once you find please advertise it. It is really important to raise the level of knowledge on the community :) > > thanks for any pointers! > > delbert > _______________________________________________ > 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. 14, 2009