January 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] clone vs shallowCopy

by Alain Plantec

Lukas Renggli a Ã©crit : > I suggest everybody to have a quick look at VW: > - they have #copy and #postCopy as we do > - they have #shallowCopy that is used from #copy as we do > - they have #dcopy (what a horrible name) that is implemented in a > similar way to what I suggested for #deepCopy > > There is nothing else. > yes, I think we should adopt this with (dcopy -> deepCopy). Alain > Lukas > >

Jan. 13, 2010

Re: [Pharo-project] clone vs shallowCopy

by Lukas Renggli

>> It doesn't handle recursion, which makes it pretty useless. > > That's what #veryDeepCopy does, though it does it in a more complicated > way. #deepCopy has the advantage of being simple and fast. And useless. I've never used it. If you change something here, it subtly breaks something there. I suggest everybody to have a quick look at VW: - they have #copy and #postCopy as we do - they have #shallowCopy that is used from #copy as we do - they have #dcopy (what a horrible name) that is implemented in a similar way to what I suggested for #deepCopy There is nothing else. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Jan. 13, 2010

Re: [Pharo-project] Problem with Inspector [WAS] Fwd: [BetaTesting] [ANN] Pharo1.0-10505-rc1dev10.01.1

by Mariano Martinez Peck

I forgot to cc Frederic :) 2010/1/12 Mariano Martinez Peck <marianopeck(a)gmail.com> > > > 2010/1/12 Serge Stinckwich <serge.stinckwich(a)gmail.com> > >> Thank you for your good work Mariano. I use your image for my >> development right now. The inspector is crashing in unexpected ways. >> >> Just try : #(1 2 3 4 5 6 7 9 10) inspect. >> and in the panel below on the right, just evaluate for example : 3+7 with >> CTRL-D >> several times. After a while, the following screen appears. >> >> > > Thanks Serge for the report. I could reproduce it even in my first cmd d to > 3 +7 > > I created the issue: http://code.google.com/p/pharo/issues/detail?id=1783 > > I cc Frederic as it seems to be a problem with the inspector. > > Cheers > > Mariano > > >> 2010/1/10 Mariano Martinez Peck <marianopeck(a)gmail.com>: >> > Hi Folks/Beta-Testers! >> > >> > I have prepare a new PharoDev image. This image, has same differences >> with >> > the previous ones that you should know: >> > >> > 1) This is the first Dev image I ever prepare. I adapt to Mac OS >> Damien's >> > bash scripts to build them and I also cleanup all the Squeak stuff from >> > those bash scripts. So, maybe there are some problems. Forgive me if >> this is >> > the case. I would like you to check, not only the Image in itself but >> also >> > the zip. The package.txt, changelog, the fonts, etc. >> > >> > 2) This image puts TrueType fonts again. We won't put StrikeFonts or >> DejaVu >> > package until there is big bug with them. We know those fonts are >> faster, >> > but still a bit buggy. If you fix those issues, cool! >> > >> > 3) This image DOES NOT include O2. I know there are a lot of people who >> use >> > it (mostly in Moose), but unfortunately, this was a decision taken. O2 >> > depends and overrides OB making this more unstable sometimes. The same >> as >> > the TrueType, we will put O2 again when this can be perfectly load in a >> > PharoCore image without anything about OB. >> > Sorry, but we rather affect only O2 users and not all. If you want >> packages >> > support, then help in O2 development. >> > >> > 4) In previous Dev images only tests from PharoCore were included. Now, >> it >> > also includes the tests from the external packages loaded. >> > >> > 5) This image was build using Metacello configurations. If you want, >> compare >> > the installScript.st from this image to the previous one. >> > >> > 6) There is no Web image this time. If you want to install Seaside 2.8.4 >> > evaluate: >> > >> > Gofer new >> > squeaksource: 'MetacelloRepository'; >> > package: 'ConfigurationOfSeaside28'; >> > load. >> > >> > (Smalltalk at: #ConfigurationOfSeaside28) load >> > >> > And if you want Seaside 3.0 evaluate: >> > >> > Gofer new >> > squeaksource: 'MetacelloRepository'; >> > package: 'ConfigurationOfSeaside30'; >> > load. >> > >> > (Smalltalk at: #ConfigurationOfSeaside30) loadLatestVersion >> > >> > However, I am not sure if this is perfectly working in Pharo. >> > >> > >> > >> > Ok .... Here is the link: >> > >> https://gforge.inria.fr/frs/download.php/25156/pharo1.0-10505-rc1dev10.01.1… >> > >> > I will wait a couple of days now and I will also start to use this image >> for >> > my development. If there are issues, report them. If we have big issues, >> > this image is not release. On the other hand, if it works well, we >> release >> > it. >> > >> > _______________________________________________ >> > Pharo-project mailing list >> > Pharo-project(a)lists.gforge.inria.fr >> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > >> >> >> >> -- >> Serge Stinckwich >> UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam >> Smalltalkers do: [:it | All with: Class, (And love: it)] >> http://doesnotunderstand.org/ >> >> _______________________________________________ >> 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 >

