- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Gofer vs Installer

by StÃ©phane Ducasse

>> >> >>> 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

Sept. 19, 2009

Re: [Pharo-project] Gofer vs Installer

by Miguel Enrique CobÃ¡ Martinez

El sÃ¡b, 19-09-2009 a las 18:34 +0200, Lukas Renggli escribiÃ³: > For Gofer: > > > 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? 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. 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. > > > speed? > > Not optimized yet. > > > license? > > MIT Can you please give us a big picture of the role Gofer will have? > > Lukas Thanks -- Miguel CobÃ¡ http://miguel.leugim.com.mx

Sept. 19, 2009

Re: [Pharo-project] Status of Alien FFI

by Ken Treis

Hi Stef, The CairoGraphics package is MIT-licensed. I will update the SqueakSource project page to reflect this. Ken On Sep 16, 2009, at 12:51 PM, StÃ©phane Ducasse wrote: > ok what is its license? > > Stef > >> what is the cairoPackage? >>> For pharo 1.1 I would like to see Rome cleaned and loadable/ >>> integrated >>> in pharo. >> >> It's a port of Travis Griggs' package from VisualWorks -- a fairly >> direct mapping of Cairo objects into Smalltalk. I posted it on >> SqueakSource just a couple of days ago: >> >> http://www.squeaksource.com/CairoGraphics.html >> >> I have been using it for our VisualWorks web apps for quite a while >> and wanted to bring it with me. Plus I really need portability >> between Pharo and GLASS. Not that I couldn't do that with Rome, but >> this seemed like an easier path for me. >> >> -- >> Ken Treis >> Miriam Technologies, Inc. >> >> _______________________________________________ >> 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 -- Ken Treis Miriam Technologies, Inc.

Sept. 19, 2009

Re: [Pharo-project] Gofer vs Installer

by Lukas Renggli

For Gofer: > goals? Perform MC actions (load, update, merge, revert, commit, diff, recompile) on a set of packages. > implementation? Focus on keeping the system clean, e.g. no empty categories/protocols, properly ordered categories/protocols, no duplicated repositories, etc. > speed? Not optimized yet. > license? MIT Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Sept. 19, 2009

[Pharo-project] Gofer vs Installer

by Miguel Enrique CobÃ¡ Martinez

What is the difference in: goals? implementation? speed? license? other aspects? I can see that they both can install packages in a pharo image. Thanks -- Miguel CobÃ¡ http://miguel.leugim.com.mx

Sept. 19, 2009

Re: [Pharo-project] Status of Alien FFI

by Stefan Marr

On 19 Sep 2009, at 10:53, StÃ©phane Ducasse wrote: > ok I saw smalltalk squeak > but then how do you interpret the graph? Well, the graphs are... creative... At least not intuitive. Change one of the languages to C, then you will get a feeling for what they try to express. If the first language, you base for comparison, is faster it uses only a fraction of the time the other language needs. The bar will be below the one-line. If its slower, the ratio is higher, it uses x-time the time the other language uses. > > On Sep 19, 2009, at 10:41 AM, Stefan Marr wrote: > >> >> 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… >> >> 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 > > > _______________________________________________ > 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

Sept. 19, 2009

Re: [Pharo-project] Status of Alien FFI

by Stefan Marr

Well, the Language Shootout has some inherent problems. But still, it gives a rough estimate over some interesting metrics, especially execution time. The main problem is to have efficient and well optimized implementations of the benchmarks for each language. And as far as I know, the Lua community and some of their best people spend good time to optimize the benchmark implementations to avoid unnecessary function invocations and so on, with deep knowledge of the Lua implementation. So, the Lua code could be definitely nicer. A literal translation of the Smalltalk code to Lua is considerably slower than the highly optimized version, but as far as I recall an experiment of my own, still faster than the Squeak I used. But well, fell free to step in for the Smalltalk community and optimize the benchmark implementations for speed and not for beauty... On 19 Sep 2009, at 10:50, StÃ©phane Ducasse wrote: > Hi stefan > > do you what they are really comparing? > because Smalltalk looks mysterious to me. > > Stef > > On Sep 19, 2009, at 10:41 AM, Stefan Marr wrote: > >> >> 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… >> >> 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 > > > _______________________________________________ > 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

Sept. 19, 2009

Re: [Pharo-project] Status of Alien FFI

by StÃ©phane Ducasse

ok I saw smalltalk squeak but then how do you interpret the graph? On Sep 19, 2009, at 10:41 AM, Stefan Marr wrote: > > 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… > > 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

Sept. 19, 2009

Re: [Pharo-project] Status of Alien FFI

by StÃ©phane Ducasse

Hi stefan do you what they are really comparing? because Smalltalk looks mysterious to me. Stef On Sep 19, 2009, at 10:41 AM, Stefan Marr wrote: > > 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… > > 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

Sept. 19, 2009

Re: [Pharo-project] Status of Alien FFI

by Stefan Marr

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… 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

Sept. 19, 2009