This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # beginners (15)
- # 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 (24)
- # 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 (13)
- # om (7)
- # onyx (40)
- # overtone (4)
- # pedestal (8)
- # powderkeg (4)
- # proton (2)
- # protorepl (2)
- # re-frame (14)
- # reagent (24)
- # ring-swagger (3)
- # rum (15)
- # slack-help (1)
- # spacemacs (20)
- # uncomplicate (62)
- # unrepl (29)
- # untangled (15)
- # yada (10)
Maybe Lumo and Planck could accept an argument that causes them to dump all their bundled source to a specified directory.
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 :slightly_smiling_face:
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.
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.
^ with Mike, I have no idea how easy it is to support difference :slightly_smiling_face:
Maybe a new option to write the version to stdout or somesuch.
-v is used already for verbose.
Yeah, me and @mfikes have synced up on other stuff before, we can make these work the same way too
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
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.
@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
@anmonteiro Oddly, I get this for Lumo, trying
$ brew install --devel lumo Error: No devel block is defined for lumo