Jan. 13, 2010

Re: [Pharo-project] clone vs shallowCopy

by Levente Uzonyi

On Wed, 13 Jan 2010, Lukas Renggli wrote: >>> It would be cool to merge #clone and #shallowCopy, and all the >>> different #deepCopy* instances. Also the implementation of #deepCopy >>> might need some cleanup, it seems to be rather complicated for such a >>> trivial task of copying a object graph. >> >> The implementation of #deepCopy seems to be pretty straightforward. I >> wonder how it could be simpler. > > It doesn't handle recursion, which makes it pretty useless. > That's what #veryDeepCopy does, though it does it in a more complicated way. #deepCopy has the advantage of being simple and fast. Levente > I would suggest something like: > > deepCopy > ^ self deepCopy: IdentityDictionary new > > deepCopy: anIdentityDictionary > | copy | > anIdentityDictionary at: self ifPresent: [ :value | ^ value ]. > copy := anIdentityDictionary at: self put: self shallowCopy preDeepCopy. > " copy all the variables of copy using 'var deepCopy: anIdentityDictionary' " > ^ copy postDeepCopy > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Jan. 13, 2010

Re: [Pharo-project] clone vs shallowCopy

by Levente Uzonyi

On Wed, 13 Jan 2010, StÃ©phane Ducasse wrote: > > On Jan 13, 2010, at 9:14 AM, Levente Uzonyi wrote: > >> On Wed, 13 Jan 2010, StÃ©phane Ducasse wrote: >> >>> Now it would be nice to clean that because in VW you have copy, shallowCopy and postCopy and it works. >>> They removed veryDeepCopy and other friends even when they were at the time were they could burn engineering time >>> on that. >> >> I'm sure there's a way to copy an object graph properly in VW (that's what #veryDeepCopy does). > > not really so this is why I would like to keep veryDeepCopy > >>> So for me clone is one too many. >>> And worse cloning and object cannot be a shallowCopy semantics. it should be more a veryDeepInnerVeryCopy (I could not resist sorry) >> >> #clone is copying an object, not a graph. I think the name is coming from Self. > > Probably. > >>> Of course we already clean and remove the veryDeepInnerCopy.... No comment. >>> >> >> What? > > check squeak 3.8 or related. I see the same methods starting with veryDeep as in Pharo 1.1. Levente > >> >> >> Levente >> >>>>>> - #copy is the normal copy operation. It should be used by default and >>>>>> never overridden. It calls #postCopy that can be overridden to have >>>>>> class specific copy semantics. >>>>>> >>>>>> - #shallowCopy does a shallow copy. It should never be overridden and >>>>>> only be used if you want to get these very specific semantics. >>>>>> >>>>>> - #deepCopy does a deep copy. It should never be overridden and only >>>>>> be used if you want to get these very specific semantics. >>>>>> >>>>>> - #clone comes from eToys and Morphic (AFAIK). It implements some >>>>>> other copy semantics than #copy. I don't think that anybody should >>>>>> call this method, other than code that depends on this particular copy >>>>>> behavior. >>>>> >>>>> we should copy that in Object class comment and all the methods >>>>> >>>>> >>>>> where do you see that it is morphic related for me clone is only implemented >>>>> on character, Boolean, Object, SMalltInt symbol, UndefinedObject >>>> >>>> Back in the old days, Squeak 1.1 didn't have primitive 148 (which is now used by both #shallowCopy and #clone). #shallowCopy was the way to create a "one-level copy" of an Object. It had the same code as today, but with no primitive. >>>> Primitive 148 was introduced somewhere between 1.1 and 1.19 (note that 1.2 came after 1.19). 1.19 (and probably earlier versions, but not 1.1) had #clone which was primitive only and #shallowCopy which didn't use the primitive. Morphic was being ported to Squeak at the time and it was the only user of #clone. Morphs were copied by #clone which was pretty fast, while other objects used #shallowCopy. Later the use of #clone started to spread, until primitive 148 was added to #shallowCopy. Sends of #clone were replaced with #shallowCopy and #copy, but #clone was kept, probably for backwards compatibility. >>>> >>>> #clone and #shallowCopy have a difference in their semantics. If the vm cannot allocate enough space for the new object, #clone raises an error immediately, while #shallowCopy signals the low space semaphore, so the image or the user can do something, then retries the copying. >>>> >>>> >>>> Levente >>>> >>>>> >>>>>> >>>>>> This is exactly the same problematic as with #=. There can't be just >>>>>> one #=. Other clients might consider other things when comparing >>>>>> objects. >>>>>> >>>>>> Lukas >>>>>> >>>>>> -- >>>>>> Lukas Renggli >>>>>> http://www.lukas-renggli.ch >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >

Jan. 13, 2010

Re: [Pharo-project] clone vs shallowCopy

by Lukas Renggli

>> It would be cool to merge #clone and #shallowCopy, and all the >> different #deepCopy* instances. Also the implementation of #deepCopy >> might need some cleanup, it seems to be rather complicated for such a >> trivial task of copying a object graph. > > The implementation of #deepCopy seems to be pretty straightforward. I > wonder how it could be simpler. It doesn't handle recursion, which makes it pretty useless. I would suggest something like: deepCopy ^ self deepCopy: IdentityDictionary new deepCopy: anIdentityDictionary | copy | anIdentityDictionary at: self ifPresent: [ :value | ^ value ]. copy := anIdentityDictionary at: self put: self shallowCopy preDeepCopy. " copy all the variables of copy using 'var deepCopy: anIdentityDictionary' " ^ copy postDeepCopy -- Lukas Renggli http://www.lukas-renggli.ch

Jan. 13, 2010

Re: [Pharo-project] PluggableTextMorph >> getText proposed modification

by Levente Uzonyi

On Wed, 13 Jan 2010, StÃ©phane Ducasse wrote: > Hi guys > > I would really like to get your feedback on this change because it seems to me that menu are not > good enough. There were problems with String >> #numArgs, don't know if they still exist or not, but #isUnary seems to be a better (and faster) choice. Levente > > Stef > > On Jan 12, 2010, at 6:14 AM, Ralph Boland wrote: > >> In my (Squeak) project I modified PluggableTextMorph >> getText to be >> as follows: >> >> getText >> "Retrieve the current model text" >> >> | newText | >> getTextSelector isNil ifTrue: [^Text new]. >> newText := (getTextSelector numArgs = 1) >> ifTrue: [model perform: getTextSelector with: self] >> ifFalse: [model perform: getTextSelector]. >> newText ifNil: [^Text new]. >> ^newText shallowCopy >> >> >> The change allows the getTextSelector to pass an additional argument: self. >> I made this change because I wanted to know which PluggableTextMorph >> was asking for text. >> This is useful when one has large numbers of similar PluggableTextMorphs. >> Note that the method PluggableTextMorph >> acceptTextInModel >> already does this so I didn't need to modify it. >> Thus I think my change makes PluggableTextMorph more consistent. >> >> Any chance of this change being made a part of the Pharo image? >> >> Frankly, I would prefer that all the GUI objects that have get/set messages >> had this capability. For CheckBoxes I earlier added the capability to return >> either self or some arguments (by subclassing this time). >> I am happy with the result. >> >> Another way I could do this would be to create a holder for the >> PluggableTextMorph >> (or other gui object) that would respond to the getText and >> acceptTextInModel messages >> and would know which PluggableTextMorph is speaking to it (since there >> would be only one). >> The holder would replace the model in the PluggableTextMorph and have >> a reference to the original model to which it could forward messages. >> Again this would allow me to have a large number of similar PluggableTextMorphs. >> One could create a PluggableTextMorphHolder class for this or create >> a single holder >> class that could work with different Morph classes (only one at a timeof course) >> (by responding to messages from all of them). It would be nice of >> course if these >> GUI holders already existed in Squeak/Pharo so I didn't have to invent them. >> >> Which approach do you think is better? >> >> Regards, >> >> Ralph Boland >> >> >> -- >> I've been middle class and I've been poor. >> Middle class is better. >> >> _______________________________________________ >> 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 >

Jan. 13, 2010

Re: [Pharo-project] clone vs shallowCopy

by StÃ©phane Ducasse

On Jan 13, 2010, at 9:14 AM, Levente Uzonyi wrote: > On Wed, 13 Jan 2010, StÃ©phane Ducasse wrote: > >> Now it would be nice to clean that because in VW you have copy, shallowCopy and postCopy and it works. >> They removed veryDeepCopy and other friends even when they were at the time were they could burn engineering time >> on that. > > I'm sure there's a way to copy an object graph properly in VW (that's what #veryDeepCopy does). not really so this is why I would like to keep veryDeepCopy >> So for me clone is one too many. >> And worse cloning and object cannot be a shallowCopy semantics. it should be more a veryDeepInnerVeryCopy (I could not resist sorry) > > #clone is copying an object, not a graph. I think the name is coming from Self. Probably. >> Of course we already clean and remove the veryDeepInnerCopy.... No comment. >> > > What? check squeak 3.8 or related. > > > Levente > >>>>> - #copy is the normal copy operation. It should be used by default and >>>>> never overridden. It calls #postCopy that can be overridden to have >>>>> class specific copy semantics. >>>>> >>>>> - #shallowCopy does a shallow copy. It should never be overridden and >>>>> only be used if you want to get these very specific semantics. >>>>> >>>>> - #deepCopy does a deep copy. It should never be overridden and only >>>>> be used if you want to get these very specific semantics. >>>>> >>>>> - #clone comes from eToys and Morphic (AFAIK). It implements some >>>>> other copy semantics than #copy. I don't think that anybody should >>>>> call this method, other than code that depends on this particular copy >>>>> behavior. >>>> >>>> we should copy that in Object class comment and all the methods >>>> >>>> >>>> where do you see that it is morphic related for me clone is only implemented >>>> on character, Boolean, Object, SMalltInt symbol, UndefinedObject >>> >>> Back in the old days, Squeak 1.1 didn't have primitive 148 (which is now used by both #shallowCopy and #clone). #shallowCopy was the way to create a "one-level copy" of an Object. It had the same code as today, but with no primitive. >>> Primitive 148 was introduced somewhere between 1.1 and 1.19 (note that 1.2 came after 1.19). 1.19 (and probably earlier versions, but not 1.1) had #clone which was primitive only and #shallowCopy which didn't use the primitive. Morphic was being ported to Squeak at the time and it was the only user of #clone. Morphs were copied by #clone which was pretty fast, while other objects used #shallowCopy. Later the use of #clone started to spread, until primitive 148 was added to #shallowCopy. Sends of #clone were replaced with #shallowCopy and #copy, but #clone was kept, probably for backwards compatibility. >>> >>> #clone and #shallowCopy have a difference in their semantics. If the vm cannot allocate enough space for the new object, #clone raises an error immediately, while #shallowCopy signals the low space semaphore, so the image or the user can do something, then retries the copying. >>> >>> >>> Levente >>> >>>> >>>>> >>>>> This is exactly the same problematic as with #=. There can't be just >>>>> one #=. Other clients might consider other things when comparing >>>>> objects. >>>>> >>>>> Lukas >>>>> >>>>> -- >>>>> Lukas Renggli >>>>> http://www.lukas-renggli.ch >>>>> >>>>> _______________________________________________ >>>>> 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

Jan. 13, 2010

Re: [Pharo-project] clone vs shallowCopy

by Levente Uzonyi

On Wed, 13 Jan 2010, StÃ©phane Ducasse wrote: > Now it would be nice to clean that because in VW you have copy, shallowCopy and postCopy and it works. > They removed veryDeepCopy and other friends even when they were at the time were they could burn engineering time > on that. I'm sure there's a way to copy an object graph properly in VW (that's what #veryDeepCopy does). > > So for me clone is one too many. > And worse cloning and object cannot be a shallowCopy semantics. it should be more a veryDeepInnerVeryCopy (I could not resist sorry) #clone is copying an object, not a graph. I think the name is coming from Self. > Of course we already clean and remove the veryDeepInnerCopy.... No comment. > What? Levente >>>> - #copy is the normal copy operation. It should be used by default and >>>> never overridden. It calls #postCopy that can be overridden to have >>>> class specific copy semantics. >>>> >>>> - #shallowCopy does a shallow copy. It should never be overridden and >>>> only be used if you want to get these very specific semantics. >>>> >>>> - #deepCopy does a deep copy. It should never be overridden and only >>>> be used if you want to get these very specific semantics. >>>> >>>> - #clone comes from eToys and Morphic (AFAIK). It implements some >>>> other copy semantics than #copy. I don't think that anybody should >>>> call this method, other than code that depends on this particular copy >>>> behavior. >>> >>> we should copy that in Object class comment and all the methods >>> >>> >>> where do you see that it is morphic related for me clone is only implemented >>> on character, Boolean, Object, SMalltInt symbol, UndefinedObject >> >> Back in the old days, Squeak 1.1 didn't have primitive 148 (which is now used by both #shallowCopy and #clone). #shallowCopy was the way to create a "one-level copy" of an Object. It had the same code as today, but with no primitive. >> Primitive 148 was introduced somewhere between 1.1 and 1.19 (note that 1.2 came after 1.19). 1.19 (and probably earlier versions, but not 1.1) had #clone which was primitive only and #shallowCopy which didn't use the primitive. Morphic was being ported to Squeak at the time and it was the only user of #clone. Morphs were copied by #clone which was pretty fast, while other objects used #shallowCopy. Later the use of #clone started to spread, until primitive 148 was added to #shallowCopy. Sends of #clone were replaced with #shallowCopy and #copy, but #clone was kept, probably for backwards compatibility. >> >> #clone and #shallowCopy have a difference in their semantics. If the vm cannot allocate enough space for the new object, #clone raises an error immediately, while #shallowCopy signals the low space semaphore, so the image or the user can do something, then retries the copying. >> >> >> Levente >> >>> >>>> >>>> This is exactly the same problematic as with #=. There can't be just >>>> one #=. Other clients might consider other things when comparing >>>> objects. >>>> >>>> Lukas >>>> >>>> -- >>>> Lukas Renggli >>>> http://www.lukas-renggli.ch >>>> >>>> _______________________________________________ >>>> 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 >

Jan. 13, 2010

[Pharo-project] ODBC additions; very early GUI layer

by Schwab,Wilhelm K

I put two packages in PharoTaskForces. To any and all interested parties, I've added catalog methods to the existing ODBC wrapper. See the extension methods in ODBCConnection. You will have to excuse some gratuitous selectors that make my Dolphin ODBC code feel a little less unwelcome than it otherwise might. Gary, please take a quick look at the GUI package, in particular the TreeModel. Try TreePresenter example. I plan to make analogs to the staples from Dolphin's MVP framework: text, lists, trees, images. Value adapters will appear "soon." The handling of view resources will be a challenge. The usual caveats about backups appply, just in case. Bill

Jan. 13, 2010