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

Re: [Pharo-project] clone vs shallowCopy

by Nicolas Cellier

2010/1/12 Bouraqadi Noury <bouraqadi(a)gmail.com>: > Hi, > > I found the clone primitive method in the Object class. > Its behavior looks the same as shallowCopy. Actually, shallowCopy just > sends basicShallowCopy wich calls the same primitive as clone > (primitive 148). > > a1 := Array with: Object new. > a2 := a1 clone. > a1 == a2. "--->false" > a1 first == a2 first. "--->true" > > When I look to senders (in a pharo-dev 12.2) I find the following: > -62 senders of clone. > -2 senders of basicShallowCopy > -66 senders of shallowCopy > > Looking to implementors I found: > -9 implementors of shallowCopy (all are kernel classes) > -1 implementor of basicShallowCopy (not surprizing) > -6 implementors of clone (all are kernel classes) > > Most implementors of clone and shallowCopy are different. > Yet, implementations done by same classes are the same behavior. > Other implementations of clone answer self, because there are for > objects that should/can't be copied (e.g. SmallInteger, Character). > > So, I suggest to remove clone and use shallowCopy instead (better/more > precise name). > Anybody has any reeason against? Otherwise, I'll do it. > > Noury > > basicShallowCopy was a workaround for some badly written copy in OrderedCollection. I did add it, then removed it in squeak/trunk. I suggest following the same path in Pharo. You can also remove Float>>shallowCopy since super would perform as well. I corrected it recently for fun, but it should better be removed (was removed from squeak/trunk). For clone, I don't know. Nicolas > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Jan. 12, 2010

Re: [Pharo-project] Error when i try save a image [WAS] Fwd: [BetaTesting] [ANN] Pharo1.0-10505-rc1dev10.01.1

by Mariano Martinez Peck

The problem is that when you save the image, in the shutDown list, there is freetype and it tries to finish all the handlers. The problem in this case is that one of those handlers that seems to be trying to finish has something in nil or some bad parameter which of course, gives a primitive mail. That's all my idea, maybe I am wrong as it is the first time I look in this code. As a work arround, you can install the StrikeFOnts instead of TrueTypes. It is not the real solution, but works. Just take the dev image with trutype and evaluate: FreeTypeCache clearCurrent. StrikeFont installDejaVu. Cheers On Mon, Jan 11, 2010 at 5:30 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > I could reproduce the problem. epicfan which OS are you using ? VM version > ? > > > On Mon, Jan 11, 2010 at 5:18 PM, Mariano Martinez Peck < > marianopeck(a)gmail.com> wrote: > >> yes, actually that's was the mail about. >> >> >> >> On Mon, Jan 11, 2010 at 5:11 PM, StÃ©phane Ducasse < >> stephane.ducasse(a)inria.fr> wrote: >> >>> Do Yyou still have the problem with the latest rc version? >>> >>> Stef >>> On Jan 11, 2010, at 5:02 PM, Mariano Martinez Peck wrote: >>> >>> > Sorry epicfan I have no idea at all. I cc Pharo mailing list that maybe >>> someone can help you. >>> > >>> > I was going to cc nullPointer, but I discover it is you!!! hahahahah >>> > >>> > >>> > ---------- Forwarded message ---------- >>> > From: <epicfan(a)gmail.com> >>> > Date: Mon, Jan 11, 2010 at 4:46 PM >>> > Subject: Re: [BetaTesting] [ANN] Pharo1.0-10505-rc1dev10.01.1 >>> > To: marianopeck(a)gmail.com >>> > >>> > >>> > The next error: >>> > >>> > >>> http://code.google.com/p/pharo/issues/detail?id=1283&can=7&q=bug%20when%20t… >>> > >>> > In the last version of developer image that error was fix it. But in >>> that 10505 image returns :| >>> > >>> > Regards. >>> > >>> > >>> > >>> > >>> > PD. Could I do something in my code for delete that problem? >>> > >>> > Regards again. >>> > >>> > _______________________________________________ >>> > 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. 12, 2010

Re: [Pharo-project] clone vs shallowCopy

by Igor Stasenko

2010/1/12 Levente Uzonyi <leves(a)elte.hu>: > On Tue, 12 Jan 2010, Bouraqadi Noury wrote: > >> Hi, >> >> I found the clone primitive method in the Object class. >> Its behavior looks the same as shallowCopy. Actually, shallowCopy just >> sends basicShallowCopy wich calls the same primitive as clone >> (primitive 148). >> > > I wonder what image do you use. In a standard image #clone is primitive > only, while #shallowCopy tries to copy the object if the primitive fails. > #basicShallowCopy doesn't exist. > I am using #clone, to be 100% sure that i cloning object primitively, without additional logic, which #shallowCopy may introduce. > > Levente > >> a1 := Array with: Object new. >> a2 := a1 clone. >> a1 == a2. "--->false" >> a1 first == a2 first. "--->true" >> >> When I look to senders (in a pharo-dev 12.2) I find the following: >> -62 senders of clone. >> -2 senders of basicShallowCopy >> -66 senders of shallowCopy >> >> Looking to implementors I found: >> -9 implementors of shallowCopy (all are kernel classes) >> -1 implementor of basicShallowCopy (not surprizing) >> -6 implementors of clone (all are kernel classes) >> >> Most implementors of clone and shallowCopy are different. >> Yet, implementations done by same classes are the same behavior. >> Other implementations of clone answer self, because there are for >> objects that should/can't be copied (e.g. SmallInteger, Character). >> >> So, I suggest to remove clone and use shallowCopy instead (better/more >> precise name). >> Anybody has any reeason against? Otherwise, I'll do it. >> >> Noury >> >> >> >> >> >> _______________________________________________ >> 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 > -- Best regards, Igor Stasenko AKA sig.

Jan. 12, 2010

Re: [Pharo-project] clone vs shallowCopy

by Levente Uzonyi

On Tue, 12 Jan 2010, Bouraqadi Noury wrote: > Hi, > > I found the clone primitive method in the Object class. > Its behavior looks the same as shallowCopy. Actually, shallowCopy just > sends basicShallowCopy wich calls the same primitive as clone > (primitive 148). > I wonder what image do you use. In a standard image #clone is primitive only, while #shallowCopy tries to copy the object if the primitive fails. #basicShallowCopy doesn't exist. Levente > a1 := Array with: Object new. > a2 := a1 clone. > a1 == a2. "--->false" > a1 first == a2 first. "--->true" > > When I look to senders (in a pharo-dev 12.2) I find the following: > -62 senders of clone. > -2 senders of basicShallowCopy > -66 senders of shallowCopy > > Looking to implementors I found: > -9 implementors of shallowCopy (all are kernel classes) > -1 implementor of basicShallowCopy (not surprizing) > -6 implementors of clone (all are kernel classes) > > Most implementors of clone and shallowCopy are different. > Yet, implementations done by same classes are the same behavior. > Other implementations of clone answer self, because there are for > objects that should/can't be copied (e.g. SmallInteger, Character). > > So, I suggest to remove clone and use shallowCopy instead (better/more > precise name). > Anybody has any reeason against? Otherwise, I'll do it. > > Noury > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Jan. 12, 2010

Re: [Pharo-project] Spell check test cases

by Lukas Renggli

