November 2008 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] adrian .... help :)

by Adrian Lienhard

Hi Stef Yesterday evening I did another update and it worked fine... It looks like the counter was increased twice in your case. This can happen if the image is not fresh (the counter was set already) or the #prepareNewUpdate is executed twice. To prevent this in the future I changed how the counter is computed (now it does not lazily increase it anymore but it looks at the latest updateXXX number). The previous implementation of updateXXX number + 1 does not work anymore because the new process supports to get back to apply changes another time after the verification step and hence you do not know if the updateXXX method was already created or not. I did a small update (10135) to check and it worked. So I'm curious if it works reliably for you too now. Adrian On Nov 7, 2008, at 16:12 , StÃ©phane Ducasse wrote: > adrian > > could you have a look at the scriptloader because it gets > desynchronised (I had to change the number by hand this morning > again and I followed exactly the process). May be my image counter > was not correct. I think that this counter is > brittle. I would just do what we did before taking the lastest > updateXXX number + 1 > > Stef > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Nov. 7, 2008

Re: [Pharo-project] I would like to clean the inbox! Please read

by Lukas Renggli

The package MonticelloPackageRenaming-Noury.1 introduces 2 new menu items into the Monticello Browser, by overriding and extending several methods in Monticello. If this code is included with Pharo, it should become part of Monticello itself. There are 4 test cases included. Below I review the two new functionalities independently: 1. Replace Classes Prefix: This functionality is useful, however the implementation depends on the presence of the Refactoring Browser. Furthermore this functionality is already present in the Refactoring Browser (OB-Regex) in a more generic fashion. Open | Rewrite Class allows one to batch rename, batch copy and batch create a set of classes using regular expressions. 2. Rename Package: This functionality renames class categories and method protocols to match the new package name. The code also takes care of the dependencies and removing traces of the old package in the Monticello Browser. It does not depend on external functionality. There are however 3 major problems with the implementation: (1) Class extensions extinct if they do not match the package names in a case-sensitive way. PackageInfo treats class categories case-sensitive, but protocols are handled case-insensitive. (2) Packages that share the same prefix are wrongly renamed, even if PackageInfo does not consider them to be from the same package (for example Morphic and MorphicExtras). (3) The ancestry of the renamed package is not preserved, what makes merging packages across renaming impossible. Though, I don't know if such a functionality would be possible with Monticello at all? Given the number of problems I don't suggest to include these extensions for now. Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Nov. 7, 2008

Re: [Pharo-project] About Pharo - text to go with version 1.0

by Matthias Berth

Damien, Stefan, thanks for the comments - good points. I have tried to improve the text, see http://code.google.com/p/pharo/wiki/GettingStartedAbout It now has a list of packages that Pharo includes and another list of things that are not included. Newcomers can ignore these. Cheers Matthias On Thu, Nov 6, 2008 at 11:22 AM, Stefan Schmiedl <s(a)xss.de> wrote: > On Thu, 6 Nov 2008 08:00:14 +0100 > "Damien Cassou" <damien.cassou(a)gmail.com> wrote: > >> On Wed, Nov 5, 2008 at 10:12 PM, Matthias Berth >> <matthias.berth(a)googlemail.com> wrote: >> > * great tools, e.g. OmniBrowser with refactoring support >> > * polished user interface with TrueType fonts and Polymorph widgets >> >> Don't give the tool names. Newcomers don't care. > > ... if they don't know the names from somewhere else. And newcomers > are not the only ones reading "about" docs. How about > > "... with scalable fonts (TrueType) and ??? widgets (Polymorph)" > >> > but it is a fork: Do not expect Etoy/Nebraska to work in >> > Pharo. >> >> Again, Newcomers don't care in my opinion. > > Again: a newcomer to Pharo is not necessarily a newcomer to Smalltalk or > Squeak. I am a case in point: I intermittently dabbled with Squeak, so I have > a rough knowledge about the "kid stuff" living in the image. A clear statement > that this (for me) irrelevant stuff and its supporting cruft is removed, is a plus. > > Just making Smalltalk, > s. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Nov. 7, 2008

Re: [Pharo-project] Sunit Extensions breaking the TestRunner

by Alexandre Bergel

