Clojurians
#lumo
<
2017-03-29
>

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

anmonteiro00:03:28

Closure Library is also bundled

anmonteiro00:03:39

but it’s available too :stuck_out_tongue:

anmonteiro00:03:46

for some definition of "available"

mfikes00:03:11

Maybe Lumo and Planck could accept an argument that causes them to dump all their bundled source to a specified directory.

anmonteiro01:03:24

I like that idea

cfleming02:03:49

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).

cfleming02:03:25

@mfikes Does Planck have the source available in the bundle/executable too?

mfikes02:03:06

@cfleming Yes. All the Clojure(Script) and Google Clojure JS is inside Planck, bundled in the binary.

cfleming02:03:46

@mfikes Oh, nice. In that case, I would love an option to spit it all out to a directory!

cfleming02:03:54

I’ll file issues.

mfikes02:03:42

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.

mfikes02:03:34

I suppose another corner case is if someone upgrades Lumo or Planck, effectively invalidating previously dumped source...

cfleming03:03:09

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.

cfleming03:03:40

So if their executable moves or the version changes, then the SDK will become invalid.

cfleming03:03:55

Is there a switch to get the version easily?

cfleming03:03:33

Thinking about it, the user will probably only create the SDK once per version, that might be a bit tricky during upgrades.

mfikes03:03:43

Hrm. Both Planck and Lumo spit their version out at the top of -h but that is meant for human consumption....

cfleming03:03:05

Perhaps the source dump option could also print the version to stdout

anmonteiro03:03:08

Lumo has a clojurescript-version file in the bundled output :slightly_smiling_face:

cfleming03:03:39

@anmonteiro But that’s not the same as the Lumo version, right?

cfleming03:03:53

Two Lumo releases might use the same CLJS version?

anmonteiro03:03:07

oh I'm sorry

cfleming03:03:51

That said, I’d be happy with a version file in the bundled output.

cfleming03:03:31

In fact, that would probably work better - the user would create an SDK somewhere on disk, and that contains the version.

cfleming03:03:55

Although I’d still like to be able to warn if the exe version doesn’t match the SDK version.

anmonteiro03:03:57

yeah, then just hash that

cfleming03:03:16

I think the exe still has to be able to report its version somehow.

mfikes03:03:17

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.

cfleming03:03:39

That would be great, although that degree of difference is pretty easy to support.

anmonteiro03:03:20

^ with Mike, I have no idea how easy it is to support difference :slightly_smiling_face:

mfikes03:03:23

Maybe a new option to write the version to stdout or somesuch. -v is used already for verbose.

mfikes03:03:06

--version is free of course

anmonteiro03:03:17

either that or programatic access inside the REPL itself

cfleming03:03:24

I’m going to create an issue against Lumo, and link it in a new one in Planck

anmonteiro03:03:25

depends on what would be easiest for Cursive

cfleming03:03:38

An exe flag, definitely.

anmonteiro03:03:02

Yeah, me and @mfikes have synced up on other stuff before, we can make these work the same way too

anmonteiro03:03:08

@cfleming btw Lumo has socket REPL support, just like Planck

anmonteiro03:03:16

does this help Cursive at all?

cfleming03:03:35

Yes, I haven’t added that support yet in Cursive, but yes, it will be helpful

mfikes03:03:23

:slightly_smiling_face: Perhaps Lumo and Planck will grow nREPL support some day.

anmonteiro03:03:23

I mean their own version of a socket REPL, it doesn't mimic Clojure's behavior entirely

cfleming03:03:42

I think that’s ok, as long as it conceptually does the same thing.

cfleming03:03:34

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.

cfleming03:03:46

So it’ll be one flag for getting the version, and one for dumping source.

mfikes03:03:07

I was thinking something along the lines of --dump-bundled-source /some/path (with perhaps a better name for the flag)

cfleming03:03:52

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?

mfikes03:03:16

And, the inside that directory the source would follow the usual directory structure (as if you had unjared a JAR)

cfleming03:03:42

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?

mfikes03:03:46

Yeah, I guess I'd lean towards safety and balk if it already exists...

cfleming03:03:59

Planck and Lumo are both basically a single executable file, right? There are no other auxiliary files required?

mfikes03:03:39

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

cfleming03:03:08

Ok - I was wondering if I should actually copy the binary into the SDK directory.

cfleming03:03:35

That would mean that if the user created a Planck x.y.z SDK, then it would always work with that version of Planck.

cfleming03:03:23

Otherwise I’ll have to take care of upgrading SDKs, and confirming that the version is the same.

mfikes03:03:29

Yeah, I suppose that would work. (Perhaps they could accidentally blow away the shared object libs making the binary no longer work.)

mfikes03:03:15

(For Planck, the shared object libs are standard ones, like icu, libcurl, libzip etc)

cfleming03:03:44

Actually, I guess the binary is probably in a fixed location for a version, but then symlinked on install into /usr/local/bin, right?

cfleming03:03:00

So I can just follow the symlink and use the real binary, which shouldn’t move even on an upgrade.

mfikes03:03:10

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?)

mfikes03:03:45

Lumo also has binaries you can download by hand and place where you'd like

cfleming03:03:08

Yeah, it does.

cfleming03:03:36

Ok, that sounds good. I’ll do that, and then also do a paranoid check at some points that versions still match up.

anmonteiro23:03:11

@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

anmonteiro23:03:20

you can install from master with brew install --devel lumo if you’re on a mac

mfikes23:03:27

I've almost completed the same for Planck :slightly_smiling_face:

mfikes23:03:56

@anmonteiro Oddly, I get this for Lumo, trying --HEAD instead:

$ brew install --devel lumo
Error: No devel block is defined for lumo

anmonteiro23:03:52

I meant --HEAD! I always mix up the two