Smalltalk › Amber Smalltalk

Ideas on making big changes in compiler/object model

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

4 messages Options

Dave Mason-2

Ideas on making big changes in compiler/object model

I've been building a fairly large system with Amber, but sometimes I've needed to debug using the javascript console and interact with the generated javascript - which is not fun. I also noticed the beginning of performance problems.

So I decided to look at ways to get better performance while maintaining Smalltalk semantics. I succeeded fairly well, improving performance by a factor of about 7 in a recursive micro-benchmark. The resulting code is also somewhat more readable and idiomatic Javascript. I am working on a blog post about what I did as soon as I get jsperf.org set up.

Now I want to try modifying the code generator to use the revised model. I have a compiler background, and I see more or less what needs changing, but modifying the compiler in-place in the IDE isn't going to work very well since the object model is significantly changed, so I'm just writing to see if anyone has any advice/ideas on how to make the changes be something other than a all-at-once shift.

Thanks

../Dave

--
You received this message because you are subscribed to the Google Groups "amber-lang" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

Hannes Hirzel

Re: Ideas on making big changes in compiler/object model

Hi Dave

On 9/25/14, Dave Mason <[hidden email]> wrote:
> I've been building a fairly large system with Amber, but sometimes I've
> needed to debug using the javascript console and interact with the
> generated javascript - which is not fun. I also noticed the beginning of
> performance problems.

Just curious, what does 'a fairly large system mean'? 300, 600, 1000 classes?

> So I decided to look at ways to get better performance while maintaining
> Smalltalk semantics. I succeeded fairly well, improving performance by a
> factor of about 7 in a recursive micro-benchmark. The resulting code is
> also somewhat more readable and idiomatic Javascript. I am working on a
> blog post about what I did as soon as I get jsperf.org set up.

We are looking forward to this....

> Now I want to try modifying the code generator to use the revised model. I
> have a compiler background, and I see more or less what needs changing, but
> modifying the compiler in-place in the IDE isn't going to work very well
> since the object model is significantly changed, so I'm just writing to see
> if anyone has any advice/ideas on how to make the changes be something
> other than a all-at-once shift.

As the https://github.com/amber-smalltalk/amber-examples project shows
amber projects may be recompiled completely from the command line.

What about cloing the compiler (class names with a different prefix),
do the changes in the IDE on the clone incrementally with the IDE
uses the old compiler and do tests on the command line with the clone?

Regards
Hannes

--
You received this message because you are subscribed to the Google Groups "amber-lang" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

Hannes Hirzel

Re: Ideas on making big changes in compiler/object model

P.S. An updated README is in preparation

https://github.com/hhzl/amber-examples

Section 'Amber on the command line'

And the idea presented is very sketchy .....

On 9/26/14, H. Hirzel <[hidden email]> wrote:

> Hi Dave
>
> On 9/25/14, Dave Mason <[hidden email]> wrote:
>> I've been building a fairly large system with Amber, but sometimes I've
>> needed to debug using the javascript console and interact with the
>> generated javascript - which is not fun. I also noticed the beginning of
>> performance problems.
>
> Just curious, what does 'a fairly large system mean'? 300, 600, 1000
> classes?
>
>> So I decided to look at ways to get better performance while maintaining
>> Smalltalk semantics. I succeeded fairly well, improving performance by a
>> factor of about 7 in a recursive micro-benchmark. The resulting code is
>> also somewhat more readable and idiomatic Javascript. I am working on a
>> blog post about what I did as soon as I get jsperf.org set up.
>
> We are looking forward to this....
>
>> Now I want to try modifying the code generator to use the revised model.
>> I
>> have a compiler background, and I see more or less what needs changing,
>> but
>> modifying the compiler in-place in the IDE isn't going to work very well
>> since the object model is significantly changed, so I'm just writing to
>> see
>> if anyone has any advice/ideas on how to make the changes be something
>> other than a all-at-once shift.
>
> As the https://github.com/amber-smalltalk/amber-examples project shows
> amber projects may be recompiled completely from the command line.
>
> What about cloing the compiler (class names with a different prefix),
> do the changes in the IDE on the clone incrementally with the IDE
> uses the old compiler and do tests on the command line with the clone?
>
> Regards
> Hannes
>

Manfred Kröhnert

Re: Ideas on making big changes in compiler/object model

In reply to this post by Dave Mason-2

Hello Dave,

sorry for answering so late.

Since the compiler is an integral part of Amber itself, the best way to go would probably be the following:

1. update Amber to latest git and create a new branch to develop in

2. make changes in the compiler in the IDE

3. commit the compiler package

4. create a commit (this should hopefully only contain the changes to the compiler)

5. recompile Amber with Grunt in the commandline window

6. reload the Amber page in the browser and look issues (packages not loading, etc)

7. if there are errors do a "git reset --hard HEAD" to remove all changes to the recompiled Amber files,

otherwise continue

Maybe there are some minor steps missing, but I think that this is most probably the safest way to handle Compiler changes.

Best,

Manfred

On Thu, Sep 25, 2014 at 10:51 PM, Dave Mason <[hidden email]> wrote:

I've been building a fairly large system with Amber, but sometimes I've needed to debug using the javascript console and interact with the generated javascript - which is not fun. I also noticed the beginning of performance problems.

So I decided to look at ways to get better performance while maintaining Smalltalk semantics. I succeeded fairly well, improving performance by a factor of about 7 in a recursive micro-benchmark. The resulting code is also somewhat more readable and idiomatic Javascript. I am working on a blog post about what I did as soon as I get jsperf.org set up.

Now I want to try modifying the code generator to use the revised model. I have a compiler background, and I see more or less what needs changing, but modifying the compiler in-place in the IDE isn't going to work very well since the object model is significantly changed, so I'm just writing to see if anyone has any advice/ideas on how to make the changes be something other than a all-at-once shift.

Thanks

../Dave

--
You received this message because you are subscribed to the Google Groups "amber-lang" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.