> When I load SUnit in pharoBox There is no SUnit package in PharoInbox. Are you referring to SUnitGUI-AlexandreBergel.15.mcz in Pharo? Obviously we should not have saved this file in Pharo, but in PharoInbox rather. I apologize for this. SUnitGUI-AlexandreBergel.15.mcz expects the method generateLastRunMethodNamed:for: to be present. This method is provided by two packages that may be found in PharoTreatedInbox. However there is something strange, the following method has disappeared from the image (I tried with an Core 10133 updated): -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= TestResult>>runCase: aTestCase | testCasePassed | testCasePassed := true. [[aTestCase runCase] on: self class failure do: [:signal | failures add: aTestCase. testCasePassed := false. signal return: false]] on: self class error do: [:signal | errors add: aTestCase. testCasePassed := false. signal return: false]. testCasePassed ifTrue: [passed add: aTestCase] -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Is there any reason for this? Our extension on storing results will have to be updated then... Alexandre > > I cannot run tests anymore! > David Alex can you really check? > > Guys I appreciate your work but it would be great if you could test > more > what you are doing because I spent a lot of time on problems like > that. > > Stef > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Nov. 7, 2008

Re: [Pharo-project] Sunit Extensions breaking the TestRunner

by StÃ©phane Ducasse

Thanks Stef On Nov 7, 2008, at 8:05 PM, Alexandre Bergel wrote: > Ok, I am having a look at it now... > > Alexandre > > On 7 Nov 2008, at 12:29, StÃ©phane Ducasse wrote: > >> Hi >> >> When I load SUnit in pharoBox >> I cannot run tests anymore! >> David Alex can you really check? >> >> Guys I appreciate your work but it would be great if you could test >> more >> what you are doing because I spent a lot of time on problems like >> that. >> >> Stef >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Nov. 7, 2008

Re: [Pharo-project] Sunit Extensions breaking the TestRunner

by Alexandre Bergel

Ok, I am having a look at it now... Alexandre On 7 Nov 2008, at 12:29, StÃ©phane Ducasse wrote: > Hi > > When I load SUnit in pharoBox > I cannot run tests anymore! > David Alex can you really check? > > Guys I appreciate your work but it would be great if you could test > more > what you are doing because I spent a lot of time on problems like > that. > > Stef > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Nov. 7, 2008

Re: [Pharo-project] I would like to clean the inbox! Please read

by StÃ©phane Ducasse

this is renaming... in inbox Tx lukas On Nov 7, 2008, at 6:54 PM, Lukas Renggli wrote: >> Can somebody (lukas for example) have a look at the code of noury >> on package >> renaming. >> Noury told me that it worked since years but lukas told me that >> renaming is not supported in MC >> so I'm puzzled. > > In what package is that? > > 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 >

Nov. 7, 2008

Re: [Pharo-project] I would like to clean the inbox! Please read

by Lukas Renggli

> Can somebody (lukas for example) have a look at the code of noury on package > renaming. > Noury told me that it worked since years but lukas told me that > renaming is not supported in MC > so I'm puzzled. In what package is that? Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Nov. 7, 2008

[Pharo-project] Strange primitives doing nothing

by Igor Stasenko

I'm exploring the exception support in VM, and found two strange primitives used by BlockClosure, which simply fail and doing nothing. primitiveMarkUnwindMethod "Primitive. Mark the method for exception unwinding. The primitive must fail after marking the context so that the regular code is run." self inline: false. ^self primitiveFail primitiveMarkHandlerMethod "Primitive. Mark the method for exception handling. The primitive must fail after marking the context so that the regular code is run." self inline: false. ^self primitiveFail Any ideas, why they still in use? Can there be something in between, when interpreter enters the method? Or, if nothing, then why they still there? :) -- Best regards, Igor Stasenko AKA sig.

Nov. 7, 2008

[Pharo-project] I would like to clean the inbox! Please read

by StÃ©phane Ducasse

So I will harvest what I can - collection - MC enh - copyright and I will move the rest to treated. Except I you shout and tell me that your code is ready for integration. Can somebody (lukas for example) have a look at the code of noury on package renaming. Noury told me that it worked since years but lukas told me that renaming is not supported in MC so I'm puzzled. Damien. P is your fix Name: System-damien.pollet.169 Author: damien.pollet Time: 26 October 2008, 6:31:21 pm UUID: 8baf2159-f018-43d3-b746- 5310f264ee81 Ancestors: System-damien.pollet.168 Set initials at the same time as name to avoid the infinite loop of Author>>initials ready? What is the status of the networkTests and Network submissions? Should I harvest them Stef

Nov. 7, 2008