- Pharo-dev - lists.pharo.org

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

Re: [Pharo-project] Closure fixes

by Schwab,Wilhelm K

Does this mean that gofer depends in yet-to-be-integrated closure fixes? That's fine, but it would probably stomp on my plan/hope to have gofer help me organize getting out of my current image and into an up-to-date one. Maybe the refactoring code checker that Lukas mentioned is "hidden" by my current choice of toolset and will do the job. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Michael Roberts Sent: Sunday, September 20, 2009 9:27 AM To: Pharo-project Subject: [Pharo-project] Closure fixes 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

Re: [Pharo-project] Is there a way to use rename refactor while preserving whitespace formatting in refactored methods?

by Schwab,Wilhelm K

Philippe, I **never** would have figured you as being on the pro-comment side of this topic. No offense intended, it just surprises me :) I will stop short of commenting on the complexity of the problem; I just keep hoping that it will get fixed, and will happily test anything Stef, Gwenael, et al. think is a working version. Being able to freely use the RB when rewrites are required would be a great benefit to me. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Philippe Marschall Sent: Sunday, September 20, 2009 4:41 AM To: pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Is there a way to use rename refactor while preserving whitespace formatting in refactored methods? T. J. Richter wrote: > Hi, I am using Pharo with the default browser, which is the > OmniBrowser. When I right-click on a message name in the right-most > panel and choose "rename refactor" from the menu, enter the new name > and accept, the message sends are renamed, but the whitespace > formatting in those refactored methods is not preserved. Is there any > way at present to do this while keeping the formatting intact? That's why I don't use the refactoring tools in Smalltalk. That's also why the vendors themselves don't use the refactoring tools in Smalltalk [1]. Even though they like to brag in other places how cool their refactoring tools are. And don't tell me how hard it is. Eclipse does it and their AST is more than an order of magnitude more complex. [1] http://www.cincomsmalltalk.com/blog/blogView?entry=3426663681 Cheers Philippe _______________________________________________ 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] Is there a way to use rename refactor while preserving whitespace formatting in refactored methods?

by Schwab,Wilhelm K

