Pushing Amber

Hi guys!

I would really like to push Amber more. We have quite some interesting
stuff. Here's some ideas/ongoing stuff

- new imperative compiler from Herby (I have a new compiler toolchain
  inspired by Opal that reuses his ideas, I have to finish and commit it)
- New website from John
- Better packages (with doc) from Göran?
- More doc
- Better IDE using Glamour?
- Coral integration? (I'm tired of the chunk format, and Pharo will use
  Coral in the future)
- Better client/server communication (I'd love to have a really good
  Pharo/Amber communication, and for example be able to browse Amber
  from Pharo w/ Nautilus)
- Traits?
- Pragmas?
- other things...?

Now pull requests are great, but I think we could improve the dev
process.

So would some of you like to join the effort and help making
Amber better? Any suggestion about a better dev process?

Cheers,
Nico

[hidden email] wrote:
> Hi guys!
>
> I would really like to push Amber more. We have quite some interesting
> stuff. Here's some ideas/ongoing stuff
>
> - new imperative compiler from Herby (I have a new compiler toolchain
>    inspired by Opal that reuses his ideas, I have to finish and commit it)
> - New website from John
> - Better packages (with doc) from Göran?
I don't know if this includes it, but I would definitely like to see
better (github-friendlier) model of file structure. No .deploy.js (they
can be created offline, I believe even sed could do that, though not
strighrforwardly, or very simple node code that could mock the calls,
let the file "run" and then produce whatever subset it sees fit).
I also though of .js not being series of statements, but more pure data
in form of big quasi-json* which can then be manipulated easier.

> - More doc
> - Better IDE using Glamour?
I don't see the need, IDE as-is is good enough (for me, at the moment);
there are only little quirks to fix (make tab multiline/scrollable;
allow to find references to actual method (not working in Chrome; must
find reference to something else, close it, and then change the dropdown
back to name of actual method, pain in the ass)).
But of course if someone makes better IDE, it would be nice.
> - Coral integration? (I'm tired of the chunk format, and Pharo will use
>    Coral in the future)
I can't say, I don't know Coral...
> - Better client/server communication (I'd love to have a really good
>    Pharo/Amber communication, and for example be able to browse Amber
>    from Pharo w/ Nautilus)
+1
> - Traits?
+1
> - Pragmas?
> - other things...?
>
> Now pull requests are great, but I think we could improve the dev
> process.
I don't know. Node.js works fine with github repo, fork and pullreqs.
Though I don't know the inner rules for those who have commit rights...

> So would some of you like to join the effort and help making
> Amber better? Any suggestion about a better dev process?

It depends on my state :-) I'm pretty swinging... I'd rather not bind
myself by some promise. I did some changes where I saw the need for my
case... which I will probably do in the future as well.
>
> Cheers,
> Nico

Herby

*Quasi-JSON because as I see it the functions need to be there literally.
I though of putting only args and body there and using new Function, but
in this case the function can not reference itself (which is needed for
direct-call-infrastructure-inside-function) in strict mode, which is
future-hostile (non-strict has arguments.callee).
It is also possible to include args, name and body and create function
by eval (node.js does this (not direct eval, but eval-like) for loading
modules).

Regarding communication between Pharo and Amber, I think it is worth looking at STON[1]. I've started a port of STON to Amber[2]. I plan to use STON as part of tODE[3], when I can get back to tODE development:) The latest version of tODE uses Amber as the client.

Regarding development in general I've put together the amber-skeleton project[4] which uses Pharo as a file server and stores the code on disk in Cypress disk format[5]. The Cypress disk format is aimed at allowing folks to share Smalltalk source code between dialects using git/github. Squeak, Pharo, GemStone and Amber can share code now. There are Cypress implementations that are very close to complete for Cuis and VW, with a commitment from a developer for a VA implementation...

Dale

