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

Re: [Pharo-project] UUID on ubuntu 10.04

by StÃ©phane Ducasse

I'm not sure that it is resolved. It would be good to make sure that the system does not crash even without reporting a log. May be having a stupid UUID generator as a fallback would be good. Stef > Thanks, I marked the issue as resolved and summarized the status here: > > http://bugs.squeak.org/view.php?id=7358 > > Dave > > On Wed, May 19, 2010 at 09:42:28AM +0200, St?phane Ducasse wrote: >> Apparently the student reinstalled her ubuntu from scratch (no incremental installation) and the vm did not crash >> anymore. >> >> Stef >> >> On May 17, 2010, at 9:16 PM, St?phane Ducasse wrote: >> >>> I asked the student to try. >>> >>> Stef >>> >>> On May 17, 2010, at 9:06 PM, laurent laffont wrote: >>> >>>> On ArchLinux I have the problem when UUID is built external. Official 4.0.3.2202 Unix VM binaries on http://squeakvm.org/unix/ works well for me (UUID is internal). >>>> >>>> Can you try with this one click image I made once (uses 4.0.3.2202 binaries) http://lolgzs.free.fr/pharo/Pharo-1.0-OneClick.zip >>>> >>>> Laurent Laffont >>>> >>>> http://pharocasts.blogspot.com/ >>>> http://magaloma.blogspot.com/ >>>> >>>> >>>> On Mon, May 17, 2010 at 8:24 PM, St?phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>>> I can confirm that this is exactly the same trace than the one reported by laurent (no debug file). >>>> >>>> Stef >>>> On May 17, 2010, at 7:51 PM, David T. Lewis wrote: >>>> >>>>> On Mon, May 17, 2010 at 07:38:59PM +0200, St?phane Ducasse wrote: >>>>>> Hi guys >>>>>> >>>>>> I took seaside the latest one click image and when I have to save a MC package >>>>>> I get a core dump with UUID new:... >>>>>> I checke the so.UUIDplugin is there and I do not understand. >>>>>> Can somebody with a Ubuntu give a try to save something using MC and the latest seaside one click. >>>>> >>>>> Hi Stef, >>>>> >>>>> This issue is being tracked here: http://bugs.squeak.org/view.php?id=7358 >>>>> >>>>> It is not clear to me if the issue is resolved in the Ian's latest VM >>>>> build, so if you or anyone else can confirm the UUID crash happening >>>>> with this VM, that would be helpful to clarify. >>>>> >>>>> Dave > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 19, 2010

Re: [Pharo-project] [Gofer] loading only from package cache but with the same expression

by Lukas Renggli