Stef, As the self-appointed formatting pedant (you'll find I come by the title honestly<g>), I would be happy to test the work. Lukas is right that it is a tough problem, but the RB authors seem to see comments as a waste of time, so I never sensed any real desire on their part to keep formatting. It is a shame, because it greatly reduces the value of the RB to me, and probably others. As an example, I go so far as to comment out parts of cascades and replace the lines with modified code. The comments start with month-year, and have saved my skin more often than I care to count. I might have mentioned finding three bugs in a long-standing package of mine that I recently ported from Dolphin; without comments of the type I metion, I would probably still be looking for them. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse Sent: Sunday, September 20, 2009 2:35 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Is there a way to use rename refactor while preserving whitespace formatting in refactored methods? Lukas Gwenael changed the RBParser and AST to preserve code formatting. He never understood why nobody did look at what he did. Now when marcus will be in the team I would really like to have a look so that the work on gwenael is not lost because he worked 4 months on that. But if someone is interested it would be good to check. Stef On Sep 20, 2009, at 9:16 AM, Lukas Renggli wrote: >> Hi, I am using Pharo with the default browser, which is the >> OmniBrowser. When I right-click on a message name in the right-most >> panel and choose "rename refactor" from the menu, enter the new name >> and accept, the message sends are renamed, but the whitespace >> formatting in those refactored methods is not preserved. Is there any >> way at present to do this while keeping the formatting intact? > > Automatic refactoring that preserve the formatting are extremely > difficult to implement. In a common case, like with the rewrite engine > that the refactoring browser is using internally, this is not really > feasible. It is much easier to write your own formatter that formats > as you like, even if writing a working formatter is not trivial > either. > > For details listen to what the original authors of the Refactoring > Browser say about code formatting: > <http://www.cincomsmalltalk.com/blog/blogView?entry=3426663681>. > > 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 _______________________________________________ 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] Gofer vs Installer

by Schwab,Wilhelm K

Stef, It is listed as 1229. I added a brief mention of using a list of packages to generate a load script. If I understand our current level of dependency control, it would probably be best to have an explicit list that would be litle more than a build script expressed in objects (perhaps living in a class method named for the author or something like that) that would be used to write a load script and aid the search for dirty methods. I'm not sure how helpful any of that is :) Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse Sent: Sunday, September 20, 2009 1:50 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Gofer vs Installer Ok I will I do not have the snipped at hand that can check all the dirty methods. Could you add that to bug traker with a request for feature because indeed this is a nice one. Stef On Sep 20, 2009, at 8:24 AM, Schwab,Wilhelm K wrote: > Stef, > > I've done that, but my understanding is that "all" it does is show the > methods that are packaged. I am hoping for something that would sniff > out the methods that I have altered and are not in packages that I > (somehow) claim to own. It seems like it would be really easy to miss > important work and that it should be relatively easy to create > something that scans for at-risk code. One thing I can enivision > would compare a list of packages with user-owned methods in the > system; anything that is not in one of the packages goes in a method > browser with commands to package them in likely places. > > Bill > > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr > [mailto:pharo-project-bounces@lists.gforge.inria.fr > ] On Behalf Of StÃ©phane Ducasse > Sent: Sunday, September 20, 2009 1:03 AM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Gofer vs Installer > > The first thing you can try is to check using the browse button of MC > that you extensions methods are well in your package. > > Stef > > On Sep 20, 2009, at 12:43 AM, Schwab,Wilhelm K wrote: > >> I'd like to put on my user hat for a moment. A big concern of mine >> is doing a good job of saving packages from one image and moving them >> to another. I have (hopefully) been keeping my install script >> current as I add new packages, but it currently relies on my being >> careful. >> >> Clearly having very good coverage with tests would help to check the >> health of any new image; I'm slowly working on that. It would be >> nice to have ways to check for packaging mistakes. A "smell" that >> comes to mind is any methods that I wrote but are not in packages in >> my load script. Is there anything that does such checks? Seaside >> 2.9 includes a tool that helps to manage packages, and _somewhere_ I >> have an image with that loaded and ready for shameless plagairism. >> This seems like such a common task that there must be some good tools >> to handle it?? >> >> Bill >> >> >> -----Original Message----- >> From: pharo-project-bounces(a)lists.gforge.inria.fr >> [mailto:pharo-project-bounces@lists.gforge.inria.fr >> ] On Behalf Of StÃ©phane Ducasse >> Sent: Saturday, September 19, 2009 4:07 PM >> To: Pharo-project(a)lists.gforge.inria.fr >> Subject: Re: [Pharo-project] Gofer vs Installer >> >>>> >>>> >>>>> goals? >>>> >>>> Perform MC actions (load, update, merge, revert, commit, diff, >>>> recompile) on a set of packages. >>> >>> So, not like Installer that can load packages from everywhere, Gofer >>> will concentrate on MC? What about ScriptLoader? >> >> ScriptLoader will certainly use gofer to install packages instead of >> installer >> >>> Stephane has mentioned Gofer before. Is in the plans to support only >>> MC packages for Pharo and to use Gofer as the tool for load them on >>> pharo. >> >> Yes. >> Because in pharo we do not use anything else besides on changeset to >> kick in the load. >> >>> Or nothing has been decided yet? It is considered? >>>> >>>>> implementation? >>>> >>>> Focus on keeping the system clean, e.g. no empty categories/ >>>> protocols, properly ordered categories/protocols, no duplicated >>>> repositories, etc. >>> >>> Installer can't do that? Is a question, I don't know much about the >>> internals of Installer. >> >> Compared to sometimes ago they were cleaned but >>> >>>> >>>>> speed? >>>> >>>> Not optimized yet. >>>> >>>>> license? >>>> >>>> MIT >>> >>> Can you please give us a big picture of the role Gofer will have? >> >> After discussion at Esug between dale, lukas and me listening :) it >> seems that Metacello will use Gofer to load packages. >> >> Now I think that you should give a try to Gofer and report what is >> missing or not. >> I have some behvaior I would really like to have (that are specific >> to ScriptLoader like tell me which packages have changed since a >> given marked period). >> >> >> >>> >>>> >>>> Lukas >>> >>> Thanks >>> -- >>> Miguel CobÃ¡ >>> http://miguel.leugim.com.mx >>> >>> >>> _______________________________________________ >>> 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 > > _______________________________________________ > 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

[Pharo-project] Closure fixes

by Michael Roberts

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

Sept. 20, 2009