Am idea:How to tame bin/amberc.js
Locked
 
|
It is a monster lets break it into pieces and use testing to tame it. Some of you know I am off on hacking grunt/tests/grunt-amberc.js ( see: https://github.com/tomrake/amber/tree/amber-options-feature) the grunt interface for amberc. I am currently working on testing and while debugging my mind thinks of things.... ------------------------------ This is not a do it all now plan but a sketch of how I think we can build more confidence in the amberc compilation system. A roadmp:How I would restructure rebuild and test, the current Amber compiler. Make grunt the main execution model and deprecate the node version bin/amberc. Add a lot more testing. And test again. Current stucture of bin/amberc and grunt amberc: task and bin/amberc.js Essentially the grunt task grunt/tasks/grunt-amberc.js and bin/amberc are front ends that pass control to bin/amberc.js. This primarily is done by a configuration object, amber_dir and closure.jar. #1 Simpily the matter and make amber_dir and closure.jar defined with in the configuration object. #2 define a normalized specification for the configuration object. This will add isolation and allow test points for the front-ends. #3 break amberc.js into distinct passes and parts. Define specs and test points to test various pieces. We already have the "front-end" and the Importer/Exporter and the parser. The Concatenator and the closure piece could to be separated as well. #4 Test early and often - we need to build code to test the various pieces of the compiler so we can code a little more freely and sleep at night. #5 Consider rewritting the pieces in amber, once we have clear divisions and methods to test. 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/groups/opt_out. |
Re: Am idea:How to tame bin/amberc.js
|
|
On 9/12/13, Thomas Rake <[hidden email]> wrote:
> It is a monster lets break it into pieces and use testing to tame it. > > Some of you know I am off on hacking grunt/tests/grunt-amberc.js ( see: > https://github.com/tomrake/amber/tree/amber-options-feature) the grunt > interface for amberc. I am currently working on testing and while debugging > > my mind thinks of things.... > ------------------------------ > This is not a do it all now plan but a sketch of how I think we can build > more confidence in the amberc compilation system. > > A roadmp:How I would restructure rebuild and test, the current Amber > compiler. > > Make grunt the main execution model and deprecate the node version > bin/amberc. Add a lot more testing. And test again. > > Current stucture of bin/amberc and grunt amberc: task and bin/amberc.js > > Essentially the grunt task grunt/tasks/grunt-amberc.js and bin/amberc are > front ends that pass control to bin/amberc.js. This primarily is done by a > configuration object, amber_dir and closure.jar. > > #1 Simpily the matter and make amber_dir and closure.jar defined with in > the configuration object. > > #2 define a normalized specification for the configuration object. This > will add isolation and allow test points for the front-ends. > > #3 break amberc.js into distinct passes and parts. Define specs and test > points to test various pieces. We already have the "front-end" and the > Importer/Exporter and the parser. The Concatenator and the closure piece > could to be separated as well. > > #4 Test early and often - we need to build code to test the various pieces > of the compiler so we can code a little more freely and sleep at night. > > #5 Consider rewritting the pieces in amber, once we have clear divisions > and methods to test. Tom, You did not mention anything yet about unifying the approach how Windows and Unix deal with the compiler. I do not see yet how they relate. We have a node script https://github.com/tomrake/amber/blob/amber-options-feature/bin/amberc #!/usr/bin/env node var path = require('path'); var amberc = require('./amberc.js'); ....... (197 lines) Does amber.bat still work? https://github.com/tomrake/amber/blob/amber-options-feature/bin/amber.bat It just has one line in it which calls the amber-cli. @node "%~dp0\amber-cli.js" %* May I ask you to shed some light on this as well? --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/groups/opt_out. |
Re: Am idea:How to tame bin/amberc.js
|
|
Thomas
May I ask you to add here https://github.com/amber-smalltalk/amber/wiki/Roadmap what grunt does as of now or what it is supposed to do in the 0.12 release? --Hannes On 9/13/13, H. Hirzel <[hidden email]> wrote: > On 9/12/13, Thomas Rake <[hidden email]> wrote: >> It is a monster lets break it into pieces and use testing to tame it. >> >> Some of you know I am off on hacking grunt/tests/grunt-amberc.js ( see: >> https://github.com/tomrake/amber/tree/amber-options-feature) the grunt >> interface for amberc. I am currently working on testing and while >> debugging >> >> my mind thinks of things.... >> ------------------------------ >> This is not a do it all now plan but a sketch of how I think we can build >> more confidence in the amberc compilation system. >> >> A roadmp:How I would restructure rebuild and test, the current Amber >> compiler. >> >> Make grunt the main execution model and deprecate the node version >> bin/amberc. Add a lot more testing. And test again. >> >> Current stucture of bin/amberc and grunt amberc: task and bin/amberc.js >> >> Essentially the grunt task grunt/tasks/grunt-amberc.js and bin/amberc are >> front ends that pass control to bin/amberc.js. This primarily is done by >> a >> configuration object, amber_dir and closure.jar. >> >> #1 Simpily the matter and make amber_dir and closure.jar defined with in >> the configuration object. >> >> #2 define a normalized specification for the configuration object. This >> will add isolation and allow test points for the front-ends. >> >> #3 break amberc.js into distinct passes and parts. Define specs and test >> points to test various pieces. We already have the "front-end" and the >> Importer/Exporter and the parser. The Concatenator and the closure piece >> could to be separated as well. >> >> #4 Test early and often - we need to build code to test the various >> pieces >> of the compiler so we can code a little more freely and sleep at night. >> >> #5 Consider rewritting the pieces in amber, once we have clear divisions >> and methods to test. > > Tom, > > You did not mention anything yet about unifying the approach how > Windows and Unix deal with the compiler. I do not see yet how they > relate. > > We have a node script > > https://github.com/tomrake/amber/blob/amber-options-feature/bin/amberc > #!/usr/bin/env node > var path = require('path'); > var amberc = require('./amberc.js'); > ....... > (197 lines) > > > Does amber.bat still work? > > > https://github.com/tomrake/amber/blob/amber-options-feature/bin/amber.bat > > It just has one line in it which calls the amber-cli. > > @node "%~dp0\amber-cli.js" %* > > > May I ask you to shed some light on this as well? > > --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/groups/opt_out. |
Re: Am idea:How to tame bin/amberc.js
|
|
Hello Hannes, Since I changed Amber to use a Grunt based build system I will add this information. Best, Am 13.09.2013 06:45 schrieb "H. Hirzel" <[hidden email]>:
-- Thomas 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/groups/opt_out. |
Re: Am idea:How to tame bin/amberc.js
|
|
In reply to this post by Hannes Hirzel
Hello Hannes, There is no difference in how the compiler is handled on different operating systems. In case of the scripts you mixed something up. The amberc script is a front-end to the Amber compiler for usage on the command-line. The amber and amber.bat scripts are something different. The grunt task is there as a replacement for the old Makefile based build system so you don't have to remember all the compiler flags. Making the switch to grunt was a direct step after rewriting the old shell script based command-line compiler using Node.js. Hope this helps, Am 13.09.2013 06:04 schrieb "H. Hirzel" <[hidden email]>:
-- On 9/12/13, Thomas Rake <[hidden email]> wrote: 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/groups/opt_out. |
Re: Am idea:How to tame bin/amberc.js
|
|
Hello Manfred
Thank you for the clarification. Let me rehearse and summarize what I need to know from a user point of view about the content of the amber\bin directory. Amber IDE server and REPL ----------------------------------------- amber shell script which calls node with the amber command line interface version: amber-cli.js usage: amber serve amber repl amber.bat the same for MSWindows Amber command line compiler -------------------------------------------- amberc amber compiler script for node to run under Unix, calls amberc.js amberc.bat one-liner for MSWindows which calls node and amberc Correct? --Hannes P.S. I see that the outcome of version 0.9?, 0.10?, 0.11? (which one) was the the amber compiler no longer uses a shell script but only node.js. Among other things, this facilitates amber development on Microsoft Windows. On 9/13/13, Manfred Kröhnert <[hidden email]> wrote: > Hello Hannes, > > There is no difference in how the compiler is handled on different > operating systems. > > In case of the scripts you mixed something up. > > The amberc script is a front-end to the Amber compiler for usage on the > command-line. > A Windows amberc.bat script is provided for convenience so you don't have > to call Node.js directly. > > The amber and amber.bat scripts are something different. > They combines the development server and the Amber Cli in one tool for > command-line usage. > > The grunt task is there as a replacement for the old Makefile based build > system so you don't have to remember all the compiler flags. > > Making the switch to grunt was a direct step after rewriting the old shell > script based command-line compiler using Node.js. > So far it is working well. > However, we are going to make some changes soon, to outsource some of its > complexity to existent grunt tasks. > Like this the compiler will be able to focus on its main task. > Compiling .st files into .js files and creating concatenated programs. > > Hope this helps, > Manfred > Am 13.09.2013 06:04 schrieb "H. Hirzel" <[hidden email]>: > >> On 9/12/13, Thomas Rake <[hidden email]> wrote: >> > It is a monster lets break it into pieces and use testing to tame it. >> > >> > Some of you know I am off on hacking grunt/tests/grunt-amberc.js ( see: >> > https://github.com/tomrake/amber/tree/amber-options-feature) the grunt >> > interface for amberc. I am currently working on testing and while >> debugging >> > >> > my mind thinks of things.... >> > ------------------------------ >> > This is not a do it all now plan but a sketch of how I think we can >> > build >> > more confidence in the amberc compilation system. >> > >> > A roadmp:How I would restructure rebuild and test, the current Amber >> > compiler. >> > >> > Make grunt the main execution model and deprecate the node version >> > bin/amberc. Add a lot more testing. And test again. >> > >> > Current stucture of bin/amberc and grunt amberc: task and bin/amberc.js >> > >> > Essentially the grunt task grunt/tasks/grunt-amberc.js and bin/amberc >> > are >> > front ends that pass control to bin/amberc.js. This primarily is done >> > by >> a >> > configuration object, amber_dir and closure.jar. >> > >> > #1 Simpily the matter and make amber_dir and closure.jar defined with >> > in >> > the configuration object. >> > >> > #2 define a normalized specification for the configuration object. This >> > will add isolation and allow test points for the front-ends. >> > >> > #3 break amberc.js into distinct passes and parts. Define specs and >> > test >> > points to test various pieces. We already have the "front-end" and the >> > Importer/Exporter and the parser. The Concatenator and the closure >> > piece >> > could to be separated as well. >> > >> > #4 Test early and often - we need to build code to test the various >> pieces >> > of the compiler so we can code a little more freely and sleep at night. >> > >> > #5 Consider rewritting the pieces in amber, once we have clear >> > divisions >> > and methods to test. >> >> Tom, >> >> You did not mention anything yet about unifying the approach how >> Windows and Unix deal with the compiler. I do not see yet how they >> relate. >> >> We have a node script >> >> >> https://github.com/tomrake/amber/blob/amber-options-feature/bin/amberc >> #!/usr/bin/env node >> var path = require('path'); >> var amberc = require('./amberc.js'); >> ....... >> (197 lines) >> >> >> Does amber.bat still work? >> >> >> https://github.com/tomrake/amber/blob/amber-options-feature/bin/amber.bat >> >> It just has one line in it which calls the amber-cli. >> >> @node "%~dp0\amber-cli.js" %* >> >> >> May I ask you to shed some light on this as well? >> >> --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/groups/opt_out. >> > > -- > 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/groups/opt_out. > -- 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/groups/opt_out. |
Re: Am idea:How to tame bin/amberc.js
|
|
H. Hirzel wrote: > Hello Manfred > > Thank you for the clarification. Let me rehearse and summarize what I > need to know from a user point of view about the content of the > amber\bin directory. > > > Amber IDE server and REPL > ----------------------------------------- > > amber shell script which calls node > with the amber command line interface version: amber-cli.js > usage: amber serve > amber repl > > amber.bat the same for MSWindows > > > > Amber command line compiler > -------------------------------------------- > > amberc amber compiler script for node to run under Unix, > calls amberc.js > > amberc.bat one-liner for MSWindows which calls node and amberc > > > Correct? I am sorry, but half of what you wrote is something you _don't_ need "to know from a user point of view". Only things you need is "use them, they do this: .... (and btw, you can do it in UNIX as well as Windows). All other things like "calls node ... amber-cli.js..." are _not_ user point of view. (slightly angry; motivated to kill bin directory completely and pushing users to install amber-cli package even if it only included these scripts (in fact npm can wrap node better in its own way), but installed by npm out of reach of users) Herby > --Hannes P.S.: Manfred, do you think the idea of minimal amber=cli module that would then take over more functionality over time is good idea? In particular, that it would really only wrap those two node programs (amber-cli.js and amberc) of external amber dependency and later takes more and more into its own wings? -- 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/groups/opt_out. |
Re: Am idea:How to tame bin/amberc.js
|
|
Hello Herby,
-- On Fri, Sep 13, 2013 at 11:46 AM, Herby Vojčík <[hidden email]> wrote:
Could you elaborate a tiny bit more about your idea? I think I don't completely get what your intention is. For now the amber script only wraps the AmberCli package.
What I think would be nice is to add here is the UnitTest runner, too. Adding other functionality once there is a need for it is definitely a good idea. However, I am not entirely sure if amberc should be aggregated into the same module.
Best, Manfred 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/groups/opt_out. |
Re: Am idea:How to tame bin/amberc.js
|
|
Manfred Kröhnert wrote: > Hello Herby, > > On Fri, Sep 13, 2013 at 11:46 AM, Herby Vojčík <[hidden email] > <mailto:[hidden email]>> wrote: > > > Herby > > P.S.: Manfred, do you think the idea of minimal amber=cli module > that would then take over more functionality over time is good idea? > In particular, that it would really only wrap those two node > programs (amber-cli.js and amberc) of external amber dependency and > later takes more and more into its own wings? > > > Could you elaborate a tiny bit more about your idea? > I think I don't completely get what your intention is. > > For now the amber script only wraps the AmberCli package. > What I think would be nice is to add here is the UnitTest runner, too. > Adding other functionality once there is a need for it is definitely a > good idea. They wrap amberc as well (at least for windows). So we have two node programs there (amberc, amber-cli.js). npm does nice work wrapping node programs itself (creates shell script as well as windows .cmd which both run the node script in their environment, if you add them to "bin" section of package.json, which I did). The bin directory contains some wrapper script (I say only they should be there, the thing that is wrapped should be elsewhere so no internal files are started). But such bin directory can be scraped completely in favour of npm wrapper scripts; so the suggestion is to start splitting of cli by creating very minimal amber-cli (or amber-sdk) project which have only one responsibility - to wrap amber node program, nothing else. Next steps can then decide that stays in amber and what moves to amber-cli/amber-sdk. > However, I am not entirely sure if amberc should be aggregated into the > same module. I say amberc definitely belongs to amber-cli/amber-sdk; same as cli for grunt is part of grunt-cli package, not grunt package. No amber developer would be able to live without (preferably globally) installed amber-cli/amber-sdk; same as any grunt user need globally installed grunt-cli (amber deployer, OTOH, can live without it and only use amber itself). > Best, > Manfred Herby -- 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/groups/opt_out. |
Re: Am idea:How to tame bin/amberc.js
|
|
Answers below.
-- On Sat, Sep 14, 2013 at 10:05 PM, Herby Vojčík <[hidden email]> wrote:
Okay, now I got it. Completely agree with not creating our wrapper scripts ourselves but letting npm handle this.
Okay, I thought you wanted to add amberc into the AmberCli class. Adding it to the dev tools is definitely the way to go. I was already thinking about something like that.
But we would need some logic similar to grunt-cli to detect either global or local installations of Amber (via npm) or a cloned Git repository. Maybe we can just have a look at how the grunt-cli does it
Best, Manfred 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/groups/opt_out. |
Re: Am idea:How to tame bin/amberc.js
|
|
On 9/16/13, Manfred Kröhnert <[hidden email]> wrote:
> Answers below. > > > On Sat, Sep 14, 2013 at 10:05 PM, Herby Vojčík <[hidden email]> wrote: > >> >> >> Manfred Kröhnert wrote: >> >>> Hello Herby, >>> >>> On Fri, Sep 13, 2013 at 11:46 AM, Herby Vojčík <[hidden email] >>> <mailto:[hidden email]>> wrote: >>> >>> >>> Herby >>> >>> P.S.: Manfred, do you think the idea of minimal amber=cli module >>> that would then take over more functionality over time is good idea? >>> In particular, that it would really only wrap those two node >>> programs (amber-cli.js and amberc) of external amber dependency and >>> later takes more and more into its own wings? >>> >>> >>> Could you elaborate a tiny bit more about your idea? >>> I think I don't completely get what your intention is. >>> >>> For now the amber script only wraps the AmberCli package. >>> What I think would be nice is to add here is the UnitTest runner, too. >>> Adding other functionality once there is a need for it is definitely a >>> good idea. >>> >> >> They wrap amberc as well (at least for windows). >> So we have two node programs there (amberc, amber-cli.js). >> npm does nice work wrapping node programs itself (creates shell script as >> well as windows .cmd which both run the node script in their environment, >> if you add them to "bin" section of package.json, which I did). >> >> The bin directory contains some wrapper script (I say only they should be >> there, the thing that is wrapped should be elsewhere so no internal files >> are started). But such bin directory can be scraped completely in favour >> of >> npm wrapper scripts; so the suggestion is to start splitting of cli by >> creating very minimal amber-cli (or amber-sdk) project which have only >> one >> responsibility - to wrap amber node program, nothing else. >> >> Next steps can then decide that stays in amber and what moves to >> amber-cli/amber-sdk. > > > Okay, now I got it. > Completely agree with not creating our wrapper scripts ourselves but > letting npm handle this. + 1 will simplify things as I then can call amber (node script) easily from different directories. > > >> >> However, I am not entirely sure if amberc should be aggregated into the >>> same module. >>> >> >> I say amberc definitely belongs to amber-cli/amber-sdk; same as cli for >> grunt is part of grunt-cli package, not grunt package. >> >> No amber developer would be able to live without (preferably globally) >> installed amber-cli/amber-sdk; same as any grunt user need globally >> installed grunt-cli (amber deployer, OTOH, can live without it and only >> use >> amber itself). >> > > Okay, I thought you wanted to add amberc into the AmberCli class. > Adding it to the dev tools is definitely the way to go. > > I was already thinking about something like that. > But we would need some logic similar to grunt-cli to detect either global > or local installations of Amber (via npm) or a cloned Git repository. > Maybe we can just have a look at how the grunt-cli does it > > > Best, > Manfred > > -- > 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/groups/opt_out. > -- 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/groups/opt_out. |
«
Return to Amber Smalltalk
|
1 view|%1 views
| Free forum by Nabble | Edit this page |