[1] https://github.com/svenvc/ston
[2] https://github.com/dalehenrich/ston/network
[3] http://code.google.com/p/tode/
[4] http://gemstonesoup.wordpress.com/2012/04/22/amber-skeleton-lookout-kaliningrad/
[5] https://github.com/CampSmalltalk/Cypress/wiki
----- Original Message -----
| From: "petton nicolas" <[hidden email]>
| To: "Amber ML" <[hidden email]>
| Sent: Wednesday, May 30, 2012 7:47:23 AM
| Subject: [amber-lang] Pushing Amber
|
|
| Hi guys!
|
| I would really like to push Amber more. We have quite some
| interesting
| stuff. Here's some ideas/ongoing stuff
|
| - new imperative compiler from Herby (I have a new compiler toolchain
|   inspired by Opal that reuses his ideas, I have to finish and commit
|   it)
| - New website from John
| - Better packages (with doc) from Göran?
| - More doc
| - Better IDE using Glamour?
| - Coral integration? (I'm tired of the chunk format, and Pharo will
| use
|   Coral in the future)
| - Better client/server communication (I'd love to have a really good
|   Pharo/Amber communication, and for example be able to browse Amber
|   from Pharo w/ Nautilus)
| - Traits?
| - Pragmas?
| - other things...?
|
| Now pull requests are great, but I think we could improve the dev
| process.
|
| So would some of you like to join the effort and help making
| Amber better? Any suggestion about a better dev process?
|
| Cheers,
| Nico
|

Hello.

How about debugger improvements: step buttons and "create DNU"?
Resumable exceptions?

Herby Vojčík <[hidden email]> writes:


> I don't know if this includes it, but I would definitely like to see
> better (github-friendlier) model of file structure. No .deploy.js
> (they can be created offline, I believe even sed could do that, though
> not strighrforwardly, or very simple node code that could mock the
> calls, let the file "run" and then produce whatever subset it sees
> fit).

True.

Would it be a problem for people if we include a node program that does it?

> I also though of .js not being series of statements, but more pure
> data in form of big quasi-json* which can then be manipulated easier.

I don't know about that. I don't really feel the need for it.

>> - Better IDE using Glamour?
> I don't see the need, IDE as-is is good enough (for me, at the
> moment);

The IDE is exploding. Take a look at the Browser class. We can do way
better. The inspector is also far from being perfect, we don't have a
hierarchy browser.

Using a framework like Glamour would make it a lot easier to build great
tools, maintainable and extensible.

>> Now pull requests are great, but I think we could improve the dev
>> process.
> I don't know. Node.js works fine with github repo, fork and
> pullreqs. Though I don't know the inner rules for those who have
> commit rights...

That's only me and Göran IIRC.

Nico
--
Nicolas Petton
http://nicolas-petton.fr

Dale Henrichs <[hidden email]> writes:


Hi Dale,

Can you show us a trivial example of how you would communicate bewteen
Pharo and Amber with this?

Thanks,
Nico

--
Nicolas Petton
http://nicolas-petton.fr

Denis Kudriashov <[hidden email]> writes:

> Hello.
>
> How about debugger improvements: step buttons and "create DNU"?

Yep, that's on the todo list :)

> Resumable exceptions?

Not for now.

Nico

--
Nicolas Petton
http://nicolas-petton.fr

[hidden email] wrote:
> Herby Vojčík<[hidden email]>  writes:
>>> Now pull requests are great, but I think we could improve the dev
>>> process.
>> I don't know. Node.js works fine with github repo, fork and
>> pullreqs. Though I don't know the inner rules for those who have
>> commit rights...
>
> That's only me and Göran IIRC.

I meant in nodejs case... there are more people there, I was only
contributing in fork/pullreq manner and it worked... they are doing it
still this way, but there are more commiters and they have github
organization created, they are not under personal account.

But it's true it got faster when more committers appeared there when
comparing with ry-only days.

> Nico

Herby

Right now, I'm using JSON in amber-skeleton to communicate the Cypress package contents between Amber and Pharo.

On the Pharo side I have handlers for GET and PUT requests that write[1] and read[2] JSON.

On the Amber side I have an Importer/Exporter that reads[3] and writes[4] JSON.

Basically I am using JSON to serialize the Smalltalk data structures and I have to write custom JSON readers/writers ... add a new field and I need to go around and change my readers and writers too. With STON, I wouldn't have to write custom readers and writers for my data ... STON would do all of the work and I'd be free to just worry about the Smalltalk code (add a field ... the serialization code is already written) ...

In tODE it becomes even more important to me, because every object in the Smalltalk image is a candidate to be shipped over the wire and I really don't like the idea of having to write custom readers/writers for every class in the system ...

Let me know if you need more information.

Dale

[1] https://github.com/CampSmalltalk/Cypress/blob/master/packages/Cypress-AmberFileServer.package/ZnCypressFileServerDelegate.class/instance/handlePackageGet..st#L11
[2] https://github.com/CampSmalltalk/Cypress/blob/master/packages/Cypress-AmberFileServer.package/ZnCypressFileServerDelegate.class/instance/handlePackagePut..st#L6

