Re: Progress on Darwin/Linux port?

Gilad Bracha <[email protected]> Thu, 25 Jun 2009 17:43:47 +0200
Newsgroups gmane.comp.lang.smalltalk.strongtalk
Message-ID <[email protected]>
A couple of comments:
A. Squeak's FFI is a liability and no one should seek to emulate in  
Strongtalk or anywhere else.
B. Instead, I recommend porting the Alien API  from Newspeak to  
Strongtalk. It has already been ported to Squeak. The underlying  
Newspeak primitives are very close to the Strongtalk FFI so it should  
much easier.
C. At that point, one should be able to start hooking up the Newspeak  
GUI, which can be bound to the web or to native GUI.

Cheers, Gilad

On Jun 24, 2009, at 11:12 PM, talksmall <[email protected]>  
wrote:

>
> Hi Dave,
> On Jun 24, 6:35 pm, Dave Mason <[email protected]> wrote:
>> On Jun 23, 6:34 pm, talksmall <[email protected]> wrote:
>>
>> That's great!  The reason I haven't responded in the past couple  
>> weeks
>> is that I've been cleaning stuff up before "vacation".  Which will  
>> end
>> with ESUG in France in September, maybe see some of you there.
>
>
>
>>
>>> As with the Linux port this will be a script-only
>>> version until someone (possibly me) ports UI support for OSX and
>>> Linux.
>>
>> One of my projects over the summer is to make a minimal GUI that runs
>> through Firefox, i.e. that uses only the network interface, and none
>> of the OS-specific screen handling.  I'm working to get this working
>> first on Pharo/Squeak, and then will move it to Strongtalk.  If that
>> is running on OSX by then, so much the better.  To the extent
>> possible, moving the primitives interface of Strongtalk to mirror  
>> that
>> of Squeak would make some porting much easier.
>
> A pre-req for this is some kind of socket support which Strongtalk
> doesn't have at the moment.
>
> It shouldn't really be necessary to rewrite the Strongtalk primitive
> interface in order to port over Squeak code, provided that the code
> you are porting is not tightly coupled to the low-level details of the
> Squeak implementation (and that would be a bad idea ... right?).
>
> Appropriately layered code is much easier to port than poorly designed
> code. That is one of the reasons that porting Strongtalk to other x86
> platforms has been reasonably easy - few parts of the VM directly
> depend on the OS, they are well-encapsulated and the rest of the VM
> depends, in the main, on an abstraction to the OS-layer.
>
> The same cannot be said of the dependency on the instruction set
> architecture. Porting Strongtalk over to another ISA - say ARM, or
> PowerPC - would be much harder. Similarly, porting to 64-bit will
> involve a fair amount of work. There are lots of places with implicit
> assumptions about the size of a pointer and its equivalence to the
> size of an integer, and the built-in macro assembler is not 64-bit
> aware.
>
> Once the core porting work is out of the way, I have a few competing
> projects to pick between - a UI port for OSX and Linux (probably GTK+
> based), porting Eliot Miranda's Aliens FFI interface from Squeak,
> porting some NewSpeak stuff, enhancing the still very basic UI-level
> debugger, investigating the "new backend" - a more sophisticated code
> generator for the recompiler that generates code that is about twice
> as fast as the current "old" code generator, GC finalization
> support, ... &c. So much to do, so little time, oh, and a day job too
> - they tend not to want to pay me if I don't do anything for them!
>
>> As for my expertise, I have taught C++ in an OO course, but have
>> little experience actually building programs.
>
> C++ knowledge is only really required if you want to poke around in
> the VM, in particular the recompiler from which Strongtalk gains its
> performance. Now that the bulk of the VM side of the OSX porting work
> is done, there should be little need to use C++ unless you need to
> debug, or you just want to see what makes the VM tick. Even then, the
> VM spends more time in assembly code than in C++ - either in the
> interpreter or in compiled nmethod versions of Smalltalk methods. The
> most important remaining pieces of the OSX port are Smalltalk coding
> to fix up the DLL calls for OSX so that they conform with the
> libraries under OSX.
>
> Once I have tidied up the port so that all of the tests past (both ST
> and VM-level tests) then I will upload binary versions of the VM,
> image and sources for each of the platforms. Hopefully that will
> enable people to get involved without having to build the VM first.
> For the time being that will mean command line scripting for those on
> OSX and Linux, but you can do quite a lot that way. Ruby, Perl and
> Python hackers got along without IDE support for years. A nice project
> for someone might be to build an OSProcess class in Smalltalk to allow
> execution of external commands. The Squeak version would be a good
> place to start.
>
> Regards, Steve
> >

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Strongtalk-general" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [email protected]
For more options, visit this group at http://groups.google.com/group/strongtalk-general?hl=en
-~----------~----~----~----~------~----~------~--~---