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 <[email protected]>: >> 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 >>> [email protected] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> [email protected] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
