Clojurians
#lumo
<
2017-03-28
>

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

cfleming22:03:51

Does a lumo install (via Homebrew or whatever mechanism) contain the CLJS sources anywhere, or are they compiled into the binary?

anmonteiro22:03:11

@cfleming Lumo 1.2.0 contains the CLJS sources

anmonteiro22:03:49

these are internal APIs and subject to change, but this should work:

(require '[ :as io])
(io/slurp (io/resource “cljs/core.cljs"))

anmonteiro23:03:53

bundled files are in the “classpath"

cfleming23:03:19

@anmonteiro Are they stored on the disk somewhere? To support Lumo in Cursive, I’d need to create an “SDK” with access to those files (i.e. I don’t want to access them from CLJS itself)

anmonteiro23:03:29

they’re bundled into the binary

anmonteiro23:03:47

:disappointed:

cfleming23:03:00

Is that like a glorified zip or something, or an actual binary?

anmonteiro23:03:35

you can see what files are there with:

cljs.user=> (def nexeres (js/require "nexeres"))
#'cljs.user/nexeres
cljs.user=> (.keys nexeres)

anmonteiro23:03:46

they’re gzipped + base64 encoded

anmonteiro23:03:58

and I suppose I’m just making your job harder

cfleming23:03:18

Let me step back a bit - here’s what I’d have to do.

cfleming23:03:45

Say the user says they want to create a Lumo project, or a Lumo module within an existing project.

anmonteiro23:03:39

nexeres is an internal module to Nexe, the tool we use to package up the binary

cfleming23:03:45

Ok, so the files are stored separately on disk, it’s not all crammed into a single binary?

anmonteiro23:03:52

they’re not on disk

cfleming23:03:56

Or nexeres gets them from the binary?

anmonteiro23:03:25

nexeres is just a JS object whose keys are “filenames” and the values are base64 encoded strings of the file contents

anmonteiro23:03:58

@cfleming are you going to Clojure/West?

cfleming23:03:13

No, I’m not, sadly

anmonteiro23:03:22

ah. I was hoping we could speak in person

cfleming23:03:30

Yeah, that would have helped.

cfleming23:03:55

So I guess the only option would be to write a Java lib that knows how to extract those files from the binary.

cfleming23:03:35

Or do something like download the Lumo source corresponding to the SDK version.

anmonteiro23:03:55

oh wow, that’s going to be hard

anmonteiro23:03:10

@cfleming are you trying to integrate Planck too?

anmonteiro23:03:22

Because I think you’ll have the same problem

cfleming23:03:32

I was going to start with Lumo, mostly because I’m more likely to use that myself.

cfleming23:03:51

Does the Lumo build create source artifacts of any kind?

anmonteiro23:03:10

not currently

anmonteiro23:03:16

but we could make that happen

cfleming23:03:50

Does Lumo provide more than just CLJS? Are there any Lumo-specific namespaces exposed to Lumo apps?

anmonteiro23:03:17

lumo.build.api for example

anmonteiro23:03:32

to compile projects + interface with Google Closure Compiler JS

cfleming23:03:49

Ok, I was wondering about just maintaining a mapping of Lumo version to CLJS version, and just attaching CLJS to the SDK, but I guess that won’t work.

anmonteiro23:03:49

@cfleming can you open an issue describing the problem? maybe we can get some more people to chime in and start floating ideas around

cfleming23:03:04

Sure, will do

anmonteiro23:03:28

does this thing need to be static?

anmonteiro23:03:45

how does it work with Clojure, for example? is it just static analysis?

cfleming23:03:59

So I need access to the source files, basically.

cfleming23:03:25

Including things they access like the Closure JS

cfleming23:03:13

Does Lumo make all the Closure libs available, are they bundled too?