September 2009 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Closure fixes

by Michael Roberts

hah! ok, no that wasn't what i expected. that will be why stef's image dies. but i guess i was lucky when i tried it. let me test out a new script and i will repost. cheers, Mike On Sun, Sep 20, 2009 at 7:30 PM, Lukas Renggli <renggli(a)gmail.com> wrote: >> No, the fixes are not dependent on Gofer. I am just using it to script >> the load. Â There's been a lot of chat about Gofer - i had no idea what >> it was. so i figured i'd use it for something! > > Looks cool. > > However, from your comments I doubt that Gofer does what you expect. > Gofer does not load the packages in the order specified, but instead > merges the contents of all specified packages into one single load > operation. From the comments in the script I think that every Part 1 > to 9 should all use their own Gofer instance to be truly sequential. > > Cheers, > Lukas > > -- > Lukas Renggli > http://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 >

Sept. 20, 2009

Re: [Pharo-project] Closure fixes

by Lukas Renggli

> No, the fixes are not dependent on Gofer. I am just using it to script > the load. Â There's been a lot of chat about Gofer - i had no idea what > it was. so i figured i'd use it for something! Looks cool. However, from your comments I doubt that Gofer does what you expect. Gofer does not load the packages in the order specified, but instead merges the contents of all specified packages into one single load operation. From the comments in the script I think that every Part 1 to 9 should all use their own Gofer instance to be truly sequential. Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Sept. 20, 2009

Re: [Pharo-project] Closure fixes

by Michael Roberts

No, the fixes are not dependent on Gofer. I am just using it to script the load. There's been a lot of chat about Gofer - i had no idea what it was. so i figured i'd use it for something! If your image freezes that's bad. Did it ever come back? I did this from #10451. The only thing i was worried about was if I had not copied all the packages to task forces, since they are all in my local cache. There are also a few test classes to change, but i'll do that after this is in the update stream. i.e there are 2 unexpected passes in my image because some closure/compiler tests now pass. (excellent!) I've done the recompilation slightly differently. This was one of the things i wanted to talk about. Andreas made various changes to MC packages to get it in, overriding initialize and things on various classes. I'm not sure we need that since we can use ScriptLoader. However this needs to be tested. I just trigger the recompile that squeak used. There is not a lot of UI feedback. the whole thing could do with being inside a Cursor busy during: [] etc. cheers, Mike On Sun, Sep 20, 2009 at 6:01 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > >>> If you are interested in testing the closure fixes, I have scripted >>> it. Â Run each section in turn. Â I have a few things for discussion, >>> but first some feedback would be useful. >> >> I will have a look! > > Excellent! > Once this is working I would declare it release candidates (more or > less) (and tag red tests as broken ones). > > Stef > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 20, 2009

Re: [Pharo-project] Status of Alien FFI

by Marcus Denker

On 20.09.2009, at 13:49, StÃ©phane Ducasse wrote: > They probably moved while we got stuck. It's like with money: there is an "inflation" of constant progression. Everthing gets better slowly but constantly. Over 10 years, this results in quite some progress. Especially as you get the effect of "compound interest": By making something a little bit better, the next step of making it again a little bit better gets a little bit easier. As with compound interest, the effect is non-linear and completely against human intuition. > This is all the story behind pharo: moving again. What one needs to ask is always: How great could a system be over time if one would just do the next trivial, tiny, small step? And that over 10 years? With Squeak, this was impossible. Every small improvement was directly criticised as beeing "not good enough" and thus not worthwile for Squeak. With that attitude you go nowhere. As was proven in 10 years with Squeak. Of course, you should not *just* do tiny improvements. But it's like investing: there might be the chance to buy some pre-ipo stock cheap in the future. Does that mean that I put the money under the bed for no interest, or do I invest it for some tiny percentage e.g in a money-market account the meantime? With Squeak, the community decided that doing nothing was the right thing. Marcus -- Marcus Denker - http://marcusdenker.de PLEIAD Lab - Computer Science Department (DCC) - University of Chile

Sept. 20, 2009

Re: [Pharo-project] Status of Alien FFI

by StÃ©phane Ducasse

They probably moved while we got stuck. This is all the story behind pharo: moving again. >>> Lua is SLOW :) >> >>> But still - you can go and see the speed comparison of different >>> numerical algorythms implemented in different languages. >>> Squeak leaves Lua far behind.. >> That sounds like FUD. >> But, maybe I misunderstand you here. >> >> However, Lua 5.x is FAST, especially for an interpreted language. Its >> register-based implementation seems to be much better for >> interpretation in terms of speed than the stack-based bytecode in >> Squeak. >> >> See: http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=lua&lang2… >> > Hmm.. it looks like im wrong. Because couple years back it was slower. >

Sept. 20, 2009

Re: [Pharo-project] Status of Alien FFI

by Igor Stasenko

