This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-02-20
Channels
- # aleph (19)
- # aws-lambda (8)
- # bangalore-clj (1)
- # beginners (13)
- # boot (179)
- # cljs-dev (12)
- # cljsjs (2)
- # cljsrn (6)
- # clojure (174)
- # clojure-italy (14)
- # clojure-nl (2)
- # clojure-russia (172)
- # clojure-spec (29)
- # clojure-uk (22)
- # clojurebridge (10)
- # clojureremote (1)
- # clojurescript (79)
- # cursive (46)
- # data-science (1)
- # datascript (8)
- # datomic (18)
- # defnpodcast (2)
- # emacs (9)
- # events (6)
- # hoplon (11)
- # klipse (13)
- # lein-figwheel (1)
- # leiningen (1)
- # luminus (1)
- # lumo (88)
- # numerical-computing (1)
- # off-topic (24)
- # om (33)
- # onyx (58)
- # protorepl (8)
- # re-frame (10)
- # reagent (26)
- # ring (8)
- # ring-swagger (7)
- # rum (22)
- # spacemacs (25)
- # specter (5)
- # uncomplicate (37)
- # untangled (75)
- # vim (17)
- # yada (3)
@dominicm I think I solved your issue
had to solve it in Lumo after all
Hey @anmonteiro just wanted to let you know that I did get that jar stuff done (actually still not sure why it didnt work for me originally) so after you release the update and I integrate changes, we should be good to go 馃檪
awesome 馃憤
I鈥檒l get to it after deploying my next changes
@npeckman I鈥檓 hoping by Tuesday
still have tomorrow鈥檚 holiday to work a little bit on this
Using the command line tools got rid of the gettime error
@anmonteiro that's awesome. So no more node path monkeying! :D
@anmonteiro, boot release
works now. Now I'm trying to use boot dev
but if I follow the process (`boot dev` in one terminal, yarn dev
in the other) I can't type anything in the other terminal window
oh wow.. now it works
it just took 20s or so?
look like I'm too impatient 馃檪
more like 4 seconds
the "show the prompt immediately" trick tripped me up
@pesterhazy ah right. Lumo compiles a bunch of NSes at REPL startup
In the release binary this is not a problem because they're precompiled
But in DEV you need to wait a little bit
Also they're cached so subsequent runs are faster
ah I see now
my first PR 馃檪 https://github.com/anmonteiro/lumo/pull/78
@pesterhazy looks like you forgot to run yarn lint
that's why CI may be failing
did not forget about ... I did not know about it!
or that!
20 errors wow
yeah, it's really picky
my javascript style is stuck in 1995
I did mess up indentation though, let me fix
on another note, I thought we could solve this one solely with tools.reader?
perhaps
I used https://github.com/clojure/clojure/blob/master/src/clj/clojure/main.clj#L110 as insipiraton
cljs.user=> (require '[cljs.tools.reader :as r])
nil
cljs.user=> (require '[cljs.tools.reader.reader-types :as rt])
nil
cljs.user=> (def rdr (rt/indexing-push-back-reader ";; comment\n(+ 1 2)"))
#'cljs.user/rdr
cljs.user=> (r/read rdr)
(+ 1 2)
ah interesting
I think you're overcomplicating though
quite possible 馃檪
we're probably just not handling the comment case in some bit of the code
let me try and point it to you
@pesterhazy most likely around here https://github.com/anmonteiro/lumo/blob/master/src/cljs/lumo/repl.cljs#L745
the problem I ran into was isWhitespace is used to check if more readable code is to come
hm didn't realize that read
handles comments by itself
you were right, the whole skip-ahead business wasn't necessary
ok, updated the PR
@pesterhazy oh but isEmpty
is still necessary?
FWIW Planck now also exhibits the same issue, and this is the commit in which it regressed https://github.com/mfikes/planck/commit/a98fd75f4351b05ca8c9c09c52a969cae9690fbf
the problem is isReadable for ";1" returns ""
which is interpreted as "yes it's readable"
then it's checked if it's all whitespace
if it isn't, it calls read, which correctly fails because it EOFs
that's why I modified isWhitespace to mean whitespace-or-comment
gotcha
I think it makes sense
the code is a bit complicated
it reads the form twice I think
I mean the existing code
that's why I couldn't come up with a non-invasive fix without a larger refactoring
(I thing e.g. the processLine inner loop could be moved to cljs to make things a bit easier but not sure it's worth it)
by the way, working on lumo is really comfty with the boot dev + yarn dev set up
any idea how to handle the echo "#_1" | lumo
case?
I mean I guess you could just catch EOF exceptions
or wrap everything in (do ...)
馃檪
I'm now realizing there's a difference between the "EOF while reading" and "EOF" exception
so maybe we can just catch and ignore the latter exception?
in execute, that is, not in isReadable
FWIW, in Planck鈥檚 case the bit of convoluted logic was when it read the form again to see if it was a REPL special. (I think.) Experimenting with this fix: https://github.com/mfikes/planck/commit/b82240365d1f1c1def1837fe11e23252c47b0cc5
interesting
didn't realize that portion of the code originated in planck!
Planck influenced a lot of things in Lumo. That's just one of them 馃檪
I was thinking it may be better, instead of is-readable?, to have a fn next
that returns [status next-form rest-of-string]
status would be: complete-form, partial-form or no-form
next-form the parsed form if any, and rest-of-string the remainder
This issue reminds me tangentially of http://dev.clojure.org/jira/browse/CLJS-1572, which relates to how the shipping ClojureScript REPL handles reading forms from input lines
right, I think there is some overlap, but not quite the same thing
Planck and Lumo don't exhibit that bug because we are always looking for more input to read
not sure if I should blame Andare/printfns or myself, but this simple go loop wont print in lumo?
(go (let [c (chan)]
(>! c 666)
(js/console.log (<! c))))
ok solved, chan doesn't default to 1 slot in andere.
cljs.user=> (go (let [c (async/chan 1)] (async/>! c 666) (js/console.log (async/<! c ))))
#object[cljs.core.async.impl.channels.ManyToManyChannel]
cljs.user=> 666
right, that's probably a consequence of how we do printing in the socket REPL
it's really hacky and we need to fix it
probably a Lumo bug hiding there as well
yeh ok, weird that the stdout changes from just the go macro, but ok, dont know the code so.
the problem is that it changes synchronously and the go
macro messes up with the synchronicity 馃檪