[3] https://github.com/CampSmalltalk/amber-cypress/blob/master/st/Cypress-ExportImport.st#L66
[4] https://github.com/CampSmalltalk/amber-cypress/blob/master/st/Cypress-ExportImport.st#L16
----- Original Message -----
| From: "petton nicolas" <[hidden email]>
| To: [hidden email]
| Sent: Wednesday, May 30, 2012 8:37:03 AM
| Subject: Re: [amber-lang] Pushing Amber
|
| Dale Henrichs <[hidden email]> writes:
|
|
| Hi Dale,
|
| Can you show us a trivial example of how you would communicate
| bewteen
| Pharo and Amber with this?
|
| Thanks,
| Nico
|
| > Regarding communication between Pharo and Amber, I think it is
| > worth
| > looking at STON[1]. I've started a port of STON to Amber[2]. I plan
| > to
| > use STON as part of tODE[3], when I can get back to tODE
| > development:)
| > The latest version of tODE uses Amber as the client.
| >
| > Regarding development in general I've put together the
| > amber-skeleton
| > project[4] which uses Pharo as a file server and stores the code on
| > disk in Cypress disk format[5]. The Cypress disk format is aimed at
| > allowing folks to share Smalltalk source code between dialects
| > using
| > git/github. Squeak, Pharo, GemStone and Amber can share code
| > now. There are Cypress implementations that are very close to
| > complete
| > for Cuis and VW, with a commitment from a developer for a VA
| > implementation...
| >
| > Dale
| >
| > [1] https://github.com/svenvc/ston
| > [2] https://github.com/dalehenrich/ston/network
| > [3] http://code.google.com/p/tode/
| > [4]
| > http://gemstonesoup.wordpress.com/2012/04/22/amber-skeleton-lookout-kaliningrad/
| > [5] https://github.com/CampSmalltalk/Cypress/wiki
| > ----- Original Message -----
| > | From: "petton nicolas" <[hidden email]>
| > | To: "Amber ML" <[hidden email]>
| > | Sent: Wednesday, May 30, 2012 7:47:23 AM
| > | Subject: [amber-lang] Pushing Amber
| > |
| > |
| > | Hi guys!
| > |
| > | I would really like to push Amber more. We have quite some
| > | interesting
| > | stuff. Here's some ideas/ongoing stuff
| > |
| > | - new imperative compiler from Herby (I have a new compiler
| > | toolchain
| > |   inspired by Opal that reuses his ideas, I have to finish and
| > |   commit
| > |   it)
| > | - New website from John
| > | - Better packages (with doc) from Göran?
| > | - More doc
| > | - Better IDE using Glamour?
| > | - Coral integration? (I'm tired of the chunk format, and Pharo
| > | will
| > | use
| > |   Coral in the future)
| > | - Better client/server communication (I'd love to have a really
| > | good
| > |   Pharo/Amber communication, and for example be able to browse
| > |   Amber
| > |   from Pharo w/ Nautilus)
| > | - Traits?
| > | - Pragmas?
| > | - other things...?
| > |
| > | Now pull requests are great, but I think we could improve the dev
| > | process.
| > |
| > | So would some of you like to join the effort and help making
| > | Amber better? Any suggestion about a better dev process?
| > |
| > | Cheers,
| > | Nico
| > |
|
| --
| Nicolas Petton
| http://nicolas-petton.fr
|

Dale Henrichs <[hidden email]> writes:

I like the idea :)
Could you get back to me when it will be ready and working in tODE?

Thanks,
Nico

--
Nicolas Petton
http://nicolas-petton.fr

Will do!

