Making Amber play nice with Yarn.
Locked
Making Amber play nice with Yarn.
 
|
I have a very small amount of code but it was a result of a few minutes' tinkering not following the contribution guide, so I'll keep things brief here. I tried installing the CLI via Yarn instead of NPM, and ran into a problem caused by Amber searching for files based on the nested structure of NPM. Yarn uses a flatter directory tree. Thankfully, Node includes a way to figure out where a requireable package lives in require.resolve(). I was able to replace the logic in the amberc CLI with require.resolve() (though require.resolve('amber') fails, require.resolve('amber/package.json') works). Ran into trouble patching the Smalltalk code of Amber's CLI, however. It seems that the require there is slightly different and is actually a BlockClosure instead of a proxy to a JS object. Going to set up a full dev environment with Helios so I can hunt down require's definition, but does any of this sound familiar/interesting? Jacob. 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/d/optout. |
Re: Making Amber play nice with Yarn.
|
|
Looked a little. Perhaps it's just because I'm a Smalltalk noob, but I'm having trouble hunting down where require itself is defined/where global variables in general live. Is it just an intrinsic part of the image that is updated be redefining with inline JS? I can see the compiledSource is more readable than what's generated by an average BlockClosure.
On Tue, Jul 24, 2018, 05:42 Herbert Vojčík <[hidden email]> wrote: IIRC I used resolve, but maybe not in all places. 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/d/optout. |
Re: Making Amber play nice with Yarn.
|
|
Not getting your question paragraph. Not sure what are you asking
(globals, inline js, block closure). :-/ Maybe you look at it from wrong direction? Or just I am not at my full cognitive capacity today? CLI is actually done in Smalltalk. So tinkering with compiled js won't get you anywhere as it is produced from Smalltalk sources anyway in the end. If you search for 'npm'/'Npm' or 'package.json' in Helios search box, it will surely show you where those things are used in source. I actually don't know which part fails, but everything CLI does is there in the package, somewhere. Plus, if you know which method you tinkered with in .js (you should, selector as well as class are mentioned around it), you could just find that same method in Helios (and use all its power like look for senders etc. to be sure you know what you change). Herby Jacob MacDonald wrote on 24. 7. 2018 17:11: > Looked a little. Perhaps it's just because I'm a Smalltalk noob, but I'm > having trouble hunting down where require itself is defined/where global > variables in general live. Is it just an intrinsic part of the image > that is updated be redefining with inline JS? I can see the > compiledSource is more readable than what's generated by an average > BlockClosure. > > On Tue, Jul 24, 2018, 05:42 Herbert Vojčík <[hidden email] > <mailto:[hidden email]>> wrote: > > IIRC I used resolve, but maybe not in all places. > > CLI is written in smalltalk, so by all means do install full dev > environment and look into AmberCli package inside Helios. > > Herby > > Jacob MacDonald wrote on 24. 7. 2018 2:14: > > I have a very small amount of code but it was a result of a few > minutes' > > tinkering not following the contribution guide, so I'll keep things > > brief here. > > > > I tried installing the CLI via Yarn instead of NPM, and ran into a > > problem caused by Amber searching for files based on the nested > > structure of NPM. Yarn uses a flatter directory tree. Thankfully, > Node > > includes a way to figure out where a requireable package lives in > > require.resolve(). I was able to replace the logic in the amberc CLI > > with require.resolve() (though require.resolve('amber') fails, > > require.resolve('amber/package.json') works). Ran into trouble > patching > > the Smalltalk code of Amber's CLI, however. It seems that the > require > > there is slightly different and is actually a BlockClosure > instead of a > > proxy to a JS object. Going to set up a full dev environment with > Helios Ah, this. I may understand what is the problem here. Every JS function is ST BlockClosure and vice versa (it's hard mapping; there are more of them for String, Number etc.). As you can see in other pieces of AmberCli package, you just use it as block closure, so `require(foo, bar)` is `require value: foo value: bar`. > > so I can hunt down require's definition, but does any of this sound What is "require's definition"? > > familiar/interesting? > > > > Jacob. > > > > -- > > 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] > <mailto:amber-lang%[hidden email]> > > <mailto:[hidden email] > <mailto:amber-lang%[hidden email]>>. > > For more options, visit https://groups.google.com/d/optout. > -- 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/d/optout. |
Re: Making Amber play nice with Yarn.
|
|
Ah, that. Yes, that's when it get hairy, calling "static" API on JS
functions which became ST-wrapped objects so it's hard to use them as namespaces. :-( I'd go for `(require basicAt: #resolve) value: ...` (ugly, I know, #basicAt: should not be used regularly, it's low-level API); maybe less ugly alternative is `(JSObjectProxy on: require) resolve: ...` (though uses low-level JSObjectProxy directly, too); of course it can be defined in a method of its own so you can `self requireResolve: ...`; but I would look at how this is used in other places, I am sure something like that must already have been solved at least once in cli code... maybe look for 'require' or 'resolve' in Helios searchbox? And we use AMD loader (requirejs) so I am not sure if require is the node require (probably not) and so if it actually has resolve (but IIRC I tried to preserve resolve by monkeypatching somehow when node-based project is built). Herby Jacob MacDonald wrote on 24. 7. 2018 18:22: > Ah, I was indeed looking at things from the wrong direction. > Misunderstood the hard mapping from JS func to BlockClosure. Given that > it seems that I need to wrap require.resolve because BlockClosure has no > #resolve handler? > > On Tue, Jul 24, 2018, 11:12 Herbert Vojčík <[hidden email] > <mailto:[hidden email]>> wrote: > > Not getting your question paragraph. Not sure what are you asking > (globals, inline js, block closure). :-/ Maybe you look at it from > wrong > direction? Or just I am not at my full cognitive capacity today? > > CLI is actually done in Smalltalk. So tinkering with compiled js won't > get you anywhere as it is produced from Smalltalk sources anyway in > the end. > > If you search for 'npm'/'Npm' or 'package.json' in Helios search > box, it > will surely show you where those things are used in source. I actually > don't know which part fails, but everything CLI does is there in the > package, somewhere. Plus, if you know which method you tinkered with in > .js (you should, selector as well as class are mentioned around it), > you > could just find that same method in Helios (and use all its power like > look for senders etc. to be sure you know what you change). > > Herby > > Jacob MacDonald wrote on 24. 7. 2018 17:11: > > Looked a little. Perhaps it's just because I'm a Smalltalk noob, > but I'm > > having trouble hunting down where require itself is defined/where > global > > variables in general live. Is it just an intrinsic part of the image > > that is updated be redefining with inline JS? I can see the > > compiledSource is more readable than what's generated by an average > > BlockClosure. > > > On Tue, Jul 24, 2018, 05:42 Herbert Vojčík <[hidden email] > <mailto:[hidden email]> > > <mailto:[hidden email] <mailto:[hidden email]>>> wrote: > > > > IIRC I used resolve, but maybe not in all places. > > > > CLI is written in smalltalk, so by all means do install full dev > > environment and look into AmberCli package inside Helios. > > > > Herby > > > > Jacob MacDonald wrote on 24. 7. 2018 2:14: > > > I have a very small amount of code but it was a result of > a few > > minutes' > > > tinkering not following the contribution guide, so I'll > keep things > > > brief here. > > > > > > I tried installing the CLI via Yarn instead of NPM, and > ran into a > > > problem caused by Amber searching for files based on the > nested > > > structure of NPM. Yarn uses a flatter directory tree. > Thankfully, > > Node > > > includes a way to figure out where a requireable package > lives in > > > require.resolve(). I was able to replace the logic in the > amberc CLI > > > with require.resolve() (though require.resolve('amber') fails, > > > require.resolve('amber/package.json') works). Ran into trouble > > patching > > > the Smalltalk code of Amber's CLI, however. It seems that the > > require > > > there is slightly different and is actually a BlockClosure > > instead of a > > > proxy to a JS object. Going to set up a full dev > environment with > > Helios > > Ah, this. I may understand what is the problem here. > Every JS function is ST BlockClosure and vice versa (it's hard mapping; > there are more of them for String, Number etc.). > > As you can see in other pieces of AmberCli package, you just use it as > block closure, so `require(foo, bar)` is `require value: foo value: > bar`. > > > > so I can hunt down require's definition, but does any of > this sound > > What is "require's definition"? > > > > familiar/interesting? > > > > > > Jacob. > > > > > > -- > > > 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] > <mailto:amber-lang%[hidden email]> > > <mailto:amber-lang%[hidden email] > <mailto:amber-lang%[hidden email]>> > > > <mailto:[hidden email] > <mailto:amber-lang%[hidden email]> > > <mailto:amber-lang%[hidden email] > <mailto:amber-lang%[hidden email]>>>. > > > For more options, visit https://groups.google.com/d/optout. > > > > -- > 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] > <mailto:[hidden email]>. > For more options, visit https://groups.google.com/d/optout. -- 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/d/optout. |
Re: Making Amber play nice with Yarn.
|
|
Herbert Vojčík wrote on 24. 7. 2018 18:54: > Ah, that. Yes, that's when it get hairy, calling "static" API on JS > functions which became ST-wrapped objects so it's hard to use them as > namespaces. :-( Maybe BlockClosure specifically (unlike other primitive wrapped JS classes) would benefit from #asApi selector which would `^ JSObjectProxy on: self`? > I'd go for `(require basicAt: #resolve) value: ...` (ugly, I know, > #basicAt: should not be used regularly, it's low-level API); maybe less > ugly alternative is `(JSObjectProxy on: require) resolve: ...` (though > uses low-level JSObjectProxy directly, too); of course it can be defined > in a method of its own so you can `self requireResolve: ...`; but I > would look at how this is used in other places, I am sure something like > that must already have been solved at least once in cli code... maybe > look for 'require' or 'resolve' in Helios searchbox? > > And we use AMD loader (requirejs) so I am not sure if require is the > node require (probably not) and so if it actually has resolve (but IIRC > I tried to preserve resolve by monkeypatching somehow when node-based > project is built). > > Herby > > Jacob MacDonald wrote on 24. 7. 2018 18:22: >> Ah, I was indeed looking at things from the wrong direction. >> Misunderstood the hard mapping from JS func to BlockClosure. Given >> that it seems that I need to wrap require.resolve because BlockClosure >> has no #resolve handler? >> >> On Tue, Jul 24, 2018, 11:12 Herbert Vojčík <[hidden email] >> <mailto:[hidden email]>> wrote: >> >> Not getting your question paragraph. Not sure what are you asking >> (globals, inline js, block closure). :-/ Maybe you look at it from >> wrong >> direction? Or just I am not at my full cognitive capacity today? >> >> CLI is actually done in Smalltalk. So tinkering with compiled js >> won't >> get you anywhere as it is produced from Smalltalk sources anyway in >> the end. >> >> If you search for 'npm'/'Npm' or 'package.json' in Helios search >> box, it >> will surely show you where those things are used in source. I >> actually >> don't know which part fails, but everything CLI does is there in the >> package, somewhere. Plus, if you know which method you tinkered >> with in >> .js (you should, selector as well as class are mentioned around it), >> you >> could just find that same method in Helios (and use all its power >> like >> look for senders etc. to be sure you know what you change). >> >> Herby >> >> Jacob MacDonald wrote on 24. 7. 2018 17:11: >> > Looked a little. Perhaps it's just because I'm a Smalltalk noob, >> but I'm >> > having trouble hunting down where require itself is defined/where >> global >> > variables in general live. Is it just an intrinsic part of the >> image >> > that is updated be redefining with inline JS? I can see the >> > compiledSource is more readable than what's generated by an >> average >> > BlockClosure. > >> > On Tue, Jul 24, 2018, 05:42 Herbert Vojčík <[hidden email] >> <mailto:[hidden email]> >> > <mailto:[hidden email] <mailto:[hidden email]>>> wrote: >> > >> > IIRC I used resolve, but maybe not in all places. >> > >> > CLI is written in smalltalk, so by all means do install >> full dev >> > environment and look into AmberCli package inside Helios. >> > >> > Herby >> > >> > Jacob MacDonald wrote on 24. 7. 2018 2:14: >> > > I have a very small amount of code but it was a result of >> a few >> > minutes' >> > > tinkering not following the contribution guide, so I'll >> keep things >> > > brief here. >> > > >> > > I tried installing the CLI via Yarn instead of NPM, and >> ran into a >> > > problem caused by Amber searching for files based on the >> nested >> > > structure of NPM. Yarn uses a flatter directory tree. >> Thankfully, >> > Node >> > > includes a way to figure out where a requireable package >> lives in >> > > require.resolve(). I was able to replace the logic in the >> amberc CLI >> > > with require.resolve() (though require.resolve('amber') >> fails, >> > > require.resolve('amber/package.json') works). Ran into >> trouble >> > patching >> > > the Smalltalk code of Amber's CLI, however. It seems >> that the >> > require >> > > there is slightly different and is actually a BlockClosure >> > instead of a >> > > proxy to a JS object. Going to set up a full dev >> environment with >> > Helios >> >> Ah, this. I may understand what is the problem here. >> Every JS function is ST BlockClosure and vice versa (it's hard >> mapping; >> there are more of them for String, Number etc.). >> >> As you can see in other pieces of AmberCli package, you just use >> it as >> block closure, so `require(foo, bar)` is `require value: foo value: >> bar`. >> >> > > so I can hunt down require's definition, but does any of >> this sound >> >> What is "require's definition"? >> >> > > familiar/interesting? >> > > >> > > Jacob. >> > > >> > > -- >> > > 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] >> <mailto:amber-lang%[hidden email]> >> > <mailto:amber-lang%[hidden email] >> <mailto:amber-lang%[hidden email]>> >> > > <mailto:[hidden email] >> <mailto:amber-lang%[hidden email]> >> > <mailto:amber-lang%[hidden email] >> <mailto:amber-lang%[hidden email]>>>. >> > > For more options, visit https://groups.google.com/d/optout. >> > >> >> -- >> 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] >> <mailto:[hidden email]>. >> For more options, visit https://groups.google.com/d/optout. > -- 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/d/optout. |
Re: Making Amber play nice with Yarn.
|
|
Thanks, #basicAt is exactly what I needed! And you are correct, AMDjs does not contain resolve by default but you bind it in the CLI wrapper from the Node require object.
As for the additional selector, I'm not familiar enough with Amber to have much of an opinion on semantics. #basicAt does the job but it is rather obscure and low-level. I'll keep working toward my original goal and see where I end up :) Thanks much! On Tue, Jul 24, 2018, 11:59 Herbert Vojčík <[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/d/optout. |
Re: Making Amber play nice with Yarn.
|
|
Jacob MacDonald wrote on 24. 7. 2018 21:02: > Thanks, #basicAt is exactly what I needed! And you are correct, AMDjs > does not contain resolve by default but you bind it in the CLI wrapper > from the Node require object. > > As for the additional selector, I'm not familiar enough with Amber to > have much of an opinion on semantics. #basicAt does the job but it is I was more thinking for myself... I think I add it as #provided, so one can do require provided resolve: 'package.json' or XmlHttpRequest provided DONE or so. > rather obscure and low-level. I'll keep working toward my original goal > and see where I end up :) > > Thanks much! > > On Tue, Jul 24, 2018, 11:59 Herbert Vojčík <[hidden email] > <mailto:[hidden email]>> wrote: > > > > Herbert Vojčík wrote on 24. 7. 2018 18:54: > > Ah, that. Yes, that's when it get hairy, calling "static" API on JS > > functions which became ST-wrapped objects so it's hard to use > them as > > namespaces. :-( > > Maybe BlockClosure specifically (unlike other primitive wrapped JS > classes) would benefit from #asApi selector which would `^ > JSObjectProxy > on: self`? > > > I'd go for `(require basicAt: #resolve) value: ...` (ugly, I know, > > #basicAt: should not be used regularly, it's low-level API); > maybe less > > ugly alternative is `(JSObjectProxy on: require) resolve: ...` > (though > > uses low-level JSObjectProxy directly, too); of course it can be > defined > > in a method of its own so you can `self requireResolve: ...`; but I > > would look at how this is used in other places, I am sure > something like > > that must already have been solved at least once in cli code... > maybe > > look for 'require' or 'resolve' in Helios searchbox? > > > > And we use AMD loader (requirejs) so I am not sure if require is the > > node require (probably not) and so if it actually has resolve > (but IIRC > > I tried to preserve resolve by monkeypatching somehow when > node-based > > project is built). > > > > Herby > > > > Jacob MacDonald wrote on 24. 7. 2018 18:22: > >> Ah, I was indeed looking at things from the wrong direction. > >> Misunderstood the hard mapping from JS func to BlockClosure. Given > >> that it seems that I need to wrap require.resolve because > BlockClosure > >> has no #resolve handler? > >> > >> On Tue, Jul 24, 2018, 11:12 Herbert Vojčík <[hidden email] > <mailto:[hidden email]> > >> <mailto:[hidden email] <mailto:[hidden email]>>> wrote: > >> > >> Not getting your question paragraph. Not sure what are you > asking > >> (globals, inline js, block closure). :-/ Maybe you look at > it from > >> wrong > >> direction? Or just I am not at my full cognitive capacity today? > >> > >> CLI is actually done in Smalltalk. So tinkering with > compiled js > >> won't > >> get you anywhere as it is produced from Smalltalk sources > anyway in > >> the end. > >> > >> If you search for 'npm'/'Npm' or 'package.json' in Helios search > >> box, it > >> will surely show you where those things are used in source. I > >> actually > >> don't know which part fails, but everything CLI does is > there in the > >> package, somewhere. Plus, if you know which method you tinkered > >> with in > >> .js (you should, selector as well as class are mentioned > around it), > >> you > >> could just find that same method in Helios (and use all its > power > >> like > >> look for senders etc. to be sure you know what you change). > >> > >> Herby > >> > >> Jacob MacDonald wrote on 24. 7. 2018 17:11: > >> > Looked a little. Perhaps it's just because I'm a > Smalltalk noob, > >> but I'm > >> > having trouble hunting down where require itself is > defined/where > >> global > >> > variables in general live. Is it just an intrinsic part > of the > >> image > >> > that is updated be redefining with inline JS? I can see the > >> > compiledSource is more readable than what's generated by an > >> average > >> > BlockClosure. > > >> > On Tue, Jul 24, 2018, 05:42 Herbert Vojčík > <[hidden email] <mailto:[hidden email]> > >> <mailto:[hidden email] <mailto:[hidden email]>> > >> > <mailto:[hidden email] <mailto:[hidden email]> > <mailto:[hidden email] <mailto:[hidden email]>>>> wrote: > >> > > >> > IIRC I used resolve, but maybe not in all places. > >> > > >> > CLI is written in smalltalk, so by all means do install > >> full dev > >> > environment and look into AmberCli package inside Helios. > >> > > >> > Herby > >> > > >> > Jacob MacDonald wrote on 24. 7. 2018 2:14: > >> > > I have a very small amount of code but it was a > result of > >> a few > >> > minutes' > >> > > tinkering not following the contribution guide, so > I'll > >> keep things > >> > > brief here. > >> > > > >> > > I tried installing the CLI via Yarn instead of > NPM, and > >> ran into a > >> > > problem caused by Amber searching for files based > on the > >> nested > >> > > structure of NPM. Yarn uses a flatter directory tree. > >> Thankfully, > >> > Node > >> > > includes a way to figure out where a requireable > package > >> lives in > >> > > require.resolve(). I was able to replace the logic > in the > >> amberc CLI > >> > > with require.resolve() (though > require.resolve('amber') > >> fails, > >> > > require.resolve('amber/package.json') works). Ran > into > >> trouble > >> > patching > >> > > the Smalltalk code of Amber's CLI, however. It seems > >> that the > >> > require > >> > > there is slightly different and is actually a > BlockClosure > >> > instead of a > >> > > proxy to a JS object. Going to set up a full dev > >> environment with > >> > Helios > >> > >> Ah, this. I may understand what is the problem here. > >> Every JS function is ST BlockClosure and vice versa (it's hard > >> mapping; > >> there are more of them for String, Number etc.). > >> > >> As you can see in other pieces of AmberCli package, you just > use > >> it as > >> block closure, so `require(foo, bar)` is `require value: foo > value: > >> bar`. > >> > >> > > so I can hunt down require's definition, but does > any of > >> this sound > >> > >> What is "require's definition"? > >> > >> > > familiar/interesting? > >> > > > >> > > Jacob. > >> > > > >> > > -- > >> > > 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] > <mailto:amber-lang%[hidden email]> > >> <mailto:amber-lang%[hidden email] > <mailto:amber-lang%[hidden email]>> > >> > <mailto:amber-lang%[hidden email] > <mailto:amber-lang%[hidden email]> > >> <mailto:amber-lang%[hidden email] > <mailto:amber-lang%[hidden email]>>> > >> > > <mailto:[hidden email] > <mailto:amber-lang%[hidden email]> > >> <mailto:amber-lang%[hidden email] > <mailto:amber-lang%[hidden email]>> > >> > <mailto:amber-lang%[hidden email] > <mailto:amber-lang%[hidden email]> > >> <mailto:amber-lang%[hidden email] > <mailto:amber-lang%[hidden email]>>>>. > >> > > For more options, visit > https://groups.google.com/d/optout. > >> > > >> > >> -- > >> 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] > <mailto:amber-lang%[hidden email]> > >> <mailto:[hidden email] > <mailto:amber-lang%[hidden email]>>. > >> For more options, visit https://groups.google.com/d/optout. > > > > -- > 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] > <mailto:[hidden email]>. > For more options, visit https://groups.google.com/d/optout. -- 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/d/optout. |
«
Return to Amber Smalltalk
|
1 view|%1 views
| Free forum by Nabble | Edit this page |