Status of Alien FFI

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

> 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?
>
> Regards,
>
> -Martin
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

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

> 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
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> 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
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

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

> Stef
>
> On Sep 19, 2009, at 5:28 AM, Igor Stasenko wrote:
>
>> 2009/9/18 Stéphane Ducasse <[hidden email]>:
>>> 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
>>>> [hidden email]
>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>
>>>
>>> _______________________________________________
>>> Pharo-project mailing list
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>
>>
>>
>>
>> --
>> Best regards,
>> Igor Stasenko AKA sig.
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

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

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

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

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

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

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

> 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
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

>
> 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=squeak&box=1
>

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

>>> 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=squeak&box=1
>>
> Hmm.. it looks like im wrong. Because couple years back it was slower.
>

>
> On 20.09.2009, at 13:49, Stéphane Ducasse wrote:
>
>> They probably moved while we got stuck.
>
> It's like with money: there is an "inflation" of constant
> progression. Everthing gets better slowly but constantly.
> Over 10 years, this results in quite some progress.
>
> Especially as you get the effect of "compound interest": By making
> something
> a little bit better, the next step of making it again a little bit
> better
> gets a little bit easier.
>
> As with compound interest, the effect is non-linear and completely
> against human
> intuition.
>
>> This is all the story behind pharo: moving again.
>
> What one needs to ask is always: How great could a system be over time
> if one would just
> do the next trivial, tiny, small step? And that over 10 years? With
> Squeak, this
> was impossible. Every small improvement was directly criticised as
> beeing "not good
> enough" and thus not worthwile for Squeak. With that attitude you go
> nowhere. As was
> proven in 10 years with Squeak.
>
> Of course, you should not *just* do tiny improvements. But it's like
> investing: there
> might be the chance to buy some pre-ipo stock cheap in the future.
> Does that mean
> that I put the money under the bed for no interest, or do I invest it
> for some tiny
> percentage e.g in a money-market account the meantime? With Squeak,
> the community decided
> that doing nothing was the right thing.
>
>        Marcus
>

>
> --
> Marcus Denker - http://marcusdenker.de
> PLEIAD Lab - Computer Science Department (DCC) - University of Chile
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

>
> On 20.09.2009, at 13:49, Stéphane Ducasse wrote:
>
>> They probably moved while we got stuck.
>
> It's like with money: there is an "inflation" of constant progression.
> Everthing gets better slowly but constantly.
> Over 10 years, this results in quite some progress.
>
> Especially as you get the effect of "compound interest": By making
> something a little bit better, the next step of making it again a
> little bit better gets a little bit easier.
>
> As with compound interest, the effect is non-linear and completely
> against human intuition.
>
>> This is all the story behind pharo: moving again.
>
> What one needs to ask is always: How great could a system be over time
> if one would just do the next trivial, tiny, small step? And that over
> 10 years? With Squeak, this was impossible. Every small improvement
> was directly criticised as beeing "not good enough" and thus not
> worthwile for Squeak. With that attitude you go nowhere. As was proven
> in 10 years with Squeak.
>
> Of course, you should not *just* do tiny improvements. But it's like
> investing: there
> might be the chance to buy some pre-ipo stock cheap in the future.
> Does that mean
> that I put the money under the bed for no interest, or do I invest it
> for some tiny percentage e.g in a money-market account the meantime?
> With Squeak, the community decided that doing nothing was the right
> thing.
>
>        Marcus
>

>
> --
> Marcus Denker - http://marcusdenker.de PLEIAD Lab - Computer Science
> Department (DCC) - University of Chile
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>