----- Original Message -----
| From: "petton nicolas" <[hidden email]>
| To: [hidden email]
| Sent: Wednesday, May 30, 2012 9:08:12 AM
| Subject: Re: [amber-lang] Pushing Amber
|
| Dale Henrichs <[hidden email]> writes:
|
| I like the idea :)
| Could you get back to me when it will be ready and working in tODE?
|
| Thanks,
| Nico
|
| > Right now, I'm using JSON in amber-skeleton to communicate the
| > Cypress package contents between Amber and Pharo.
| >
| > On the Pharo side I have handlers for GET and PUT requests that
| > write[1] and read[2] JSON.
| >
| > On the Amber side I have an Importer/Exporter that reads[3] and
| > writes[4] JSON.
| >
| > Basically I am using JSON to serialize the Smalltalk data
| > structures
| > and I have to write custom JSON readers/writers ... add a new field
| > and I need to go around and change my readers and writers too. With
| > STON, I wouldn't have to write custom readers and writers for my
| > data
| > ... STON would do all of the work and I'd be free to just worry
| > about
| > the Smalltalk code (add a field ... the serialization code is
| > already
| > written) ...
| >
| > In tODE it becomes even more important to me, because every object
| > in
| > the Smalltalk image is a candidate to be shipped over the wire and
| > I
| > really don't like the idea of having to write custom
| > readers/writers
| > for every class in the system ...
| >
| > Let me know if you need more information.
| >
| > Dale
| >
| > [1]
| > https://github.com/CampSmalltalk/Cypress/blob/master/packages/Cypress-AmberFileServer.package/ZnCypressFileServerDelegate.class/instance/handlePackageGet..st#L11
| > [2]
| > https://github.com/CampSmalltalk/Cypress/blob/master/packages/Cypress-AmberFileServer.package/ZnCypressFileServerDelegate.class/instance/handlePackagePut..st#L6
| >
| > [3]
| > https://github.com/CampSmalltalk/amber-cypress/blob/master/st/Cypress-ExportImport.st#L66
| > [4]
| > https://github.com/CampSmalltalk/amber-cypress/blob/master/st/Cypress-ExportImport.st#L16
| > ----- Original Message -----
| > | From: "petton nicolas" <[hidden email]>
| > | To: [hidden email]
| > | Sent: Wednesday, May 30, 2012 8:37:03 AM
| > | Subject: Re: [amber-lang] Pushing Amber
| > |
| > | Dale Henrichs <[hidden email]> writes:
| > |
| > |
| > | Hi Dale,
| > |
| > | Can you show us a trivial example of how you would communicate
| > | bewteen
| > | Pharo and Amber with this?
| > |
| > | Thanks,
| > | Nico
| > |
| > | > Regarding communication between Pharo and Amber, I think it is
| > | > worth
| > | > looking at STON[1]. I've started a port of STON to Amber[2]. I
| > | > plan
| > | > to
| > | > use STON as part of tODE[3], when I can get back to tODE
| > | > development:)
| > | > The latest version of tODE uses Amber as the client.
| > | >
| > | > Regarding development in general I've put together the
| > | > amber-skeleton
| > | > project[4] which uses Pharo as a file server and stores the
| > | > code on
| > | > disk in Cypress disk format[5]. The Cypress disk format is
| > | > aimed at
| > | > allowing folks to share Smalltalk source code between dialects
| > | > using
| > | > git/github. Squeak, Pharo, GemStone and Amber can share code
| > | > now. There are Cypress implementations that are very close to
| > | > complete
| > | > for Cuis and VW, with a commitment from a developer for a VA
| > | > implementation...
| > | >
| > | > Dale
| > | >
| > | > [1] https://github.com/svenvc/ston
| > | > [2] https://github.com/dalehenrich/ston/network
| > | > [3] http://code.google.com/p/tode/
| > | > [4]
| > | > http://gemstonesoup.wordpress.com/2012/04/22/amber-skeleton-lookout-kaliningrad/
| > | > [5] https://github.com/CampSmalltalk/Cypress/wiki
| > | > ----- Original Message -----
| > | > | From: "petton nicolas" <[hidden email]>
| > | > | To: "Amber ML" <[hidden email]>
| > | > | Sent: Wednesday, May 30, 2012 7:47:23 AM
| > | > | Subject: [amber-lang] Pushing Amber
| > | > |
| > | > |
| > | > | Hi guys!
| > | > |
| > | > | I would really like to push Amber more. We have quite some
| > | > | interesting
| > | > | stuff. Here's some ideas/ongoing stuff
| > | > |
| > | > | - new imperative compiler from Herby (I have a new compiler
| > | > | toolchain
| > | > |   inspired by Opal that reuses his ideas, I have to finish
| > | > |   and
| > | > |   commit
| > | > |   it)
| > | > | - New website from John
| > | > | - Better packages (with doc) from Göran?
| > | > | - More doc
| > | > | - Better IDE using Glamour?
| > | > | - Coral integration? (I'm tired of the chunk format, and
| > | > | Pharo
| > | > | will
| > | > | use
| > | > |   Coral in the future)
| > | > | - Better client/server communication (I'd love to have a
| > | > | really
| > | > | good
| > | > |   Pharo/Amber communication, and for example be able to
| > | > |   browse
| > | > |   Amber
| > | > |   from Pharo w/ Nautilus)
| > | > | - Traits?
| > | > | - Pragmas?
| > | > | - other things...?
| > | > |
| > | > | Now pull requests are great, but I think we could improve the
| > | > | dev
| > | > | process.
| > | > |
| > | > | So would some of you like to join the effort and help making
| > | > | Amber better? Any suggestion about a better dev process?
| > | > |
| > | > | Cheers,
| > | > | Nico
| > | > |
| > |
| > | --
| > | Nicolas Petton
| > | http://nicolas-petton.fr
| > |
|
| --
| Nicolas Petton
| http://nicolas-petton.fr
|

