Smalltalk › Squeak › Squeak - Dev

[IDEAS] Looking at Factor

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

13 messages Options

Giovanni Giorgi-2

[IDEAS] Looking at Factor

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

Bakki Kudva

Re: [IDEAS] Looking at Factor

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 Thacker

Re: [IDEAS] Looking at Factor

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

Giovanni Giorgi-2

Re: [IDEAS] Looking at Factor

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

Hiren Thacker

Re: Looking at Factor

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.

Bryce Kampjes

Re: [IDEAS] Looking at Factor

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

J J-6

Re: [IDEAS] Looking at Factor

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
>

Bryce Kampjes

Re: [IDEAS] Looking at Factor

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-6

Re: [IDEAS] Looking at Factor

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
>

Bryce Kampjes

Re: [IDEAS] Looking at Factor

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

J J-6

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

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.

Giovanni Giorgi-3

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

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

Bryce Kampjes

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

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