Yes because the intent was that the primitive would return a failure error code versus prim failed, guess why? On 9/15/09, Johan Brichau <johan.brichau@uclouvain.be> wrote:

The problem is that Pharo no longer considers the following primitive call syntactically correct: <primitive: 'primCalloc' error: errorCode module: 'IA32ABI'>

It does work if we omit the errorCode: <primitive: 'primCalloc' module: 'IA32ABI'>

Was this change in the parser intended??

On 15 Sep 2009, at 00:15, Stéphane Ducasse wrote:

...

Hi ken

fernando is the guy that fixed alien so he will probably reply to you

Stef On Sep 14, 2009, at 11:36 PM, Ken Treis wrote:

...

I'm unable to load Alien-Core into the latest Pharo (I'm on 10451), mostly because the package overrides some methods in Scanner/Parser and those overrides are out of sync with the current Pharo base. Is anyone working on bringing these into sync? I would be glad to take a stab at it but I'm hardly the best qualified person to do that.

If there's a better mailing list for Alien issues/discussion, please let me know.

Thanks,

-- Ken Treis Miriam Technologies, Inc.

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

---------------------------- Johan Brichau johan.brichau@uclouvain.be

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

-- =========================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

On 16 Sep 2009, at 10:33, Peter Hugosson-Miller wrote:

Is it possible to make 'Alien-Core' depend on 'Alien-Prereqs' (i.e. a nested dependency)? If it were then the correct loading order would be achieved

Probably that is the easiest solution. I'm just a bit lost in what is the preferred way of expressing package dependencies and loading process. I see Monticello's package dependencies but I also see specifically created load scripts and things like Flair and Gofer. I'm rediscovering development in Pharo-Squeak (I have been mostly working in Visualworks the last 5 years). So perhaps I'm asking a silly question that does not make sense? ;-) ---------------------------- Johan Brichau johan.brichau@uclouvain.be

Probably that is the easiest solution.

Most of the time we did not rely on the dependencies because I'm not sure that the order can be specified. I think that in the future we will use metacello to resolve this ordering.

I'm just a bit lost in what is the preferred way of expressing package dependencies and loading process. I see Monticello's package dependencies but I also see specifically created load scripts and things like Flair and Gofer.

Flair was a parallel track to get a kind of metacello system. It will disappear. Gofer is a simple interface to replace Installer and metacello will use it to load and script loading of packages.

I'm rediscovering development in Pharo-Squeak (I have been mostly working in Visualworks the last 5 years). So perhaps I'm asking a silly question that does not make sense? ;-)

No the problem is that we are also inventing new ways of managing our artefacts. Stef

Hi ken it is correct that alien touches the parser? The declarations are not pragmas compliant. Of course your suggestion makes sense. When marcus is back in europe I will check the status of the new handwritten parser because it would be good to use it. Stef On Sep 16, 2009, at 5:36 PM, Ken Treis wrote:

On Sep 16, 2009, at 1:06 AM, Johan Brichau wrote:

...

I separated the extensions to the Parser (necessary to load the primitive methods) into a separate package Alien-Prereqs. If you load Alien-Prereqs before Alien-Core, it will work.

Thanks Johan, that's good news here. I appreciate it.

Given that Alien requires modifications to the core parser, and that the Alien-modified parser is backwards-compatible with the base parser... is there any chance we can get the Alien modifications into the base? Without that, Pharo software updates that touch parser code will end up reverting the code in Alien-Prereqs, right?

-- Ken Treis Miriam Technologies, Inc.

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

I will let eliot comment on that because I'm alien newbie. We cleaned it so that people can use it but

...

it is correct that alien touches the parser? The declarations are not pragmas compliant.

Yes -- there's a hack in there that allows an error code variable to be passed in the <primitive> pragma where otherwise the parser would expect a literal.

...

Of course your suggestion makes sense. When marcus is back in europe I will check the status of the new handwritten parser because it would be good to use it.

Thanks Stef. I've got some other ideas for Alien; is this list the best place to discuss those? Specifically:

* AlienLibrary shouldn't do its cleanup at shutdown, it should do it at image startup instead. That way a simple image save won't invalidate all of my external references.

* I'm creating a partial Alien library for GemStone so that I can use the CairoGraphics package in both Pharo and GLASS.

what is the cairoPackage? For pharo 1.1 I would like to see Rome cleaned and loadable/integrated in pharo.

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.

* Similarly, I'd like an API on AlienLibrary that distinguishes between integers and longs. In the CairoGraphics package I've added some methods to this effect:

CRLibrary int: 'cairo_surface_write_to_png' with: handle with: string address

or

patternHandle := CRLibrary pointer: 'cairo_pop_group' with: handle.

I like the way it reads. And even though on IA32 they both use the same 4-byte primitive, on x86-64 I could have pointers return an 8- byte Alien and ints return a 4-byte primitive.

* Same story with the basic data accessors like (un)signedLongAt: -- I'd want to add something like (un)signedIntAt et. al.

Yes, I realize that some of this is overkill for IA32 only, but on the other hand I think a couple of these intention-revealing changes would make Alien client code prettier.

Sorry to be so wordy. I'd be glad to do all of the Smalltalk-level coding on this -- much of it is done already in my image -- but I thought I'd better ask the maintainer(s) first and this list is the best forum I've found for Alien issues.

-- Ken Treis Miriam Technologies, Inc.

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

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.

* Similarly, I'd like an API on AlienLibrary that distinguishes between integers and longs. In the CairoGraphics package I've added some methods to this effect:

One minor point is that whether integers and longs are different depends on the platforms data model. Under MS Win64, integers and long integers are both 32bit, while on most unixes integers are 32bit while long ints are 64bit. (LLP64 and LP64 models respectively) I don't know if this is important though.

On Wed, Sep 16, 2009 at 6:17 PM, Ken Treis <ken@miriamtech.com> wrote:

On Sep 16, 2009, at 12:02 PM, Douglas Brebner wrote:

...

One minor point is that whether integers and longs are different depends on the platforms data model. Under MS Win64, integers and long integers are both 32bit, while on most unixes integers are 32bit while long ints are 64bit. (LLP64 and LP64 models respectively)

I don't know if this is important though.

Good point. All of my platforms are LP64 (Mac OS X and Linux x86-64), and my main objective at present is to get this working for an application I'm committed to build, so I was ignoring those sorts of cross-platform details.

+1. Please take into consideration to make Alien cross platform!!! Just as FFI is.

Perhaps there would need to be new primitives for the basic size of each relevant C type? I'm anxious to hear what Eliot might have to say about this since he's got about 2000x more experience with this than I do.

-- Ken Treis Miriam Technologies, Inc.

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr 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 johan.brichau@uclouvain.be

Martin indeed it would be great to have a kind of standard On Sep 18, 2009, at 12:57 AM, Martin McClure 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.

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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

yes this is one of my dream but .... I'm not good enough to make it come true. 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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

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

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

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

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

_______________________________________________ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr 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=...

And: Virtual Machine Showdown: Stack Versus Registers Yunhe Shi and Kevin Casey and M. Anton Ertl and David Gregg ACM Trans. Archit. Code Optim.4(4):1--36(2008)

Best regards Stefan

...

Especially, i think, if you use language for scripting, so scripts will tend to contain more logic than heavy numeric crunching (because for numerical crunching hardcore devs using C & GPU) - smalltalk will win even more.

...

Stef

On Sep 19, 2009, at 5:28 AM, Igor Stasenko wrote:

...

2009/9/18 Stéphane Ducasse <stephane.ducasse@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- project

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

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

-- Stefan Marr Software Languages Lab Former Programming Technology Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://prog.vub.ac.be/~smarr Phone: +32 2 629 3956 Fax: +32 2 629 3525

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

ok I saw smalltalk squeak but then how do you interpret the graph? On Sep 19, 2009, at 10:41 AM, Stefan Marr wrote:

On 19 Sep 2009, at 08:46, Igor Stasenko wrote:

...

Lua is SLOW :)

...

But still - you can go and see the speed comparison of different numerical algorythms implemented in different languages. Squeak leaves Lua far behind.. That sounds like FUD. But, maybe I misunderstand you here.

However, Lua 5.x is FAST, especially for an interpreted language. Its register-based implementation seems to be much better for interpretation in terms of speed than the stack-based bytecode in Squeak.

See: http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=lua&lang2=...

And: Virtual Machine Showdown: Stack Versus Registers Yunhe Shi and Kevin Casey and M. Anton Ertl and David Gregg ACM Trans. Archit. Code Optim.4(4):1--36(2008)

Best regards Stefan

...

Especially, i think, if you use language for scripting, so scripts will tend to contain more logic than heavy numeric crunching (because for numerical crunching hardcore devs using C & GPU) - smalltalk will win even more.

...

Stef

On Sep 19, 2009, at 5:28 AM, Igor Stasenko wrote:

