Yes, indeed. Right now, for most use cases we use the SerialPort class, but
we still have some FFI code for other stuff hanging around. I plan to write
it as a plugin as soon as I have the time.

Cheers,
RIcho

On Fri, Jul 22, 2011 at 10:37 AM, Bert Freudenberg <bert at freudenbergs.de>wrote:

> It's not part of Etoys yet. If its low-level interface indeed requires FFI,
> then that interface would have to be rewritten as plugin for Etoys to
> include it.
>
> - Bert -
>
> On 22.07.2011, at 14:55, karl ramberg wrote:
>
> What about the Physical Etoys project ?
> http://tecnodacta.com.ar/gira/projects/physical-etoys/
>
> Karl
>
> On Fri, Jul 22, 2011 at 2:20 PM, Bert Freudenberg <bert at freudenbergs.de>wrote:
>
>>
>> On 22.07.2011, at 02:10, Eliot Miranda wrote:
>>
>> >
>> >
>> > On Thu, Jul 21, 2011 at 4:57 PM, Igor Stasenko <siguctua at gmail.com>
>> wrote:
>> > On 22 July 2011 02:34, Eliot Miranda <eliot.miranda at gmail.com> wrote:
>> > > Hi All,
>> > >     today I committed the threaded FFI plugin along with the threaded
>> VM and
>> > > hope to be able to support people in doing threaded FFI work on the
>> x86
>> > > platforms really soon now (Esteban, amongst others, this means you ;)
>> ).
>> > >  But to put the image-level code that uses the new FFI plugin into
>> > > production the standard VM needs to be upgraded to not crash with the
>> > > ExternalFunction image changes the new threaded FFI plugin wants.  The
>> main
>> > > change is that ExternalFunction changes size, gaining a stackSize inst
>> var
>> > > which is used to tell the FFI plugin how much stack spacer to reserve
>> for
>> > > marshalling (its computed on first use).  The best way for this to
>> happen is
>> > > to start using the ThreadedFFIPlugin as the standard plugin in the
>> > > Interpreter VM. The ThreadedFFIPlugin overall is simpler than the old
>> FFI
>> > > plugin (no assembler support code) and better (fully reentrant).  But
>> for
>> > > this to happen we may need to implement the platform=specific parts of
>> > > the ThreadedFFIPlugin (still entirely Smalltalk code) for PowerPC and
>> ARM
>> > > (and perhaps others, SPARC??).  I understand what has to be done and I
>> can
>> > > explain it to anyone interested in working on the problem, but I don't
>> have
>> > > any hardware with which I can test the results so its pretty pointless
>> my
>> > > doing the work and producing something inevitably broken.  So are
>> there
>> > > people out there who would be interested in doing the port to PPC and
>> ARM?
>> > >  It means fleshing out the classes
>> > >     ThreadedARMFFIPlugin ThreadedFFICalloutStateForARM
>> > >     ThreadedPPCBEFFIPlugin ThreadedFFICalloutStateForPPC
>> > > and having a solid understanding of how alloca works to do stack
>> allocation
>> > > and how the ABIs on ARM and PPC pass registers.
>> > > here's hoping there are a few good low-level people who would be
>> interested.
>> > > Let me know.
>> >
>> > I wonder if you find anyone today using these archs, not saying using
>> > squeak/pharo on them + knowing low-level details + wanting to help :)
>> >
>> > Right, chances are thin.  But then if no one is interested then the work
>> doesn't need to be done.  Bert, you mentioned the other day that PPC was
>> still relevant for etoys.  But am I right in thinking etoys never uses the
>> FFI?
>>
>> Right. Etoys should run on both ARM and PPC, but it does not use FFI.
>>
>> - Bert -
>>
>>
>>
>>
>
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20110722/1d45f0bd/attachment.htm