Clojurians
#cljs-dev
<
2017-04-25
>

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

thheller07:04:53

maybe there is some place to extend this

thheller07:04:35

but I think the :externs-sources is populated by the calls you mention above

thheller07:04:32

not familiar with what happens in cljs.closure at all

cgrand13:04:10

I’ve been working on making the REPL for self-hosted CLJS a “real” REPL. https://github.com/cgrand/cljs-js-repl/blob/master/README.md This repo contains: • an async input stream protocol with a couple of impls (PipeReader, StringReader, LineColNumberingReader) in the io namespace • an async reader (and its EDN pendant too) built on top of io • an async port of clojure.main/repl (dynamic bindings are correctly supported so you can have several ns at once) All of this allows to take over the REPL session and installs another REPL (or whatever) like one can do with a Clojure REPL. I believe it would be beneficial to have a better common REPL infrastructure. I’d like to discuss if/how it’s possible to have such features in Clojurescript.

cgrand15:04:18

@mfikes @anmonteiro I just realized that my repl works by accident because eval is not really async. If I add a setTimeout it messes things. However upon further analysis I think there’s a fundamental problem with async eval: it can’t capture and restore the dynamic context where it was invoked (`cljs.js/eval*` supports a handful of hardcoded dynvars but no hook for the user to setup her env.)

anmonteiro15:04:00

Yeah, bindings don't work in an async environment

anmonteiro15:04:31

@cgrand if you look at the cljs.js namespace you'll see that it passes bound-vars around

anmonteiro15:04:48

Which are captured when first calling a method from that namespace

cgrand15:04:29

@anmonteiro yes but afaict it’s a closed set, no?

anmonteiro15:04:56

Probably is. You may be able to add more to that context by calling private fns

anmonteiro15:04:30

But I wouldn't encourage you to do that

cgrand15:04:59

so (binding [*foo* 42] (eval '*foo* (fn [r] (prn (:value r)))) can’t work.

cgrand15:04:05

I used *foo* but even *print-fn* isn’t passed around

cgrand15:04:24

Hmm no, I don’t think. Well I have done about the same (`dynvars` ns). Maybe something hacky could be done

john16:04:03

And there's nothing that could be done with web workers, to make a seemingly async eval?

john16:04:59

no I suppose not...

john16:04:57

What about a run time loop that constantly carries bindings forward? Something like a gameloop like: https://github.com/rm-hull/big-bang

dnolen16:04:41

@cgrand there’s really no way to make this work, if namespaces are to be loaded from disk or across the wire - which they often are

dnolen16:04:47

in JS anyway

dnolen16:04:37

some groundwork would have to be done first - an efficient bound-fn

dnolen16:04:52

Brandon Bloom had a interesting proposal about that

dnolen16:04:36

but it seemed like it would still have problems

cgrand17:04:16

@dnolen that's where I was getting: a binding conveyance mechanism is needed even if it's an opt in. Do you have the link to Brandon's proposal handy?

dnolen19:04:16

I don’t think any of the ideas got written up anywhere

oahner20:04:29

is the test suite supposed to work on windows out of the box?

dnolen20:04:13

@oahner it should but I think the small number of Windows using ClojureScript means it’s unclear how good/bad the experience is

oahner20:04:22

ahh, gotcha

oahner20:04:12

well, it's surprisingly okay; I'm using msys2 and got all the sh scripts working by tweaking the classpaths to use ; instead of :

oahner20:04:25

since java is set to path.separator as ; on windows

dnolen20:04:05

ok cool, I thought someone added working PowerShell thing at one point?

oahner20:04:26

I tried it but couldn't get it to work; it fails trying to run bin/cljsc

oahner20:04:24

would you be interested in a patch that modifies the sh scripts to checks what the current host's JVM path separator property is and uses that? I believe that would satisfy all platforms

oahner20:04:21

the alternative would be to provide batch scripts for all the sh scripts