This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-02-23
Channels
- # aleph (8)
- # aws (2)
- # beginners (36)
- # cider (35)
- # cljs-dev (157)
- # cljsjs (3)
- # cljsrn (5)
- # clojure (97)
- # clojure-dev (5)
- # clojure-gamedev (3)
- # clojure-italy (27)
- # clojure-russia (11)
- # clojure-spec (19)
- # clojure-uk (39)
- # clojured (6)
- # clojurescript (87)
- # clojutre (4)
- # community-development (35)
- # cursive (8)
- # datascript (2)
- # datomic (14)
- # dirac (8)
- # duct (3)
- # figwheel (13)
- # fulcro (22)
- # graphql (20)
- # jobs (1)
- # london-clojurians (1)
- # off-topic (55)
- # onyx (3)
- # parinfer (3)
- # protorepl (39)
- # re-frame (3)
- # reagent (26)
- # ring (7)
- # ring-swagger (2)
- # rum (1)
- # shadow-cljs (107)
- # spacemacs (8)
- # test-check (4)
- # unrepl (3)
I wouldn't know where to start digging even 😄
A nice visual demo of the power of cljs.main
and git deps: https://gist.github.com/mfikes/e600e965da916699a703c9b1f1ff6d3b
(Derived from and inspired by https://twitter.com/athos0220/status/966892316496572416)
I’m whittling down what I think is necessary for the next release - the only 2 big ticket items are pREPL & caching
let me know if there’s some smaller things you’d like to see get included and I’ll think about it
@dnolen Also https://dev.clojure.org/jira/browse/CLJS-2469 is zero-risk IMO
BTW, sorted the cljs.main
failure mentioned above: I had 1.9.946 specified in my ~/.clojure/deps.edn
and it was taking that version over the one specified in the gist
Yeah, it feels like there is a good chance for regressions given how much change is in this release. Hopefully with git deps, we can get some users in the community to try things out prior to release. I doubt it, though, and we'll probably have to follow the next release with one shortly after to fix any undiscovered things.
@mfikes all in good time I think as people start using deps.edn, getting to work of shas will eventually be a thing
It may take a while to sort the Chakra stuff. If you go to the regular dowload links for it at https://github.com/Microsoft/ChakraCore/releases it appears they are having internal auth errors right now
As an aside, I wonder if we can have a cljs.repl.chakra
will have to check and see if it has the needed hooks 🙂
@mfikes I'm using jsvu locally, not sure if that might be easier for the CI: https://github.com/GoogleChromeLabs/jsvu
Interesting. FWIW, we are currently using fairly straightforward mechanisms to fetch / install VMs: https://github.com/clojure/clojurescript/blob/master/.travis.yml#L9-L13
@bronsa Clojure 1.10 has read+string
I don’t think tools.reader
has anything similar right? The source logging reader isn’t sufficient since it only works if what’s read can support meta
@dnolen I wanted access to the source in shadow-cljs as well. it works when using readers/source-logging-pushback-reader
and then poking at some internals. https://github.com/thheller/shadow-cljs/blob/master/src/main/shadow/cljs/repl.clj#L434 and https://github.com/thheller/shadow-cljs/blob/master/src/main/shadow/cljs/repl.clj#L472-L477
@bronsa blocked from implementing pREPL until tools.reader supports the same operation, either by delivering read+string
(preferable) or by providing stable hooks
hrm ClojureScript pREPL needs to rely on Clojure tap>
and related fns. I’m leaning towards Clojure 1.10 being a requirement if you want to use pREPL but not making Clojure 1.10 be a hard dependency.
Agree it should be a soft dep, folks will be using nRepl
facilities for very long time (at least as long as tooling catches up)
@dnolen just pinging you about backgrounding the watcher for the cljs.main cli when the repl is requested
Ambly now has a command line binary for the JavaScriptCore side of things, making it trivial to essentially fire up JavaScriptCore and connect to it using the new cljs.main
capability. http://ambly.fikesfarm.com
And @bhauman ClojureScript rebel-readline composes with Ambly. Freakishly cool that this level of ClojureScript REPL composability is working. https://twitter.com/mfikes/status/967147239608025088
It is great when you have 2 or 3 things not specifically designed to work directly with each other successfully composing. 🙂
I like the way aliases compose a lot actually, I have one only for :socket
that at the moment does not work but will be appliable to all the clojure repls on the JVM (cljs included)
One interesting thing about the above rebel-readline / Ambly is that is doesn't really terminate by running a main or a -r
, but the REPL is the result of the last -e
. (An interesting twist, a -e
that doesn't terminate but is your REPL.)
@bhauman boom https://github.com/clojure/clojurescript/blob/3d73dec71763585977f015cb45c9d5c74540f466/src/main/clojure/cljs/core/server.clj#L127-L143
nnnniiiiiiceeeee
more work for inf-clojure
contributors 😅
looking over pREPL the only thing I can see that it needs doing is create user ns, and I need to implement specials
in my mind it would be nice if the cljs.repl/wrap-fn captured printed output on the client and sent it back
and its interesting because it seems that the cljs.repl would be better served if it was backed by the prepl with a connection where the client itself has a tap>.
https://github.com/clojure/clojurescript/blob/master/src/main/clojure/cljs/repl.cljc#L617
oh right there’s a category of things that we should separate before we think about to solve it
the wrap-fn idea was only a simple idea to include a {:out "hello" :value nil}
to simply duplex the result value
we capture out at pREPL
, as long as you print in your REPL implementation this works correctly
(I've opened a ticket regarding Chakra https://github.com/Microsoft/ChakraCore/issues/4738)
so REPLs can communicate that however they want, then in Clojure they just call tap>
… done
semantics are just that anyone that calls it with some data, it will just appear in pREPLs as :tap
and fact I think the idea of a prepl as a remote data repl still feels like it should be more split across the client/clojure boundary
first cut of pREPL is done, there’s some obvious things missing (`:npm-deps`, etc.) but I think people need to kick the tires for us to proceed
So @dnolen about the pg
problem, I got an answer back from the maintainers:
> ./lib is a module by virtue of containing an index.js; you should report a bug with the failing tools.
I thought it was just an easy patch but it is probably not what I was imagining
@richiardiandrea Closure is supposed to handle that, but I think module-deps also does some work
ok, so I will reopen the issue, it requires more digging