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

[Pharo-project] Re: #2

by nicolas cellier

Igor Stasenko <siguctua@...> writes: > > 2008/10/10 StÃ©phane Ducasse <stephane.ducasse <at> inria.fr>: > > Yeap it would be good to fix that. > > for me > > > > #2 -> #'2' > > ## -> #'#' > > so, > ##word > should be treated as: > > '#' asSymbol word > > ? ## is questionable: we can accept such a syntax, but what for exactly? If no valuable reason, shouldn't we better enforce syntaxic check in Parser and signal malformed statements as an error as would any other Smalltalk? Quite sure that NewCompiler already fix all this stuff. What are the plans about its integration? Waiting for Eliot's COG?

Oct. 10, 2008

Re: [Pharo-project] Re: #2

by StÃ©phane Ducasse

> >> Yeap it would be good to fix that. >> for me >> >> #2 -> #'2' >> ## -> #'#' > > so, > ##word > should be treated as: > > '#' asSymbol word '#' asSymbol produces #'#' so I do not know if this is what I want but we could have #something -> #'something' so #123 - returns a symbol and not a number. and keep #( #{ #( for stuff if we want in the futur. #[ ] #{ } #( )

Oct. 10, 2008

Re: [Pharo-project] History and SUnit

by Alexandre Bergel

There is the history button. You can save a result to compare them later. Alexandre On 10 Oct 2008, at 16:44, Damien Pollet wrote: > On Fri, Oct 10, 2008 at 1:25 PM, Alexandre Bergel > <alexandre(a)bergel.eu> wrote: >>> - I don't understand the "Progress" feature. What I did is run the >>> tests, >>> then "Store results", then I fixed a failing test, then "Run >>> Failures", then >>> "Show progress". But nothing happens. Maybe I did something wrong? >> >> Result is displayed in the Transcript. Sorry to not have said it >> before. >> We though first about opening a workspace with the result inside, >> but I did >> not find an easy way to do it. So, for now, it prints in the >> Transcript. > > What about summarizing progress with the passes/failures/errors > statistics after each run, and if one wants more details, then > clicking on the statistics opens a workspace with the detailed list of > fixed/broken tests ? > > -- > Damien Pollet > type less, do more [ | ] http://people.untyped.org/damien.pollet > > _______________________________________________ > 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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Oct. 10, 2008

Re: [Pharo-project] Level Playing Field: an overview

by StÃ©phane Ducasse

