This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-02-15
Channels
- # aws (1)
- # beginners (6)
- # boot (25)
- # cider (30)
- # cljs-dev (50)
- # cljsrn (45)
- # clojure (98)
- # clojure-austin (5)
- # clojure-czech (1)
- # clojure-dev (21)
- # clojure-dusseldorf (29)
- # clojure-germany (2)
- # clojure-greece (117)
- # clojure-italy (2)
- # clojure-nl (4)
- # clojure-russia (26)
- # clojure-serbia (10)
- # clojure-spec (123)
- # clojure-turkiye (1)
- # clojure-uk (27)
- # clojured (13)
- # clojurescript (57)
- # core-async (18)
- # cursive (13)
- # datomic (20)
- # defnpodcast (16)
- # emacs (8)
- # events (2)
- # figwheel (3)
- # instaparse (1)
- # jobs (3)
- # jobs-discuss (39)
- # klipse (9)
- # lumo (100)
- # mount (1)
- # numerical-computing (1)
- # off-topic (22)
- # om (34)
- # onyx (17)
- # pedestal (1)
- # perun (29)
- # re-frame (60)
- # reagent (16)
- # remote-jobs (8)
- # rethinkdb (6)
- # ring-swagger (19)
- # rum (1)
- # slack-help (1)
- # specter (3)
- # untangled (1)
- # yada (17)
I’m interested in using lumo for command line works. Got a few questions.
1. Is there any usage example that I can learn from out there?
2. If I want to interact with i/o (filesystem, network), should I shell out to use bash stuffs like cp
, curl
etc or should I use Node.js standard library like fs
, http
?
3. To shell out, I should use something like child_process
(https://nodejs.org/api/child_process.html), right?
4. If I want to use npm libraries, how to I pack them into single easy-to-distribute file? Is that what calvin is for? Any calvin example I can learn from?
Have a question - I want to incorporate a lib - spec.cljs - into a CLJS project that I npm install, and invoke with Lumo. Anyone walked this path?
@anmonteiro did you get a chance to look into that dependency stuff? I'd like to write a cli tool which uses a nodejs dependency & not sure if I'll be able to.
@dominicm I did not and I should feel bad; I've had the tab open for ages. I'll ping you over the weekend
@anmonteiro It's okay, there is a workaround(https://github.com/juxt/mach/commit/62d2f5891233f0f1d088253840706239e92c61d2) anyway, but it's… ugly 😛
Cool I'll look at it too
@jonpither: can you clarify?
@anmonteiro I think I answered @jonpither's question in the JUXT slack 😛
Fo you mean using cljs.spec
from Lumo?
Oh awesome
It's really cool to see how JUXT has picked up Lumo
Motivates me to work on it a little more
Just wanna say I appreciate it you guys
It's exciting tech. @malcolmsparks has called 2017 "The year of Clojurescript on the server"
There are some Lumo news coming soon, I'm hoping mid-next week
Gonna take advantage of the 3-day weekend to try and release it
Lumo is awesome thus far @anmonteiro. I'm working also on https://github.com/juxt/roll which I'm using Lumo (via Mach) to drive. Haven't had as much fun for ages 🙂
I have some scripts I've written for allowing admins to rotate passwords. Lumo has been a great choice
We love it
So cool
@anmonteiro look forward to seeing your updates. Right now we're using Roll, by doing this in a Machfile: #eval "node_modules/@juxt/roll/src/roll/core.cljs", to reuse NPM Cljs modules...
Right. I think the story around consuming libraries and modules is not thought out at all
I can't decide if it should be a part of Lumo or not
I suppose we could attempt to read some kind of file (the equivalent to project.clj or build.boot) when starting up
@anmonteiro I feel like there's tension between how clojurescript currently expects to find dependencies & so on, & how node.js finds dependencies too.
But that's only half the story. Publishing artifacts being the other half
The problem is we must emulate the classpath to be able to consume CLJS deps
But we don't really need that notion to import Node packages
This has worked out really well, that's not the part I'm worried about
I just feel like Lumo is in the equivalent state of calling Clojure via java -cp ... clojure.main
@anmonteiro I'd be a little wary - perhaps for no good reason - about leaning on project.clj... right now we have a simple Machfile.edn that uses Lumo and it's nice to be out of the usual Lein/Boot JVM world. But hey, I've only just rocked up into this space
And there could be an easier path to enlightenment
@jonpither: I'm not suggesting we use the JVM
Just drawing parallels
@anmonteiro I like your approach of leaving Lumo to be the java -cp
. I love that we have competing lein & boot.
Cool. Mostly I'm just looking to gather community feedback
And go from there
yeah - I was more commenting on using project.clj. But I read your point more carefully, apologies: I suppose we could attempt to read some kind of file (the equivalent to project.clj or build.boot) when starting up
Keep in mind that Lumo is just 3 months old :-)
One think we wondering with Mach, is if there were a way to suck down cljs file dependencies from Git even 🙂
We've got a lot to do and learn
that's more appropiate for Mach, but prob less so for Lumo where people will want NPM like repos with lots of interdependent cljs in
The problem with that is CLJS projects may not have your expected structure
Unlike Golang which can do it because they enforce a certain structure
klipse does it in some cases but I'm not sure if it's hardcoded or not
I suppose NPM can also do that because it reads package.json, which not every CLJS project will have
@jonpither: yes that's right
Could you make the rule that any dependent project must have the package.json to be supported?
I think it just needs some maturity. David Nolen has told me more than once that we can't get anything done in less than 2 years
Let's see how the state of Lumo is in 2yrs :-)
@jonpither: that would be one solution, but it needs education
But I didn't even have the time to put together a docs website yet :/
I could maybe start by opening the Wiki, and go from there
Then people could help me start it
@anmonteiro Am I grasping the entirety of the difficulties with:
- Node.js uses main for exposing apis mostly, with a main
being the only entrypoint to the project, which normally exposes the rest of the api, slightly unsuitable for cljs deps
- Clojurescript expects a list of folders in which to search for ns/file.clj based namespacing
- There's currently no way to start downloading jars from maven in node.js which could be used to form a "classpath"
Just from our hacky Mach prototype, I could envisage changing: #eval "node_modules/@juxt/roll/src/roll/core.cljs" to #eval ["@juxt/roll" :roll.core] where it a) looks for the roll npm module, b) uses the package.json to determine where the source is c) expects the file to be there based on the second arg
@dominicm: 1,2 and last can be summed up as heterogeneity of NPM vs traditional Maven repos, but you get it
Getting those deps could be solved with NPM and Huckleberry, but I don't know if Huckleberry is ready for usage yet
If you don't know what it is I'll send the link when I'm at the computer
@dominicm: another problem to think about is how to declare a project's dependencies in a declarative, straightforward way (linking back to the project.clj talk)
I'm more than happy to open the Lumo wiki where we can distill these ideas in a design page
@anmonteiro I feel like a tool can be built on Huckleberry to fetch deps & run lumo with the classpath set. Which would make me think that Maven is the logical place to host code with cljs in it. There would still need to be node.js dependencies, but those can also be resolved by that same build tool using npm as a lib (or in a better world maybe yarn as a lib)
https://github.com/anmonteiro/lumo/pull/41 if something like this got merged, I think the boot equivalent wouldn't be too difficult…
that’ll get merged eventually
unfortunately the work I’m gonna be landing this weekend kinda moves the project structure around a little bit so there’ll be some conflicts
I know @npeckman hasn’t had a lot of time to work on it, but it’ll be in Lumo in the near future
I've been working on it a lot this week, I'm currently struggling to get js zip to do what I want. Should have some time to really nail down my issues tomorrow and get it in a place you can evaluate soon!
@npeckman awesome. feel free to shoot any questions about JSZip
@anmonteiro my big problem is this: when I get the zip object for the jar (an array of files) the files don't have the name field populated. Like when I get a file object off the array, I use the toText ()
method to see the file, and the name field on the object exists as the documentation states, but the name field is just an empty object. Trying to list all the file names so this is a big barrier
@npeckman that hasn’t been my experience
I know the library is mature so I figure it's my fault, just trying to figure out what I'm doing wrong.
umo 1.1.0
ClojureScript 1.9.456
Docs: (doc function-name-here)
Exit: Control+D or :cljs/quit or exit
cljs.user=> (def JSZip (js/require "jszip"))
#'cljs.user/JSZip
cljs.user=> (def zip (.load (JSZip.) (fs.readFileSync "om.jar")))
#'cljs.user/zip
cljs.user=> (.-name (.file zip "om/next.cljc"))
"om/next.cljc"
cljs.user=>
^ here’s an example
@npeckman you can also get all the files in the Zip, e.g.:
Lumo 1.1.0
ClojureScript 1.9.456
Docs: (doc function-name-here)
Exit: Control+D or :cljs/quit or exit
cljs.user=> (def JSZip (js/require "jszip"))
#'cljs.user/JSZip
cljs.user=> (def zip (.load (JSZip.) (fs.readFileSync "om.jar")))
#'cljs.user/zip
cljs.user=> (js/Object.keys zip.files)
#js ["META-INF/MANIFEST.MF" "META-INF/maven/org.omcljs/om/pom.xml" "META-INF/leiningen/org.omcljs/om/project.clj" "project.clj" "META-INF/leiningen/org.omcljs/om/README.md" "META-INF/" "META-INF/maven/" "META-INF/maven/org.omcljs/" "META-INF/maven/org.omcljs/om/" "META-INF/maven/org.omcljs/om/pom.properties" "data_readers.clj" "deps.cljs" "om/" "om/checksums.clj" "om/core.clj" "om/core.cljs" "om/dom.cljc" "om/dom.cljs" "om/externs.js" "om/impl.cljs" "om/next/" "om/next/cache.cljs" "om/next/impl/" "om/next/impl/parser.cljc" "om/next/protocols.cljc" "om/next/server.clj" "om/next.cljc" "om/tempid.cljc" "om/transit.cljc" "om/util.cljc"]
cljs.user=>
@anmonteiro Thanks for the examples, think I'll be able to use them to hammer out my problems pretty quickly. I think the other big thing you needed were tests, I really hope to get that all to you before the weekend starts
@npeckman no rush, as I said there are some changes coming to the project structure and there’ll be conflicts 🙂
what's the big change?
don't keep us in the dark!
inquiring minds want to know
no changes, just accretions
hoping to make startup even faster too
I have an idea or 2
not that’s it’s slow right now 😇
it really isn't 🙂
I have some free time over the next few weeks, maybe I can do some hacking on lumo too,
if there are any low hanging fruits?
@pesterhazy this would be good one to start https://github.com/anmonteiro/lumo/issues/74
this one seems easy too, and awesome for UX https://github.com/anmonteiro/lumo/issues/62
no promises but will see what I can do
@jonpither I put some work to rsolve the deps gathering issue you can take a look at https://github.com/eginez/calvin
@dominicm the calvin project I have been working on address "There's currently no way to start downloading jars from maven in node.js which could be used to form a “classpath””, in fact calvin is already creating a classpath for you and launching the repl with such classpath, granted is reading project.clj but that doesn’t need to be the case