...

2009/9/18 Stéphane Ducasse <stephane.ducasse@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- project

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

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

-- Stefan Marr Software Languages Lab Former Programming Technology Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://prog.vub.ac.be/~smarr Phone: +32 2 629 3956 Fax: +32 2 629 3525

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

2009/9/19 Stefan Marr <pharo@stefan-marr.de>:

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

Hmm.. it looks like im wrong. Because couple years back it was slower.

And: Virtual Machine Showdown: Stack Versus Registers Yunhe Shi and Kevin Casey and M. Anton Ertl and David Gregg ACM Trans. Archit. Code Optim.4(4):1--36(2008)

Best regards Stefan

...

Especially, i think, if you use language for scripting, so scripts will tend to contain more logic than heavy numeric crunching (because for numerical crunching hardcore devs using C & GPU) - smalltalk will win even more.

...

Stef

On Sep 19, 2009, at 5:28 AM, Igor Stasenko wrote:

...

2009/9/18 Stéphane Ducasse <stephane.ducasse@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- project

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

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

-- Stefan Marr Software Languages Lab Former Programming Technology Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://prog.vub.ac.be/~smarr Phone: +32 2 629 3956 Fax:   +32 2 629 3525

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

-- Best regards, Igor Stasenko AKA sig.

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

Sig, The term "bus factor" arose from legitimate concerns to be sure, but let's not start predicting Pharo's downfall just yet. At the rate things are progressing, it will become a formidable system. With a sound foundation, innovation will be possible without sweeping change to the system itself. If at some point it falls into the wrong hands, one could always branch off from a stable release and be happy for a very long time. Who is asking for backward-compatibility? Is it the Squeak community, or Pharo users? Bill -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Igor Stasenko Sent: Sunday, September 20, 2009 1:44 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Status of Alien FFI 2009/9/20 Marcus Denker <denker@acm.org>:

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

(wearing a devil's advocate hat) I fear that Pharo, at some day could repeat the fate of Squeak. At version 2.0, 3.0 or whatever, you will lose interest (for whatever reason) in supporting it and step down from leading the project, as well as other current developers. The people who will lead it next will have a bit less authority to change anything, and there already will be a certain 'backwards compatibility' pressure from community. Also, much more people will not feel so confident in new leaders comparing to you, simply because they could not know much about them, or because they are not founders etc etc. In this situation, if someone will raise a hand, and say - lets throw out X, and replace it with Y, because its better, will have a high chances to be burned out. (wearing off a devil's advocate hat) I hope that there are a good strategy behind activities in Pharo, to not let the progress slowdown. And if not, then it is right time to think about it.

-- Marcus Denker - http://marcusdenker.de PLEIAD Lab - Computer Science Department (DCC) - University of Chile

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

Sig, If someone finds something truly better, more power to them. I predict Pharo will be tough to beat though. Bill -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Igor Stasenko Sent: Sunday, September 20, 2009 2:32 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Status of Alien FFI 2009/9/20 Schwab,Wilhelm K <bschwab@anest.ufl.edu>:

Sig,

The term "bus factor" arose from legitimate concerns to be sure, but let's not start predicting Pharo's downfall just yet.  At the rate things are progressing, it will become a formidable system.  With a sound foundation, innovation will be possible without sweeping change to the system itself.  If at some point it falls into the wrong hands, one could always branch off from a stable release and be happy for a very long time.

I do not agree. No matter how well , sound, formiddable the system are. There are always a chance that you miss something, and someone will find something better. The risks i outlined in previous post is not related to the quality of software, these risks are lying in social plane, rather than technical. If you need a stable, countinuously progressing system, first thing you need is a stable community with clear vision what goals are. But when community grows exponentially, and if it happens that at some point you got a weak leadership, wrong things start happening. Just because the probability of it is higher than before :)

Who is asking for backward-compatibility?  Is it the Squeak community, or Pharo users?

Ask the same question after 5-10 years :)

Bill

-----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Igor Stasenko Sent: Sunday, September 20, 2009 1:44 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Status of Alien FFI

2009/9/20 Marcus Denker <denker@acm.org>:

...

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

