- Pharo-dev - lists.pharo.org

Re: [Pharo-project] FileReference should throw error when deleting unexisting files?

by Mariano Martinez Peck

On Tue, Jun 12, 2012 at 3:39 PM, Sean P. DeNigris <sean(a)clipperadams.com>wrote: > > Mariano Martinez Peck wrote > > > > Now I found another problem.... > > > > | filesystem reference | > > filesystem := FileSystem store: DiskStore activeClass createDefault. > > reference := filesystem * 'plonk'. > > reference openWritable: true. > > reference exists > > > > -> answers false > > Answers true for me on Mac with this vm: > > https://ci.lille.inria.fr/pharo/view/Cog/job/Cog-VM/Architecture=32,OS=mac/… > > really??? i have just tried with that VM and I still get a false. Can you try with a different name instead of 'plonk' ??? like 'dasdasdasdasdasd' ? :) > -- > View this message in context: > http://forum.world.st/FileReference-should-throw-error-when-deleting-unexis… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > -- Mariano http://marianopeck.wordpress.com

June 12, 2012

Re: [Pharo-project] Pharo 2.0 Jenkins build failing

by Pavel Krivanek

On Tue, Jun 12, 2012 at 3:53 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > Pavel Krivanek-3 wrote >> >> But will it work on Jenkins? Because the update process will want to >> process the updates one by one so Jenkins will want to load this >> patches too late (as part of later update). I guess we will need to >> revert the last updates. >> > > Hmm... it seemed like a *lot* of work for Steph to get the FS-everywhere and > progress bar updates in... is there no way to sneak the st files in just to > get it working? Can we temporarily change the build script to insert the sts > or maybe just wrap it in an error handler that catches invalid dates coming > out of the zip reading method... > > Once we're up to latest update, I can just make a slice... > > Sean I hope it will be possilbe to create packages with the progress bar patches and then to create one all-embracing update simply using the latest packages versions. -- Pavel > > -- > View this message in context: http://forum.world.st/Pharo-2-0-Jenkins-build-failing-tp4634306p4634477.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

June 12, 2012

Re: [Pharo-project] Pharo 2.0 Jenkins build failing

by Sean P. DeNigris

Pavel Krivanek-3 wrote > > But will it work on Jenkins? Because the update process will want to > process the updates one by one so Jenkins will want to load this > patches too late (as part of later update). I guess we will need to > revert the last updates. > Hmm... it seemed like a *lot* of work for Steph to get the FS-everywhere and progress bar updates in... is there no way to sneak the st files in just to get it working? Can we temporarily change the build script to insert the sts or maybe just wrap it in an error handler that catches invalid dates coming out of the zip reading method... Once we're up to latest update, I can just make a slice... Sean -- View this message in context: http://forum.world.st/Pharo-2-0-Jenkins-build-failing-tp4634306p4634477.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

June 12, 2012

Re: [Pharo-project] Pharo 2.0 Jenkins build failing

by Pavel Krivanek

But will it work on Jenkins? Because the update process will want to process the updates one by one so Jenkins will want to load this patches too late (as part of later update). I guess we will need to revert the last updates. -- Pavel On Tue, Jun 12, 2012 at 3:20 AM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > StÃ©phane Ducasse wrote >> >> Thanks Sean. >> I'm going to paris for a presentation so I may have a look tomorrow >> evening. >> > > No problem. If anybody needs the latest update (#20129 currently) before > then, the st files attached to the issue are only needed to update > heedlessly. > > Otherwise, you can download 20119 from Jenkins and do a "software update" > via the world menu (or programmatically). > > n.b. the latest Cog Jit VM on Jenkins crashes when doing this update. The > latest Jenkins Stack VM works fine. > > HTH, > Sean > > -- > View this message in context: http://forum.world.st/Pharo-2-0-Jenkins-build-failing-tp4634306p4634400.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

June 12, 2012

Re: [Pharo-project] subclassResponsibility, how does it work?

by Sean P. DeNigris

