June 2012 - Pharo-dev - lists.pharo.org

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

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

by StÃ©phane Ducasse

+ 1 > he... I'm ok with that. But I want #deleteIfAbsent: :) >

June 12, 2012

Re: [Pharo-project] Look and font competition

by StÃ©phane Ducasse

If the symptoms persist consider taking one week off your keyboardâ¦

June 12, 2012

Re: [Pharo-project] Look and font competition

by StÃ©phane Ducasse

On Jun 12, 2012, at 11:37 AM, Damien Cassou wrote: > On Tue, Jun 12, 2012 at 11:14 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > yesterday we where hacking with Igor a non-OpenGL version of vm... and then we said... why not VM-support for look and feel? > So, we quickly coded this different options for look and feel (to get these, you just need to fuck up matrix translations and endianess): > > stop it! It burns LOL you do not like pink ponies but you like pink flyod. strange no? Stef > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

June 12, 2012

Re: [Pharo-project] Look and font competition

by StÃ©phane Ducasse

Ben you are cool :) I'm amazed I should buy a windows machine, I would have never imagine that they did it! You really beat us on that one :). May be we will not put it on web for the Pharo2.0 announce :) Now if somebody with better design tastes than us would have some time we would really like to get a real professional style for 2.0. Stef >> this morning Igor shows me all his work around dynlib loading of third party plugins. And yes now we get all the third party plugins downloaded and compiled (yes with only one copy of FT2)â¦.Great stuff! >> Now we would like to organize a little competition for the official look of Pharo 2.0. So if you feel that you are a little bit designer inside, please send us proposals. >> We propose this one :) based on Curlz MT (welcome to the world of the pink little ponies) :) >> >> >> > Perhaps you want to consider something like Microsoft's beloved paper clip helper ? > > <PharoPonyInterface.png>

June 12, 2012

Re: [Pharo-project] Look and font competition

by Damien Cassou

On Tue, Jun 12, 2012 at 11:14 AM, Esteban Lorenzano <estebanlm(a)gmail.com>wrote: > yesterday we where hacking with Igor a non-OpenGL version of vm... and > then we said... why not VM-support for look and feel? > So, we quickly coded this different options for look and feel (to get > these, you just need to fuck up matrix translations and endianess): > stop it! It burns -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

June 12, 2012