Splitting boot.js
Locked
 
|
Hello,
I tried to split boot.js which is kinda monolithic into parts, aiming not only at splitting but also at allowing experiments like running amber without some of its kernel parts. IMO this should leads to cleaner design of core parts. Maybe it also end up readable, nicely splitted to well-defined chunks. The outcome is the micro system of reassemblable objects (https://github.com/herby/brikz) and using it, I was able to split boot.js to 13+1 moving parts (13 are truly external parts, the one is a few fundamentals that I wasn't able to actually stick as a moving part but they must be there before anything (just dummy constuctors SmalltalkObject and Smalltalk and inherits function connecting them). I also managed to run only subset of parts (with the three runtime parts) during loading, and only during init I added the three runtime parts and wsa able to start amber finely. It also showed there is one super-dependent part that have seven other dependencies (methods adding/removing). It could be nice if it could be redesigned not to be such demanding. If you're interested, see https://github.com/herby/amber/tree/decoupling-bootjs. 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. |
|
|
Herby
This is interesting. Where do I find these 13 parts of boot.js? https://github.com/herby/amber/tree/decoupling-bootjs/js ?? --Hannes On 7/24/13, Herby Vojčík <[hidden email]> wrote: > Hello, > > I tried to split boot.js which is kinda monolithic into parts, aiming > not only at splitting but also at allowing experiments like running > amber without some of its kernel parts. IMO this should leads to cleaner > design of core parts. > > Maybe it also end up readable, nicely splitted to well-defined chunks. > > The outcome is the micro system of reassemblable objects > (https://github.com/herby/brikz) and using it, I was able to split > boot.js to 13+1 moving parts (13 are truly external parts, the one is a > few fundamentals that I wasn't able to actually stick as a moving part > but they must be there before anything (just dummy constuctors > SmalltalkObject and Smalltalk and inherits function connecting them). > > I also managed to run only subset of parts (with the three runtime > parts) during loading, and only during init I added the three runtime > parts and wsa able to start amber finely. > > It also showed there is one super-dependent part that have seven other > dependencies (methods adding/removing). It could be nice if it could be > redesigned not to be such demanding. > > If you're interested, see > https://github.com/herby/amber/tree/decoupling-bootjs. > > 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. > > > -- 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. |
|
|
Inside the file. It is conceptual splitting. Every class ending with 'Brik' is one part. They are assembled in the bottom.
H. Hirzel wrote: > Herby > > This is interesting. > Where do I find these 13 parts of boot.js? > > https://github.com/herby/amber/tree/decoupling-bootjs/js ?? > > --Hannes > > On 7/24/13, Herby Vojčík<[hidden email]> wrote: >> Hello, >> >> I tried to split boot.js which is kinda monolithic into parts, aiming >> not only at splitting but also at allowing experiments like running >> amber without some of its kernel parts. IMO this should leads to cleaner >> design of core parts. >> >> Maybe it also end up readable, nicely splitted to well-defined chunks. >> >> The outcome is the micro system of reassemblable objects >> (https://github.com/herby/brikz) and using it, I was able to split >> boot.js to 13+1 moving parts (13 are truly external parts, the one is a >> few fundamentals that I wasn't able to actually stick as a moving part >> but they must be >> SmalltalkObject and Smalltalk and inherits function connecting them). >> >> I also managed to run only subset of parts (with the three runtime >> parts) during loading, and only during init I added the three runtime >> parts and wsa able to start amber finely. >> >> It also showed there is one super-dependent part that have seven other >> dependencies (methods adding/removing). It could be nice if it could be >> redesigned not to be such demanding. >> >> If you're interested, see >> https://github.com/herby/amber/tree/decoupling-bootjs. >> >> 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. >> >> >> > -- 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. |
|
|
>>> I also managed to run only subset of parts (with the three runtime
>>> parts) during loading, and only during init I added the three runtime erratum: "with the three runtime parts omitted" -- 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. |
|
|
In reply to this post by Herby Vojčík
On 7/25/13, Herby Vojčík <[hidden email]> wrote:
> Inside the file. It is conceptual splitting. Every class ending with 'Brik' > is one part. They are assembled in the bottom. > Thank you https://github.com/herby/amber/blob/decoupling-bootjs/js/boot.js I think I think this is the skeleton /* line 0001 */ (function () { /* Reconfigurable micro composition system, https://github.com/herby/brikz */ function Brikz(api, apiKey, initKey) { var brikz = this, backup = {}; apiKey = apiKey || 'exports'; initKey = initKey || '__init__'; /* .......*/ /* line 1046 */ /* Making smalltalk that can load */ brikz.root = RootBrik; brikz.dnu = DNUBrik; brikz.organize = OrganizeBrik; brikz.selectorConversion = SelectorConversionBrik; brikz.classInit = ClassInitBrik; brikz.manipulation = ManipulationBrik; brikz.classes = ClassesBrik; brikz.methods = MethodsBrik; brikz.stInit = SmalltalkInitBrik; brikz.augments = AugmentsBrik; brikz.rebuild(); /* Making smalltalk that can run */ function runnable () { brikz.messageSend = MessageSendBrik; brikz.runtime = RuntimeBrik; brikz.primitives = PrimitivesBrik; brikz.rebuild(); }; global_smalltalk = api; global_nil = brikz.root.nil; global__st = api._st; api._st = null; })(); -- 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. |
|
|
H. Hirzel wrote: > On 7/25/13, Herby Vojčík<[hidden email]> wrote: >> Inside the file. It is conceptual splitting. Every class ending with 'Brik' >> is one part. They are assembled in the bottom. >> > > Thank you > https://github.com/herby/amber/blob/decoupling-bootjs/js/boot.js > > I think I think this is the skeleton > > > /* line 0001 */ > > (function () { > > /* Reconfigurable micro composition system, https://github.com/herby/brikz */ > > function Brikz(api, apiKey, initKey) { > var brikz = this, backup = {}; > apiKey = apiKey || 'exports'; > initKey = initKey || '__init__'; > > > /* .......*/ > > > > > /* line 1046 */ > > /* Making smalltalk that can load */ > > brikz.root = RootBrik; > brikz.dnu = DNUBrik; > brikz.organize = OrganizeBrik; > brikz.selectorConversion = SelectorConversionBrik; > brikz.classInit = ClassInitBrik; > brikz.manipulation = ManipulationBrik; > brikz.classes = ClassesBrik; > brikz.methods = MethodsBrik; > brikz.stInit = SmalltalkInitBrik; > brikz.augments = AugmentsBrik; > > brikz.rebuild(); > > /* Making smalltalk that can run */ > > function runnable () { > brikz.messageSend = MessageSendBrik; > brikz.runtime = RuntimeBrik; > brikz.primitives = PrimitivesBrik; > > brikz.rebuild(); > }; > > global_smalltalk = api; > global_nil = brikz.root.nil; > global__st = api._st; > api._st = null; > > })(); > > > -- Hannes Exactly, And the "+1" I mentioned are a few lines between Brikz function and first *Brik. There are two hacks (or roghe edges, as you call it) - _st should be in RuntimeBrik but it is unfortunaltely needed while loading where it is early-bound in package .js files, though not used until smalltalk code is run; and runnable is called directly in SmalltalkInitBrik which does not make it truly decoupled, but the code could be potentially changed so it is called indirectly (eg. 'st.kickoff();') and injected (eg. 'api.kickoff=function(){...};'). -- 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. |
|
|
How does the Brikz mechanism in boot.js (in the 'support' directory)
relate to the require.js module loader? It seems that Brikz is a composition mechanism within a require.js AMD module. Right? --Hannes On 7/25/13, Herby Vojčík <[hidden email]> wrote: > > > H. Hirzel wrote: >> On 7/25/13, Herby Vojčík<[hidden email]> wrote: >>> Inside the file. It is conceptual splitting. Every class ending with >>> 'Brik' >>> is one part. They are assembled in the bottom. >>> >> >> Thank you >> https://github.com/herby/amber/blob/decoupling-bootjs/js/boot.js >> >> I think I think this is the skeleton >> >> >> /* line 0001 */ >> >> (function () { >> >> /* Reconfigurable micro composition system, https://github.com/herby/brikz >> */ >> >> function Brikz(api, apiKey, initKey) { >> var brikz = this, backup = {}; >> apiKey = apiKey || 'exports'; >> initKey = initKey || '__init__'; >> >> >> /* .......*/ >> >> >> >> >> /* line 1046 */ >> >> /* Making smalltalk that can load */ >> >> brikz.root = RootBrik; >> brikz.dnu = DNUBrik; >> brikz.organize = OrganizeBrik; >> brikz.selectorConversion = SelectorConversionBrik; >> brikz.classInit = ClassInitBrik; >> brikz.manipulation = ManipulationBrik; >> brikz.classes = ClassesBrik; >> brikz.methods = MethodsBrik; >> brikz.stInit = SmalltalkInitBrik; > >> brikz.augments = AugmentsBrik; >> >> brikz.rebuild(); >> >> /* Making smalltalk that can run */ >> >> function runnable () { >> brikz.messageSend = MessageSendBrik; >> brikz.runtime = RuntimeBrik; >> brikz.primitives = PrimitivesBrik; >> >> brikz.rebuild(); >> }; >> >> global_smalltalk = api; >> global_nil = brikz.root.nil; >> global__st = api._st; >> api._st = null; >> >> })(); >> >> >> -- Hannes > > > Exactly, And the "+1" I mentioned are a few lines between Brikz function and > first *Brik. > > There are two hacks (or roghe edges, as you call it) - _st should be in > RuntimeBrik but it is unfortunaltely needed while loading where it is > early-bound in package .js files, though not used until smalltalk code is > run; and runnable is called directly in SmalltalkInitBrik which does not > make it truly decoupled, but the code could be potentially changed so it is > called indirectly (eg. 'st.kickoff();') and injected (eg. > 'api.kickoff=function(){...};'). > > -- > 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. |
|
|
they are independent
H. Hirzel wrote: > How does the Brikz mechanism in boot.js (in the 'support' directory) > relate to the require.js module loader? It seems that Brikz is a > composition mechanism within a require.js AMD module. > > Right? > > --Hannes > > On 7/25/13, Herby Vojčík<[hidden email]> wrote: >> >> H. Hirzel wrote: >>> On 7/25/13, Herby Vojčík<[hidden email]> wrote: >>>> Inside the file. It is conceptual splitting. Every class ending with >>>> 'Brik' >>>> is one part. They are assembled in the bottom. >>>> >>> Thank you >>> https://github.com/herby/amber/blob/decoupling-bootjs/js/boot.js >>> >>> I think I think this is the skeleton >>> >>> >>> /* line 0001 */ >>> >>> (function () { >>> >>> /* Reconfigurable micro composition system, https://github.com/herby/brikz >>> */ >>> >>> function Brikz(api, apiKey, initKey) { >>> var brikz = this, backup = {}; >>> apiKey = apiKey || 'exports'; >>> initKey = initKey || '__init__'; >>> >>> >>> /* .......*/ >>> > >> >>> >>> >>> /* line 1046 */ >>> >>> /* Making smalltalk that can load */ >>> >>> brikz.root = RootBrik; >>> brikz.dnu = DNUBrik; >>> brikz.organize = OrganizeBrik; >>> brikz.selectorConversion = SelectorConversionBrik; >>> brikz.classInit = ClassInitBrik; >>> brikz.manipulation = ManipulationBrik; >>> brikz.classes = ClassesBrik; >>> brikz.methods = MethodsBrik; >>> brikz.stInit = SmalltalkInitBrik; >>> brikz.augments = AugmentsBrik; >>> >>> brikz.rebuild(); >>> >>> /* Making smalltalk that can run */ >>> >>> function runnable () { >>> brikz.messageSend = MessageSendBrik; >>> brikz.runtime = RuntimeBrik; >>> brikz.primitives = PrimitivesBrik; >>> >>> brikz.rebuild(); >>> }; >>> >>> global_smalltalk = api; >>> global_nil = brikz.root.nil; >>> global__st = api._st; >>> api._st = null; >>> >>> })(); >>> >>> >>> -- Hannes >> >> Exactly, And the "+1" I mentioned are a few lines between Brikz function and >> first *Brik. >> >> There are two hacks (or roghe edges, as you call it) >> RuntimeBrik but it is unfortunaltely needed while loading where it is >> early-bound in package .js files, though not used until smalltalk code is >> run; and runnable is called directly in SmalltalkInitBrik which does not >> make it truly decoupled, but the code could be potentially changed so it is >> called indirectly (eg. 'st.kickoff();') and injected (eg. >> 'api.kickoff=function(){...};'). >> >> -- >> 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. |
|
|
sure, but why didn't you use AMD modules to split boot.js.?
On 9/7/13, Herby Vojčík <[hidden email]> wrote: > they are independent > > H. Hirzel wrote: >> How does the Brikz mechanism in boot.js (in the 'support' directory) >> relate to the require.js module loader? It seems that Brikz is a >> composition mechanism within a require.js AMD module. >> >> Right? >> >> --Hannes >> >> On 7/25/13, Herby Vojčík<[hidden email]> wrote: >>> >>> H. Hirzel wrote: >>>> On 7/25/13, Herby Vojčík<[hidden email]> wrote: >>>>> Inside the file. It is conceptual splitting. Every class ending with >>>>> 'Brik' >>>>> is one part. They are assembled in the bottom. >>>>> >>>> Thank you >>>> https://github.com/herby/amber/blob/decoupling-bootjs/js/boot.js >>>> >>>> I think I think this is the skeleton >>>> >>>> >>>> /* line 0001 */ >>>> >>>> (function () { >>>> >>>> /* Reconfigurable micro composition system, >>>> https://github.com/herby/brikz >>>> */ >>>> >>>> function Brikz(api, apiKey, initKey) { >>>> var brikz = this, backup = {}; >>>> apiKey = apiKey || 'exports'; >>>> initKey = initKey || '__init__'; >>>> >>>> >>>> /* .......*/ >>>> >> >>> >>>> >>>> >>>> /* line 1046 */ >>>> >>>> /* Making smalltalk that can load */ >>>> >>>> brikz.root = RootBrik; >>>> brikz.dnu = DNUBrik; >>>> brikz.organize = OrganizeBrik; >>>> brikz.selectorConversion = SelectorConversionBrik; >>>> brikz.classInit = ClassInitBrik; >>>> brikz.manipulation = ManipulationBrik; >>>> brikz.classes = ClassesBrik; >>>> brikz.methods = MethodsBrik; >>>> brikz.stInit = SmalltalkInitBrik; >>>> brikz.augments = AugmentsBrik; >>>> >>>> brikz.rebuild(); >>>> >>>> /* Making smalltalk that can run */ >>>> >>>> function runnable () { >>>> brikz.messageSend = MessageSendBrik; >>>> brikz.runtime = RuntimeBrik; >>>> brikz.primitives = PrimitivesBrik; >>>> >>>> brikz.rebuild(); >>>> }; >>>> >>>> global_smalltalk = api; >>>> global_nil = brikz.root.nil; >>>> global__st = api._st; >>>> api._st = null; >>>> >>>> })(); >>>> >>>> >>>> -- Hannes >>> >>> Exactly, And the "+1" I mentioned are a few lines between Brikz function >>> and >>> first *Brik. >>> >>> There are two hacks (or roghe edges, as you call it) > - _st should be in >>> RuntimeBrik but it is unfortunaltely needed while loading where it is >>> early-bound in package .js files, though not used until smalltalk code >>> is >>> run; and runnable is called directly in SmalltalkInitBrik which does not >>> make it truly decoupled, but the code could be potentially changed so it >>> is >>> called indirectly (eg. 'st.kickoff();') and injected (eg. >>> 'api.kickoff=function(){...};'). >>> >>> -- >>> 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. |
|
|
Brikz are a bit different, main difference is it is _composition_ mechanism (as opposed to _module transporter and loader_ nature of AMD), that is, it composes an object out of parts in runtime, and is able to rebuild it (the same object) by removing some and adding new parts later.
H. Hirzel wrote: > sure, but why didn't you use AMD modules to split boot.js.? > > On 9/7/13, Herby Vojčík<[hidden email]> wrote: >> they are independent >> >> H. Hirzel wrote: >>> How does the Brikz mechanism in boot.js (in the 'support' directory) >>> relate to the require.js module loader? It seems that Brikz is a >>> composition mechanism within a require.js AMD module. >>> >>> Right? >>> >>> --Hannes >>> >>> On 7/25/13, Herby Vojčík<[hidden email]> wrote: >>>> H. Hirzel wrote: >>>>> On 7/25/13, Herby Vojčík<[hidden email]> wrote: >>>>>> Inside the file. It is conceptual splitting. Every class ending with >>>>>> 'Brik' >>>>>> is one part. They are assembled in the bottom. >> >>>> >>>>> Thank you >>>>> https://github.com/herby/amber/blob/decoupling-bootjs/js/boot.js >>>>> >>>>> I think I think this is the skeleton >>>>> >>>>> >>>>> /* line 0001 */ >>>>> >>>>> (function () { >>>>> >>>>> /* Reconfigurable micro composition system, >>>>> https://github.com/herby/brikz >>>>> */ >>>>> >>>>> function Brikz(api, apiKey, initKey) { >>>>> var brikz = this, backup = {}; >>>>> apiKey = apiKey || 'exports'; >>>>> initKey = initKey || '__init__'; >>>>> >>>>> >>>>> /* .......*/ >>>>> >>>>> >>>>> /* line 1046 */ >>>>> >>>>> /* Making smalltalk that can load */ >>>>> >>>>> brikz.root = RootBrik; >>>>> brikz.dnu = DNUBrik; >>>>> brikz.organize = OrganizeBrik; >>>>> brikz.selectorConversion = SelectorConversionBrik; >>>>> brikz.classInit = ClassInitBrik; >>>>> brikz.manipulation = ManipulationBrik; >>>>> brikz.classes = ClassesBrik; >>>>> brikz.methods = MethodsBrik; >>>>> brikz.stInit = SmalltalkInitBrik; >>>>> brikz.augments = AugmentsBrik; >>>>> >>>>> brikz.rebu >>>>> >>>>> /* Making smalltalk that can run */ >>>>> >>>>> function runnable () { >>>>> brikz.messageSend = MessageSendBrik; >>>>> brikz.runtime = RuntimeBrik; >>>>> brikz.primitives = PrimitivesBrik; >>>>> >>>>> brikz.rebuild(); >>>>> }; >>>>> >>>>> global_smalltalk = api; >>>>> global_nil = brikz.root.nil; >>>>> global__st = api._st; >>>>> api._st = null; >>>>> >>>>> })(); >>>>> >>>>> >>>>> -- Hannes >>>> Exactly, And the "+1" I mentioned are a few lines between Brikz function >>>> and >>>> first *Brik. >>>> >>>> There are two hacks (or roghe edges, as you call it) >> - _st should be in >>>> RuntimeBrik but it is unfortunaltely needed while loading where it is >>>> early-bound in package .js files, though not used until smalltalk code >>>> is >>>> run; and runnable is called directly in SmalltalkInitBrik which does not >>>> make it truly decoupled, but the code could be potentially changed so it >>>> is >>>> called indirectly (eg. 'st.kickoff();') and injected (eg >>>> 'api.kickoff=function(){...};'). >>>> >>>> -- >>>> 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. |
|
|
I understand. Brickz is about configuring an object at run time. Is
there some documentation about the pattern used? I understand that brickz are unloaded after they have been used in the boot process. On 9/7/13, Herby Vojčík <[hidden email]> wrote: > Brikz are a bit different, main difference is it is _composition_ mechanism > (as opposed to _module transporter and loader_ nature of AMD), that is, it > composes an object out of parts in runtime, and is able to rebuild it (the > same object) by removing some and adding new parts later. > > H. Hirzel wrote: >> sure, but why didn't you use AMD modules to split boot.js.? >> >> On 9/7/13, Herby Vojčík<[hidden email]> wrote: >>> they are independent >>> >>> H. Hirzel wrote: >>>> How does the Brikz mechanism in boot.js (in the 'support' directory) >>>> relate to the require.js module loader? It seems that Brikz is a >>>> composition mechanism within a require.js AMD module. >>>> >>>> Right? >>>> >>>> --Hannes >>>> >>>> On 7/25/13, Herby Vojčík<[hidden email]> wrote: >>>>> H. Hirzel wrote: >>>>>> On 7/25/13, Herby Vojčík<[hidden email]> wrote: >>>>>>> Inside the file. It is conceptual splitting. Every class ending with >>>>>>> 'Brik' >>>>>>> is one part. They are assembled in the bottom. >>> >>>>> >>>>>> Thank you >>>>>> https://github.com/herby/amber/blob/decoupling-bootjs/js/boot.js >>>>>> >>>>>> I think I think this is the skeleton >>>>>> >>>>>> >>>>>> /* line 0001 */ >>>>>> >>>>>> (function () { >>>>>> >>>>>> /* Reconfigurable micro composition system, >>>>>> https://github.com/herby/brikz >>>>>> */ >>>>>> >>>>>> function Brikz(api, apiKey, initKey) { >>>>>> var brikz = this, backup = {}; >>>>>> apiKey = apiKey || 'exports'; >>>>>> initKey = initKey || '__init__'; >>>>>> >>>>>> >>>>>> /* .......*/ >>>>>> >>>>>> >>>>>> /* line 1046 */ >>>>>> >>>>>> /* Making smalltalk that can load */ >>>>>> >>>>>> brikz.root = RootBrik; >>>>>> brikz.dnu = DNUBrik; >>>>>> brikz.organize = OrganizeBrik; >>>>>> brikz.selectorConversion = SelectorConversionBrik; >>>>>> brikz.classInit = ClassInitBrik; >>>>>> brikz.manipulation = ManipulationBrik; >>>>>> brikz.classes = ClassesBrik; >>>>>> brikz.methods = MethodsBrik; >>>>>> brikz.stInit = SmalltalkInitBrik; >>>>>> brikz.augments = AugmentsBrik; >>>>>> >>>>>> brikz.rebu > ild(); >>>>>> >>>>>> /* Making smalltalk that can run */ >>>>>> >>>>>> function runnable () { >>>>>> brikz.messageSend = MessageSendBrik; >>>>>> brikz.runtime = RuntimeBrik; >>>>>> brikz.primitives = PrimitivesBrik; >>>>>> >>>>>> brikz.rebuild(); >>>>>> }; >>>>>> >>>>>> global_smalltalk = api; >>>>>> global_nil = brikz.root.nil; >>>>>> global__st = api._st; >>>>>> api._st = null; >>>>>> >>>>>> })(); >>>>>> >>>>>> >>>>>> -- Hannes >>>>> Exactly, And the "+1" I mentioned are a few lines between Brikz >>>>> function >>>>> and >>>>> first *Brik. >>>>> >>>>> There are two hacks (or roghe edges, as you call it) >>> - _st should be in >>>>> RuntimeBrik but it is unfortunaltely needed while loading where it is >>>>> early-bound in package .js files, though not used until smalltalk code >>>>> is >>>>> run; and runnable is called directly in SmalltalkInitBrik which does >>>>> not >>>>> make it truly decoupled, but the code could be potentially changed so >>>>> it >>>>> is >>>>> called indirectly (eg. 'st.kickoff();') and injected (eg > . >>>>> 'api.kickoff=function(){...};'). >>>>> >>>>> -- >>>>> 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. > -- 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. |
|
|
H. Hirzel wrote: > I understand. Brickz is about configuring an object at run time. Is > there some documentation about the pattern used? I understand that > brickz are unloaded after they have been used in the boot process. No, they are not. Look at the end of boot.js, there you see smalltalk object is built out of briks neede for loading, then it is returned as such, and only in process of initializing `runnable` function is called which reconfigures it by adding runtime so that it can actually run code. Brikz is still alive, just not accessible directly. (You can experiment to create "non-modifying" amber that can run code finely, just is unable to add methods by rebuilding it without methods brik, for example) -- 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 |