[squeak-dev] Re: [Pharo-project] Alien FFI

Ok, after much mindless poking, cross checking and testing, retesting,  
writing sunits today I  can say the Alien FFI logic is mostly ported  
into Pharo.

In the http://www.squeaksource.com/Alien.html MC library

I would suggest someone with an eye towards "Compiler, CompileMethod,  
ParseNode" carefully look at the changes in "Alien-Core" to ensure  
I've not trashed some important part of the Pharo Compiler or Traits.  
I can't say if the changes are destructive or passive?

you will find:

For VMMaker folks

Alien-VMMaker-Support   which provides the changes to the latest  
VMMaker  from squeaksource to build a Alien aware VM.
Alien-VMMaker-Plugins   which is the plugin logic

For users of Alien

Alien-Core-First - Load this first otherwise you'll get a parsing  
error later
Alien-Core -   Load this next, Compiler changes etc..
Alien-LibC - LibC support for os-x/unix/windows
Alien-CoreTest - SUnits

Optional stuff then is

Alien-MacOSX-Core - Objective-C interface
Alien-MacOSX-AppKit- Objective-C application api
Alien-MacOSX-Examples- Objective-C examples
Alien-Win32 - Windows examples.

Lastly load

Alien-Last-Class-Initialize - To ensure all the initializers were run,  
just in case MC loses it's mind...


Oh and you need a plugin and a VM.   It's midnight again and I don't  
have one compiled up for distribution, Monday's chore...
Anyway you should be able to load the source code, point/learn about  
how it's used.

Someone will have to build a Unix one, and a Windows one.

For the moment there is NO powerpc version since that requires a bit  
of icky assembler. Same for the iPhone btw (icky ARM assembler).

On 23-Nov-08, at 4:20 AM, Stéphane Ducasse wrote:

> the future looks shining :)
>
> Stef

--
=
=
=
========================================================================
John M. McIntosh <[hidden email]>
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
=
=
=
========================================================================

2008/11/24 John M McIntosh <[hidden email]>: Thanks for description, it would be interesting to try it out and
compare with current FFI.
I beleive plugin will require some platform files to be able to build
it? You seem missed this part.

--
Best regards,
Igor Stasenko AKA sig.

On 24-Nov-08, at 12:54 AM, Igor Stasenko wrote:

> Thanks for description, it would be interesting to try it out and
> compare with current FFI.
> I beleive plugin will require some platform files to be able to build
> it? You seem missed this part.

I believe I checked in the required Platform files to the Cross  
subdirectory IA32ABI
also changes were made to sqVirtualMachine.c/h again in Cross.

I've not check in any specific macintosh files yet, that would be the  
xcode project and minor pieces.

However someone should be able to build a Unix flavor, sorry I don't  
have any unix make file etc.

--
=
=
=
========================================================================
John M. McIntosh <[hidden email]>
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
=
=
=
========================================================================

On Mon, Nov 24, 2008 at 12:13 AM, John M McIntosh
<[hidden email]> wrote:
> I would suggest someone with an eye towards "Compiler, CompileMethod,
> ParseNode" carefully look at the changes in "Alien-Core" to ensure I've not
> trashed some important part of the Pharo Compiler or Traits. I can't say if
> the changes are destructive or passive?

Many of those have to do with primitive errorCode support, and it
would be nice to categorize them separately. I didn't look closely,
but those that have to do with variable bindings are likely to be
irrelevant.

And sorry, but adding #asAlien to True, False and UndefinedObject is
just wrong. Nor should have it been in String from the start.

Cheers,

--Vassili

Ok, well asAlien seems to be used as conversion methods to ensure a  
passed object is an alien.
What would you like to do instead?

I'll integrate the primitive Error code changes this week and do any  
clean up.
If you would like to suggest which variable bindings  can be deleted  
I'll correct that.

On 24-Nov-08, at 9:49 AM, Vassili Bykov wrote:

--
=
=
=
========================================================================
John M. McIntosh <[hidden email]>
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
=
=
=
========================================================================