2009/9/19 Stefan Marr <pharo(a)stefan-marr.de>: > > On 19 Sep 2009, at 08:46, Igor Stasenko wrote: > >> Lua is SLOW :) > >> But still - you can go and see the speed comparison of different >> numerical algorythms implemented in different languages. >> Squeak leaves Lua far behind.. > That sounds like FUD. > But, maybe I misunderstand you here. > > However, Lua 5.x is FAST, especially for an interpreted language. Its > register-based implementation seems to be much better for > interpretation in terms of speed than the stack-based bytecode in > Squeak. > > See: http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=lua&lang2… > Hmm.. it looks like im wrong. Because couple years back it was slower. > And: Virtual Machine Showdown: Stack Versus Registers > Yunhe Shi and Kevin Casey and M. Anton Ertl and David Gregg > ACM Trans. Archit. Code Optim.4(4):1--36(2008) > > > Best regards > Stefan > >> Especially, i think, if you use language for scripting, so scripts >> will tend to contain more logic than heavy numeric crunching (because >> for numerical crunching hardcore devs using C & GPU) - smalltalk will >> win even more. >> >>> Stef >>> >>> On Sep 19, 2009, at 5:28 AM, Igor Stasenko wrote: >>> >>>> 2009/9/18 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>>>> yes this is one of my dream but .... >>>>> I'm not good enough to make it come true. >>>>> >>>> >>>> Lua is specifically designed from the very starting to live well as >>>> embedded system, written in C. No wonder that its having very good C >>>> interoperability. >>>> And that's why, at the time i found the smalltalk, first thing i >>>> thought, that >>>> creating an interoperability layer between C and smalltalk will >>>> unleash its potential >>>> for use in scripting. >>>> Unfortunately, almost every implementation i found & read about >>>> smalltalk vere designed as a >>>> self-sustained (or self-sufficient) sandboxed environment with a >>>> little care about host interoperability in mind. >>>> Even existence of FFI in Squeak doesn't changes that, because Squeak >>>> VM architecture >>>> as well as language-side design prevents you from controlling >>>> interpreter from outside. >>>> A less painful way for achieving a kind of embedding, as Andreas >>>> mentioned, that you can write the >>>> plugin which using callback machinery and create an image which >>>> simpli >>>> 'listening' for calls from outside >>>> then handle them and put response back. >>>> But i can't tell, how efficient it could be comparing to Lua >>>> scripting >>>> interface. >>>> >>>> For instance, if i would want to enable the dynamic primitive >>>> publishing (which host application may want to >>>> use), then this would require VM changes. >>>> That's why i proposed , some time ago, to modify the VM internal >>>> infrastructure to have a kind of namespace, >>>> which is dynamically built-up using associations of symbols (C >>>> strings) with some pointer/values. >>>> Then you can publish primitives at any time you wanting to, replace >>>> them at run time and do many other >>>> kind of tricks, which is possible, when function pointer is not >>>> bound >>>> at compile time, but discovered by VM >>>> at run time. At some point we could even use a JIT to generate the >>>> primitives and then let VM to pick them up at run time. >>>> This means, that at some point you could JIT everything you need, >>>> and >>>> replace the C-compiled VM stuff after booting the >>>> image, and from now on, VM is not something which is made from stone >>>> like all C-compiled binaries. So different >>>> images could carry own system inside which, once its booted up, no >>>> longer needs the statically compiled crap. >>>> This also means, that by having a good JIT and VM tuned for this, we >>>> don't really need writing any C code anymore, because >>>> main reason why we doing this is speed and easy interoperability >>>> with >>>> host environment. :) >>>> >>>>> Stef >>>>> >>>>> On Sep 18, 2009, at 6:40 PM, Lawson English wrote: >>>>> >>>>>> Johan Brichau wrote: >>>>>>> On 16 Sep 2009, at 20:37, Ken Treis wrote: >>>>>>> >>>>>>> >>>>>>>> * I'm creating a partial Alien library for GemStone so that I >>>>>>>> can >>>>>>>> use the CairoGraphics package in both Pharo and GLASS. But on >>>>>>>> x86-64, there there's a size difference between a pointer/long >>>>>>>> and >>>>>>>> an integer. It'd be nice to have some more explicit APIs on >>>>>>>> Alien, >>>>>>>> so I could say "Alien newCInteger" or "Alien newCLong" and have >>>>>>>> the >>>>>>>> platform return me the proper size Alien. Even without the >>>>>>>> platform >>>>>>>> size differences, it seems awkward to use "Alien newC: 4" >>>>>>>> everywhere >>>>>>>> I want an integer, "Alien newC: 8" where I want a double, etc. >>>>>>>> >>>>>>> >>>>>>> Exactly. >>>>>>> >>>>>>> It becomes worse once you start having structs and nested structs >>>>>>> or >>>>>>> structs with pointers to structs ;-) >>>>>>> >>>>>>> I'm using Alien as the FFI to port JavaConnect from Visualworks >>>>>>> to >>>>>>> Pharo/Squeak. As you say, it is a pain to work at such a low- >>>>>>> level >>>>>>> compared to the DLLCC in VW. I am planning to do some work on >>>>>>> creating >>>>>>> a higher-level interface for it such that we can operate it as >>>>>>> you >>>>>>> mention, including the correct bytesizes for all platforms. >>>>>>> >>>>>>> At the moment, I'm mostly focusing on getting the port to work >>>>>>> right >>>>>>> before I start creating an interface on top of the current Alien >>>>>>> interface. >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> Something to keep in mind is the need for a straightforward way of >>>>>> going >>>>>> the other way: John Mcintosh's port of the Squeak VM to iPhone >>>>>> implies >>>>>> that the same thing could be done in other Lua-ish situations, >>>>>> allowing >>>>>> people to use smalltalk syntax for game scripting. With the right >>>>>> libraries for an IDE, I would think squeak could be very >>>>>> attractive to >>>>>> at least some people in place of/in addition to using Lua. >>>>>> >>>>>> >>>>>> Lawson >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>>>> >>>> >>>> >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko AKA sig. >>>> >>>> _______________________________________________ >>>> 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 >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > Stefan Marr > Software Languages Lab > Former Programming Technology Lab > Vrije Universiteit Brussel > Pleinlaan 2 / B-1050 Brussels / Belgium > http://prog.vub.ac.be/~smarr > Phone: +32 2 629 3956 > Fax: Â +32 2 629 3525 > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Sept. 20, 2009

