[Pharo-project] Status of Alien FFI
stephane.ducasse at inria.fr
Sat Sep 19 02:24:33 EDT 2009
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.
On Sep 19, 2009, at 5:28 AM, Igor Stasenko wrote:
> 2009/9/18 Stéphane Ducasse <stephane.ducasse at 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
> 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
> 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. :)
>> 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
>>>>> platform return me the proper size Alien. Even without the
>>>>> size differences, it seems awkward to use "Alien newC: 4"
>>>>> I want an integer, "Alien newC: 8" where I want a double, etc.
>>>> It becomes worse once you start having structs and nested structs
>>>> 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
>>>> 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
>>>> before I start creating an interface on top of the current Alien
>>> Something to keep in mind is the need for a straightforward way of
>>> the other way: John Mcintosh's port of the Squeak VM to iPhone
>>> that the same thing could be done in other Lua-ish situations,
>>> 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.
>>> Pharo-project mailing list
>>> Pharo-project at lists.gforge.inria.fr
>> Pharo-project mailing list
>> Pharo-project at lists.gforge.inria.fr
> Best regards,
> Igor Stasenko AKA sig.
> Pharo-project mailing list
> Pharo-project at lists.gforge.inria.fr
More information about the Pharo-dev