Denis Kudriashov <[hidden email]> writes:

ahahah :)

I said that it was on the todo list, not that it was done ;)
Stepping support requires some heavy changes in the compiler. But we'll
get there.

Cheers,
Nico

--
Nicolas Petton
http://nicolas-petton.fr

Denis Kudriashov <[hidden email]> writes:

+1

Nico

--
Nicolas Petton
http://nicolas-petton.fr

tODE is not quite as ambitious ... in many ways it is a special case ... I am not interested in arbitrary behavior as much as rendering arbitrary objects on the client and allowing for customization of the rendering algorithms ....

arbitrary objects means that I can't use canned rendering routines pre-loaded on the client ... it also means that I'm interested in navigating arbitrary object graphs (in arbitrary ways) ...

All of this points me away from heading down the proxy route (at the moment) ...

The other thing that rattles around in the back of my brain is that the last time we went through this client/server "phase shift" proxies didn't "win the day", so I don't see it doing that again:) ...

With all of that said, I might end up in proxie-land when all is said and done ... just not heading there right out of the gate...

Dale

----- Original Message -----
| From: "Denis Kudriashov" <[hidden email]>
| To: [hidden email]
| Sent: Wednesday, May 30, 2012 10:48:17 AM
| Subject: Re: [amber-lang] Pushing Amber
|
|
| 2012/5/30 Dale Henrichs < [hidden email] >
|
|
| In tODE it becomes even more important to me, because every object in
| the Smalltalk image is a candidate to be shipped over the wire and I
| really don't like the idea of having to write custom readers/writers
| for every class in the system ...
|
|
|
| I dream about RemoteSmalltalk:)
| And about server side proxy objects (from GLORP, Gemstone,..) which
| are transparently accessible from browser.
|

On 05/30/2012 05:56 PM, Herby Vojčík wrote:
Personally I favor "speed" instead of "strictness" when it comes to
development - so picking people we trust and give them a good ole
fashion commit bit is a good way forward I think.

And hey, git is an SCM right ;)? We can always undo stuff :)

Regarding packages, I am not sure when I will be able to squeeze in more
time in the near future so if ANYONE is interested in improving that
area, feel free to speak up and I can explain what we have so far.

I just laid the "floor" for the fun stuff, in other words - I created
the concept of "package" instead of class categories, reified them on a
core level deep inside boot.js so we *really* have them, added some
Amber side code for reflecting on them, and then I added support in both
st and js formats to serialize simple metadata together with the package
(early in file so we can only parse that out first).

The idea being of course to put dependency information and more into
that metadata - and then be able to do dependency resolv etc.

Perhaps Dale gets tickled? Feel free to grab hold of it then :)

regards, Göran

Göran,

I'll take your bait:)

My thoughts so far have circled around the fact that the dependencies could/should(?) be resolved on the server side ... no need for the client-code to worry about package dependencies ... the server is close to the file system so it should do the heavy lifting ...

If we are using Pharo/Squeak/GemStone as a server, one _could_ use Metacello configurations to manage dependencies ... in fact it would be simple to manage the server and client code in the same configuration....

I'm in the middle of creating a scripting API that allows one to specify a load that looks like the following:

  Metacello new
    project: 'STON';
    version: '1.0';
    repository: 'https://github.com/dalehenrich/ston:amber/repository';
    load.

This code _could_ be executed in Amber on the client, with the actual Metacello heavy lifting done on the server side (where Metacello is already running)...a load list could be returned to the client and we'd be off to the races ....

The down-side to this approach is that there would be a hell of a lot of work to get Metacello ported to Node.js:)

I've looked at Node.js and frankly the file system support is in the dark ages ... I was going to do a variant of the server for amber-skeleton in Node.js, but when I discovered that you couldn't recursively delete a directory with the standard node.js installation I surrendered and just did a Pharo version ... While I'm sure one could work hard at this and eventually duplicate the whole Pharo class library in Node.js...I'm not the one that will go that route:)