Re: [Pharo-project] Closure fixes

by StÃ©phane Ducasse

>> If you are interested in testing the closure fixes, I have scripted >> it. Run each section in turn. I have a few things for discussion, >> but first some feedback would be useful. > > I will have a look! Excellent! Once this is working I would declare it release candidates (more or less) (and tag red tests as broken ones). Stef

Sept. 20, 2009

Re: [Pharo-project] Closure fixes

by StÃ©phane Ducasse

Apparently when I run the tests the image freezes. I also thought that the image was recompiled in squeak. Stef > cool to see that you can script that. > > Stef > > On Sep 20, 2009, at 4:27 PM, Michael Roberts wrote: > >> If you are interested in testing the closure fixes, I have scripted >> it. Run each section in turn. I have a few things for discussion, >> but first some feedback would be useful. >> Cheers, >> Mike >> >> >> "A. Load Gofer" >> ScriptLoader new installGofer. >> >> >> "B. Install packages" >> | gofer | >> gofer := Gofer new. >> gofer >> url: 'http://www.squeaksource.com/PharoTaskForces'; >> addAll: #( >> "Part 2" >> 'Kernel-MikeRoberts.405' >> >> "Part 3" >> 'Compiler-MikeRoberts.130' >> 'CompilerTests-MikeRoberts.21' >> 'KernelTests-MikeRoberts.150' >> >> "Part 4" >> 'Compiler-MikeRoberts.131' >> >> "Part 5" >> 'Kernel-MikeRoberts.406' >> >> "Part 6" >> 'Kernel-MikeRoberts.407' >> >> "Part 7" >> 'System-Changes-MikeRoberts.13' >> 'System-Download-MikeRoberts.11' >> 'System-Support-MikeRoberts.89' >> >> "Part 8" >> 'Tools-MikeRoberts.202' >> >> "Part 9 - setup recompile" >> 'System-Support-MikeRoberts.90' >> ). >> gofer load. >> >> >> "C. Recompile" >> Utilities initializeClosures. >> Utilities compileUsingClosures. >> >> >> "D. Run the tests please" >> TestRunner open >> >> _______________________________________________ >> 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

Sept. 20, 2009

Re: [Pharo-project] Closure fixes

by Marcus Denker

On 20.09.2009, at 10:27, Michael Roberts wrote: > If you are interested in testing the closure fixes, I have scripted > it. Run each section in turn. I have a few things for discussion, > but first some feedback would be useful. I will have a look! Marcus -- Marcus Denker - http://marcusdenker.de PLEIAD Lab - Computer Science Department (DCC) - University of Chile

Sept. 20, 2009

Re: [Pharo-project] Closure fixes

by StÃ©phane Ducasse

cool to see that you can script that. Stef On Sep 20, 2009, at 4:27 PM, Michael Roberts wrote: > If you are interested in testing the closure fixes, I have scripted > it. Run each section in turn. I have a few things for discussion, > but first some feedback would be useful. > Cheers, > Mike > > > "A. Load Gofer" > ScriptLoader new installGofer. > > > "B. Install packages" > | gofer | > gofer := Gofer new. > gofer > url: 'http://www.squeaksource.com/PharoTaskForces'; > addAll: #( > "Part 2" > 'Kernel-MikeRoberts.405' > > "Part 3" > 'Compiler-MikeRoberts.130' > 'CompilerTests-MikeRoberts.21' > 'KernelTests-MikeRoberts.150' > > "Part 4" > 'Compiler-MikeRoberts.131' > > "Part 5" > 'Kernel-MikeRoberts.406' > > "Part 6" > 'Kernel-MikeRoberts.407' > > "Part 7" > 'System-Changes-MikeRoberts.13' > 'System-Download-MikeRoberts.11' > 'System-Support-MikeRoberts.89' > > "Part 8" > 'Tools-MikeRoberts.202' > > "Part 9 - setup recompile" > 'System-Support-MikeRoberts.90' > ). > gofer load. > > > "C. Recompile" > Utilities initializeClosures. > Utilities compileUsingClosures. > > > "D. Run the tests please" > TestRunner open > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 20, 2009