Clojurians
#lumo
<
2017-12-18
>

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

cgrand13:12:31

Hi, what’s the rationale behind the lumo.repl/executeXXX functions being synchronous? and/or: is there a reason for eval and print being bolted together in executeXXX?

hlolli13:12:16

@cgrand you're refering to this part? https://github.com/anmonteiro/lumo/blob/master/src/cljs/snapshot/lumo/repl.cljs#L222-L223 I've been looking at this a tiny bit, when removeing this part, the repl just won't work.

cgrand13:12:37

no, not that

cgrand13:12:10

out of curiosity, do you get a stack overflow if you uncomment that?

hlolli13:12:44

no, not with dev, I remember just typeing command and press enter, and nothing happens and the promt disappears.

anmonteiro13:12:46

what’s the problem with that

cgrand13:12:28

we just get a value out of evaluation and it’s going straight to printing, I’d like to potentially suspend the loop here so it means introcuding a callback

anmonteiro13:12:00

can’t you use lumo.core/eval?

cgrand13:12:37

@anmonteiro sure I can. It all depends on what is your goal. Do you want to make lumo repls “upgradable” or do you want to require user to add some unrepl stuff to their classpath and specify a special :accept?

cgrand13:12:12

The later is already possible since you introduced :accept.

cgrand13:12:02

The former requires current lumo repl to be modified.

cgrand14:12:21

To explain what’s the problem: if you want to make a REPL upgradable then you need to consider the fact that the E in REPL may expand to another REPL, yielding a RR’E’P’L’PL (where all the prime versions are the user upgrade). If you want to allow the user to process input you have to prevent your main loop from processing it. If you want to support several connections at once in JS you can’t do that by blocking.