This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-03-29
Channels
- # beginners (24)
- # boot (6)
- # cider (22)
- # cljsjs (1)
- # cljsrn (12)
- # clojars (3)
- # clojure (170)
- # clojure-china (2)
- # clojure-dusseldorf (18)
- # clojure-finland (1)
- # clojure-italy (32)
- # clojure-nl (1)
- # clojure-russia (65)
- # clojure-sanfrancisco (1)
- # clojure-spec (21)
- # clojure-uk (46)
- # clojurescript (92)
- # clojutre (1)
- # clr (7)
- # cursive (7)
- # datomic (6)
- # dirac (49)
- # emacs (17)
- # events (1)
- # funcool (20)
- # hoplon (6)
- # job (1)
- # jobs (1)
- # keechma (2)
- # leiningen (6)
- # lumo (74)
- # off-topic (15)
- # om (7)
- # onyx (40)
- # overtone (4)
- # pedestal (8)
- # powderkeg (4)
- # proton (2)
- # protorepl (2)
- # re-frame (18)
- # reagent (24)
- # ring-swagger (3)
- # rum (15)
- # slack-help (1)
- # spacemacs (20)
- # uncomplicate (62)
- # unrepl (29)
- # untangled (10)
- # yada (10)
Closure Library is also bundled
but it’s available too 😛
for some definition of "available"
Maybe Lumo and Planck could accept an argument that causes them to dump all their bundled source to a specified directory.
I like that idea
Nice, I like it too. Is that feasible/easy? The other option I was considering was modifying the builds to create a source artifact that could be hosted somewhere (the Github releases page, perhaps).
@cfleming Yes. All the Clojure(Script) and Google Clojure JS is inside Planck, bundled in the binary.
@mfikes Oh, nice. In that case, I would love an option to spit it all out to a directory!
Thanks! If you find subtle corner requirements, like "only dump here if not already here, for perf reasons" I'd see no issue with that.
I suppose another corner case is if someone upgrades Lumo or Planck, effectively invalidating previously dumped source...
I don’t think that would be required - when the user is setting up a Lumo/Planck SDK, I’ll probably get them to specify where their executable is, and then hash that path with the version.
So if their executable moves or the version changes, then the SDK will become invalid.
Thinking about it, the user will probably only create the SDK once per version, that might be a bit tricky during upgrades.
Hrm. Both Planck and Lumo spit their version out at the top of -h
but that is meant for human consumption....
Lumo has a clojurescript-version file in the bundled output 🙂
@anmonteiro But that’s not the same as the Lumo version, right?
oh I'm sorry
In fact, that would probably work better - the user would create an SDK somewhere on disk, and that contains the version.
Although I’d still like to be able to warn if the exe version doesn’t match the SDK version.
yeah, then just hash that
ah right
Lumo and Planck fairly closely adhere to the same command line arguments, etc., so if we make the behavior the same then Cursive could more easily support both.
I agree
^ with Mike, I have no idea how easy it is to support difference 🙂
Maybe a new option to write the version to stdout or somesuch. -v
is used already for verbose.
either that or programatic access inside the REPL itself
depends on what would be easiest for Cursive
Yeah, me and @mfikes have synced up on other stuff before, we can make these work the same way too
exciting!
@cfleming btw Lumo has socket REPL support, just like Planck
does this help Cursive at all?
I mean their own version of a socket REPL, it doesn't mimic Clojure's behavior entirely
Since I think the executable has to be able to return its version so that I can confirm that the SDK matches the executable, I’ll just create the version file inside the SDK files myself.
I was thinking something along the lines of --dump-bundled-source /some/path
(with perhaps a better name for the flag)
Right, that was what I was thinking. I’m not sure what the behaviour should be if the directory exists or doesn’t exist - any ideas?
And, the inside that directory the source would follow the usual directory structure (as if you had unjared a JAR)
Would we rather make it easy to overwrite an existing dumped SDK, or conservatively force the user to name a non-existent directory to avoid overwriting things?
Planck and Lumo are both basically a single executable file, right? There are no other auxiliary files required?
That used to be true of Planck, but 2.0.0+ dynamically links with shared object libraries, but those are installed automatically when you do brew install planck
That would mean that if the user created a Planck x.y.z SDK, then it would always work with that version of Planck.
Otherwise I’ll have to take care of upgrading SDKs, and confirming that the version is the same.
Yeah, I suppose that would work. (Perhaps they could accidentally blow away the shared object libs making the binary no longer work.)
Actually, I guess the binary is probably in a fixed location for a version, but then symlinked on install into /usr/local/bin
, right?
So I can just follow the symlink and use the real binary, which shouldn’t move even on an upgrade.
yeah, it is unlikely to move. Lumo supports installation via npm and brew, and on Ubuntu Planck supports apt-get
(Does IntelliJ even run on Linux?)
Ok, that sounds good. I’ll do that, and then also do a paranoid check at some points that versions still match up.
I’ve filed https://github.com/anmonteiro/lumo/issues/112 and https://github.com/mfikes/planck/issues/473
@cfleming had a little time during my trip to Portland today and cranked out the SDK thing.
lumo --version
or lumo -V
outputs Lumo’s version, lumo -D dir
or lumo --dump-sdk dir
dumps the bundled resources to dir
/cc @mfikes
you can install from master with brew install --devel lumo
if you’re on a mac
@anmonteiro Oddly, I get this for Lumo, trying --HEAD
instead:
$ brew install --devel lumo
Error: No devel block is defined for lumo
I meant --HEAD
! I always mix up the two