Hello!
A. AFAICT, the requirejs branch is ready to use and contains all features with one exception I will cover later. B. No globals are defined at all: amber.js is defined in such a way that it just configures require.js (or any conforming loader) and you should load amber as well as your packages by using AMD loader directly. Like in this example: require.config({ config: { 'amber_vm/smalltalk': { defaultNamespace: 'amber' } } }); require( ["amber_vm/smalltalk", "amber_set/full-devel"], function (smalltalk) { smalltalk.initialize(); smalltalk.Browser._open() } ); First, you should tell amber which namespace it should add to newly created packages. If you are sure no new packages are going to be created (besides ones loaded), you could eschew the first call (well, not really, see two paragraphs below). The second call simply loads amber and well-known set of packages, you can add your own packages to the array. In a function, you must call initialize by hand, then any start code you want to happen. This is the price of not having the globals, so no "smart" wrapper that would know when to call initialize. If you load your own packages (that are in your own namespaces), you should put path mappings in the require.config call. Thus, it is almost inevitable that there will be one require.config call and then one require call with list of packages to load and code to run afterwards. This is more complicated then simple loadAmber(), but in practice, it was longer, you had to list packages at least anyway; and nothing more than these two calls is really needed. Also, keeping it on amd level is friendlier to different kind of embedding and mixing scenarios. C. There is still no general way (it wasn't there before, as well, just to mention, only the core was loaded from .deploy.js, the rest was always full .js) to use .deploy.js instead of .js. The partial solution (only remap core to .deploy.js) is possible by specific configuration of require.js. But because of no-globals (B. above) the remapping is not present as a function (it is in fact not present at all, because I don't know where to put it or whether to put it there at all now), it may be put in different file that can be loaded after amber.js (but it sort-of defeats the purpose of .deploy.js to be loaded asap). For me, the best solution would be not to care of .deploy.js at all, changing the way it is compiled so that it is put in different directory, and just mapping the right path at deploy time. 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. |
thanks Herby for the detailed email :)
I agree about .deploy.js, I would remove them completely and provide an app based deployment solution. I'll see if I can read everything in your branch before merging :) Nico On Aug 26, 2013, at 2:16 PM, Herby Vojčík <[hidden email]> wrote: > Hello! > > > A. > > AFAICT, the requirejs branch is ready to use and contains all features with one exception I will cover later. > > > B. > > No globals are defined at all: amber.js is defined in such a way that it just configures require.js (or any conforming loader) and you should load amber as well as your packages by using AMD loader directly. Like in this example: > > require.config({ > config: { > 'amber_vm/smalltalk': { > defaultNamespace: 'amber' > } > } > }); > require( > ["amber_vm/smalltalk", "amber_set/full-devel"], > function (smalltalk) { > smalltalk.initialize(); > > smalltalk.Browser._open() > } > ); > > First, you should tell amber which namespace it should add to newly created packages. If you are sure no new packages are going to be created (besides ones loaded), you could eschew the first call (well, not really, see two paragraphs below). > > The second call simply loads amber and well-known set of packages, you can add your own packages to the array. In a function, you must call initialize by hand, then any start code you want to happen. This is the price of not having the globals, so no "smart" wrapper that would know when to call initialize. > > If you load your own packages (that are in your own namespaces), you should put path mappings in the require.config call. Thus, it is almost inevitable that there will be one require.config call and then one require call with list of packages to load and code to run afterwards. > > This is more complicated then simple loadAmber(), but in practice, it was longer, you had to list packages at least anyway; and nothing more than these two calls is really needed. Also, keeping it on amd level is friendlier to different kind of embedding and mixing scenarios. > > > C. > > There is still no general way (it wasn't there before, as well, just to mention, only the core was loaded from .deploy.js, the rest was always full .js) to use .deploy.js instead of .js. The partial solution (only remap core to .deploy.js) is possible by specific configuration of require.js. But because of no-globals (B. above) the remapping is not present as a function (it is in fact not present at all, because I don't know where to put it or whether to put it there at all now), it may be put in different file that can be loaded after amber.js (but it sort-of defeats the purpose of .deploy.js to be loaded asap). For me, the best solution would be not to care of .deploy.js at all, changing the way it is compiled so that it is put in different directory, and just mapping the right path at deploy time. > > > 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. -- Nicolas Petton http://www.nicolas-petton.fr -- 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. |
Free forum by Nabble | Edit this page |