Short term schedule?

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

Short term schedule?

Nicolas Petton
Hi guys,

I propose a short term schedule for Amber:

- Keep the semantic as it is for now ( = no new pseudo variable for JS) *but* keep it in mind and open for discussion
  (I propose this because I'm still unsure about it :-) )

- Include the ImpCompiler from Herbert as soon as it will be ready, and keep the current compiler as the default one, at least for the time being

- Improve the current compiler with the previously mentioned issues (I'm especially interested in variables scope, JS var name clashes and such things)

- Improve the website (Got some news about it John?)

- Move to ES5 with and possibly include a shim lib.

- Keep pushing, fixing issues, adding tests and doc

- release!!

Nico
Reply | Threaded
Open this post in threaded view
|

Re: Short term schedule?

laurent laffont
What do you think about timeboxing ? I mean releasing every 4 months for example ?

Laurent

On Wed, May 9, 2012 at 11:57 PM, nicolas petton <[hidden email]> wrote:
Hi guys,

I propose a short term schedule for Amber:

- Keep the semantic as it is for now ( = no new pseudo variable for JS) *but* keep it in mind and open for discussion
  (I propose this because I'm still unsure about it :-) )

- Include the ImpCompiler from Herbert as soon as it will be ready, and keep the current compiler as the default one, at least for the time being

- Improve the current compiler with the previously mentioned issues (I'm especially interested in variables scope, JS var name clashes and such things)

- Improve the website (Got some news about it John?)

- Move to ES5 with and possibly include a shim lib.

- Keep pushing, fixing issues, adding tests and doc

- release!!

Nico

Reply | Threaded
Open this post in threaded view
|

Re: Short term schedule?

gokr
Hi all!

I am all for Nicolas list - keeping the issue tracker clean is a good
priority, but I think at two "infrastructural" things would be nice to
get some movement on:

1. Make deployment "trivial". Right now it is fairly trivial to get
started with Amber I would say, with the one-click and all. But
deployment still takes a few steps... For example, wouldn't it be way
cool if one could press a button in the IDE and it would just put
together a zip that gets downloaded with *all* inside - you just unpack
it under Apache somewhere and bam, done.

2. Move forward with the package model. When I worked on that I got so
far as having proper Package class and ability to keep and save meta
data in them etc. But a simple working dependency model is of course the
next step.

I have a huge list of other cool things, but the above two may be the
most "important". And well, improving the Debugger would also be way nice.

Time boxing, sure. Works for me, but I think Nicolas should decide.

regards, Göran
Reply | Threaded
Open this post in threaded view
|

Re: Short term schedule?

Herby Vojčík
In reply to this post by Nicolas Petton


nicolas petton wrote:

> Hi guys,
>
> I propose a short term schedule for Amber:
>
> - Keep the semantic as it is for now ( = no new pseudo variable for JS)
> *but* keep it in mind and open for discussion
>    (I propose this because I'm still unsure about it :-) )
>
> - Include the ImpCompiler from Herbert as soon as it will be ready, and
> keep the current compiler as the default one, at least for the time being

It's stalled on the nameclash issue further compicated by inline JS
element. If it would be possible to accept on of the proposals I have
posted yesterday (or day before) subject "Variable names / inline
JS:...", it would un-stall it.

Otherwise, it's more or less ready and I would like to put it to hard test.

One thing to this: I would like to have single point where the compiler
could be switched... one possibility is to rename existing compiler to
FunCompiler and create alias in boot.js - it is probably ok to have this
point static, switching code generating in runtime is probably not needed.

> - Improve the current compiler with the previously mentioned issues (I'm
> especially interested in variables scope, JS var name clashes and such
> things)
>
> - Improve the website (Got some news about it John?)
>
> - Move to ES5 with and possibly include a shim lib.
>
> - Keep pushing, fixing issues, adding tests and doc
>
> - release!!

1.0 or 0.9.2?

You did not mention restructuring st.send mechanism, so I presume you
see this as longer goal?

> Nico