[Pharo-project] SystemDictionary has one corrupted entry in 1.1 core 11284 image
Applying the 11281-11284 updates seems to leave exactly one entry in the SystemDictionary in the wrong place (too high by one) in the array. Which entry depends on the image. In the downloadable 11284 image it's #MCPTest. I haven't been able to determine how this happens, but executing: Smalltalk globals rehash seems to clean it up. Regards, -Martin ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] RC3 - small stuff
Bill, the "no matching versins" message means that there are no "stable" versions available, so the project is under development and is changing... If you want to try it anyway ... it _is_ under active development. You can load an explicit version using the loader ... look at the config and see what the version name is... Dale - "Wilhelm K Schwab" wrote: | Dale, | | Another project that Citezen might need is Rio. It looks like Damien | has been busy. The ConfigurationOfCitezen is in the repository. For | fun, I tried | | Gofer project load:'Citezen' | | and get an error "No versions matching version (latest)" I am not | sure whether this is something that I should stop nagging and let | Damien fix, or if I'm not doing this correctly. | | Bill | | | -Original Message- | From: pharo-project-boun...@lists.gforge.inria.fr | [mailto:pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Dale | Henrichs | Sent: Monday, March 22, 2010 2:18 PM | To: Pharo-project@lists.gforge.inria.fr | Cc: Pharo-project@lists.gforge.inria.fr | Subject: Re: [Pharo-project] RC3 - small stuff | | Bill, | | Looks like ConfgurationOfCitezen does need required projects added (I | am willing to help the maintainers - drop me a line). | | Perhaps the configs aren't ready for prime time and that's why they | have not been added to MetacelloRepository. | | You can add repositories to your own GoferProject: | | Gofer project repository: 'Repository URL'. | | Will add another repository to the search path. | | Dale | - "Wilhelm K Schwab" wrote: | | | Hello all, | | | | Some time ago, there was (I thought) a patch for saving workspace | text | | to a file; I had hoped to find that in 1.0, but it is not in RC3 | that | | I can find. | | | | The first thing I did was load the Loader extensions to Gofer. It | | installed as expected. I have not looked into the code, but tried | | #search: and found things like Citezen and Rio missing. That might | be | | "simply" because the Configuration* packages are not in the | Metacello | | repository?? If so, are they not there for a non-trivial reason? | | | | I then grabbed ConfigurationOfCitezen, and was hung up by an | | unsatisfied dependence on SmaCC. The SmaCC runtime is in my RC1 | image, | | but I don't know how/why it was loaded; presumably CZLoader did it. | | | | Are these bugs or features? I am leaning toward bugs, but the | | question is whether any or all of the following appicable: (1) | | ConfigurationOfCitezen needs to load prerequisites; (2) Loader is in | | | the wrong to not see them; (3) I need to add repositories to | Loader; | | (4) various ConfigurationOf* packages need to be in the Metacello | | repository. | | | | Any ideas? | | | | Bill | | | | | | ___ | | Pharo-project mailing list | | Pharo-project@lists.gforge.inria.fr | | http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project | | ___ | Pharo-project mailing list | Pharo-project@lists.gforge.inria.fr | http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] How I build squeak-vm with FT2Plugin on Linux
> > >>> Thanks Bryce!!! would be cool to have the "official" Linux VM for Pharo >>> 1.0 release with this feature. >>> >> >> >> I've built one here >> http://lolgzs.free.fr/pharo/Squeak-3.11.3.2135-src-pached.tar.gz with >> FT2Plugin and the patched bitlbt. >> >> > Excellent!!! do you know if this vm has the "Gnuification" ??? > I don't think so as I use the current stable VM 3.11.3. rev 2135. I will try with last trunk. Laurent Laffont > > I saw an email from Adrian in VM maling list saying he has problem with > that. > > > >> If someone can test it on another machine ... >> >> > > I will try later (lazy to open virtual box hahah) > > > Note that I have several tests failing with this VM on RC3 image (but it >> doesn't crash, so that's far better than my previous custom VM :) >> >> Laurent Laffont >> >> >>> >>> ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] How I build squeak-vm with FT2Plugin on Linux
2010/3/22 laurent laffont > > > 2010/3/22 Mariano Martinez Peck > > >> >> On Mon, Mar 22, 2010 at 9:22 PM, Bryce Kampjes > > wrote: >> >>> On Thu, 2010-03-11 at 10:28 +0100, Mariano Martinez Peck wrote: >>> > Both really interesting posts. Now...Some people reported that the >>> > Exupery Linux VM has "nicer" fonts than the standard VM, even if both >>> > use true type. >>> > Then Bryce Kampjes said in the mailing list: >>> > >>> > "If it's font related then the Exupery VMs also have a patched bitlbt >>> > for >>> > subpixel antialiasing. The true type code uses that to make fonts look >>> > a >>> > bit nicer." >>> > >>> > Do you know how that can be included ? >>> >>> Apply the .cs in the following email to your copy of VMMaker and also >>> build the truetype plugin: >>> >>> >>> http://n4.nabble.com/Fwd-Pharo-project-New-Pharo-based-on-core-10309-with-antialiased-fonts-td107050.html#a107071 >>> >>> The truetype work was done by Andy Tween. Googling for him, truetype, >>> plugin, and VM should find a bit more information. >>> >>> >> Thanks Bryce!!! would be cool to have the "official" Linux VM for Pharo >> 1.0 release with this feature. >> > > > I've built one here > http://lolgzs.free.fr/pharo/Squeak-3.11.3.2135-src-pached.tar.gz with > FT2Plugin and the patched bitlbt. > > Excellent!!! do you know if this vm has the "Gnuification" ??? I saw an email from Adrian in VM maling list saying he has problem with that. > If someone can test it on another machine ... > > I will try later (lazy to open virtual box hahah) Note that I have several tests failing with this VM on RC3 image (but it > doesn't crash, so that's far better than my previous custom VM :) > > Laurent Laffont > > >> >> Cheers >> >> Mariano >> >> >> Bryce >>> >>> >>> ___ >>> Pharo-project mailing list >>> Pharo-project@lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> ___ >> Pharo-project mailing list >> Pharo-project@lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] bug in the code of CompiledMethod >> =
On Mon, Mar 22, 2010 at 2:54 PM, Nicolas Cellier < nicolas.cellier.aka.n...@gmail.com> wrote: > You might also want to check last code published in trunk. > I saw that. You're eliminating closeTo: for float comparison which seems fine to me :) Thanks Nicolas! However, it is indicative that a recompile all is necessary after redefining the number scanning facilities. I guess that this is part of the standard release build process. If not, we should add it. > > Nicolas > > 2010/3/22 Eliot Miranda : > > > > > > On Mon, Mar 22, 2010 at 2:25 PM, Stéphane Ducasse > > wrote: > >> > >> eliot > >> > >> Your changes fixed some of the problems. Now I tried to fix the test > >> testAnalogousCodeTo in MethodPropertiesTest and > >> the expression returns false. > >> > >> (#zork->'hello') analogousCodeTo: (#zork->'hello') -> false > >> > >> (#zork->'hello') = (#zork->'hello') -> true > > > > For me > > #(#zork -> 'hello') size 3 > > In Pharo is it true that > > #(#zork -> 'hello') size 1 > > ??!?! > > In that case I would implement analogousCodeTo: in Association, e.g. > > analogousCodeTo: anObject > > ^anObject class == self class > > and: [key = anObject key > > and: [value = anObject value]] > > > > But if Association isn't a literal I would simply check > > MethodPropertiesTests. It could be obsolete. > >> > >> Stef > >> > >> On Mar 22, 2010, at 6:20 PM, Eliot Miranda wrote: > >> > >> > Oops. Find attached. > >> > > >> > 2010/3/22 Cyrille Delaunay > >> > try in a Pharo-1.0-10515-rc3 image : > >> > > >> > |set| > >> > set := Set new. > >> > Collection withAllSubclasses do: [:aClass | > >> > set addAll: aClass methods > >> > ]. > >> > > >> > It will raise an exception telling: "MessageNotUnderstood: > >> > ByteSymbol>>analogousCodeTo:". > >> > Indeed, in the code of CompiledMethod >> = , the message > >> > 'analogousCodeTo:' is send to a > >> > symbol. > >> > > >> > > >> > I opened an Issue: > >> > http://code.google.com/p/pharo/issues/detail?id=2185 > >> > > >> > > >> > > >> > ___ > >> > Pharo-project mailing list > >> > Pharo-project@lists.gforge.inria.fr > >> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >> > > >> > > >> > > ___ > >> > Pharo-project mailing list > >> > Pharo-project@lists.gforge.inria.fr > >> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >> > >> > >> ___ > >> Pharo-project mailing list > >> Pharo-project@lists.gforge.inria.fr > >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > ___ > > Pharo-project mailing list > > Pharo-project@lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] How I build squeak-vm with FT2Plugin on Linux
2010/3/22 Mariano Martinez Peck > > > On Mon, Mar 22, 2010 at 9:22 PM, Bryce Kampjes > wrote: > >> On Thu, 2010-03-11 at 10:28 +0100, Mariano Martinez Peck wrote: >> > Both really interesting posts. Now...Some people reported that the >> > Exupery Linux VM has "nicer" fonts than the standard VM, even if both >> > use true type. >> > Then Bryce Kampjes said in the mailing list: >> > >> > "If it's font related then the Exupery VMs also have a patched bitlbt >> > for >> > subpixel antialiasing. The true type code uses that to make fonts look >> > a >> > bit nicer." >> > >> > Do you know how that can be included ? >> >> Apply the .cs in the following email to your copy of VMMaker and also >> build the truetype plugin: >> >> >> http://n4.nabble.com/Fwd-Pharo-project-New-Pharo-based-on-core-10309-with-antialiased-fonts-td107050.html#a107071 >> >> The truetype work was done by Andy Tween. Googling for him, truetype, >> plugin, and VM should find a bit more information. >> >> > Thanks Bryce!!! would be cool to have the "official" Linux VM for Pharo 1.0 > release with this feature. > I've built one here http://lolgzs.free.fr/pharo/Squeak-3.11.3.2135-src-pached.tar.gz with FT2Plugin and the patched bitlbt. If someone can test it on another machine ... Note that I have several tests failing with this VM on RC3 image (but it doesn't crash, so that's far better than my previous custom VM :) Laurent Laffont > > Cheers > > Mariano > > > Bryce >> >> >> ___ >> Pharo-project mailing list >> Pharo-project@lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] bug in the code of CompiledMethod >> =
You might also want to check last code published in trunk. Nicolas 2010/3/22 Eliot Miranda : > > > On Mon, Mar 22, 2010 at 2:25 PM, Stéphane Ducasse > wrote: >> >> eliot >> >> Your changes fixed some of the problems. Now I tried to fix the test >> testAnalogousCodeTo in MethodPropertiesTest and >> the expression returns false. >> >> (#zork->'hello') analogousCodeTo: (#zork->'hello') -> false >> >> (#zork->'hello') = (#zork->'hello') -> true > > For me > #(#zork -> 'hello') size 3 > In Pharo is it true that > #(#zork -> 'hello') size 1 > ??!?! > In that case I would implement analogousCodeTo: in Association, e.g. > analogousCodeTo: anObject > ^anObject class == self class > and: [key = anObject key > and: [value = anObject value]] > > But if Association isn't a literal I would simply check > MethodPropertiesTests. It could be obsolete. >> >> Stef >> >> On Mar 22, 2010, at 6:20 PM, Eliot Miranda wrote: >> >> > Oops. Find attached. >> > >> > 2010/3/22 Cyrille Delaunay >> > try in a Pharo-1.0-10515-rc3 image : >> > >> > |set| >> > set := Set new. >> > Collection withAllSubclasses do: [:aClass | >> > set addAll: aClass methods >> > ]. >> > >> > It will raise an exception telling: "MessageNotUnderstood: >> > ByteSymbol>>analogousCodeTo:". >> > Indeed, in the code of CompiledMethod >> = , the message >> > 'analogousCodeTo:' is send to a >> > symbol. >> > >> > >> > I opened an Issue: >> > http://code.google.com/p/pharo/issues/detail?id=2185 >> > >> > >> > >> > ___ >> > Pharo-project mailing list >> > Pharo-project@lists.gforge.inria.fr >> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > >> > >> > ___ >> > Pharo-project mailing list >> > Pharo-project@lists.gforge.inria.fr >> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> ___ >> Pharo-project mailing list >> Pharo-project@lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] bug in the code of CompiledMethod >> =
On Mon, Mar 22, 2010 at 2:25 PM, Stéphane Ducasse wrote: > eliot > > Your changes fixed some of the problems. Now I tried to fix the test > testAnalogousCodeTo in MethodPropertiesTest and > the expression returns false. > > (#zork->'hello') analogousCodeTo: (#zork->'hello') -> false > > (#zork->'hello') = (#zork->'hello') -> true > For me #(#zork -> 'hello') size 3 In Pharo is it true that #(#zork -> 'hello') size 1 ??!?! In that case I would implement analogousCodeTo: in Association, e.g. analogousCodeTo: anObject ^anObject class == self class and: [key = anObject key and: [value = anObject value]] But if Association isn't a literal I would simply check MethodPropertiesTests. It could be obsolete. > Stef > > On Mar 22, 2010, at 6:20 PM, Eliot Miranda wrote: > > > Oops. Find attached. > > > > 2010/3/22 Cyrille Delaunay > > try in a Pharo-1.0-10515-rc3 image : > > > > |set| > > set := Set new. > > Collection withAllSubclasses do: [:aClass | > > set addAll: aClass methods > > ]. > > > > It will raise an exception telling: "MessageNotUnderstood: > ByteSymbol>>analogousCodeTo:". > > Indeed, in the code of CompiledMethod >> = , the message > 'analogousCodeTo:' is send to a > > symbol. > > > > > > I opened an Issue: > > http://code.google.com/p/pharo/issues/detail?id=2185 > > > > > > > > ___ > > Pharo-project mailing list > > Pharo-project@lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > ___ > > Pharo-project mailing list > > Pharo-project@lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] bug in the code of CompiledMethod >> =
not sure that it does not introduce side effect but Association>>isLiteral ^ self key isLiteral and: [self value isLiteral] Fix the problem. stef On Mar 22, 2010, at 10:25 PM, Stéphane Ducasse wrote: > eliot > > Your changes fixed some of the problems. Now I tried to fix the test > testAnalogousCodeTo in MethodPropertiesTest and > the expression returns false. > > (#zork->'hello') analogousCodeTo: (#zork->'hello') -> false > > (#zork->'hello') = (#zork->'hello') -> true > > Stef > > On Mar 22, 2010, at 6:20 PM, Eliot Miranda wrote: > >> Oops. Find attached. >> >> 2010/3/22 Cyrille Delaunay >> try in a Pharo-1.0-10515-rc3 image : >> >> |set| >> set := Set new. >> Collection withAllSubclasses do: [:aClass | >> set addAll: aClass methods >> ]. >> >> It will raise an exception telling: "MessageNotUnderstood: >> ByteSymbol>>analogousCodeTo:". >> Indeed, in the code of CompiledMethod >> = , the message 'analogousCodeTo:' >> is send to a >> symbol. >> >> >> I opened an Issue: >> http://code.google.com/p/pharo/issues/detail?id=2185 >> >> >> >> ___ >> Pharo-project mailing list >> Pharo-project@lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> ___ >> Pharo-project mailing list >> Pharo-project@lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] bug in the code of CompiledMethod >> =
eliot Your changes fixed some of the problems. Now I tried to fix the test testAnalogousCodeTo in MethodPropertiesTest and the expression returns false. (#zork->'hello') analogousCodeTo: (#zork->'hello') -> false (#zork->'hello') = (#zork->'hello') -> true Stef On Mar 22, 2010, at 6:20 PM, Eliot Miranda wrote: > Oops. Find attached. > > 2010/3/22 Cyrille Delaunay > try in a Pharo-1.0-10515-rc3 image : > > |set| > set := Set new. > Collection withAllSubclasses do: [:aClass | > set addAll: aClass methods > ]. > > It will raise an exception telling: "MessageNotUnderstood: > ByteSymbol>>analogousCodeTo:". > Indeed, in the code of CompiledMethod >> = , the message 'analogousCodeTo:' > is send to a > symbol. > > > I opened an Issue: > http://code.google.com/p/pharo/issues/detail?id=2185 > > > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Thanks martin :)
On Mar 22, 2010, at 9:33 PM, stephane ducasse wrote: > hi martin > > marcus and me integrated your fixes. Marcus should send a nice update mail. done. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] [update 1.1] #11284
#11284 == Hashed collection performance improvement, phase 4 of 4. Changes identityHash to cover most of the positive SmallInteger range, and uses good prime table sizes. This makes large hashed collections much faster, and does not penalize the small ones. Targeted at Pharo Core 1.1-11280 Load the slice for each phase in order. Allow maybe half an hour to load all four phases; the intermediate phases load very slowly due to existing hashed collections running in "slow but safe" mode while their hash function changes under them. In phase 4: * All of the scanFor: methods modified in phase 1 are loaded into their final form (sometimes a revert to original) which does not scan the entire table before giving up. * The rehashing class and temporary methods are removed, having done their job at the end of phase 3. -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] [update 1.1] #11283
#11283 == Hashed collection performance improvement, phase 3 of 4. Changes identityHash to cover most of the positive SmallInteger range, and uses good prime table sizes. This makes large hashed collections much faster, and does not penalize the small ones. Targeted at Pharo Core 1.1-11280 Load the slice for each phase in order. Allow maybe half an hour to load all four phases; the intermediate phases load very slowly due to existing hashed collections running in "slow but safe" mode while their hash function changes under them. In phase 3: * Identity hash values are changed. * Set>>growSize, rendered obsolete by phase 2, is removed. * A "Rehasher" class is added * Rehasher class>>initialize rehashes all hashed collections. Phase 3 takes several minutes to load, due to load and rehashing taking place in "slow but safe" mode. -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] [update 1.1] #11282
#11282 == Hashed collection performance improvement, phase 2 of 4. Changes identityHash to cover most of the positive SmallInteger range, and uses good prime table sizes. This makes large hashed collections much faster, and does not penalize the small ones. Targeted at Pharo Core 1.1-11280 Load the slice for each phase in order. Allow maybe half an hour to load all four phases; the intermediate phases load very slowly due to existing hashed collections running in "slow but safe" mode while their hash function changes under them. In phase 2: * All methods that will ultimately need to send #basicIdentityHash are modified to do so. * Hashed collections now choose their table sizes to be prime using the HashTableSizes class loaded in phase 1. * Hashed collections are made cautious but slow. They will continue to operate even when their hashing is broken, as it will be during part of the loading of phase 3. This caution will be removed in phase 4. Loading phase 2 may take several minutes due to the cautious hashed collection slowdown. -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] [update 1.1] #11281
#11281 -- Changes identityHash to cover most of the positive SmallInteger range, and uses good prime table sizes. This makes large hashed collections much faster, and does not penalize the small ones. Targeted at Pharo Core 1.1-11280 Load the slice for each phase in order. Allow maybe half an hour to load all four phases; the intermediate phases load very slowly due to existing hashed collections running in "slow but safe" mode while their hash function changes under them. In phase 1: * Methods and classes that will be referenced in phase 2 are added. This includes #basicIdentityHash and the size-selecting class. * No behavior is changed yet. -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] How I build squeak-vm with FT2Plugin on Linux
On Mon, Mar 22, 2010 at 9:22 PM, Bryce Kampjes wrote: > On Thu, 2010-03-11 at 10:28 +0100, Mariano Martinez Peck wrote: > > Both really interesting posts. Now...Some people reported that the > > Exupery Linux VM has "nicer" fonts than the standard VM, even if both > > use true type. > > Then Bryce Kampjes said in the mailing list: > > > > "If it's font related then the Exupery VMs also have a patched bitlbt > > for > > subpixel antialiasing. The true type code uses that to make fonts look > > a > > bit nicer." > > > > Do you know how that can be included ? > > Apply the .cs in the following email to your copy of VMMaker and also > build the truetype plugin: > > > http://n4.nabble.com/Fwd-Pharo-project-New-Pharo-based-on-core-10309-with-antialiased-fonts-td107050.html#a107071 > > The truetype work was done by Andy Tween. Googling for him, truetype, > plugin, and VM should find a bit more information. > > Thanks Bryce!!! would be cool to have the "official" Linux VM for Pharo 1.0 release with this feature. Cheers Mariano Bryce > > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Thanks martin :)
hi martin marcus and me integrated your fixes. Marcus should send a nice update mail. Thanks again. Stef (from my bed, got a nice virus from my smallest boy). ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] How I build squeak-vm with FT2Plugin on Linux
On Thu, 2010-03-11 at 10:28 +0100, Mariano Martinez Peck wrote: > Both really interesting posts. Now...Some people reported that the > Exupery Linux VM has "nicer" fonts than the standard VM, even if both > use true type. > Then Bryce Kampjes said in the mailing list: > > "If it's font related then the Exupery VMs also have a patched bitlbt > for > subpixel antialiasing. The true type code uses that to make fonts look > a > bit nicer." > > Do you know how that can be included ? Apply the .cs in the following email to your copy of VMMaker and also build the truetype plugin: http://n4.nabble.com/Fwd-Pharo-project-New-Pharo-based-on-core-10309-with-antialiased-fonts-td107050.html#a107071 The truetype work was done by Andy Tween. Googling for him, truetype, plugin, and VM should find a bit more information. Bryce ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] RC3 - small stuff
Dale, Another project that Citezen might need is Rio. It looks like Damien has been busy. The ConfigurationOfCitezen is in the repository. For fun, I tried Gofer project load:'Citezen' and get an error "No versions matching version (latest)" I am not sure whether this is something that I should stop nagging and let Damien fix, or if I'm not doing this correctly. Bill -Original Message- From: pharo-project-boun...@lists.gforge.inria.fr [mailto:pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Dale Henrichs Sent: Monday, March 22, 2010 2:18 PM To: Pharo-project@lists.gforge.inria.fr Cc: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] RC3 - small stuff Bill, Looks like ConfgurationOfCitezen does need required projects added (I am willing to help the maintainers - drop me a line). Perhaps the configs aren't ready for prime time and that's why they have not been added to MetacelloRepository. You can add repositories to your own GoferProject: Gofer project repository: 'Repository URL'. Will add another repository to the search path. Dale - "Wilhelm K Schwab" wrote: | Hello all, | | Some time ago, there was (I thought) a patch for saving workspace text | to a file; I had hoped to find that in 1.0, but it is not in RC3 that | I can find. | | The first thing I did was load the Loader extensions to Gofer. It | installed as expected. I have not looked into the code, but tried | #search: and found things like Citezen and Rio missing. That might be | "simply" because the Configuration* packages are not in the Metacello | repository?? If so, are they not there for a non-trivial reason? | | I then grabbed ConfigurationOfCitezen, and was hung up by an | unsatisfied dependence on SmaCC. The SmaCC runtime is in my RC1 image, | but I don't know how/why it was loaded; presumably CZLoader did it. | | Are these bugs or features? I am leaning toward bugs, but the | question is whether any or all of the following appicable: (1) | ConfigurationOfCitezen needs to load prerequisites; (2) Loader is in | the wrong to not see them; (3) I need to add repositories to Loader; | (4) various ConfigurationOf* packages need to be in the Metacello | repository. | | Any ideas? | | Bill | | | ___ | Pharo-project mailing list | Pharo-project@lists.gforge.inria.fr | http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] RC3 - small stuff
Chris, Understood, but somebody created what I thought was a correct patch to add something to the workspace menu to do it, and it would be a shame to lose it. Bill -Original Message- From: pharo-project-boun...@lists.gforge.inria.fr [mailto:pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Chris Muller Sent: Monday, March 22, 2010 1:59 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] RC3 - small stuff Hi Bill, I think you can just create a new file in the file-list, cut and paste your WS into it, save again.. On Mon, Mar 22, 2010 at 1:16 PM, Schwab,Wilhelm K wrote: > Hello all, > > Some time ago, there was (I thought) a patch for saving workspace text to a > file; I had hoped to find that in 1.0, but it is not in RC3 that I can find. > > The first thing I did was load the Loader extensions to Gofer. It installed > as expected. I have not looked into the code, but tried #search: and found > things like Citezen and Rio missing. That might be "simply" because the > Configuration* packages are not in the Metacello repository?? If so, are > they not there for a non-trivial reason? > > I then grabbed ConfigurationOfCitezen, and was hung up by an unsatisfied > dependence on SmaCC. The SmaCC runtime is in my RC1 image, but I don't know > how/why it was loaded; presumably CZLoader did it. > > Are these bugs or features? I am leaning toward bugs, but the question is > whether any or all of the following appicable: (1) ConfigurationOfCitezen > needs to load prerequisites; (2) Loader is in the wrong to not see them; (3) > I need to add repositories to Loader; (4) various ConfigurationOf* packages > need to be in the Metacello repository. > > Any ideas? > > Bill > > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Implementing MethodWrappers in Smalltalk
Hi Mariano, I worked on a similar problem for a new code profiler. Spy is a framework for easily performing program execution analysis. A short tutorial, screenshots, and some examples are available on: http://www.moosetechnology.org/tools/Spy If you're working in that direction, I would be delighted to collaborate. Cheers, Alexandre On 22 Mar 2010, at 12:51, Mariano Martinez Peck wrote: Hi folks. I was reading the PBE chapter about reflection where it talks a little about Method Wrappers. Then, I took a look at TestCoverage implementation. After that, I took a look at http://www.squeaksource.com/ObjectsAsMethodsWrap The main difference between both approaches are: TestCoverage - Just extends from ProtoObject, implement doesNotUnderstand: , run: aSelector with: anArray in: aReceiver, etc - To install and uninstall the wrappers uses methodDictionary at: xxx put: yyy - Just for test coverage. ObjectAsMethodWrapper - Is more generic, support pre and post closures, and you can subclass and create you own wrapper - To install and uninstall the wrappers it uses Class >> addSelector: self selector withMethod: self So...what I did ?? I created a TestCoverage but creating a subclass of ObjectAsMethodWrapper called TestCoverageMethodWrapper which just implements a 1 or 2 methods. I mean, I reused the generic ObjectAsMethodWrapper. It seems to work ok. I did some test running TestCoverage with both implementation and it seems mine (TestCoverageMethodWrapper) is 30% much slower than the original. Trying to understand why, I think it is because the original one uses just methodDictionary at: xxx put: yyy but mine uses Class >> addSelector: self selector withMethod: self. In this last method, there are all the notifications, add to localSelectors...etc Now...I have two questions: 1) For a generic approach to method wrappers, which of those two ways would you use ? should I care about notifying, adding to localSelectors, etc? Or at is just temporal, I don't care ? which are the pros and cons you see with each alternative ? 2) Do you think it make sense to the package ObjectsAsMethodsWrap in PharoCore as a "library" to create lightweight proxies ? It is just 4 classes and it would be cool to change TestCoverage to that implementation. Then, you only don't have the library, but also some real examples. Of course, this can be done if we eleiminate the 30% of slowleness. so...what do you think ? Cheers Mariano ___ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] RC3 - small stuff
Bill, Looks like ConfgurationOfCitezen does need required projects added (I am willing to help the maintainers - drop me a line). Perhaps the configs aren't ready for prime time and that's why they have not been added to MetacelloRepository. You can add repositories to your own GoferProject: Gofer project repository: 'Repository URL'. Will add another repository to the search path. Dale - "Wilhelm K Schwab" wrote: | Hello all, | | Some time ago, there was (I thought) a patch for saving workspace text | to a file; I had hoped to find that in 1.0, but it is not in RC3 that | I can find. | | The first thing I did was load the Loader extensions to Gofer. It | installed as expected. I have not looked into the code, but tried | #search: and found things like Citezen and Rio missing. That might be | "simply" because the Configuration* packages are not in the Metacello | repository?? If so, are they not there for a non-trivial reason? | | I then grabbed ConfigurationOfCitezen, and was hung up by an | unsatisfied dependence on SmaCC. The SmaCC runtime is in my RC1 image, | but I don't know how/why it was loaded; presumably CZLoader did it. | | Are these bugs or features? I am leaning toward bugs, but the | question is whether any or all of the following appicable: (1) | ConfigurationOfCitezen needs to load prerequisites; (2) Loader is in | the wrong to not see them; (3) I need to add repositories to Loader; | (4) various ConfigurationOf* packages need to be in the Metacello | repository. | | Any ideas? | | Bill | | | ___ | Pharo-project mailing list | Pharo-project@lists.gforge.inria.fr | http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] RC3 - small stuff
Hi Bill, I think you can just create a new file in the file-list, cut and paste your WS into it, save again.. On Mon, Mar 22, 2010 at 1:16 PM, Schwab,Wilhelm K wrote: > Hello all, > > Some time ago, there was (I thought) a patch for saving workspace text to a > file; I had hoped to find that in 1.0, but it is not in RC3 that I can find. > > The first thing I did was load the Loader extensions to Gofer. It installed > as expected. I have not looked into the code, but tried #search: and found > things like Citezen and Rio missing. That might be "simply" because the > Configuration* packages are not in the Metacello repository?? If so, are > they not there for a non-trivial reason? > > I then grabbed ConfigurationOfCitezen, and was hung up by an unsatisfied > dependence on SmaCC. The SmaCC runtime is in my RC1 image, but I don't know > how/why it was loaded; presumably CZLoader did it. > > Are these bugs or features? I am leaning toward bugs, but the question is > whether any or all of the following appicable: (1) ConfigurationOfCitezen > needs to load prerequisites; (2) Loader is in the wrong to not see them; (3) > I need to add repositories to Loader; (4) various ConfigurationOf* packages > need to be in the Metacello repository. > > Any ideas? > > Bill > > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] RC3 - small stuff
Hello all, Some time ago, there was (I thought) a patch for saving workspace text to a file; I had hoped to find that in 1.0, but it is not in RC3 that I can find. The first thing I did was load the Loader extensions to Gofer. It installed as expected. I have not looked into the code, but tried #search: and found things like Citezen and Rio missing. That might be "simply" because the Configuration* packages are not in the Metacello repository?? If so, are they not there for a non-trivial reason? I then grabbed ConfigurationOfCitezen, and was hung up by an unsatisfied dependence on SmaCC. The SmaCC runtime is in my RC1 image, but I don't know how/why it was loaded; presumably CZLoader did it. Are these bugs or features? I am leaning toward bugs, but the question is whether any or all of the following appicable: (1) ConfigurationOfCitezen needs to load prerequisites; (2) Loader is in the wrong to not see them; (3) I need to add repositories to Loader; (4) various ConfigurationOf* packages need to be in the Metacello repository. Any ideas? Bill ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Implementing MethodWrappers in Smalltalk
> 1) For a generic approach to method wrappers, which of those two ways would > you use ? should I care about notifying, adding to localSelectors, etc? > Or at is just temporal, I don't care ? > which are the pros and cons you see with each alternative ? I used #at:put: because we put-back the identical compiled methods as fast as possible, even while the tests are running. Triggering notifications while running might also cause undesired side effects. Also note that code doing reflection (iterating over pragmas, literals, ...) might break if you are not super careful. > 2) Do you think it make sense to the package ObjectsAsMethodsWrap in > PharoCore as a "library" to create lightweight proxies ? It is just 4 > classes and it would be cool to change TestCoverage to that implementation. > Then, you only don't have the library, but also some real examples. Of > course, this can be done if we eleiminate the 30% of slowleness. I guess it is slower because it is very generic and does block activations. > so...what do you think ? There are also MethodWrappers from the RB engine that come with an integration into OB. I wouldn't include the extra package, after all the implementation is pretty simple and also very specific. For a different use-case the implementation would probably look completely different. Check the mailing list, we had some discussions and did various iterations back when this was integrated. Lukas -- Lukas Renggli http://www.lukas-renggli.ch ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] bug in the code of CompiledMethod >> =
Oops. Find attached. 2010/3/22 Cyrille Delaunay > try in a Pharo-1.0-10515-rc3 image : > > |set| > set := Set new. > Collection withAllSubclasses do: [:aClass | > set addAll: aClass methods > ]. > > It will raise an exception telling: "MessageNotUnderstood: > ByteSymbol>>analogousCodeTo:". > Indeed, in the code of CompiledMethod >> = , the message 'analogousCodeTo:' > is send to a > symbol. > > > I opened an Issue: > > http://code.google.com/p/pharo/issues/detail?id=2185 > > > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > Object-analogousCodeTo.st Description: Binary data ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Implementing MethodWrappers in Smalltalk
Hi folks. I was reading the PBE chapter about reflection where it talks a little about Method Wrappers. Then, I took a look at TestCoverage implementation. After that, I took a look at http://www.squeaksource.com/ObjectsAsMethodsWrap The main difference between both approaches are: TestCoverage - Just extends from ProtoObject, implement doesNotUnderstand: , run: aSelector with: anArray in: aReceiver, etc - To install and uninstall the wrappers uses methodDictionary at: xxx put: yyy - Just for test coverage. ObjectAsMethodWrapper - Is more generic, support pre and post closures, and you can subclass and create you own wrapper - To install and uninstall the wrappers it uses Class >> addSelector: self selector withMethod: self So...what I did ?? I created a TestCoverage but creating a subclass of ObjectAsMethodWrapper called TestCoverageMethodWrapper which just implements a 1 or 2 methods. I mean, I reused the generic ObjectAsMethodWrapper. It seems to work ok. I did some test running TestCoverage with both implementation and it seems mine (TestCoverageMethodWrapper) is 30% much slower than the original. Trying to understand why, I think it is because the original one uses just methodDictionary at: xxx put: yyy but mine uses Class >> addSelector: self selector withMethod: self. In this last method, there are all the notifications, add to localSelectors...etc Now...I have two questions: 1) For a generic approach to method wrappers, which of those two ways would you use ? should I care about notifying, adding to localSelectors, etc? Or at is just temporal, I don't care ? which are the pros and cons you see with each alternative ? 2) Do you think it make sense to the package ObjectsAsMethodsWrap in PharoCore as a "library" to create lightweight proxies ? It is just 4 classes and it would be cool to change TestCoverage to that implementation. Then, you only don't have the library, but also some real examples. Of course, this can be done if we eleiminate the 30% of slowleness. so...what do you think ? Cheers Mariano ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] [update 1.1] #11287
11287 - Issue 2136: Smalltalk and SmalltalkImage -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] [update 1.1] #11286
11286 - Issue 2179: Tweak from nicolas in sync Pharo and Squeak Issue 2181: CompiledMethod >>getSourceFor: selector in: class Issue 2173: MC browser selection Issue 2186: Adding some methods to the WorldMenu for deprecation Issue 2142: isInMemory should be removed. -- Marcus Denker -- mar...@2denker.de http://www.2denker.de 2denker UG (haftungsbeschränkt) Sitz Köln Amtsgericht - Registergericht - Köln, HRB 65065 Geschäftsführer: Christian Denker und Dr. Marcus Denker ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] [update 1.1] #11285
11285 - - Issue 2180: Move MetaObjectTools from core to PharoDev - Issue 2165: CleanUp unused packages -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] isInMemory :)
good! Stef On Mar 22, 2010, at 2:59 PM, Adrian Lienhard wrote: > My plan is to extract ImageSegments into an external package and maintain it > there. Since I will probably not be able to make the class swapping work, > this part of image segments will be dropped. > > If you start with removing #isInMemory, thats fine with me. I can do the rest > later. > > Cheers, > Adrian > > > On Mar 22, 2010, at 14:42 , Stéphane Ducasse wrote: > >> so do we remove imageSegments support? >> >> Stef >> >> The reason why the #isInmemory checks are there at all is the following: >> >> -> they used imageSegements (and before, the ObjectOut stuff) to swap >> out objecs to disk >> -> Now if you access the class, it is loaded again. >> -> doing anything that looks at "all classes" would load the classes. >> (all of them) >> -> this includes things like "Object subclasses". or "Smalltalk >> classNames". >> -> e.g. Openign a browser would load all classes. >> -> so we put #isInMemory everywhere > > Yes I know that :) > Now I was wondering what adrian meant. > >> -> this of course means that #subclasses would just return those that >> by chance are >>in memory... I don't understand how that can work. Honestly :-) >> >> I think we shoud remove all that stuff and do it "for real". c.f. Loom. > > probably. so I was wondering: what exactly is bad in swapping in all classes when opening a browser? 1) no need to swap in *everything*. Classe are large because they reference *lots* of methods (which in turn reference lots of literals). But most cases where we iterate over all classes we will not touch the methods (other than when we *want* the methods). => be fine grained. Loading all classes does not imply loading all methodDictcs. 2) If I am interested in all classes, I am interested in all classes. Give them to me! And get rid of them as soon as I am not interested anymore => on-demand loading is half of the story. On-No-Demand-*Unloading* is needed, too. This means, when developing, we will have all classes (or at least parts of them) in memory. (*because we look at them*). But in Deployment, the working set of objects will be different, and only those classes that are needed for *execution* will stay in memory. 3) Intelligent caching. Of course we don't load objects one-by-one, we will have an intelligent cache. We will do intelligent pre-fetching, too, to not have to go to disk for each object when it's clear that probably we will load more that just that one object (or it's cheap to load more). But that is orthogonal and invisible. >>> >>> Exactly! If granularity even was at the method level (executing 100 methods >>> of Morph would not bring in all 1000 methods), we could get a system that >>> is *really* small (and also faster because GC has to do less work). >>> >>> Adrian >>> ___ >>> Pharo-project mailing list >>> Pharo-project@lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> ___ >> Pharo-project mailing list >> Pharo-project@lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] [ANN 1.1] prebuild Core#11284
https://gforge.inria.fr/frs/download.php/26693/PharoCore-1.1-11284-UNSTABLE.zip -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] isInMemory :)
My plan is to extract ImageSegments into an external package and maintain it there. Since I will probably not be able to make the class swapping work, this part of image segments will be dropped. If you start with removing #isInMemory, thats fine with me. I can do the rest later. Cheers, Adrian On Mar 22, 2010, at 14:42 , Stéphane Ducasse wrote: > so do we remove imageSegments support? > > Stef > > The reason why the #isInmemory checks are there at all is the following: > > -> they used imageSegements (and before, the ObjectOut stuff) to swap > out objecs to disk > -> Now if you access the class, it is loaded again. > -> doing anything that looks at "all classes" would load the classes. > (all of them) > -> this includes things like "Object subclasses". or "Smalltalk > classNames". > -> e.g. Openign a browser would load all classes. > -> so we put #isInMemory everywhere Yes I know that :) Now I was wondering what adrian meant. > -> this of course means that #subclasses would just return those that > by chance are > in memory... I don't understand how that can work. Honestly :-) > > I think we shoud remove all that stuff and do it "for real". c.f. Loom. probably. >>> >>> >>> so I was wondering: what exactly is bad in swapping in all classes when >>> opening a browser? >>> >>> 1) no need to swap in *everything*. Classe are large because they >>> reference *lots* of methods (which in turn reference >>> lots of literals). >>> But most cases where we iterate over all classes we will not touch >>> the methods (other than when we *want* >>> the methods). >>> >>> => be fine grained. Loading all classes does not imply >>> loading all methodDictcs. >>> >>> 2) If I am interested in all classes, I am interested in all classes. >>> Give them to me! >>>And get rid of them as soon as I am not interested anymore >>> >>> => on-demand loading is half of the story. >>> On-No-Demand-*Unloading* is needed, too. >>> >>> This means, when developing, we will have all classes (or at >>> least parts of them) in memory. >>> (*because we look at them*). But in Deployment, the working >>> set of objects will be different, and >>> only those classes that are needed for *execution* will stay in >>> memory. >>> >>> 3) Intelligent caching. Of course we don't load objects one-by-one, we >>> will have an intelligent cache. >>> We will do intelligent pre-fetching, too, to not have to go to >>> disk for each object when it's clear that >>> probably we will load more that just that one object (or it's >>> cheap to load more). >>> >>> But that is orthogonal and invisible. >> >> Exactly! If granularity even was at the method level (executing 100 methods >> of Morph would not bring in all 1000 methods), we could get a system that is >> *really* small (and also faster because GC has to do less work). >> >> Adrian >> ___ >> Pharo-project mailing list >> Pharo-project@lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] bug in the code of CompiledMethod >> =
Thanks cyrille! Stef On Mar 22, 2010, at 2:33 PM, Cyrille Delaunay wrote: > try in a Pharo-1.0-10515-rc3 image : > > |set| > set := Set new. > Collection withAllSubclasses do: [:aClass | > set addAll: aClass methods > ]. > > It will raise an exception telling: "MessageNotUnderstood: > ByteSymbol>>analogousCodeTo:". > Indeed, in the code of CompiledMethod >> = , the message 'analogousCodeTo:' > is send to a > symbol. > > > I opened an Issue: > http://code.google.com/p/pharo/issues/detail?id=2185 > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] isInMemory :)
so do we remove imageSegments support? Stef The reason why the #isInmemory checks are there at all is the following: -> they used imageSegements (and before, the ObjectOut stuff) to swap out objecs to disk -> Now if you access the class, it is loaded again. -> doing anything that looks at "all classes" would load the classes. (all of them) -> this includes things like "Object subclasses". or "Smalltalk classNames". -> e.g. Openign a browser would load all classes. -> so we put #isInMemory everywhere >>> >>> Yes I know that :) >>> Now I was wondering what adrian meant. >>> -> this of course means that #subclasses would just return those that by chance are in memory... I don't understand how that can work. Honestly :-) I think we shoud remove all that stuff and do it "for real". c.f. Loom. >>> >>> probably. >> >> >> so I was wondering: what exactly is bad in swapping in all classes when >> opening a browser? >> >> 1) no need to swap in *everything*. Classe are large because they >> reference *lots* of methods (which in turn reference >>lots of literals). >> But most cases where we iterate over all classes we will not touch >> the methods (other than when we *want* >> the methods). >> >> => be fine grained. Loading all classes does not imply >> loading all methodDictcs. >> >> 2) If I am interested in all classes, I am interested in all classes. >> Give them to me! >> And get rid of them as soon as I am not interested anymore >> >> => on-demand loading is half of the story. >> On-No-Demand-*Unloading* is needed, too. >> >> This means, when developing, we will have all classes (or at >> least parts of them) in memory. >> (*because we look at them*). But in Deployment, the working >> set of objects will be different, and >> only those classes that are needed for *execution* will stay in >> memory. >> >> 3) Intelligent caching. Of course we don't load objects one-by-one, we >> will have an intelligent cache. >>We will do intelligent pre-fetching, too, to not have to go to >> disk for each object when it's clear that >>probably we will load more that just that one object (or it's >> cheap to load more). >> >> But that is orthogonal and invisible. > > Exactly! If granularity even was at the method level (executing 100 methods > of Morph would not bring in all 1000 methods), we could get a system that is > *really* small (and also faster because GC has to do less work). > > Adrian > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Question about HostMenuSystem
This is cool to see a bold guy like that pushing that :) Keep pushing mariano. Stef On Mar 22, 2010, at 12:19 AM, Michael Rueger wrote: > On 3/21/10 4:07 PM, Mariano Martinez Peck wrote: > >> Hi Michael. Let me see if I understood. >> >> - In PharoCore I remove InputEventSensor >> processMenuEvent: and the >> invocation from ImputEventSensor >> processEvent: evt > > correct > And make sure to do it in the right order and have backups of your image ;-) > >> >> - In the package HostMenuSystem, I create a subclass of >> InputEventHandler (Suppose called HostMenuEventHandler). It is correct >> to subclass from this class ? > > Yes > >> - In HostMenuEventHandler I create the method handleEvent: that does >> the if type = EventTypeMenu and do everything > > Yes > >> - In a class side method initialize or similar, I put: >> >> HostMenuEventHandler new registerIn: InputEventFetcher default. >> >> Is that correct? I mean, it is correct to register in InputEventFetcher >> or I should use another class ? > > You understood perfectly :-) > > Now I'm curious if it actually works... > > Will hopefully be a good example of how the new event handling setup allows > us to do these things without system overrides. > > Michael > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] bug in the code of CompiledMethod >> =
try in a Pharo-1.0-10515-rc3 image : |set| set := Set new. Collection withAllSubclasses do: [:aClass | set addAll: aClass methods ]. It will raise an exception telling: "MessageNotUnderstood: ByteSymbol>>analogousCodeTo:". Indeed, in the code of CompiledMethod >> = , the message 'analogousCodeTo:' is send to a symbol. I opened an Issue: http://code.google.com/p/pharo/issues/detail?id=2185 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] GSoC next steps
Janko Mivšek wrote: > > Hi Geert, > >> Why a private discussion and/or voting? Isn't the whole point of GSoC to >> engage the entire Smalltalk community? > > Smalltalk GSoC Mentors mailing list is actually visible to others, just > that it is created in Slovenian and now I can't change the language. If > someone knows how... Here is the link: > > http://groups.google.si/group/smalltalk-gsoc-mentors > Just use .com instead of .si to see the group in English :) http://groups.google.com/group/smalltalk-gsoc-mentors Janko Mivšek wrote: > > Also, I think this list should stay semi-public and it is not for > inclusion on the Nabble. Just for interesting public therefore :) This > will then be a right balance between privacy of mentors and public > interest of community, IMO. > > Best regards > Janko > Are you sure about this semi-public thingy? :) -- View this message in context: http://n4.nabble.com/GSoC-next-steps-tp1676708p1677352.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] GSoC next steps
Hi Geert, On 22. 03. 2010 09:04, Geert Claes wrote: > Mariano Martinez Peck wrote: >> >> I am not sure but I think it is a private mailing list where mentors will >> be able to discuss and vote. >> Anyway, I will ask Janko just in case I am wrong. > Why a private discussion and/or voting? Isn't the whole point of GSoC to > engage the entire Smalltalk community? Smalltalk GSoC Mentors mailing list is actually visible to others, just that it is created in Slovenian and now I can't change the language. If someone knows how... Here is the link: http://groups.google.si/group/smalltalk-gsoc-mentors Also, I think this list should stay semi-public and it is not for inclusion on the Nabble. Just for interesting public therefore :) This will then be a right balance between privacy of mentors and public interest of community, IMO. Best regards Janko ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Getting the website ready for 1.0
>> If there is one-click images for Pharo, it might be easier for newbies. >> >> > There is, but experimental: > > look in https://gforge.inria.fr/frs/?group_id=1299 > "One-Click Experiments" > > Adrian offered him self also to do a new one for 1.0 Did I? I think that was Marcus :). But anyway, yes, we want to do 1-click images for the release. Adrian ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] isInMemory :)
On Mar 21, 2010, at 23:46 , Marcus Denker wrote: > > On Mar 21, 2010, at 11:18 PM, Stéphane Ducasse wrote: >>> >>> The reason why the #isInmemory checks are there at all is the following: >>> >>> -> they used imageSegements (and before, the ObjectOut stuff) to swap >>> out objecs to disk >>> -> Now if you access the class, it is loaded again. >>> -> doing anything that looks at "all classes" would load the classes. >>> (all of them) >>> -> this includes things like "Object subclasses". or "Smalltalk >>> classNames". >>> -> e.g. Openign a browser would load all classes. >>> -> so we put #isInMemory everywhere >> >> Yes I know that :) >> Now I was wondering what adrian meant. >> >>> -> this of course means that #subclasses would just return those that >>> by chance are >>> in memory... I don't understand how that can work. Honestly :-) >>> >>> I think we shoud remove all that stuff and do it "for real". c.f. Loom. >> >> probably. > > > so I was wondering: what exactly is bad in swapping in all classes when > opening a browser? > > 1) no need to swap in *everything*. Classe are large because they > reference *lots* of methods (which in turn reference > lots of literals). >But most cases where we iterate over all classes we will not touch > the methods (other than when we *want* >the methods). > > => be fine grained. Loading all classes does not imply > loading all methodDictcs. > >2) If I am interested in all classes, I am interested in all classes. > Give them to me! > And get rid of them as soon as I am not interested anymore > > => on-demand loading is half of the story. > On-No-Demand-*Unloading* is needed, too. > > This means, when developing, we will have all classes (or at > least parts of them) in memory. >(*because we look at them*). But in Deployment, the working > set of objects will be different, and > only those classes that are needed for *execution* will stay in > memory. > > 3) Intelligent caching. Of course we don't load objects one-by-one, we > will have an intelligent cache. > We will do intelligent pre-fetching, too, to not have to go to > disk for each object when it's clear that > probably we will load more that just that one object (or it's > cheap to load more). > >But that is orthogonal and invisible. Exactly! If granularity even was at the method level (executing 100 methods of Morph would not bring in all 1000 methods), we could get a system that is *really* small (and also faster because GC has to do less work). Adrian ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Getting the website ready for 1.0
On Mon, Mar 22, 2010 at 9:32 AM, Serge Stinckwich < serge.stinckw...@gmail.com> wrote: > 2010/3/22 laurent laffont : > > OK, so the One Click image is really important. Nevertheless, I think > there > > should be a mean to quickly understand the distinction between VM and > image, > > that you can have several images. (The concept of image is new for a lot > of > > people :), and it was for me 1 year and a half ago. It takes some time > to > > understand how to work with. Then I thought it was a revolution :D ). > > Yes i think they are important for the 1.0 release. I could help to test > them. > Me too. Laurent Laffont ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Getting the website ready for 1.0
2010/3/22 laurent laffont : > OK, so the One Click image is really important. Nevertheless, I think there > should be a mean to quickly understand the distinction between VM and image, > that you can have several images. (The concept of image is new for a lot of > people :), and it was for me 1 year and a half ago. It takes some time to > understand how to work with. Then I thought it was a revolution :D ). Yes i think they are important for the 1.0 release. I could help to test them. -- 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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] isInMemory :)
On Mar 21, 2010, at 23:18 , Stéphane Ducasse wrote: > > On Mar 21, 2010, at 10:59 PM, Marcus Denker wrote: > >> >> On Mar 21, 2010, at 10:51 PM, Stéphane Ducasse wrote: >> >> Well... it is needed for the swapping out of classes. If we remove >> #isInMemory, we should also remove the whole image segment stub >> mechanism because it becomes useless without the isInMemory protection. >>> >>> what I was thinking to remove is the use of isInMemory from >>> SystemDictionary>>allClasses and friends. >>> Now I do not get 100% what you are saying. >>> Do you say that all the queries should be protected against bringing back >>> classes on disc? >> >> The reason why the #isInmemory checks are there at all is the following: >> >> -> they used imageSegements (and before, the ObjectOut stuff) to swap >> out objecs to disk >> -> Now if you access the class, it is loaded again. >> -> doing anything that looks at "all classes" would load the classes. >> (all of them) >> -> this includes things like "Object subclasses". or "Smalltalk >> classNames". >> -> e.g. Openign a browser would load all classes. >> -> so we put #isInMemory everywhere > > Yes I know that :) > Now I was wondering what adrian meant. In addition to what Marcus said above I meant that when we remove isInMemory we should also remove the swapping code that is part of image segments (e.g., the class ImageSegmentRootStub and various methods in ImageSegment) because it cannot work anymore and hence is useless. Cheers, Adrian ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Getting the website ready for 1.0
OK, so the One Click image is really important. Nevertheless, I think there should be a mean to quickly understand the distinction between VM and image, that you can have several images. (The concept of image is new for a lot of people :), and it was for me 1 year and a half ago. It takes some time to understand how to work with. Then I thought it was a revolution :D ). Laurent Laffont 2010/3/22 Mariano Martinez Peck > > > On Mon, Mar 22, 2010 at 8:51 AM, Serge Stinckwich < > serge.stinckw...@gmail.com> wrote: > >> 2010/3/22 laurent laffont : >> > Hi, >> > last saturday I have organized a Pharo workshop in Annecy. 6 people out >> of 9 >> > discovered Pharo & Smalltalk. >> > A first point to understand for newcommers is that you need: >> > - the VM for your platform >> > - the Pharo image >> > - open the image with the VM. >> > So maybe you should put as big sized text at the top of Download page a >> > "Quick start" section like this: >> > Step 1: Dowload Pharo image and unzip it. >> > Step 2: Download the VM for your platform Mac OSX >> > >> > Step 3: Run the squeak/pharo binary (pharo.exe on windows, squeak.sh on >> > Linux, ...). A file brower is opened, select the .image. >> > Step 4: Have fun >> >> If there is one-click images for Pharo, it might be easier for newbies. >> >> > There is, but experimental: > > look in https://gforge.inria.fr/frs/?group_id=1299 > "One-Click Experiments" > > Adrian offered him self also to do a new one for 1.0 > > In addition, for windows people, you have Torsten installer that you can > find here: > > http://www.pharo-project.org/pharo-download > > "Ready Made Setup" > > Cheers > > Mariano > > >> -- >> >> 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@lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] GSoC next steps
Mariano Martinez Peck wrote: > > I am not sure but I think it is a private mailing list where mentors will > be able to discuss and vote. > Anyway, I will ask Janko just in case I am wrong. > Why a private discussion and/or voting? Isn't the whole point of GSoC to engage the entire Smalltalk community? -- View this message in context: http://n4.nabble.com/GSoC-next-steps-tp1676708p1677279.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Getting the website ready for 1.0
On Mon, Mar 22, 2010 at 8:51 AM, Serge Stinckwich < serge.stinckw...@gmail.com> wrote: > 2010/3/22 laurent laffont : > > Hi, > > last saturday I have organized a Pharo workshop in Annecy. 6 people out > of 9 > > discovered Pharo & Smalltalk. > > A first point to understand for newcommers is that you need: > > - the VM for your platform > > - the Pharo image > > - open the image with the VM. > > So maybe you should put as big sized text at the top of Download page a > > "Quick start" section like this: > > Step 1: Dowload Pharo image and unzip it. > > Step 2: Download the VM for your platform Mac OSX > > > > Step 3: Run the squeak/pharo binary (pharo.exe on windows, squeak.sh on > > Linux, ...). A file brower is opened, select the .image. > > Step 4: Have fun > > If there is one-click images for Pharo, it might be easier for newbies. > > There is, but experimental: look in https://gforge.inria.fr/frs/?group_id=1299 "One-Click Experiments" Adrian offered him self also to do a new one for 1.0 In addition, for windows people, you have Torsten installer that you can find here: http://www.pharo-project.org/pharo-download "Ready Made Setup" Cheers Mariano > -- > 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@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] GSoC next steps
On Mon, Mar 22, 2010 at 8:47 AM, Geert Claes wrote: > > > Mariano Martinez Peck wrote: > > > > ... > > We created a mailing list for all the mentors. If you are mentor, you > > should be there. If you are not, please contact us. > > ... > > > > Where can I find this mailing list so I can add it to the other mailing > lists on Nabble if you like? > I am not sure but I think it is a private mailing list where mentors will be able to discuss and vote. Anyway, I will ask Janko just in case I am wrong. Thanks Mariano > -- > View this message in context: > http://n4.nabble.com/GSoC-next-steps-tp1676708p1677264.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Getting the website ready for 1.0
2010/3/22 laurent laffont : > Hi, > last saturday I have organized a Pharo workshop in Annecy. 6 people out of 9 > discovered Pharo & Smalltalk. > A first point to understand for newcommers is that you need: > - the VM for your platform > - the Pharo image > - open the image with the VM. > So maybe you should put as big sized text at the top of Download page a > "Quick start" section like this: > Step 1: Dowload Pharo image and unzip it. > Step 2: Download the VM for your platform Mac OSX > > Step 3: Run the squeak/pharo binary (pharo.exe on windows, squeak.sh on > Linux, ...). A file brower is opened, select the .image. > Step 4: Have fun If there is one-click images for Pharo, it might be easier for newbies. -- 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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Getting the website ready for 1.0
Hi, last saturday I have organized a Pharo workshop in Annecy. 6 people out of 9 discovered Pharo & Smalltalk. A first point to understand for newcommers is that you need: - the VM for your platform - the Pharo image - open the image with the VM. So maybe you should put as big sized text at the top of Download page a "Quick start" section like this: Step 1: Dowload Pharo image and unzip it. Step 2: Download the VM for your platform Mac OSX Step 3: Run the squeak/pharo binary (pharo.exe on windows, squeak.sh on Linux, ...). A file brower is opened, select the .image. Step 4: Have fun Cheers, Laurent Laffont On Sun, Mar 21, 2010 at 12:48 PM, Adrian Lienhard wrote: > Hi all, > > I've updated the website content, in particular the following pages, which > are linked from the welcome workspace: > > http://www.pharo-project.org/documentation/getting-started > http://www.pharo-project.org/documentation/tutorials-books > > If you have any suggestions to improve the website (e.g., for the FAQ), > please let me know! > > Cheers, > Adrian > > BTW, I also updated the download links to the new Pharo RC3 image > > ___ > http://www.adrian-lienhard.ch/ > > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] GSoC next steps
Mariano Martinez Peck wrote: > > ... > We created a mailing list for all the mentors. If you are mentor, you > should be there. If you are not, please contact us. > ... > Where can I find this mailing list so I can add it to the other mailing lists on Nabble if you like? -- View this message in context: http://n4.nabble.com/GSoC-next-steps-tp1676708p1677264.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