> I think you didn't pick up the other fix in RBBugFixes > > RBLiteralValuesSpellingRule>>initialize > Â Â Â Â super initialize. > Â Â Â Â matcher := RBParseTreeSearcher new. > Â Â Â Â matcher matches: '`#literal' > Â Â Â Â Â Â Â Â do: > Â Â Â Â Â Â Â Â Â Â Â Â [ :node :answer | > Â Â Â Â Â Â Â Â Â Â Â Â | nodeValue | > Â Â Â Â Â Â Â Â Â Â Â Â nodeValue := node value. > Â Â Â Â Â Â Â Â Â Â Â Â (nodeValue isString or: [ nodeValue isSymbol or: [ nodeValue isCollection > ] ]) ifTrue: > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â [ answer add: nodeValue ]. > Â Â Â Â Â Â Â Â Â Â Â Â answer ] Thank you. Indeed, I did not see this change. I implemented it slightly different to ignore ByteArrays and to flatten out nested literal array collections. > The tests are on 'RB' 'OK' etc, in the quotes in class comments. Leading > capitals are stripped off. If $' is passed through, the check gets made on > K', and as it is 2 characters doesn't get disallowed. That's why the tests > need the pass through of ' taken out at the moment. If instead, Â where you > store the result: > Â result add: output contents > if you strip out trailing $' before storing, this would let you verify don't > and smalltalk's as well, I think. > Then you'd need a different test from the position in the stream for size = > 1. > > I only hit this edge case because I had a class comment about namespace > related prefixes- 'WA' 'RB' etc. > > So now 'OK' is not checked, under the 'strip out leading capitals' scenario. > At some point it might be nice to check these as well - eg WARenderCanvas > rather than WBRenderCanvas. YAGNI, NASA, other abbreviations. > > Code Critics browser still doesn't show Method Protocols in bold. In bold? They are highlighted here. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Jan. 12, 2010

Re: [Pharo-project] [Feature Request] Better integration with OSX Window Management

by Stefan Marr

Hi Eliot: On 11 Jan 2010, at 19:26, Eliot Miranda wrote: > Hi Stefan, > > not much of a comfort but as a work-=around I *think* you can fix the problem either by > - disconnecting the second monitor, which will rearrange all the windows onto your laptop screen, and then reattach the second monitor > or > - choosing Turn On Mirroring from the displays menu, which will also rearrange windows, and then turn off mirroring No, it does not. I have to explicitly go to my monitor arrangement settings and restore the configuration I have at home. Just experienced it again. Any idea where I could start to look at that? Thanks Stefan > > On Mon, Jan 11, 2010 at 4:34 AM, Stefan Marr <pharo(a)stefan-marr.de> wrote: > Hello: > > I just had a very annoying experience with the lake of sufficient window management tools on Mac OS X. (Annoying enough to write this mail...) > > > The following happened: > > At home I have a external screen attached to my mac book, it is configured to be a secondary screen positioned above the main (internal) screen. > > The Pharo window was moved to that screen. > > In the office, I have another configuration, and there was no way to get hold of the Pharo window anymore. > > It remembered its positioning and was just of screen. Expose allows me to see it, and shows even a beautiful animation moving it out of reach after clicking on it. > > Obviously the menu SqueakVM > Quit is not really helpful, since the question whether to save or not is displayed unreachable off screen, too. > > > > I am not sure whether the standard OS X window menu functionality with "minimize" and "zoom" would help here, but might be a start. On the other hand, I would guess, that the OSX windowing systems sends some events which could be handled like all other windows do. > > > The only workaround for the moment, is to have a external screen and fiddle with the screen configuration and positioning until I can get hold of the window... Not exactly convenient. > > > Best regards > Stefan > > -- > Stefan Marr > Software Languages Lab > Vrije Universiteit Brussel > Pleinlaan 2 / B-1050 Brussels / Belgium > http://soft.vub.ac.be/~smarr > Phone: +32 2 629 3956 > Fax: +32 2 629 3525 > > > _______________________________________________ > 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 -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 3956 Fax: +32 2 629 3525

Jan. 12, 2010

Re: [Pharo-project] Etymology of #perform:?

by Levente Uzonyi

On Tue, 12 Jan 2010, Adrian Kuhn wrote: > Smalltalk is based on message sending, but sending a method is called #perform: > rather than #send:? When I read aloud the code is it "perform a message" or You don't send a method, but a message. The message contains a method and optionally arguments. > "perform a method", both seem to be wrong. The first since, well, methods are > sent not performed. And the second since, well, the argument is a message and a > not a method. What is the etymology or rational for this? Maybe if one of the The argument is a selector which is the name of the method that should be performed. Levente > old Smalltalkers (or Marcus with his awesome knowledge of Smalltalk history) > can elaborate on this? > > --AA > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Jan. 12, 2010

[Pharo-project] clone vs shallowCopy

by Bouraqadi Noury

Hi, I found the clone primitive method in the Object class. Its behavior looks the same as shallowCopy. Actually, shallowCopy just sends basicShallowCopy wich calls the same primitive as clone (primitive 148). a1 := Array with: Object new. a2 := a1 clone. a1 == a2. "--->false" a1 first == a2 first. "--->true" When I look to senders (in a pharo-dev 12.2) I find the following: -62 senders of clone. -2 senders of basicShallowCopy -66 senders of shallowCopy Looking to implementors I found: -9 implementors of shallowCopy (all are kernel classes) -1 implementor of basicShallowCopy (not surprizing) -6 implementors of clone (all are kernel classes) Most implementors of clone and shallowCopy are different. Yet, implementations done by same classes are the same behavior. Other implementations of clone answer self, because there are for objects that should/can't be copied (e.g. SmallInteger, Character). So, I suggest to remove clone and use shallowCopy instead (better/more precise name). Anybody has any reeason against? Otherwise, I'll do it. Noury

Jan. 12, 2010

[Pharo-project] Failing tests in PharoDev image

by Mariano Martinez Peck

Hi fokls: Let's do the last effort. We have little failing tests in new Dev image. We even have all the OB tests in green!! thanks Lukas Now, the current failing tests are: - ProcessSpecificTest has two tests: testDynamicVariable and testLocalVariable both fails when the first time that are run. However, if I re run them, they are green. The same happens with MCPackageTest >> testUnload - testUndeclare Here I have a problem with OB for example. OBPluggableService is used in OBDefinitionPanelTest >> scanCommands: but OBPluggableService doesn't exist. I don't know where it is that class. - OBButtonBarTest >> testLayout is failing in "self assert: rects third right <= bar right" because "rects third right" answers 402 and "bar right " ansers 400. - There is also ObjectFinalizerTests testFinalizationOfEquals As it is says here: http://code.google.com/p/pharo/issues/detail?id=1564 Ok, any help you can give would be cool. Thanks Mariano

Jan. 12, 2010

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

by Mariano Martinez Peck

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 >

Jan. 12, 2010