Hi, surfing on the web I have found this new language: http://factorcode.org/ It is a stack-based language with a very flexible parser.
It borrows idea from Self and it seems very promising to me. And it has the concept of image, ispector, debugger and so on... give it a try!
Thanks for the link! I'd like to check it out. Did a bit of Forth programming couple of decades ago. This looks great. Continuations in Forth...who'd have thunk it!
-bakki
On 9/6/06, Giovanni Giorgi daitangio@gmail.com wrote:
Hi, surfing on the web I have found this new language: http://factorcode.org/ It is a stack-based language with a very flexible parser.
It borrows idea from Self and it seems very promising to me. And it has the concept of image, ispector, debugger and so on... give it a try!
-- Software Architect http://www.objectsroot.com/ Software is nothing
Slava Pestov( jEdit fame ) a long time java guy , who designed Factor was fade up with java BTW ;)
On 9/6/06, Bakki Kudva bakki.kudva@gmail.com wrote:
Thanks for the link! I'd like to check it out. Did a bit of Forth programming couple of decades ago. This looks great. Continuations in Forth...who'd have thunk it!
-bakki
On 9/6/06, Giovanni Giorgi daitangio@gmail.com wrote:
Hi, surfing on the web I have found this new language: http://factorcode.org/ It is a stack-based language with a very flexible parser.
It borrows idea from Self and it seems very promising to me. And it has the concept of image, ispector, debugger and so on... give it a try!
-- Software Architect http://www.objectsroot.com/ Software is nothing
On 9/7/06, Hiren Thacker hithacker@gmail.com wrote:
Slava Pestov( jEdit fame ) a long time java guy , who designed Factor was fade up with java BTW ;)
Do you mean give up java?
I am studying factor and would be quite easy to build a Squeak-bytecode2factor compiler. Because factor has a x86/PPC compiler, we can get for free a very fast Squeak at the end.
And Factor documentation is good, even if language is not (yet) so old.
On 9/6/06, Bakki Kudva <bakki.kudva@gmail.com > wrote:
Thanks for the link! I'd like to check it out. Did a bit of Forth programming couple of decades ago. This looks great. Continuations in Forth...who'd have thunk it!
-bakki
On 9/6/06, Giovanni Giorgi daitangio@gmail.com wrote:
Hi, surfing on the web I have found this new language: http://factorcode.org/ It is a stack-based language with a very flexible parser.
On 9/7/06, Giovanni Giorgi daitangio@gmail.com wrote:
On 9/7/06, Hiren Thacker hithacker@gmail.com wrote:
Slava Pestov( jEdit fame ) a long time java guy , who designed Factor was fade up with java BTW ;)
Do you mean give up java?
Mostly.He told in his old JRoller blog that he will code in java only if getting paid.
Giovanni Giorgi writes:
I am studying factor and would be quite easy to build a Squeak-bytecode2factor compiler. Because factor has a x86/PPC compiler, we can get for free a very fast Squeak at the end.
If your goal is to make Squeak much faster then helping out on Exupery would probably be less work with more gain. Exupery can already compile almost all of Squeak's bytecodes. It has polymorphic inline caches to speed up sends. It can compile blocks. It can dynamically inline primitives.
The current priorities are compiling more primitives and fixing bugs aiming at getting to a 1.0 release as soon as possible.
Bryce
Does the "real closures" package work with it?
Thanks JJ
From: Bryce Kampjes bryce@kampjes.demon.co.uk Reply-To: The general-purpose Squeak developers listsqueak-dev@lists.squeakfoundation.org To: The general-purpose Squeak developers listsqueak-dev@lists.squeakfoundation.org Subject: Re: [IDEAS] Looking at Factor Date: Thu, 7 Sep 2006 19:19:48 +0100
Giovanni Giorgi writes:
I am studying factor and would be quite easy to build a Squeak-bytecode2factor compiler. Because factor has a x86/PPC compiler, we can get for free a very fast Squeak at the end.
If your goal is to make Squeak much faster then helping out on Exupery would probably be less work with more gain. Exupery can already compile almost all of Squeak's bytecodes. It has polymorphic inline caches to speed up sends. It can compile blocks. It can dynamically inline primitives.
The current priorities are compiling more primitives and fixing bugs aiming at getting to a 1.0 release as soon as possible.
Bryce
J J writes:
Does the "real closures" package work with it?
It might, I haven't tested that. But I'm compiling bytecodes so I'll only need to repeat any VM level changes. It's something that should be done, though it might be better to help get real closures into mainstream Squeak first than work on Exupery support for them.
Bryce
Well, I think the reason they haven't made the package default is speed. But it sounds like what your doing makes things fast enough that it would be ok. That's why I asked.
From: Bryce Kampjes bryce@kampjes.demon.co.uk Reply-To: The general-purpose Squeak developers listsqueak-dev@lists.squeakfoundation.org To: The general-purpose Squeak developers listsqueak-dev@lists.squeakfoundation.org Subject: Re: [IDEAS] Looking at Factor Date: Thu, 7 Sep 2006 21:08:13 +0100
J J writes:
Does the "real closures" package work with it?
It might, I haven't tested that. But I'm compiling bytecodes so I'll only need to repeat any VM level changes. It's something that should be done, though it might be better to help get real closures into mainstream Squeak first than work on Exupery support for them.
Bryce
J J writes:
Well, I think the reason they haven't made the package default is speed. But it sounds like what your doing makes things fast enough that it would be ok. That's why I asked.
It's a good point.
From Exupery's perspective, it is better for me to focus on getting to
a 1.0. There's a lot of work required to build a compiler that will speed up real programs. For over a year, Exupery has outperformed VisualWorks for raw bytecode performance but hasn't yet made a difference for real programs. Adding all the extra features needed to benefit real code has and still is the current focus. At the moment that means implementing key primitives then fixing bugs.
Bryce
Any guess when 1.0 will be finished? Are you the only person working on this?
Also, just to make sure I understand: I came from a C++ background, and when I hear "inlining" I think of C++ inline (when ever you see this "function" replace it, at the call site, with the body of the "function"). I assume you mean the same thing in smalltalk? It does look like smalltalk could make some huge gains from such inlining since so much of the code just calls other methods with slightly different arguments.
From: Bryce Kampjes bryce@kampjes.demon.co.uk Reply-To: The general-purpose Squeak developers listsqueak-dev@lists.squeakfoundation.org To: The general-purpose Squeak developers listsqueak-dev@lists.squeakfoundation.org Subject: Re: [IDEAS] Looking at Factor Date: Thu, 7 Sep 2006 19:19:48 +0100
Giovanni Giorgi writes:
I am studying factor and would be quite easy to build a Squeak-bytecode2factor compiler. Because factor has a x86/PPC compiler, we can get for free a very fast Squeak at the end.
If your goal is to make Squeak much faster then helping out on Exupery would probably be less work with more gain. Exupery can already compile almost all of Squeak's bytecodes. It has polymorphic inline caches to speed up sends. It can compile blocks. It can dynamically inline primitives.
The current priorities are compiling more primitives and fixing bugs aiming at getting to a 1.0 release as soon as possible.
Bryce
As far as I know inlining is what you think. In Smalltalk every compiled method has an object represnting it. As I knew Exupery builds a special method object containing machine-opcode.
After years of Smalltalk usage, I came to the point to which the real problem is slow message sending. Because in Smalltalk every message send is dynamic, the performance penalty is very high.
VW had a mechanism similar to Exupery in the last years but it does not seem to me a lot more fast then squeak in some areas.
On 9/30/06, J J azreal1977@hotmail.com wrote:
Any guess when 1.0 will be finished? Are you the only person working on this?
Also, just to make sure I understand: I came from a C++ background, and when I hear "inlining" I think of C++ inline (when ever you see this "function" replace it, at the call site, with the body of the "function"). I assume you mean the same thing in smalltalk? It does look like smalltalk could make some huge gains from such inlining since so much of the code just calls other methods with slightly different arguments.
From: Bryce Kampjes bryce@kampjes.demon.co.uk Reply-To: The general-purpose Squeak developers listsqueak-dev@lists.squeakfoundation.org To: The general-purpose Squeak developers listsqueak-dev@lists.squeakfoundation.org Subject: Re: [IDEAS] Looking at Factor Date: Thu, 7 Sep 2006 19:19:48 +0100
Giovanni Giorgi writes:
I am studying factor and would be quite easy to build a Squeak-bytecode2factor compiler. Because factor has a x86/PPC compiler, we can get for free a very fast Squeak at the end.
If your goal is to make Squeak much faster then helping out on Exupery would probably be less work with more gain. Exupery can already compile almost all of Squeak's bytecodes. It has polymorphic inline caches to speed up sends. It can compile blocks. It can dynamically inline primitives.
The current priorities are compiling more primitives and fixing bugs aiming at getting to a 1.0 release as soon as possible.
Bryce
J J writes:
Any guess when 1.0 will be finished? Are you the only person working on this?
I've been saying about a year, so I'd guess 1.0 by next summer. However that depends on what ends up going into 1.0 and how busy I am over the next year.
I'm the main person working on it. There's been about 5 other contributors so far including Andy and Patrick who did the Windows and Solaris x86 ports.
Also, just to make sure I understand: I came from a C++ background, and when I hear "inlining" I think of C++ inline (when ever you see this "function" replace it, at the call site, with the body of the "function"). I assume you mean the same thing in smalltalk? It does look like smalltalk could make some huge gains from such inlining since so much of the code just calls other methods with slightly different arguments.
Inlining means the same thing except driven automatically by profiling rather than an "inline" keyword. In this case read the work done by Urs Holzle for Self to get a feeling for the specifics.
Exupery will also dynamically decompile when nessisary. This is to allow seemless debugging and meta-programming. Exupery already dynamically decompiles methods when it clears it's code cache or on image saves.
Inlining is planned as the 2.0 feature. Yes, it's important, keeping it out of 1.0 is a way to reduce scope creep in 1.0.
Bryce
squeak-dev@lists.squeakfoundation.org
-
Bakki Kudva -
Bryce Kampjes -
bryce＠kampjes.demon.co.uk
-
Giovanni Giorgi -
Giovanni Giorgi -
Hiren Thacker -
J J