Closed arichiardi closed 7 years ago
I don't know how to change it against wip/lumo
...
Why remove? It is so so useful when you have problems, you can ask a user to execute to send the output of the "Executing:" command..don't you think? -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
@arichiardi That hasn't been my experience - it's not helpful enough to justify the clutter. The serverless plugin logs the parameters it's passing to the script - everything else that's being logged could just as well be obtained by asking for the config file, or asking for a directory listing.
Ok, I can do that but I feel you really close for future kinds of compilers. And then you need to push a major version for the change? What is the advantage of a boolean? -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
I can use camel case -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
If you prefer that, use camel case.
I think it makes more sense. Will change it. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Ok will remove the commit. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Ok addressed all the change requests and added some doc to the README
Thanks - why is 1.7.0+ required, just so I know?
Because there is was a breaking change from lumo.core/command-line-args to cljs.core.
We could actually support both namespaces in our code but 1.7.0 will be broken unless we use an unmangled get on global.
@arichiardi Why are we using *command-line-args*
if the -main
function receives the args as a sequence? With older versions of lumo, can you verify that receiving the arg vector still works? I would very much like to remove the version restriction.
The reason is node sends all the args, even the ones passed to lumo itself and we don't want those.
Sure I can tweak that.
Yeah, let's work around it.
@arichiardi Regarding the fix, is command-line-args empty, or unbound in older versions of lumo?
Premise: the above works for the three versions regardless, so seq
does the right thing even when unbound.
In 1.6.0
we have only bound lumo.core
, in 1.7.0
bound only cljs.core
. In the bugged version, the lumo.core
JS mangled object is filled but not bound in cljs, where cljs.core
is but will always be nil
.
Btw I have just noticed there that I don't need seq
because it is already done in lumo
.
Presumably you can use the unmangled syntax to refer to the lumo.core var -
lumo.core/*command-line-args*
?
@moea not that would not work in 1.7.0
. That is why I used the mangled version :wink:
If lumo.core
is required, why would it not work?
Good point! Maybe it is not require
d anymore? I have not investigated the why in depth, a bit in a hurry today.
I mean if you just add (:require [lumo.core])
to the module, I don't see how it cannot work.
No I don't think it can work because the defonce
is missing and therefore it is not in the compiler state.
However the global JS object is filled up at runtime so we can query it.
If the namespace is required, you will get a compiler warning about an undefined var, and nil at runtime. Please make the change.
Will do, probably more verbose and uglier than what is now, but hey, you're the boss :smile:
Awesome, it seems like it is nice and working now :wink:
This patch adds various improvements to the lumo build, notably:
custom.cljsCompiler
option in serverless.yml