Hi All, in response to Janko message about teams I would like to create two new new teams called:
Faster Execution Engine
and Faster Interoperability Engine
(suggestions as to what FUM could stand for gratefully received).
Yes, you smell the blood of an Englishman. I would like to be team leader. The tasks are:
Faster Execution Engine: produce an execution engine that supports closures and provides performance broadly comparable with other Smalltalk JIT virtual machines, of the order of 10 to 20 times faster than the current VM for benchFib.
Faster Interoperability Engine: produce a more flexible and faster FFI based on and integrated with the execution technology in FEE.
best Eliot
Eliot Miranda wrote:
in response to Janko message about teams I would like to create two new new teams called: Faster Execution Engine
I am interested in joining this one.
and Faster Interoperability Engine (suggestions as to what FUM could stand for gratefully received).
Fast Unloadable Modules
Yes, you smell the blood of an Englishman.
Bryce? I am sure he could help with this :-)
-- Jecel
2008/12/16 Eliot Miranda eliot.miranda@gmail.com:
Hi All, in response to Janko message about teams I would like to create two new new teams called: Faster Execution Engine and Faster Interoperability Engine (suggestions as to what FUM could stand for gratefully received). Yes, you smell the blood of an Englishman. I would like to be team leader. The tasks are: Faster Execution Engine: produce an execution engine that supports closures and provides performance broadly comparable with other Smalltalk JIT virtual machines, of the order of 10 to 20 times faster than the current VM for benchFib.
Faster Interoperability Engine: produce a more flexible and faster FFI based on and integrated with the execution technology in FEE.
I'm interested in this too :)
best Eliot
On Tue, Dec 16, 2008 at 1:44 PM, Igor Stasenko siguctua@gmail.com wrote:
2008/12/16 Eliot Miranda eliot.miranda@gmail.com:
Hi All, in response to Janko message about teams I would like to create two
new
new teams called: Faster Execution Engine and Faster Interoperability Engine (suggestions as to what FUM could stand for gratefully received). Yes, you smell the blood of an Englishman. I would like to be team
leader.
The tasks are: Faster Execution Engine: produce an execution engine that supports closures and provides performance broadly comparable with other Smalltalk JIT virtual machines,
of
the order of 10 to 20 times faster than the current VM for benchFib.
Faster Interoperability Engine: produce a more flexible and faster FFI based on and integrated with
the
execution technology in FEE.
I'm interested in this too :)
Welcome aboard.
best Eliot
-- Best regards, Igor Stasenko AKA sig.
Hi Eliot--
This seems to be a hit. :) Okay, I updated the Teams page and created mailing lists for those teams.
thanks!
-C
-- Craig Latta improvisational musical informaticist www.netjam.org Smalltalkers do: [:it | All with: Class, (And love: it)]
Ta!
On Tue, Dec 16, 2008 at 9:16 PM, Craig Latta craig@netjam.org wrote:
Hi Eliot--
This seems to be a hit. :) Okay, I updated the Teams page and created
mailing lists for those teams.
thanks!
-C
-- Craig Latta improvisational musical informaticist www.netjam.org Smalltalkers do: [:it | All with: Class, (And love: it)]
Faster Interoperability Engine: produce a more flexible and faster FFI based on and integrated with the execution technology in FEE.
I would suggest looking at the classes in GNU Smalltalk so that we may end up having something compatible, but I already hear the FUD (Faster Unfounded Doubts) team screaming.
Anyway, this stuff is pretty well documented, so I can make a pdf of the docs so that you can rebuild it cleanly.
Paolo
Paolo Bonzini wrote:
I would suggest looking at the classes in GNU Smalltalk so that we may end up having something compatible, but I already hear the FUD (Faster Unfounded Doubts) team screaming.
Easy answer: Release that code under MIT and there will be no problem.
Cheers, - Andreas
Anyway, this stuff is pretty well documented, so I can make a pdf of the docs so that you can rebuild it cleanly.
Paolo
On 17.12.2008, at 16:02, Andreas Raab wrote:
Paolo Bonzini wrote:
I would suggest looking at the classes in GNU Smalltalk so that we may end up having something compatible, but I already hear the FUD (Faster Unfounded Doubts) team screaming.
Easy answer: Release that code under MIT and there will be no problem.
Cheers,
- Andreas
Anyway, this stuff is pretty well documented, so I can make a pdf of the docs so that you can rebuild it cleanly. Paolo
How about unit tests under MIT? Could serve as both spec and compatibility test.
- Bert -
Bert Freudenberg wrote:
On 17.12.2008, at 16:02, Andreas Raab wrote:
Paolo Bonzini wrote:
I would suggest looking at the classes in GNU Smalltalk so that we may end up having something compatible, but I already hear the FUD (Faster Unfounded Doubts) team screaming.
Easy answer: Release that code under MIT and there will be no problem.
Cheers,
- Andreas
Anyway, this stuff is pretty well documented, so I can make a pdf of the docs so that you can rebuild it cleanly. Paolo
How about unit tests under MIT? Could serve as both spec and compatibility test.
That's a very good idea.
In the meanwhile I'll prepare the docs.
Paolo
On Wed, 17 Dec 2008 16:09:21 +0100, Bert Freudenberg wrote:
On 17.12.2008, at 16:02, Andreas Raab wrote:
Paolo Bonzini wrote:
I would suggest looking at the classes in GNU Smalltalk so that we may end up having something compatible, but I already hear the FUD (Faster Unfounded Doubts) team screaming.
Easy answer: Release that code under MIT and there will be no problem.
Cheers,
- Andreas
Anyway, this stuff is pretty well documented, so I can make a pdf of the docs so that you can rebuild it cleanly. Paolo
How about unit tests under MIT? Could serve as both spec and compatibility test.
+ 1 for the hero of the day. Seriously. This is soo obvious that nobody even thought about it until you suggested it <de>Hut ab</de>
/Klaus
- Bert -
squeak-dev@lists.squeakfoundation.org