On 24-Nov-08, at 6:37 AM, David Pennell wrote:

> John,
>
> Its probably worthwhile to find a place to post Eliot's  
> documentation files for Alien.
>
> -david

Documentation files and a start on a wiki page is at:

http://wiki.squeak.org/squeak/6100


--
=
=
=
========================================================================
John M. McIntosh <[hidden email]>
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
=
=
=
========================================================================

On Mon, Nov 24, 2008 at 11:37 AM, John M McIntosh
<[hidden email]> wrote:
> Ok, well asAlien seems to be used as conversion methods to ensure a passed
> object is an alien.
> What would you like to do instead?

I'd like to remove String>>asAlien and have no #asAlien methods. C and
Smalltalk worlds are too different, and poor man's marshalling with
#asAlien only adds confusion. It works in a simple unambiguous way
only for some objects like True and False. String>>asAlien is already
not transparent because it allocates a static buffer that needs
freeing. And then, how far do we take this? A ByteArray could
conceivably have #asAlien, but should we also handle Arrays of
Integers? What about Arrays of Strings?

Apart from the C semantics, this is also a questionable style. The
general rule for the choice between instance creation or conversion
messages is that conversion messages make sense when the classes are
sufficiently similar. An Alien is not an alternative form of a String,
and "'foo' asAlien" is not a conversion of a String to an Alien. It's
a creation of an Alien initialized in a particular way. There could be
other equally meaningful ways of initializing it from the same data,
so "Alien newCString: 'foo'" works because we could also have "Alien
newUnicodeString: 'foo'", and "'foo' asAlien" is a convenience that
doesn't scale (and also makes aliens appear less alien than they ought
to).

--Vassili

2008/11/24 Vassili Bykov <[hidden email]>:
how about
'foo' asAlien: #CString
'foo' asAlien: #UnicodeString

and generic form:
anyObject asAlien: #someAlienType

the key point is to let object itself decide how to convert to
appropriate alien object, because there is no other who knows better
how to perform a conversion.

A conversion requires a collaboration between object to be converted
and destination type.
There is no way to make ' Alien newCString: arbirtatyObject ' working
without putting/using special behavior into arbirtatyObject.

> --Vassili
>
>


--
Best regards,
Igor Stasenko AKA sig.

Vassili Bykov wrote:
+1

Cheers,
   - Andreas

Andreas Raab a écrit :
I tend to agree.
However, the case you submit is already handled as:

        'foo' asWideString asAlien.

See http://wiki.squeak.org/squeak/uploads/6100/Alien%20FFI.pdf.

On Mon, Nov 24, 2008 at 1:29 PM, Igor Stasenko <[hidden email]> wrote:
Yes, there is. This is why I said C and Smalltalk worlds are too
different. There are cases when you only know what at the call site
what representation you want. For example, an array of strings can be
represented as a null-terminated array of pointers or a double
null-terminated buffer where one null-terminated string follows
another.

> A conversion requires a collaboration between object to be converted
> and destination type.

Exactly, but often there is no Smalltalk equivalent of the destination
type. Because of that a more tractable code results when the
representation is manufactured somewhere close to the foreign call
site, relying on public API of the Smalltalk object, rather than by
magical methods sprinkled throughout the system.

> There is no way to make ' Alien newCString: arbirtatyObject ' working
> without putting/using special behavior into arbirtatyObject.

But I'm not advocating for the argument of newCString: to be an
arbitrary object.

Cheers,

--Vassili

On Mon, Nov 24, 2008 at 2:07 PM, nicolas cellier <[hidden email]> wrote:
> I tend to agree.
> However, the case you submit is already handled as:
>
>        'foo' asWideString asAlien.
>
> See http://wiki.squeak.org/squeak/uploads/6100/Alien%20FFI.pdf.

But that was just one particular example. And even for that one, bits
in what exactly Unicode encoding would "asWideString asAlien" produce,
and how could I get a different one?