(wearing a devil's advocate hat)

I fear that Pharo, at some day could repeat the fate of Squeak. At version 2.0, 3.0 or whatever, you will lose interest (for whatever reason) in supporting it and step down from leading the project, as well as other current developers. The people who will lead it next will have a bit less authority to change anything, and there already will be a certain 'backwards compatibility' pressure from community. Also, much more people will not feel so confident in new leaders comparing to you, simply because they could not know much about them, or because they are not founders etc etc. In this situation, if someone will raise a hand, and say - lets throw out X, and replace it with Y, because its better, will have a high chances to be burned out.

(wearing off a devil's advocate hat)

I hope that there are a good strategy behind activities in Pharo, to not let the progress slowdown. And if not, then it is right time to think about it.

...

-- Marcus Denker - http://marcusdenker.de PLEIAD Lab - Computer Science Department (DCC) - University of Chile

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

Good luck. For my time and money, fool me once, shame on you, ... Bill -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Lawson English Sent: Sunday, September 20, 2009 7:13 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Status of Alien FFI Schwab,Wilhelm K wrote:

Sig,

If someone finds something truly better, more power to them. I predict Pharo will be tough to beat though.

Bill

Not to rain on anyone's parade, but C# 4.0 is just around the corner and MS is obviously grabbing features from everyone in existence... Lawson _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

I can only speak for myself here, but if Python were enough, I'd have switched already. So either we are to believe that Pharo will grow too big for its own good, or M$ will glossy-ad us out of existence. Let's just build what we want and let the other half do their own thing. -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Lawson English Sent: Sunday, September 20, 2009 9:28 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Status of Alien FFI Not meant as a promotion of C# 4, just an observation about MS marketing power and R&D resources... The C# 4.0 IDE gives you scripting language prototyping capabilities roughly equivalent to Python's, at least according to the MS promo videos. Lawson Schwab,Wilhelm K wrote:

Good luck. For my time and money, fool me once, shame on you, ...

Bill

-----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Lawson English Sent: Sunday, September 20, 2009 7:13 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Status of Alien FFI

Schwab,Wilhelm K wrote:

...

Sig,

If someone finds something truly better, more power to them. I predict Pharo will be tough to beat though.

Bill

Not to rain on anyone's parade, but C# 4.0 is just around the corner and MS is obviously grabbing features from everyone in existence...

Lawson

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

I hope I'll remember to watch it later, but this type of thing has been going on for a long time. I remember a friend of mine getting excited about a thing called Actor. There was this weird thing called Smalltalk, and these guys (Whitewater Group??) came along and "fixed" it by giving it C syntax. Not meaning to bash my friend; just pointing out how long people have been trying to take part of Smalltalk without really understanding the bulk of it. To be fair, look no further than Croquet for some blame here. They insisted on making an immersive 3D system rather than factoring it to provide whatever level the user might want. Maybe later we can start up a group to pull their retained mode framework into Pharo to serve simulation and gaming projects. Let's leave Tweak behind though. Bill -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Igor Stasenko Sent: Sunday, September 20, 2009 9:30 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Status of Alien FFI To add some OT and concerns about Lua & really cool stuff, see this video http://vimeo.com/5254161 it looks like right now we (smalltalkers and 3D game-devs, who are certaintly ones who are on a bleeding edge of technology) are living in different dimensions, and both of us know little about each other.. what i find really frustrating. The guy who narrating the video, came to conclusion, that its cool to be able to simply copy the code snippet & run it on different host/project without recompiling C++ stuff, also mentioned that operating on entity level (by scripting particular object(s)) makes life much easier, especially when project complexity grows and grows bigger.. I just wonder , if Lua is so good for him, what would he say, when discover the smalltalk, and especially its environment, which inherently allows to work with objects in real time without edit-recompile-run cycle. :) 2009/9/21 Schwab,Wilhelm K <bschwab@anest.ufl.edu>:

Good luck.  For my time and money, fool me once, shame on you, ...

Bill

-----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Lawson English Sent: Sunday, September 20, 2009 7:13 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Status of Alien FFI

Schwab,Wilhelm K wrote:

...

Sig,

If someone finds something truly better, more power to them.  I predict Pharo will be tough to beat though.

Bill

Not to rain on anyone's parade, but C# 4.0 is just around the corner and MS is obviously grabbing features from everyone in existence...

Lawson

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

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

I hit a similar problem with ODBC on 64 bit systems. One caution though: we can't completely lose control of the size when fixing this. One might need to read something written by a 32 bit system on a 64 bit one. Just as with int and DWORD, there needs to be a way to ask for the proper size for the platform or for a specific width. I once saw a system (then thinking 16/32 bit) where they had the platform and fixed types backwards, but that's another story ~:( Bill Saludos, Fernando Il giorno Sep 16, 2009, alle ore 8:37 PM, Ken Treis ha scritto:

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

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project