Camillo Bruni-3 wrote > > this question is more appropriate on the user mailinglist or on even > better on stackoverflow (tag #pharo) > please repost on pharo-users@.inria > +1 -- View this message in context: http://forum.world.st/subclassResponsibility-how-does-it-work-tp4634436p463… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

June 12, 2012

Re: [Pharo-project] FileReference should throw error when deleting unexisting files?

by Sean P. DeNigris

Mariano Martinez Peck wrote > > Now I found another problem.... > > | filesystem reference | > filesystem := FileSystem store: DiskStore activeClass createDefault. > reference := filesystem * 'plonk'. > reference openWritable: true. > reference exists > > -> answers false Answers true for me on Mac with this vm: https://ci.lille.inria.fr/pharo/view/Cog/job/Cog-VM/Architecture=32,OS=mac/… -- View this message in context: http://forum.world.st/FileReference-should-throw-error-when-deleting-unexis… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

June 12, 2012

Re: [Pharo-project] FileReference should throw error when deleting unexisting files?

by Mariano Martinez Peck

Now I found another problem.... | filesystem reference | filesystem := FileSystem store: DiskStore activeClass createDefault. reference := filesystem * 'plonk'. reference openWritable: true. reference exists -> answers false, but | filesystem reference | filesystem := FileSystem memory. reference := filesystem * 'plonk'. reference openWritable: true. reference exists -> answers true. So...first, they should be polimorphic, right? second, which one is the correct? I guess in memory? thanks On Tue, Jun 12, 2012 at 11:45 AM, StÃ©phane Ducasse < stephane.ducasse(a)inria.fr> wrote: > + 1 > > > he... I'm ok with that. But I want #deleteIfAbsent: :) > > > > -- Mariano http://marianopeck.wordpress.com

June 12, 2012

Re: [Pharo-project] recompiling class

by Stan Shepherd

Marcus Denker-4 wrote > > In Smalltalk, not only *new* instances get the changed > class layout, but *all* existing ones are migrated. > > There is always just one version of a class in the system, all instances > are of that version. > Excepting Gemstone, which allows different versions to coexist, and can specify differing migration strategies for instances: http://www.gemstone.com/docs/GemStoneS/GemStone6X/6.5/GSS-ProgGuide-6.0.pdf ...Stan On Jun 9, 2012, at 8:26 AM, S Krish wrote: > > > Can we do this in Pharo: > > "in Java, the computation of numeric offsets for instance elds in memory > is done by > the run-time system. This permits updating a class with new instance elds > or methods without > affecting existing code. In other words, it is possible to run an > existing bytecode file for a subclass > after updating and recompiling the class, but without recompiling the > subclass." Hello, In Smalltalk, not only *new* instances get the changed class layout, but *all* existing ones are migrated. There is always just one version of a class in the system, all instances are of that version. Thus, if you add a instvar in a superclass, the iVar offsets of the subclasses have to be fixed. Right now this is done by recompiling the all subclasses, but you could be much more intelligent: filter for those methods that actually reference ivars and then don't recompile but just change the offset. This "just" is more difficult than it seems: changing an offset can mean that the bytecode needed is larger (2 instead of 1), and that then means jump offsets need to be changed. Which in turn can mean that the larger jump needs more bytecode, too.. So in practice, the best is to decompile to an Intermediate Representation that is at the level of bytecode, yet abtracts away jumps and the decision of which bytecode exactly it used. For the backend of Opal, I did some crude benchmark for Martin this week: Decompiling to IR and re-generating of all methods in Morph that access iVars takes 0.8 seconds... We will add the IR backend to 2.0 soon and the new ClassBuilder will use it. But in general, it would be nice to late-bind the offsets and just use names in the representation that a method is saved in. Marcus -- Marcus Denker -- http://marcusdenker.de -- View this message in context: http://forum.world.st/recompiling-class-tp4633989p4634467.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

June 12, 2012

Re: [Pharo-project] FileReference should throw error when deleting unexisting files?

by Henrik Sperre Johansen

On 11.06.2012 20:38, Mariano Martinez Peck wrote: > So if we now do: > > 'afileThatDoesntExist' asFileReference delete > > I get a PrimitiveFailed. If this is what we want, can I add: > > FileReference >> deleteIfExists > > self exists ifTrue: [ self delete] > > or something like that? because lots of places (tearDown of tests) I > want to remove crao which may or may not exist... > > thanks > > -- > Mariano > http://marianopeck.wordpress.com > Is there any specific reason why you need to use setUp/tearDown instead of a more restricted scope? For scoped operations like tests, I always liked the XFileNamed: do: api, when you have references, how about: aFileReference tempFileDo: [:fileStream :canonicalPath (culled) |] Could be useful for command line interaction as well, I guess. Cheers, Henry

June 12, 2012

Re: [Pharo-project] Look and font competition

by Igor Stasenko

On 12 June 2012 11:44, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > If the symptoms persist consider taking one week off your keyboardâ¦ > > unfortunately, we managed to display it like it should :) -- Best regards, Igor Stasenko.

June 12, 2012