March 2011 - Pharo-dev - lists.pharo.org

[Pharo-project] COG VM Locale?

by Hilaire Fernandes

Is it likely it'll be fixed? If so when? I need to know so I can move to plan B if necessary. http://code.google.com/p/cog/issues/detail?id=1 Hilaire -- Education 0.2 -- http://blog.ofset.org/hilaire

March 26, 2011

Re: [Pharo-project] "Does Committing Code to an Open Source Project Mean Committing Career Suicide?"

by csrabak＠bol.com.br

Craig, IANALÂ but the reading of the section 2897 (1) and (2) seem to me exactly the cases the site is bringing on, and being so harder to discern in cases of SW development than other 'hard' stuff, like say kid toy inventions versus working in a factory that builds industrial furnaces. -- Cesar Rabak Em 25/03/2011 06:00, Craig Latta < craig(a)netjam.org > escreveu: Wow. The stuff in there about California law is simply false. See the California labor code, sections 2870-2872 (e.g., at [1]). -C [1] http://law.justia.com/codes/california/2009/lab/2870-2872.html -- Craig Latta www.netjam.org/resume +31 06 2757 7177 + 1 415 287 3547

March 25, 2011

Re: [Pharo-project] Pharo 1.2 red again

by Dale Henrichs

On Mar 25, 2011, at 3:29 PM, Tudor Girba wrote: > Sounds great. So, what needs to be done then? That depends upon what you are trying to do...For GemStone I have a class called GLASSProjectSupport that does the following: 1. fetches all mczs and configurations for ConfigurationOfGLASS into an in-memory dictionary-based repository 2. copies new mcz files (packages and configs) into a directory in an svn checkout directory, recording the original repository from which the package was downloaded 3. updates a packing list file so that the new mcz files are automatically copied into the correct directory for release 4. generates a topaz script that is used to bootstrap GLASS from the svn directory and the repository map is used to set the repositoryGroup correctly (as if the mcz files weren't loaded from the svn directory). The basic script for doing step 1 is here: http://code.google.com/p/metacello/wiki/FAQ#How_do_I_create_a_local_cache_r… although you would probably want to set ignoreImage: to true: version ignoreImage: true. There's a little bit more monkey business if you want to store your project configuration (like ConfigurationOfGLASS) in your archive directory. If you want to record the original repositories or get your hands on the list of mcz files/configs that were loaded, then it gets a little more complicated: loadDirective := version fetch loadDirective You can traverse the loadDirective and extract the additional information you might want ... If you are going to load using Metacello then a script for step 4 is here: http://code.google.com/p/metacello/wiki/FAQ#How_do_I_override_the_repositor… I have toyed with the idea of creating something like a .mar file which would essentially encapsulate the above into a couple of steps: - one for create the .mar file - one for loading from the .mar file The .mar file would be a zipped up directory repository plus some sort of doit that would provide the load instructions/options....for a .mar file it might be worth restoring the repositoryGroups for the mcz files, which means recording a repository map... I haven't looked closely at the .sar file stuff, but maybe the .mar file could be wrapped in a .sar so that other deliverables could be included ... and a .mar file would just be a special case of a .sar file? I am partial to the .mar file idea and I don't think there's that much new that would have to be invented, but I haven't thought through all of the issues yet ... but now might be a good time to encapsulate the whole process and tie it up with a bow:) Dale

March 25, 2011

Re: [Pharo-project] Pharo 1.2 red again

by Tudor Girba

Sounds great. So, what needs to be done then? I would be interested to use this in the context of Moose as well. Cheers, Doru On 24 Mar 2011, at 21:36, StÃ©phane Ducasse wrote: > this is a good news > > Stef > > On Mar 24, 2011, at 4:59 PM, Dale Henrichs wrote: > >> Stef, >> >> Yep ... all the pieces are there ... it's just a matter of putting them together in the right order..this is what we do for GemStone GLASS builds... >> >> Dale >> >> On Mar 24, 2011, at 1:21 AM, StÃ©phane Ducasse wrote: >> >>> henrichs >>> >>> do you know if you have now the pieces in place to be able to freeze a configuration and all its recursive sets in a dedicated repository? >>> >>> Stef >> >> > > -- www.tudorgirba.com "Every successful trip needs a suitable vehicle."

March 25, 2011

Re: [Pharo-project] Issue 2704 in pharo: Tests for broken withNoLineLongerThan: behavior.

by pharo＠googlecode.com

Comment #9 on issue 2704 by nicolas....(a)gmail.com: Tests for broken withNoLineLongerThan: behavior. http://code.google.com/p/pharo/issues/detail?id=2704 SLICE-Issue-2704-String-withNoLineLongerThan-nice.1 contains fresh Squeak test and fix. Pocho, you can correct the alternative if you want, but this method is damned tricky (I broke some teeth on it).

March 25, 2011

Re: [Pharo-project] Issue 2704 in pharo: Tests for broken withNoLineLongerThan: behavior.

by pharo＠googlecode.com

Comment #8 on issue 2704 by nicolas....(a)gmail.com: Tests for broken withNoLineLongerThan: behavior. http://code.google.com/p/pharo/issues/detail?id=2704 No, both methods fails with this test: String crlf withNoLineLongerThan: 5. Also, does your version works when there is no space available near ? 'ThisMightBe tooLong' withNoLineLongerThan: 5.

March 25, 2011

Re: [Pharo-project] [update 1.3] #13110

by Igor Stasenko

On 25 March 2011 20:36, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > On Mar 25, 2011, at 7:01 PM, Miguel CobÃ¡ wrote: > >> El vie, 25-03-2011 a las 18:34 +0100, StÃ©phane Ducasse escribiÃ³: >>> 13110 >>> ----- >>> >>> - Issue 3881: Â Â Â Â Problem with Inst var refs.... Thanks Benjamin van Ryseghem. >>> - Issue 3879: Â Â Â Â Wipe out positional arguments cruft from compiler. Thanks Igor Stasenko. >>> - Â Issue 3859: Â Â Â Pluggin control. Thanks Igor Stasenko. >>> - Issue 3715: Â Â Â Â Workspace shouting after switching between shout/unshout. Thanks Benjamin van Ryseghem. >>> - Cleaning MCPackageManager. >>> - Fixing some as yet unclassified categories. >>> >>> Stef and igor happy integrating and chatting about life :) >> >> .. the universe and everything? > > No just life and fun :) > Vision... I showed to igor my old squeak presentation made with Etoy navigator to show him the old > blue look which was quite cool in 1999 but was never integrated in squeak. Anyway different period. > It was sad to see that there was great things in past, which was then abandoned, because nobody took care about putting everything together and making it into Squeak images by default. >> 42! > > -- Best regards, Igor Stasenko AKA sig.