Matthew could you sign the license agreement (MIT) of pharo? Stef On Oct 10, 2008, at 6:04 PM, Matthew Fulmer wrote: > On Fri, Oct 10, 2008 at 02:31:49PM +0200, St?phane Ducasse wrote: >> I would like to be able to get rid of PLF for loading MC1.6 or >> friend. > > There is a good reason that LPF exists. Monticello is by far > the flakiest package to load with Monticello. Unless you are > using an atomic loader, you are changing the code of Monticello > while running Monticello, and it can and does fail in > unpredictable ways. LPF uses a two-phase process, where > Monticello is loaded _twice_, first from file-outs, then from > .mcz's to make it work reliably. You can see the script > responsible for this bit of hackery at: > > http://installer.pbwiki.org/LevelPlayingField-Monticello15 > > On top of that, Monticello, as of 3.9, depends on Traits, and so > Monticello does not work correctly in images outside the 3.9 > tree. So LPF, in order to load MC into anything other than 3.9 > and above, has a backport package whereby enough of Traits and > Pragma are stubbed out for Monticello to work in all other > images. There are two backports, one for Croquet, and one for > everything else: > > http://installer.pbwiki.org/LevelPlayingField-Croquet1:0beta > http://installer.pbwiki.org/LevelPlayingField-Squeak3:8 > > Furthermore, LPF applies several bug fixes to things outside > Monticello and PackageInfo to make it work more reliably. You > can see which bugs are fixed by browsing the script: > > http://installer.pbwiki.org/LevelPlayingField > > If you look at that page, you can see that Monticello 1.5 is > supported on 15 different versions of Squeak, which, I think, is > quite a feat > > Once you have bootstrapped MC1.6, LPF becomes unnecessary, since > you can now upgrade Monticello anytime, since the loader is > atomic. MC1.5 has a non-atomic loader, so still requires LPF > for reliable upgrades. so, once MC1.6 is in Pharo, you won't > need LPF anymore. > > MC1.6 has made pretty good progress. It is very reliable, but I > still haven't made it work with Traits. I use MC1.6 exclusively. > > MC1.6 is just MC1.5 with the non-atomic loader replaced with an > atomic loader dependent on SystemEditor. The atomic loader is > included with MC1.5, but is disabled. To load it, load > SystemEditor, then enable the preference > #useMonticelloAtomicLoader : > > http://installer.pbwiki.org/Monticello16-Beta > > > Hopefully, that explains what LPF is all about. I realize you > may not like the way it is implemented, as scripts on a wiki > page. I'm working on that. I'm working on a build script that > could build Monticello-1.5.x.sar that includes most everything > in LPF, but with no dependency on Installer. > > In the meantime, here are the precise steps in order to load > MC1.5 into Pharo, derived from LPF: > > Recommended fix: > 1. Install the fix for bug 7131 > > Required fix: > 1. Install the fix for bug 7205 > > To install or upgrade MC1.5: > 1. Load the latest PackageInfo-Base using either a file-out, or > using MczInstaller, but *NOT* using Monticello > 2. Load the latest Monticello.impl using a file-out, or using > MczInstaller, but *NOT* using Monticello > 3. Load the latest PackageInfo-Base again, this time using > Monticello > 4. Load the latest Monticello.impl again, this time using > Monticello > > After installing MC1.5 for the first time, clear all MC caches > of MC 1.0 leftovers: > > (MCPackage named: 'Monticello') workingCopy unregister! > (MCPackage named: 'PackageInfo') workingCopy unregister! > MCMethodDefinition freeSomeSpace! > MCFileBasedRepository freeSomeSpace! > DataStream initialize! > > To switch from MC1.5 to MC1.6: > 1. Install the latest SystemEditor > 2. Enable the preference #useMonticelloAtomicLoader > > To upgrade MC1.6: > 1. Install the latest SystemEditor > 2. Install the latest PackageInfo-Base > 3. Install the latest Monticello.impl > > -- > Matthew Fulmer -- http://mtfulmer.wordpress.com/ > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 10, 2008

Re: [Pharo-project] Re: #2

by Igor Stasenko

2008/10/10 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > Yeap it would be good to fix that. > for me > > #2 -> #'2' > ## -> #'#' so, ##word should be treated as: '#' asSymbol word ? > #something that is not a ( should be > #'something' > > Stef > > On Oct 10, 2008, at 5:38 PM, nicolas cellier wrote: > >> Igor Stasenko <siguctua@...> writes: >> >>> >>> hello stef, >>> >>> recently i poked with scanner/parser and i wonder what possible >>> literals/combinations are correct and what is not: >>> >>> - a well known: >>> >>> #word , #keyword(s) -- Symbolic literal >>> #- #* ... etc. Symbolic literal >>> #( ...) -- array literal >>> >>> - now what about these: >>> >>> #123 -- number, or '123' asSymbol? >>> >>> ##( ... ) --- ?? >>> ##word --- ?? >>> ##... -- ??? >>> ###... --- ??? >>> >> >> Hehe >> >> that reminds me >> >> http://lists.squeakfoundation.org/pipermail/squeak-dev/2007-May/117145.html >> >> http://lists.squeakfoundation.org/pipermail/squeak-dev/2007-May/117153.html >> >> I see not all are fixed in old compiler. >> Also note the discrepancy between parsing and printing >> You might want to fix #isLiteralSymbol: too... >> >> >> _______________________________________________ >> 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.

Oct. 10, 2008

Re: [Pharo-project] Level Playing Field: an overview

by StÃ©phane Ducasse

Thanks matthew for all the explanation. You know we are careful because all our infrastructure depends on MC. :) Now about the two steps process this is important to have it because it is important to be able in the future to have an image without MC. Or at least to keep that in mind. I will look at Kernel-Extensions and the fixes you mention. Could you add them in the bug tracking system? This way we increase the chance that we really check them. Stef > On Fri, Oct 10, 2008 at 02:31:49PM +0200, St?phane Ducasse wrote: >> I would like to be able to get rid of PLF for loading MC1.6 or >> friend. > > There is a good reason that LPF exists. Monticello is by far > the flakiest package to load with Monticello. Unless you are > using an atomic loader, you are changing the code of Monticello > while running Monticello, and it can and does fail in > unpredictable ways. LPF uses a two-phase process, where > Monticello is loaded _twice_, first from file-outs, then from > .mcz's to make it work reliably. You can see the script > responsible for this bit of hackery at: > > http://installer.pbwiki.org/LevelPlayingField-Monticello15 > > On top of that, Monticello, as of 3.9, depends on Traits, and so > Monticello does not work correctly in images outside the 3.9 > tree. So LPF, in order to load MC into anything other than 3.9 > and above, has a backport package whereby enough of Traits and > Pragma are stubbed out for Monticello to work in all other > images. There are two backports, one for Croquet, and one for > everything else: > > http://installer.pbwiki.org/LevelPlayingField-Croquet1:0beta > http://installer.pbwiki.org/LevelPlayingField-Squeak3:8 > > Furthermore, LPF applies several bug fixes to things outside > Monticello and PackageInfo to make it work more reliably. You > can see which bugs are fixed by browsing the script: > > http://installer.pbwiki.org/LevelPlayingField > > If you look at that page, you can see that Monticello 1.5 is > supported on 15 different versions of Squeak, which, I think, is > quite a feat > > Once you have bootstrapped MC1.6, LPF becomes unnecessary, since > you can now upgrade Monticello anytime, since the loader is > atomic. MC1.5 has a non-atomic loader, so still requires LPF > for reliable upgrades. so, once MC1.6 is in Pharo, you won't > need LPF anymore. > > MC1.6 has made pretty good progress. It is very reliable, but I > still haven't made it work with Traits. I use MC1.6 exclusively. > > MC1.6 is just MC1.5 with the non-atomic loader replaced with an > atomic loader dependent on SystemEditor. The atomic loader is > included with MC1.5, but is disabled. To load it, load > SystemEditor, then enable the preference > #useMonticelloAtomicLoader : > > http://installer.pbwiki.org/Monticello16-Beta > > > Hopefully, that explains what LPF is all about. I realize you > may not like the way it is implemented, as scripts on a wiki > page. I'm working on that. I'm working on a build script that > could build Monticello-1.5.x.sar that includes most everything > in LPF, but with no dependency on Installer. > > In the meantime, here are the precise steps in order to load > MC1.5 into Pharo, derived from LPF: > > Recommended fix: > 1. Install the fix for bug 7131 > > Required fix: > 1. Install the fix for bug 7205 > > To install or upgrade MC1.5: > 1. Load the latest PackageInfo-Base using either a file-out, or > using MczInstaller, but *NOT* using Monticello > 2. Load the latest Monticello.impl using a file-out, or using > MczInstaller, but *NOT* using Monticello > 3. Load the latest PackageInfo-Base again, this time using > Monticello > 4. Load the latest Monticello.impl again, this time using > Monticello > > After installing MC1.5 for the first time, clear all MC caches > of MC 1.0 leftovers: > > (MCPackage named: 'Monticello') workingCopy unregister! > (MCPackage named: 'PackageInfo') workingCopy unregister! > MCMethodDefinition freeSomeSpace! > MCFileBasedRepository freeSomeSpace! > DataStream initialize! > > To switch from MC1.5 to MC1.6: > 1. Install the latest SystemEditor > 2. Enable the preference #useMonticelloAtomicLoader > > To upgrade MC1.6: > 1. Install the latest SystemEditor > 2. Install the latest PackageInfo-Base > 3. Install the latest Monticello.impl > > -- > Matthew Fulmer -- http://mtfulmer.wordpress.com/ > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 10, 2008

Re: [Pharo-project] Re: #2

by StÃ©phane Ducasse

Yeap it would be good to fix that. for me #2 -> #'2' ## -> #'#' #something that is not a ( should be #'something' Stef On Oct 10, 2008, at 5:38 PM, nicolas cellier wrote: > Igor Stasenko <siguctua@...> writes: > >> >> hello stef, >> >> recently i poked with scanner/parser and i wonder what possible >> literals/combinations are correct and what is not: >> >> - a well known: >> >> #word , #keyword(s) -- Symbolic literal >> #- #* ... etc. Symbolic literal >> #( ...) -- array literal >> >> - now what about these: >> >> #123 -- number, or '123' asSymbol? >> >> ##( ... ) --- ?? >> ##word --- ?? >> ##... -- ??? >> ###... --- ??? >> > > Hehe > > that reminds me > http://lists.squeakfoundation.org/pipermail/squeak-dev/2007-May/117145.html > http://lists.squeakfoundation.org/pipermail/squeak-dev/2007-May/117153.html > > I see not all are fixed in old compiler. > Also note the discrepancy between parsing and printing > You might want to fix #isLiteralSymbol: too... > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 10, 2008

Re: [Pharo-project] problem with cursor

by StÃ©phane Ducasse

Indeed this sounds much better. What a crap. I will really curve out this etoy crap./ Stef On Oct 10, 2008, at 4:37 PM, David RÃ¶thlisberger wrote: > Utilities cleanseOtherworldlySteppers

Oct. 10, 2008

[Pharo-project] Level Playing Field: an overview

by Matthew Fulmer

On Fri, Oct 10, 2008 at 02:31:49PM +0200, St?phane Ducasse wrote: > I would like to be able to get rid of PLF for loading MC1.6 or friend. There is a good reason that LPF exists. Monticello is by far the flakiest package to load with Monticello. Unless you are using an atomic loader, you are changing the code of Monticello while running Monticello, and it can and does fail in unpredictable ways. LPF uses a two-phase process, where Monticello is loaded _twice_, first from file-outs, then from .mcz's to make it work reliably. You can see the script responsible for this bit of hackery at: http://installer.pbwiki.org/LevelPlayingField-Monticello15 On top of that, Monticello, as of 3.9, depends on Traits, and so Monticello does not work correctly in images outside the 3.9 tree. So LPF, in order to load MC into anything other than 3.9 and above, has a backport package whereby enough of Traits and Pragma are stubbed out for Monticello to work in all other images. There are two backports, one for Croquet, and one for everything else: http://installer.pbwiki.org/LevelPlayingField-Croquet1:0beta http://installer.pbwiki.org/LevelPlayingField-Squeak3:8 Furthermore, LPF applies several bug fixes to things outside Monticello and PackageInfo to make it work more reliably. You can see which bugs are fixed by browsing the script: http://installer.pbwiki.org/LevelPlayingField If you look at that page, you can see that Monticello 1.5 is supported on 15 different versions of Squeak, which, I think, is quite a feat Once you have bootstrapped MC1.6, LPF becomes unnecessary, since you can now upgrade Monticello anytime, since the loader is atomic. MC1.5 has a non-atomic loader, so still requires LPF for reliable upgrades. so, once MC1.6 is in Pharo, you won't need LPF anymore. MC1.6 has made pretty good progress. It is very reliable, but I still haven't made it work with Traits. I use MC1.6 exclusively. MC1.6 is just MC1.5 with the non-atomic loader replaced with an atomic loader dependent on SystemEditor. The atomic loader is included with MC1.5, but is disabled. To load it, load SystemEditor, then enable the preference #useMonticelloAtomicLoader : http://installer.pbwiki.org/Monticello16-Beta Hopefully, that explains what LPF is all about. I realize you may not like the way it is implemented, as scripts on a wiki page. I'm working on that. I'm working on a build script that could build Monticello-1.5.x.sar that includes most everything in LPF, but with no dependency on Installer. In the meantime, here are the precise steps in order to load MC1.5 into Pharo, derived from LPF: Recommended fix: 1. Install the fix for bug 7131 Required fix: 1. Install the fix for bug 7205 To install or upgrade MC1.5: 1. Load the latest PackageInfo-Base using either a file-out, or using MczInstaller, but *NOT* using Monticello 2. Load the latest Monticello.impl using a file-out, or using MczInstaller, but *NOT* using Monticello 3. Load the latest PackageInfo-Base again, this time using Monticello 4. Load the latest Monticello.impl again, this time using Monticello After installing MC1.5 for the first time, clear all MC caches of MC 1.0 leftovers: (MCPackage named: 'Monticello') workingCopy unregister! (MCPackage named: 'PackageInfo') workingCopy unregister! MCMethodDefinition freeSomeSpace! MCFileBasedRepository freeSomeSpace! DataStream initialize! To switch from MC1.5 to MC1.6: 1. Install the latest SystemEditor 2. Enable the preference #useMonticelloAtomicLoader To upgrade MC1.6: 1. Install the latest SystemEditor 2. Install the latest PackageInfo-Base 3. Install the latest Monticello.impl -- Matthew Fulmer -- http://mtfulmer.wordpress.com/