The default Gofer only uses the package cache: Gofer new repositories --> an Array(a MCCacheRepository(/Users/renggli/University/pharo/PetitParser/package-cache)) If you specify other repositories they are tried in that order as well: Gofer new renggli: 'ob'; squeaksource: 'rb'; repositories --> an Array(a MCCacheRepository(/Users/renggli/University/pharo/PetitParser/package-cache) a MCHttpRepository(http://source.lukas-renggli.ch/ob) a MCHttpRepository(http://www.squeaksource.com/rb)) If you disable the package cache, the package cache is ignored: Gofer new disablePackageCache; renggli: 'ob'; squeaksource: 'rb'; repositories --> an Array(a MCHttpRepository(http://source.lukas-renggli.ch/ob) a MCHttpRepository(http://www.squeaksource.com/rb)) If you disable repository errors inaccessible repositories are ignored and don't throw an error (you have to tell that though): Gofer new disableRepositoryErrors; renggli: 'ob'; squeaksource: 'rb'; repositories --> an Array(a MCCacheRepository(/Users/renggli/University/pharo/PetitParser/package-cache) a MCHttpRepository(http://source.lukas-renggli.ch/ob) a MCHttpRepository(http://www.squeaksource.com/rb)) Lukas On 19 May 2010 16:59, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Hi lukas > > is it possible that for an expression that would work if we get network Gofer looks only in the package cache. > so that when you do not have internet but are sure that the files you need are in the package cache > you can use gofer to load them > > I thought is was working but this is not that clear. I could not make it work in the library. > > Stef > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli www.lukas-renggli.ch

May 19, 2010

Re: [Pharo-project] problem with CompiledMethod equality

by Eliot Miranda

On Wed, May 19, 2010 at 4:58 AM, Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com> wrote: > Hi Eliot, > What about super sends ? > > Object>>beNasty > ^self > > Collection>>beNasty > self addLast; 1. > super beNasty. > > OrderedCollection>>beNasty > self addLast; 1. > super beNasty. > Good point. I still find the existing #= definition very useful for compiler verification. > > Do you think you can remove OrderedCollection>>beNasty ? > > Nicolas > > 2010/5/19 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > > Elliot I think that we already took into changes made by nicolas. > > > > Stef > > > > On May 19, 2010, at 2:35 AM, Eliot Miranda wrote: > > > >> Hi Lukas, > >> > >> On Tue, May 18, 2010 at 8:17 AM, Lukas Renggli <renggli(a)gmail.com> > wrote: > >> > Same method in different classes do not equal eachother though, if > I've not made a mistake in: > >> > > >> > |mrtCp| > >> > mrtCp := (InstructionClient>>#methodReturnTop) copy. > >> > mrtCp literalAt: 2 put: #ContextPart->ContextPart. > >> > (InstructionClient>>#methodReturnTop) = mrtCp > >> > >> For methods that send super the behavior changes if you change the > >> class binding. That's probably why it is not ignored for #=. > >> > >> In fact I would suggest to #= from compiled method altogether, in most > >> cases it doesn't do what one would expect in a given context anyway. > >> There are too many and possibility completely different > >> interpretations of #= for CompiledMethod. #== is the only decent > >> implementation for this class. > >> > >> I sympathise but I think there is a reasonable default interpretation of > #= for CompiledMethod that is what most people want. The intent is to > answer whether two methods have the same execution semantics and same method > tags & properties, e.g. if one were to compile the same source code in two > different classes that had the same inst var offsets for the inst vars in > the methods, then one would want those methods to be #=. This allows tests > such as > >> - checking whether a subclass has a method that is #= to a superclass, > and is hence redundant. > >> - checking whether a set of sourceless methods are equivalent so that > they may be shared under different selectors (e.g. think auto-generated > accessor methods which can be cached and shared) > >> So for this informal definition the selector and the class are > irrelevant, but bytecodes and literals (apart from the selector and method > class literals) are relevant. Its almost a short-cut comparison of > error-free decompilation, although there are differences in the bytecode > that wouldn't show in decompilation (e.g. using long branches for short > branches). > >> > >> The current definition serves for compiler hackers as it tells you > accurately whether a compiler change has an effect on the bytecode, can be > used to test whether compilation followed by decompilation followed by > recompilation has an effect, etc. While it may not be a universal code > comparison method it has met my needs throughout the closure compiler so at > least I'm pretty happy with it. > >> > >> (pleading for CompiledMethod>>#= to stay the same as the current Squeak > 4.1 definition, which ever since Nichoas Celier's float compilation changes, > is pretty darned good). > >> > >> best > >> Eliot > >> > >> > >> > >> > >> > >> Lukas > >> > >> > > >> > At the very least, the branches of > >> > index = 1 and: [ #(117 120) includes: self primitive ]) > >> > ifTrue: [ > >> > > >> > REALLY deserve some comments... > >> > > >> > Cheers, > >> > Henry > >> > > >> > > >> > > >> > _______________________________________________ > >> > Pharo-project mailing list > >> > Pharo-project(a)lists.gforge.inria.fr > >> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >> > > >> > >> > >> > >> -- > >> Lukas Renggli > >> www.lukas-renggli.ch > >> > >> _______________________________________________ > >> Pharo-project mailing list > >> Pharo-project(a)lists.gforge.inria.fr > >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >> > >> _______________________________________________ > >> 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 > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

May 19, 2010

[Pharo-project] [Gofer] loading only from package cache but with the same expression

by StÃ©phane Ducasse

Hi lukas is it possible that for an expression that would work if we get network Gofer looks only in the package cache. so that when you do not have internet but are sure that the files you need are in the package cache you can use gofer to load them I thought is was working but this is not that clear. I could not make it work in the library. Stef

May 19, 2010

Re: [Pharo-project] UUID on ubuntu 10.04

by David T. Lewis

Thanks, I marked the issue as resolved and summarized the status here: http://bugs.squeak.org/view.php?id=7358 Dave On Wed, May 19, 2010 at 09:42:28AM +0200, St?phane Ducasse wrote: > Apparently the student reinstalled her ubuntu from scratch (no incremental installation) and the vm did not crash > anymore. > > Stef > > On May 17, 2010, at 9:16 PM, St?phane Ducasse wrote: > > > I asked the student to try. > > > > Stef > > > > On May 17, 2010, at 9:06 PM, laurent laffont wrote: > > > >> On ArchLinux I have the problem when UUID is built external. Official 4.0.3.2202 Unix VM binaries on http://squeakvm.org/unix/ works well for me (UUID is internal). > >> > >> Can you try with this one click image I made once (uses 4.0.3.2202 binaries) http://lolgzs.free.fr/pharo/Pharo-1.0-OneClick.zip > >> > >> Laurent Laffont > >> > >> http://pharocasts.blogspot.com/ > >> http://magaloma.blogspot.com/ > >> > >> > >> On Mon, May 17, 2010 at 8:24 PM, St?phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > >> I can confirm that this is exactly the same trace than the one reported by laurent (no debug file). > >> > >> Stef > >> On May 17, 2010, at 7:51 PM, David T. Lewis wrote: > >> > >>> On Mon, May 17, 2010 at 07:38:59PM +0200, St?phane Ducasse wrote: > >>>> Hi guys > >>>> > >>>> I took seaside the latest one click image and when I have to save a MC package > >>>> I get a core dump with UUID new:... > >>>> I checke the so.UUIDplugin is there and I do not understand. > >>>> Can somebody with a Ubuntu give a try to save something using MC and the latest seaside one click. > >>> > >>> Hi Stef, > >>> > >>> This issue is being tracked here: http://bugs.squeak.org/view.php?id=7358 > >>> > >>> It is not clear to me if the issue is resolved in the Ian's latest VM > >>> build, so if you or anyone else can confirm the UUID crash happening > >>> with this VM, that would be helpful to clarify. > >>> > >>> Dave

May 19, 2010

[Pharo-project] CollaborActive Book ...

by Geert Claes

Is there an easier way to upload, insert and replace pictures in the Collaboractive Book? -- View this message in context: http://forum.world.st/CollaborActive-Book-tp2222835p2222835.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 19, 2010

Re: [Pharo-project] about condenseChanges

by Marcus Denker

On May 19, 2010, at 2:42 PM, StÃ©phane Ducasse wrote: > Yes I thought about that too. > Now I done it to remove strange compiled methods floating around. > But that's done with #cleanUpForRelease.... it removes all changesets, then the CMs that are referenced by them are GCed. Marcus > Stef > > On May 19, 2010, at 2:37 PM, Henrik Johansen wrote: > >> On May 19, 2010, at 2:05 33PM, StÃ©phane Ducasse wrote: >> >>> Hi marcus/others >>> >>> I did a condenseChanges and I'm planning to issue a new image. I wanted to avoid to put it in the stream of updates >>> because since it takes a long time everybody can be penalized but at the same time we will not have the same flow >>> if we start from 1.0 and press update. >>> Thoughts? >>> >>> Stef >> Is it really necessary? >> The difference in a zipped archive together with the image is a meager 1.2MB. >> I personally really don't mind the 5MB extra of spent diskspace for the uncondensed .changes file... >> >> Cheers, >> Henry >> _______________________________________________ >> 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 -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

May 19, 2010

Re: [Pharo-project] about condenseChanges

by StÃ©phane Ducasse

Yes I thought about that too. Now I done it to remove strange compiled methods floating around. Stef On May 19, 2010, at 2:37 PM, Henrik Johansen wrote: > On May 19, 2010, at 2:05 33PM, StÃ©phane Ducasse wrote: > >> Hi marcus/others >> >> I did a condenseChanges and I'm planning to issue a new image. I wanted to avoid to put it in the stream of updates >> because since it takes a long time everybody can be penalized but at the same time we will not have the same flow >> if we start from 1.0 and press update. >> Thoughts? >> >> Stef > Is it really necessary? > The difference in a zipped archive together with the image is a meager 1.2MB. > I personally really don't mind the 5MB extra of spent diskspace for the uncondensed .changes file... > > Cheers, > Henry > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 19, 2010

Re: [Pharo-project] about condenseChanges

by Henrik Johansen

On May 19, 2010, at 2:05 33PM, StÃ©phane Ducasse wrote: > Hi marcus/others > > I did a condenseChanges and I'm planning to issue a new image. I wanted to avoid to put it in the stream of updates > because since it takes a long time everybody can be penalized but at the same time we will not have the same flow > if we start from 1.0 and press update. > Thoughts? > > Stef Is it really necessary? The difference in a zipped archive together with the image is a meager 1.2MB. I personally really don't mind the 5MB extra of spent diskspace for the uncondensed .changes file... Cheers, Henry

May 19, 2010

[Pharo-project] [update 1.1] #11367

by stephane ducasse

11367 ----- - Issue 2435: Cleanup for release does not work due to changes in NaturalLanguageTranslator - Issue 2442: Add an help entry in WorldMenu - condense changes I will issue a new image soon Stef

May 19, 2010