[IDEAS] Looking at Factor

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

[IDEAS] Looking at Factor

Giovanni Giorgi-2
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

Reply | Threaded
Open this post in threaded view
|

Re: [IDEAS] Looking at Factor

Bakki Kudva
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 <[hidden email]> 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
>
>

Reply | Threaded
Open this post in threaded view
|

Re: [IDEAS] Looking at Factor

Hiren Thacker
Slava Pestov( jEdit fame ) a long time java guy , who designed Factor was fade up with java BTW ;)
 
On 9/6/06, Bakki Kudva <[hidden email]> 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 <[hidden email]> 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
>
>




--
Hiren J.Thacker

Reply | Threaded
Open this post in threaded view
|

Re: [IDEAS] Looking at Factor

Giovanni Giorgi-2
On 9/7/06, Hiren Thacker <[hidden email]> 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 <[hidden email] > 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 <[hidden email]> 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.


--
Software Architect
http://www.objectsroot.com/
Software is nothing

Reply | Threaded
Open this post in threaded view
|

Re: Looking at Factor

Hiren Thacker
On 9/7/06, Giovanni Giorgi <[hidden email]> wrote:
> On 9/7/06, Hiren Thacker <[hidden email]> 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.

Reply | Threaded
Open this post in threaded view
|

Re: [IDEAS] Looking at Factor

Bryce Kampjes
In reply to this post by Giovanni Giorgi-2
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

Reply | Threaded
Open this post in threaded view
|

Re: [IDEAS] Looking at Factor

J J-6
Does the "real closures" package work with it?

Thanks
JJ


>From: Bryce Kampjes <[hidden email]>
>Reply-To: The general-purpose Squeak developers
>list<[hidden email]>
>To: The general-purpose Squeak developers
>list<[hidden email]>
>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
>



Reply | Threaded
Open this post in threaded view
|

Re: [IDEAS] Looking at Factor

Bryce Kampjes
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

Reply | Threaded
Open this post in threaded view
|

Re: [IDEAS] Looking at Factor

J J-6
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 <[hidden email]>
>Reply-To: The general-purpose Squeak developers
>list<[hidden email]>
>To: The general-purpose Squeak developers
>list<[hidden email]>
>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
>



Reply | Threaded
Open this post in threaded view
|

Re: [IDEAS] Looking at Factor

Bryce Kampjes
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

Reply | Threaded
Open this post in threaded view
|

Exupery (was Re: [IDEAS] Looking at Factor)

J J-6
In reply to this post by Bryce Kampjes
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 <[hidden email]>
>Reply-To: The general-purpose Squeak developers
>list<[hidden email]>
>To: The general-purpose Squeak developers
>list<[hidden email]>
>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
>



Reply | Threaded
Open this post in threaded view
|

Re: Exupery (was Re: [IDEAS] Looking at Factor)

Giovanni Giorgi-3
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 <[hidden email]> 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 <[hidden email]>
> >Reply-To: The general-purpose Squeak developers
> >list<[hidden email]>
> >To: The general-purpose Squeak developers
> >list<[hidden email]>
> >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
> >
>
>
>
>


--
Software Architect
http://www.objectsroot.com/
Software is nothing

Reply | Threaded
Open this post in threaded view
|

Exupery (was Re: [IDEAS] Looking at Factor)

Bryce Kampjes
In reply to this post by J J-6
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