March 25, 2011

Re: [Pharo-project] [update 1.3] #13110

by StÃ©phane Ducasse

On Mar 25, 2011, at 7:01 PM, Miguel CobÃ¡ wrote: > El vie, 25-03-2011 a las 18:34 +0100, StÃ©phane Ducasse escribiÃ³: >> 13110 >> ----- >> >> - Issue 3881: Problem with Inst var refs.... Thanks Benjamin van Ryseghem. >> - Issue 3879: Wipe out positional arguments cruft from compiler. Thanks Igor Stasenko. >> - Issue 3859: Pluggin control. Thanks Igor Stasenko. >> - Issue 3715: Workspace shouting after switching between shout/unshout. Thanks Benjamin van Ryseghem. >> - Cleaning MCPackageManager. >> - Fixing some as yet unclassified categories. >> >> Stef and igor happy integrating and chatting about life :) > > .. the universe and everything? No just life and fun :) Vision... I showed to igor my old squeak presentation made with Etoy navigator to show him the old blue look which was quite cool in 1999 but was never integrated in squeak. Anyway different period. > 42!

March 25, 2011

Re: [Pharo-project] Remove #class as a Compiler optimization

by Igor Stasenko

On 25 March 2011 19:22, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > > > On Fri, Mar 25, 2011 at 7:08 PM, Toon Verwaest <toon.verwaest(a)gmail.com> > wrote: >> >>>> What do you think? >>> >>> I am for... for the JIT is is a monomorphic send to a primitive, so the >>> IC will be very effective >>> and should take care that the lookup is actually almost never done. (and >>> the lookup is the >>> only thing the #class bytecode saves, as the target method is a >>> primitive). >> >> I think that programmers should have the illusion that the VM interacts >> with the system through message sends. By being able to overwrite this >> particular message you break this illusion. The VM will just fetch the real >> class; but the user doesn't get access to it anymore. Telling the system >> that this particular message shouldn't be overwritten is probably a good >> thing. >> >> If you want to overwrite the method class, maybe your tools should send >> another message than class in the first place? > > Of course I can do that. I can also do > > Â Â Â (ParseNode classVarNamed:Â 'StdSelectors') removeKey: #class ifAbsent: > []. > Â Â Â Compiler recompileAll. > > I don't care. I have it working for my "usage". This was just an example. > > And don't compare #class with all the boolean methods like #ifNil:Â and > friendsÂ or the bytecodes for integer operations....I think #class is sent > far less times than those... > Yes. and i predict that performance impact in macro benchmarks, where you running normal code (which not sending this message intentionally in a loop) will be at the noise level magnitude. > >> >> I do however agree that many other optimizations become slightly >> superfluous, such as bytecodes for integer operations ... that somehow seems >> like compile-time inline-cached behavior without the ability to flush the >> cache :) >> >> cheers, >> Toon >> > > -- Best regards, Igor Stasenko AKA sig.

March 25, 2011

Re: [Pharo-project] pharo closures

by Eliot Miranda

On Fri, Mar 25, 2011 at 12:54 AM, StÃ©phane Ducasse < stephane.ducasse(a)inria.fr> wrote: > > On Mar 25, 2011, at 2:51 AM, Toon Verwaest wrote: > > > Ok, I will do so. (read the f-ing paper) I only read the blogpost until > now. > > which paper? > Is there something more than the blog? I read the old VW5 paper but eliot > told me that this is old and not accurate with Cog anymore. > The http://www.esug.org/data/Articles/misc/oopsla99-contexts.pdf paper describes the problem with an implementation of closures using contexts such as that described by Toon, since the pre-5i implementation is isomorphic to Toon's. It also describes the 5i solution which is also essentially isomorphic to my Squeak closure implementation. But in detail this paper clearly does not describe my Squeak closure implementation; the bytecodes have different names etc. > > > > I just realized that I actually made a mistake in my mental model of your > model. See! It's complex! > > So I realized that getting to the remotes is exactly as fast as going to > the parent or outer context. > > > > This makes it as fast as having a method context with maximally 2 nested > contexts (3 blocks nested), and faster than deeper nestings. How often does > it occur that you have deeper nesting in Pharo? Is it worthwhile to make the > remote arrays just for those cases? > > > > Is the copying really worthwhile to make those cases faster? > > > > My biggest problem until now is... why wouldn't you be able to do > everything you do with the remote arrays, directly with the context frames? > Why limit it to only the part that is being closed over? The naive > implementation that just extends squeak with proper closure-links will > obviously be slow. I agree that you need a stack. Now I'd just like to read > why you choose to just take a part of the frame (the remote array) rather > than the whole frame. This would avoid the copyTemps thing... > > > > But then. I guess I should go off and read the f-ing paper. I hope that > particular thing is described there, since it's basically the piece I'm > missing. > > > > Also I don't exactly know what Peter Deutsch did, but if it was the > straightforward implementation then it seems obvious you get such a > speedup. Implementing it is less obvious, naturally ;) > > These responses are exactly why I posed the question here... I'd like to > understand why. No offense. > > > > cheers, > > Toon > > > > > > On 03/25/2011 02:22 AM, Eliot Miranda wrote: > >> Toon, > >> > >> what you describe is how Peter Deutsch designed closures for > ObjectWorks 2.4 & ObjectWorks 2.5, whose virtual machine and bytecode set > served all the way through VisualWorks 3.0. If you read the context > management paper you'll understand why this is a really slow design for a > JIT. When I replaced that scheme by one essentially isomorphic to the > Squeak one the VM became substantially faster; for example factors of two > and three in exception delivery performance. The description of the problem > and the performance numbers are all in the paper. There are two main > optimizations I performed on the VisualWorkas VM, one is the closures scheme > and the other is PICs. Those together sped-up what was the fastest > commercial Smalltalk implementation by a factor of two on most platforms and > a factor of three on Windows. > >> > >> I'm sorry it's complex, but if one wants good performance it's a price > well-worth paying. After all I was able to implement the compiler and > decompiler within a month, and Jorge proved at INRIA-Lille that I'm far form > the only person on the planet who understands it. Lispers have understood > the scheme for a long time now. > >> > >> best, > >> Eliot > >> > >> On Thu, Mar 24, 2011 at 6:01 PM, Toon Verwaest <toon.verwaest(a)gmail.com> > wrote: > >> > >> I can't say that i clearly understood your concept. But if it will > >> simplify implementation > >> without seemingly speed loss, i am all ears :) > >> > >> > >> test > >> |b| > >> [ |a| > >> a + b ] > >> > >> Suppose you can't compile anything away, then you get > >> > >> |============== > >> |MethodContext > >> | > >> |a := ... > >> |============== > >> ^ > >> | > >> |============== > >> |BlockContext > >> | > >> |b := ... > >> |============== > >> > >> And you just look up starting at the current context and go up. Except > if the var is from the homeContext, then you directly follow the > home-context pointer. > >> Since all contexts link to the home-context, this makes it 1 pointer > indirection to get to the method's context. 1 for the parent context. So > that makes only 2 indirections starting from the 3 nested block (so when you > have [ ... [ ... [ ... ] ... ] ... ]; where all of them are required for > storing captured data. ifTrue:ifFalse: etc blocks obviously don't count. And > blocks without shared locals could be left out (although we might not do > that, for debugging reasons). > >> > >> Hope that helps. > >> > >> cheers, > >> Toon > >> > >> > > > > >

March 25, 2011