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

Re: [Pharo-project] Issue 3507 in pharo: SUnitUnloader >> unloadTestPackages is wrong and outdated

by pharo＠googlecode.com

Updates: Cc: stephane.ducasse Comment #2 on issue 3507 by marianopeck: SUnitUnloader >> unloadTestPackages is wrong and outdated http://code.google.com/p/pharo/issues/detail?id=3507 In inbox Name: SLICE-Issue-3507-unloadTestPackagesIsOutdated-MarianoMartinezPeck.1 Author: MarianoMartinezPeck Time: 6 January 2011, 7:35:54 pm UUID: c182a210-fb4f-4205-9c26-4f1874864774 Ancestors: Dependencies: SUnit-MarianoMartinezPeck.40121 Fix to issue 3507

Jan. 6, 2011

Re: [Pharo-project] Issue 3507 in pharo: SUnitUnloader >> unloadTestPackages is wrong and outdated

by Adrian Lienhard

On Jan 6, 2011, at 17:54 , Mariano Martinez Peck wrote: > Thanks for the remark anyway Adrian. Now, after evaluating the unloads, I > open a Monticello Browser and I don't see any package as dirty. However, > this is not really confident. Sometimes Monticello shows a package not > direty, but just after doing a "changes" it gets dirty....is this enought or > I should do something else to be sure there are no dirties? Yes, there are indeed cases where the package is not correctly marked dirty. I think that's safe to verify with "changes", though. Cheers, Adrian

Jan. 6, 2011

Re: [Pharo-project] Origins [poll]

by Bernardo Ezequiel Contreras

Jan. 6, 2011

Re: [Pharo-project] Monticello and source origin

by StÃ©phane Ducasse

yes more meta data would help Stef On Jan 5, 2011, at 9:06 AM, Torsten Bergmann wrote: > When I create a changeset and file it out I can see > the image (Pharo/Squeak and version) that was used > to create the code in the header. > > Currently when I find an MCZ somewhere on the web > I'm not able to see if Pharo 1.0 or Pharo 1.2 or > Squeak 4.1 was used to create it. > > At least I havent found something when I check > "package", "version", "snapshot.bin" or "snapshot"/source > in the ZIP. > > Would'nt it make sense to add something like this? > > Thx > Torsten > > > -- > Neu: GMX De-Mail - Einfach wie E-Mail, sicher wie ein Brief! > Jetzt De-Mail-Adresse reservieren: http://portal.gmx.net/de/go/demail >

Jan. 6, 2011

Re: [Pharo-project] Origins [poll]

by Alexandre Bergel

It would be cool to know what are your key interests Alexandre On 6 Jan 2011, at 14:04, Bernardo Ezequiel Contreras wrote: > Name|Native Language|Greeting in native lang|Born country|Writing from > > Bernardo Contreras | Spanish | Hola | Argentina | Buenos Aires, Argentina > > > cheers > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Jan. 6, 2011

Re: [Pharo-project] Monticello and source origin

by Mariano Martinez Peck

That's true. It should be possible to do..maybe you need to: - Modify the commti so that in add the first line (like the fileOut does) with such info into the source.st - Modify squeaksource or whatever so that it lets you unzip the mzc, open the source.st and take the first line or something like that. On Wed, Jan 5, 2011 at 9:06 AM, Torsten Bergmann <astares(a)gmx.de> wrote: > When I create a changeset and file it out I can see > the image (Pharo/Squeak and version) that was used > to create the code in the header. > > Currently when I find an MCZ somewhere on the web > I'm not able to see if Pharo 1.0 or Pharo 1.2 or > Squeak 4.1 was used to create it. > > At least I havent found something when I check > "package", "version", "snapshot.bin" or "snapshot"/source > in the ZIP. > > Would'nt it make sense to add something like this? > > Thx > Torsten > > > -- > Neu: GMX De-Mail - Einfach wie E-Mail, sicher wie ein Brief! > Jetzt De-Mail-Adresse reservieren: http://portal.gmx.net/de/go/demail > >

Jan. 6, 2011

Re: [Pharo-project] why (MCPackage named: 'NonExistenPackage') unload. doesnt fail ?

by Mariano Martinez Peck

