Clojurians
#lumo
<
2017-02-20
>

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

anmonteiro01:02:51

@dominicm I think I solved your issue

anmonteiro01:02:09

had to solve it in Lumo after all

npeckman01:02:08

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 :slightly_smiling_face:

anmonteiro01:02:32

awesome :+1:

anmonteiro01:02:42

I’ll get to it after deploying my next changes

npeckman01:02:35

Thanks! Any idea when you'll push? Excited to see the new release!

anmonteiro01:02:19

@npeckman I’m hoping by Tuesday

anmonteiro01:02:31

still have tomorrow’s holiday to work a little bit on this

npeckman01:02:47

cool, looking forward to it!

pesterhazy08:02:46

Using the command line tools got rid of the gettime error

dominicm08:02:42

@anmonteiro that's awesome. So no more node path monkeying! :D

pesterhazy13:02:37

@anmonteiro, boot release works now. Now I'm trying to use boot dev

pesterhazy13:02:13

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

pesterhazy13:02:57

oh wow.. now it works

pesterhazy13:02:03

it just took 20s or so?

pesterhazy13:02:11

look like I'm too impatient :slightly_smiling_face:

pesterhazy13:02:24

more like 4 seconds

pesterhazy13:02:00

the "show the prompt immediately" trick tripped me up

anmonteiro17:02:54

@pesterhazy ah right. Lumo compiles a bunch of NSes at REPL startup

anmonteiro17:02:16

In the release binary this is not a problem because they're precompiled

anmonteiro17:02:28

But in DEV you need to wait a little bit

anmonteiro17:02:40

Also they're cached so subsequent runs are faster

pesterhazy18:02:47

ah I see now

anmonteiro18:02:24

@pesterhazy looks like you forgot to run yarn lint

anmonteiro18:02:36

that's why CI may be failing

pesterhazy18:02:43

did not forget about ... I did not know about it!

anmonteiro18:02:52

:slightly_smiling_face:

pesterhazy18:02:04

20 errors wow

anmonteiro18:02:13

yeah, it's really picky

pesterhazy18:02:20

my javascript style is stuck in 1995

pesterhazy18:02:40

I did mess up indentation though, let me fix

anmonteiro18:02:45

on another note, I thought we could solve this one solely with tools.reader?

anmonteiro18:02:37

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)

anmonteiro18:02:47

ah interesting

anmonteiro18:02:58

I think you're overcomplicating though

pesterhazy18:02:13

quite possible :slightly_smiling_face:

anmonteiro18:02:16

we're probably just not handling the comment case in some bit of the code

anmonteiro18:02:25

let me try and point it to you

pesterhazy18:02:12

the problem I ran into was isWhitespace is used to check if more readable code is to come

pesterhazy18:02:47

hm didn't realize that read handles comments by itself

pesterhazy18:02:24

you were right, the whole skip-ahead business wasn't necessary

pesterhazy18:02:41

ok, updated the PR

anmonteiro18:02:21

@pesterhazy oh but isEmpty is still necessary?

anmonteiro18:02:01

FWIW Planck now also exhibits the same issue, and this is the commit in which it regressed https://github.com/mfikes/planck/commit/a98fd75f4351b05ca8c9c09c52a969cae9690fbf

pesterhazy19:02:05

the problem is isReadable for ";1" returns ""

pesterhazy19:02:14

which is interpreted as "yes it's readable"

pesterhazy19:02:30

then it's checked if it's all whitespace

pesterhazy19:02:56

if it isn't, it calls read, which correctly fails because it EOFs

pesterhazy19:02:35

that's why I modified isWhitespace to mean whitespace-or-comment

anmonteiro19:02:47

I think it makes sense

pesterhazy19:02:58

the code is a bit complicated

pesterhazy19:02:05

it reads the form twice I think

pesterhazy19:02:11

I mean the existing code

pesterhazy19:02:59

that's why I couldn't come up with a non-invasive fix without a larger refactoring

pesterhazy19:02:30

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

pesterhazy19:02:24

by the way, working on lumo is really comfty with the boot dev + yarn dev set up

pesterhazy19:02:42

any idea how to handle the echo "#_1" | lumo case?

pesterhazy19:02:00

I mean I guess you could just catch EOF exceptions

pesterhazy19:02:08

or wrap everything in (do ...) :slightly_smiling_face:

pesterhazy19:02:23

I'm now realizing there's a difference between the "EOF while reading" and "EOF" exception

pesterhazy19:02:41

so maybe we can just catch and ignore the latter exception?

pesterhazy19:02:15

in execute, that is, not in isReadable

mfikes19:02:31

FWIW, in Planck’s 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

pesterhazy19:02:06

didn't realize that portion of the code originated in planck!

anmonteiro19:02:56

Planck influenced a lot of things in Lumo. That's just one of them :slightly_smiling_face:

pesterhazy19:02:09

I was thinking it may be better, instead of is-readable?, to have a fn next that returns [status next-form rest-of-string]

pesterhazy19:02:38

status would be: complete-form, partial-form or no-form

pesterhazy19:02:07

next-form the parsed form if any, and rest-of-string the remainder

mfikes19:02:32

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

anmonteiro19:02:46

right, I think there is some overlap, but not quite the same thing

anmonteiro20:02:25

Planck and Lumo don't exhibit that bug because we are always looking for more input to read

hlolli21:02:04

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

hlolli21:02:33

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

anmonteiro22:02:26

@hlolli nice job figuring it out. /cc @mfikes ^

anmonteiro22:02:02

right, that's probably a consequence of how we do printing in the socket REPL

anmonteiro22:02:13

it's really hacky and we need to fix it

anmonteiro22:02:19

probably a Lumo bug hiding there as well

hlolli22:02:12

yeh ok, weird that the stdout changes from just the go macro, but ok, dont know the code so.

anmonteiro22:02:50

the problem is that it changes synchronously and the go macro messes up with the synchronicity :slightly_smiling_face: