- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Status of Alien FFI

by StÃ©phane Ducasse

probably but from a research vehicule perspective having a clean system is a big win. stef On Sep 19, 2009, at 8:46 AM, Igor Stasenko wrote: > 2009/9/19 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> in fact the meta level interface of the VM is missing. >> And I would love to have what you describe. >> When I was tired by smalltalk I was thikning to build one on top of >> lua. >> > > Lua is SLOW :) > Once i recommended one game developer to use Lua for scripting.. > and he wired it into C project pretty easily.. but instead of writing > glue code which precompiling > all scripts, he decided to not spend much time on it and parse the > scripts from source each time he may need to run it.. > The surprise was, that despite this crappy binding, game running at a > decent frame rate :) > But still - you can go and see the speed comparison of different > numerical algorythms implemented in different languages. > Squeak leaves Lua far behind.. > 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

Sept. 19, 2009

Re: [Pharo-project] Status of Alien FFI

by Igor Stasenko

2009/9/19 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > in fact the meta level interface of the VM is missing. > And I would love to have what you describe. > When I was tired by smalltalk I was thikning to build one on top of lua. > Lua is SLOW :) Once i recommended one game developer to use Lua for scripting.. and he wired it into C project pretty easily.. but instead of writing glue code which precompiling all scripts, he decided to not spend much time on it and parse the scripts from source each time he may need to run it.. The surprise was, that despite this crappy binding, game running at a decent frame rate :) But still - you can go and see the speed comparison of different numerical algorythms implemented in different languages. Squeak leaves Lua far behind.. 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.

Sept. 19, 2009

[Pharo-project] plan for pharo release candidates

by StÃ©phane Ducasse

Hi all I did not integrate some pending changes because I would like to give priority to the closure fixes. Now I do not have the time to really look at them and I'm not expert in the changes made. So if someone wants to help this is the time. We will have in 3 weeks the pharo sprint and I think that this is not a great time to do that. I will be busy again this week with my day job and no time for pharo this week. Sorry. Stef

Sept. 19, 2009

[Pharo-project] Fwd: Status of Alien FFI

by StÃ©phane Ducasse

Begin forwarded message: > From: Eliot Miranda <eliot.miranda(a)gmail.com> > Date: September 19, 2009 12:44:43 AM CEDT > To: StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > Subject: Re: [Pharo-project] Status of Alien FFI > > On Fri, Sep 18, 2009 at 12:29 AM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> >> >> Begin forwarded message: >> >>> From: Martin McClure <martin(a)hand2mouse.com> >>> Date: September 18, 2009 12:57:43 AM CEDT >>> To: Pharo-project(a)lists.gforge.inria.fr >>> Subject: Re: [Pharo-project] Status of Alien FFI >>> Reply-To: Pharo-project(a)lists.gforge.inria.fr >>> >>> 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. >>> >>> I'd like to work toward a standard FFI that works across many >>> Smalltalk >>> dialects. Right now, it's too hard to port packages such as >>> CairoGraphics that call large external libraries. A year ago, I >>> tried >>> porting CairoGraphics from VW to an early version of GemStone's >>> FFI. It >>> was way too much work. >>> >>> And GemStone/S 64-bit 3.0, due out probably sometime next year, will >>> have a completely new FFI. It's probably not too late to influence >>> the >>> design for better compatibility. >>> >>> Is Alien, possibly with some changes, a suitable cross-platform >>> cross-dialect FFI standard? Or is it too low-level? > > I think it is OK as a substrate for data representation but not for > calls. It is a little low-level but also a lot simpler and easier to > use than CDatum et al. I'm attaching the doc and you ca make up your > own mind. > > >>> >>> Regards, >>> >>> -Martin >>> >>> _______________________________________________ >>> 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

in fact the meta level interface of the VM is missing. And I would love to have what you describe. When I was tired by smalltalk I was thikning to build one on top of lua. 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

Sept. 19, 2009

Re: [Pharo-project] Spring in November, Argentina

by StÃ©phane Ducasse

for me this is ok too. this can also be the sunday before since I will arrive from chile the firday evening. stef On Sep 18, 2009, at 11:32 PM, Mariano Martinez Peck wrote: > Do we know the exact day of the sprint? I suggest during weekend as > most of us has to work during the week. It would be nice on Sunday > 22 but I don't know if the University is open. > > Best, > > Mariano > > > On Thu, Sep 10, 2009 at 8:25 PM, Alexandre Bergel > <alexandre(a)bergel.eu> wrote: > Done. you're on the list. > > Alexandre > > On 10 Sep 2009, at 17:21, csrabak(a)bol.com.br wrote: > > > My first name is Cesar. > > > > > > Em 09/09/2009 13:29, Alexandre Bergel < alexandre(a)bergel.eu > > > escreveu: > > > > > > I can add it. What is your firstname - name ? > > > > Alexandre > > > > > > On 9 Sep 2009, at 10:00, csrabak(a)bol.com.br wrote: > > > > > Would it suffice I add a comment in the wiki or should I get > some > > > specific id in order to edit the wiki page itself? > > > > > > BTW, if anything else fails:: I'm attemting to apply :-) > > > > > > > > > Em 08/09/2009 15:10, Alexandre Bergel < alexandre(a)bergel.eu > > > > > > escreveu: > > > > > > > > > Dear List, > > > > > > I added a section in the Sprint wiki page: > > > http://code.google.com/p/pharo/wiki/PharoSprints?ts=1252433348&updated=… > > > > > > People should add their name. I will send a remainder a few > days > > > before the event. > > > > > > Cheers, > > > Alexandre > > > > > > -- > > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > > Alexandre Bergel http://www.bergel.eu > > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > 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 > > > > > > > -- > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > Alexandre Bergel http://www.bergel.eu > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > > > > > > > _______________________________________________ > > 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 > > > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > 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. 19, 2009

Re: [Pharo-project] Status of Alien FFI

by Igor Stasenko

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.

Sept. 19, 2009

Re: [Pharo-project] Spring in November, Argentina

by Mariano Martinez Peck

Do we know the exact day of the sprint? I suggest during weekend as most of us has to work during the week. It would be nice on Sunday 22 but I don't know if the University is open. Best, Mariano On Thu, Sep 10, 2009 at 8:25 PM, Alexandre Bergel <alexandre(a)bergel.eu>wrote: > Done. you're on the list. > > Alexandre > > On 10 Sep 2009, at 17:21, csrabak(a)bol.com.br wrote: > > > My first name is Cesar. > > > > > > Em 09/09/2009 13:29, Alexandre Bergel < alexandre(a)bergel.eu > > > escreveu: > > > > > > I can add it. What is your firstname - name ? > > > > Alexandre > > > > > > On 9 Sep 2009, at 10:00, csrabak(a)bol.com.br wrote: > > > > > Would it suffice I add a comment in the wiki or should I get some > > > specific id in order to edit the wiki page itself? > > > > > > BTW, if anything else fails:: I'm attemting to apply :-) > > > > > > > > > Em 08/09/2009 15:10, Alexandre Bergel < alexandre(a)bergel.eu > > > > > > escreveu: > > > > > > > > > Dear List, > > > > > > I added a section in the Sprint wiki page: > > > > http://code.google.com/p/pharo/wiki/PharoSprints?ts=1252433348&updated=… > > > > > > People should add their name. I will send a remainder a few days > > > before the event. > > > > > > Cheers, > > > Alexandre > > > > > > -- > > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > > Alexandre Bergel http://www.bergel.eu > > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > 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 > > > > > > > -- > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > Alexandre Bergel http://www.bergel.eu > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > > > > > > > _______________________________________________ > > 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 > > > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 18, 2009

Re: [Pharo-project] Progress bars

by StÃ©phane Ducasse

Check SystemProgressMorph example 'Progress' displayProgressAt: Display center from: 0 to: 1000 during: [:bar | 0 to: 1000 do: [:i | bar value: i. (Delay forMilliseconds: 2) wait]] Stef On Sep 18, 2009, at 7:33 PM, Schwab,Wilhelm K wrote: > Hello all, > > Is there a preferred way to produce a progress bar? The example > below seems to work, but is there a better way? Is there a way to > provide a cancel button? > > Bill > > > > [ > #( 1 2 3 4 5 ) > do:[ :each | > ( Delay forMilliseconds:500 ) wait. > ] > displayingProgress:'Gratuitous Progress Bar.' > ] fork. > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 18, 2009

[Pharo-project] Progress bars

by Schwab,Wilhelm K

Hello all, Is there a preferred way to produce a progress bar? The example below seems to work, but is there a better way? Is there a way to provide a cancel button? Bill [ #( 1 2 3 4 5 ) do:[ :each | ( Delay forMilliseconds:500 ) wait. ] displayingProgress:'Gratuitous Progress Bar.' ] fork.

Sept. 18, 2009