On Thu, Jan 6, 2011 at 3:46 PM, Mariano Martinez Peck <marianopeck(a)gmail.com > wrote: > > > On Thu, Jan 6, 2011 at 3:32 PM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>wrote: > >> +1. Someone wanting something that "just runs" can/should do something >> like >> >> (MCPackage named: 'HelpSystem' ifNone:'[ DeafObject current ]) unload >> > > Exactly. > Now...I don't know the impact of doing this change. Maybe we screw up > monticello hehehe > > Even more.... If you have the packages: 'HelpSystem-Core' and 'HelpSystem-Tests', what do you think that happens if I do: (MCPackage named: 'HelpSystem') unload. All classes and categories are removed and the two packages 'HelpSystem-Core' and 'HelpSystem-Tests' are kept and marked as dirty.... grrrrrr > cheer > > mariano > > >> >> >> Another approach is to trap and log errors so that a lengthy build process >> completes and then clearly shows where it encountered problems. >> >> Bill >> >> >> ________________________________________ >> From: pharo-project-bounces(a)lists.gforge.inria.fr [ >> pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of StÃ©phane >> Ducasse [stephane.ducasse(a)inria.fr] >> Sent: Thursday, January 06, 2011 6:11 AM >> To: Pharo-project(a)lists.gforge.inria.fr >> Subject: Re: [Pharo-project] why (MCPackage named: 'NonExistenPackage') >> unload. doesnt fail ? >> >> > Do we want that? I am finding a lot of outdated code that uses code like >> that and it doesnt fail, but still doesnt unload the package. >> > >> > For example, cleanUpForRelease does a >> > (MCPackage named: 'HelpSystem') unload. >> > >> > and that package doesnt exist anymore since it was split.... >> > >> > so...do we want that silent behaviour ? >> >> probably not. >> Better fix the scripts as early as possible >> >> > >> > cheers >> > >> > mariano >> >> >> >> >

Jan. 6, 2011

Re: [Pharo-project] Origins [poll]

by Bernardo Ezequiel Contreras

Jan. 6, 2011

Re: [Pharo-project] Issue 3508 in pharo: cleanUpForProduction should really unload 'Graphics-Resources'

by pharo＠googlecode.com

Comment #3 on issue 3508 by marianopeck: cleanUpForProduction should really unload 'Graphics-Resources' http://code.google.com/p/pharo/issues/detail?id=3508 Hi Adrian. Are you checking in Pharo1.2 ? Because I don't see any package GraphicsResources and in addition, if I browse Graphics-Resources I see the class extensions with the correct caegory *GraphicsResources Finally, I don't see a package Graphics, but instead all Graphics-Something cheers

Jan. 6, 2011

Re: [Pharo-project] Issue 3507 in pharo: SUnitUnloader >> unloadTestPackages is wrong and outdated

by Mariano Martinez Peck

On Thu, Jan 6, 2011 at 11:00 AM, Adrian Lienhard <adi(a)netstyle.ch> wrote: > Hi Torsten, > > Sorry, you are right. I apparently checked this in an 1.1.1 image (and I > forgot that you have refactored Regex). Splitting the package up into -Core > -Help and -Tests is a good solution indeed. > > So the change of #unloadTestPackages proposed by Mariano makes perfect > sense. > > Thanks for the remark anyway Adrian. Now, after evaluating the unloads, I open a Monticello Browser and I don't see any package as dirty. However, this is not really confident. Sometimes Monticello shows a package not direty, but just after doing a "changes" it gets dirty....is this enought or I should do something else to be sure there are no dirties? thanks mariano > Cheers, > Adrian > > > On Jan 6, 2011, at 10:08 , Torsten Bergmann wrote: > > >> I have the following remark: when I implemented this I took care to make > all >remaining packages non-dirty. For example, you unload > "Regex-Tests-Core" and >this will change the contents of the "Regex" package > and hence make it >dirty. To avoid this, I moved tests into their own > package â either into > >> ... > >> Apparently somebody didn't take care when updating VB-Regex because the > >tests are back in the main Regex package. > > > > Hi Adrian, > > > > I dont understand what you mean: > > > > Anything we forgot was to update #unloadTestPackages (which is now > > solved with issue 3507 by Mariano). > > > > In Pharo1.2beta #12292 there is no "VB-Regex" or "Regex" package > > anymore. So nothing to become dirty here. > > > > There is a "Regex-Core", "Regex-Help" and "Regex-Tests-Core". > > So test can easily be unloaded and existing packages are > > still clean. > > > > And yes ... if you would manually create a package "Regex" > > then it would have become "dirty" (because class categories > > are abused). But we know that and it can only be solved by > > introducing real packages. Using a "RegexTest..." package > > icould be a workaround and avoids this - but we use the > > same naming scheme as Seaside. > > > > Bye > > T. > > > > > > > > > > -- > > GMX DSL Doppel-Flat ab 19,99 Euro/mtl.! Jetzt mit > > gratis Handy-Flat! http://portal.gmx.net/de/go/dsl > > > > >

Jan. 6, 2011