If someone else were to port FileDirectory or FS to Amber/Node.js then we'd be getting somewhere, but that's just the start ...

Personally, I will be leaning towards using a Smalltalk-based server, so I can use Smalltalk on both ends.

Dale

----- Original Message -----
| From: "Göran Krampe" <[hidden email]>
| To: [hidden email]
| Sent: Thursday, May 31, 2012 1:02:55 PM
| Subject: Re: [amber-lang] Pushing Amber
|
| On 05/30/2012 05:56 PM, Herby Vojčík wrote:
| > [hidden email] wrote:
| >> Herby Vojčík<[hidden email]> writes:
| >>>> Now pull requests are great, but I think we could improve the
| >>>> dev
| >>>> process.
| >>> I don't know. Node.js works fine with github repo, fork and
| >>> pullreqs. Though I don't know the inner rules for those who have
| >>> commit rights...
| >>
| >> That's only me and Göran IIRC.
| >
| > I meant in nodejs case... there are more people there, I was only
| > contributing in fork/pullreq manner and it worked... they are doing
| > it
| > still this way, but there are more commiters and they have github
| > organization created, they are not under personal account.
|
| Personally I favor "speed" instead of "strictness" when it comes to
| development - so picking people we trust and give them a good ole
| fashion commit bit is a good way forward I think.
|
| And hey, git is an SCM right ;)? We can always undo stuff :)
|
| Regarding packages, I am not sure when I will be able to squeeze in
| more
| time in the near future so if ANYONE is interested in improving that
| area, feel free to speak up and I can explain what we have so far.
|
| I just laid the "floor" for the fun stuff, in other words - I created
| the concept of "package" instead of class categories, reified them on
| a
| core level deep inside boot.js so we *really* have them, added some
| Amber side code for reflecting on them, and then I added support in
| both
| st and js formats to serialize simple metadata together with the
| package
| (early in file so we can only parse that out first).
|
| The idea being of course to put dependency information and more into
| that metadata - and then be able to do dependency resolv etc.
|
| Perhaps Dale gets tickled? Feel free to grab hold of it then :)
|
| regards, Göran
|

I personally would prefer sweetness over nerdness.

Very well said, Sebastian!

On 01. 06. 2012 22:22, Sebastian Sastre wrote:
> I personally would prefer sweetness over nerdness.
>
> What I mean is that I prefer not having any too technical fancyness over
> a great development experience that leads to a more qualified creativity
> process powered by amber.
>
> People hate IE for many reasons (that are ridiculously nerdy) and, in
> the other hand,love the WebKit tool for a reason. And I think amber has
> the chance to provide an even better experience for developing software
> than WebKit.
>
> But if we jump into specializations and complications that too few
> people know about too soon, and maintain our attention out of this idea
> about rewarding creativity, I'm afraid that it will lead us into a path
> of compartmentalization instead of a sweet creative process which would
> be ironic because smalltalk was originally conceived to reward the
> creative spirit.
>
> Now to illustrate my point in a practical way:
> I totally can live without pragmas and traits, etc but having a little
> redesigned IDE and a stepping debugger will skyrocket productivity and
> what happens when you skyrocket productivity? you can do more apps for
> more clients. And what happens when you can do more apps for more
> clients? quantity lead you to quality so you end up working better and
> with even better chances of doing great work.
>
> my 2 cents
>
> sebastian
>
>
> Em quarta-feira, 30 de maio de 2012 11h47min23s UTC-3, nicolas petton
> escreveu:
>
>
>     Hi guys!
>
>     I would really like to push Amber more. We have quite some interesting
>     stuff. Here's some ideas/ongoing stuff
>
>     - new imperative compiler from Herby (I have a new compiler toolchain
>       inspired by Opal that reuses his ideas, I have to finish and
>     commit it)
>     - New website from John
>     - Better packages (with doc) from Göran?
>     - More doc
>     - Better IDE using Glamour?
>     - Coral integration? (I'm tired of the chunk format, and Pharo will use
>       Coral in the future)
>     - Better client/server communication (I'd love to have a really good
>       Pharo/Amber communication, and for example be able to browse Amber
>       from Pharo w/ Nautilus)
>     - Traits?
>     - Pragmas?
>     - other things...?
>
>     Now pull requests are great, but I think we could improve the dev
>     process.
>
>     So would some of you like to join the effort and help making
>     Amber better? Any suggestion about a better dev process?
>
>     Cheers,
>     Nico
>
-- Janko Mivšek Aida/Web Smalltalk Web Application Server http://www.aidaweb.s