Oct. 10, 2008

[Pharo-project] [Fwd: gmane.comp.lang.smalltalk.sapphire.devel: Authorization required]

by nicolas cellier

One more thing strange: when i post a reply through http://comments.gmane.org/gmane.comp.lang.smalltalk.pharo.devel/2360 then i get a confirmation for the old list name: gmane.comp.lang.smalltalk.sapphire.devel -------- Message original -------- From: - Fri Oct 10 17:46:41 2008 X-Account-Key: account4 X-UIDL: 48ef7f72-0004149f-32fff902 X-Mozilla-Status: 0003 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Received: from localhost (localhost [127.0.0.1]) by mailrecv01.ifrance.com (Postfix) with ESMTP id AAEDD1E8DD3 for <ncellier(a)ifrance.com>; Fri, 10 Oct 2008 17:30:02 +0200 (CEST) X-Spam-Score: 2 X-Spam-Level: ** X-Spam-Status: No, score=2 tagged_above=-999 required=6.2 tests=[FROM_LOCAL_HEX=2] Received: from mailrecv01.ifrance.com ([127.0.0.1]) by localhost (mailrecv03.ifrance.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id hkQcEZn16DU2 for <ncellier(a)ifrance.com>; Fri, 10 Oct 2008 17:30:02 +0200 (CEST) X-Greylist: from auto-whitelisted by SQLgrey-1.7.3 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mailrecv01.ifrance.com (Postfix) with ESMTP id 412581E8DD2 for <ncellier(a)ifrance.com>; Fri, 10 Oct 2008 17:30:02 +0200 (CEST) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1KoK4Q-0003Mv-S5 for ncellier(a)ifrance.com; Fri, 10 Oct 2008 15:38:26 +0000 From: Gmane Autoauthorizer <auth-5debf6d14fd23d9c22d27f04e5f7d097(a)auth.gmane.org> To: ncellier(a)ifrance.com References: <loom.20081010T152509-580(a)post.gmane.org> Subject: gmane.comp.lang.smalltalk.sapphire.devel: Authorization required Message-Id: <E1KoK4Q-0003Mv-S5(a)ciao.gmane.org> Date: Fri, 10 Oct 2008 15:38:26 +0000 You have sent a message to be posted on the gmane.comp.lang.smalltalk.sapphire.devel newsgroup. Before the message is posted on the newsgroup, you have to confirm that you exist. Just reply to this message, and the message will be posted. You have to respond within one week. -- Your friendly autoauthorizer at Gmane.org http://gmane.org/

Oct. 10, 2008