Fork me on GitHub
#cljs-dev
<
2018-02-23
>
dnolen00:02:28

there might be a lot of reasons why that one doesn’t work

richiardiandrea02:02:16

I wouldn't know where to start digging even 😄

mfikes14:02:09

A nice visual demo of the power of cljs.main and git deps: https://gist.github.com/mfikes/e600e965da916699a703c9b1f1ff6d3b

sundarj14:02:13

super cool!

dnolen14:02:36

that’s pretty neat

mfikes14:02:14

I'm currently digging into why it fails on one of my boxes...

dnolen14:02:20

I’m whittling down what I think is necessary for the next release - the only 2 big ticket items are pREPL & caching

dnolen14:02:12

let me know if there’s some smaller things you’d like to see get included and I’ll think about it

dnolen14:02:39

anything around improving cljs.main will be prioritized of course

mfikes15:02:05

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

dnolen15:02:42

@rauh I’m not really interested in any of these smaller perf patches for now

dnolen15:02:15

we can easily get them in afterwards, this release is going to be a whopper as it is

mfikes15:02:31

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.

mfikes15:02:19

BTW, I forgot to mention: Unit tests are failing in "CI"

mfikes15:02:10

Oh, Chakra download is missing? Hrm.

mfikes15:02:37

Maybe Microsoft's Akamai CDN is messed up

mfikes15:02:18

Looks like the content moved. Will test and submit a patch to the .travis.yml

dnolen15:02:49

@mfikes all in good time I think as people start using deps.edn, getting to work of shas will eventually be a thing

mfikes15:02:55

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

mfikes15:02:59

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 🙂

rauh15:02:49

@mfikes I'm using jsvu locally, not sure if that might be easier for the CI: https://github.com/GoogleChromeLabs/jsvu

mfikes15:02:06

Interesting. FWIW, we are currently using fairly straightforward mechanisms to fetch / install VMs: https://github.com/clojure/clojurescript/blob/master/.travis.yml#L9-L13

dnolen17:02:43

@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

thheller17:02:53

@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

thheller17:02:17

but I don't think there is anything official

dnolen17:02:36

yeah I think this should be fixed to match Clojure

dnolen17:02:42

@bronsa blocked from implementing pREPL until tools.reader supports the same operation, either by delivering read+string (preferable) or by providing stable hooks

dnolen17:02:01

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.

richiardiandrea17:02:36

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)

bronsa18:02:14

@dnolen I'll add read+string in the next few days

bhauman18:02:54

@dnolen just pinging you about backgrounding the watcher for the cljs.main cli when the repl is requested

bhauman18:02:20

also looking forward to seeing how prepl is shaping up

dnolen18:02:31

@bhauman oh right can you raise that priority to critical so I don’t forget.

bhauman18:02:46

is there a ticket?

bhauman18:02:53

I'll find it if there is

dnolen18:02:59

If not need one

bhauman18:02:11

cljs.main is going to be so great for git bisect

mfikes19:02:20

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

mfikes21:02:46

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

bhauman21:02:21

that's awesome stuff @mfikes 🙂

mfikes21:02:04

It is great when you have 2 or 3 things not specifically designed to work directly with each other successfully composing. 🙂

bhauman21:02:31

good on us!!!

richiardiandrea21:02:21

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)

mfikes21:02:46

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

dnolen21:02:23

I don’t I’m going to bother with a standard eval in clj, it’s trivial

richiardiandrea21:02:31

nnnniiiiiiceeeee

richiardiandrea21:02:47

more work for inf-clojure contributors 😅

dnolen21:02:54

anyways pREPL clients can do what ever they want

dnolen21:02:00

everything is always in order

dnolen21:02:10

so you can distinguish tooling stuff from user stuff

dnolen21:02:00

pREPL does do a lot less of course - no prompt, etc.

dnolen21:02:24

but I don’t really think that stuff is hard to do anyway

bhauman21:02:05

how does that read+string work?

dnolen21:02:38

you need Clojure 1.10.0-alpha4 for this stuff, read+string is there

bhauman21:02:55

it will work for clojurescript forms?

dnolen21:02:20

it will when tools.reader supports it, @bronsa is already aware

dnolen21:02:48

but what’s here is probably enough for experimenting which I encourage

ghadi21:02:03

Define "in order" @dnolen?

dnolen21:02:25

order is enforced

dnolen21:02:34

serialized order

dnolen21:02:49

so if you write a form you know the next :ret will be for what you wrote

ghadi21:02:09

Ah. (Out/err can come late though)

dnolen21:02:57

@ghadi but you can ignore those anyway

dnolen21:02:13

in the tooling case, you can’t know about random I/O side effects anyhow

dnolen21:02:35

note that :out :err :ret :tap are all distinguished

dnolen21:02:10

one form, one :ret is the invariant tooling can rely on

dnolen22:02:26

looking over pREPL the only thing I can see that it needs doing is create user ns, and I need to implement specials

dnolen22:02:42

if there’s something else people want it to do, let’s discuss

bhauman22:02:40

in my mind it would be nice if the cljs.repl/wrap-fn captured printed output on the client and sent it back

bhauman22:02:29

along with the value

bhauman22:02:51

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

dnolen22:02:12

I don’t know what you mean by the wrap-fn bit

dnolen22:02:29

the value is always pr-stred thing on the client

dnolen22:02:34

that’s the only option

dnolen22:02:01

but I don’t know what you mean

bhauman22:02:24

(eval (print "hello"))

bhauman22:02:50

the clojure prepl captures out

dnolen22:02:03

oh right there’s a category of things that we should separate before we think about to solve it

bhauman22:02:19

absolutely

dnolen22:02:21

tap> and printing belong to that category

bhauman22:02:58

the wrap-fn idea was only a simple idea to include a {:out "hello" :value nil} to simply duplex the result value

bhauman22:02:55

but there are better solutions

dnolen22:02:15

yeah changing wrap-fn isn’t necessary

bhauman22:02:16

I really like the idea of a tap on the client side

dnolen22:02:19

you don’t need that

dnolen22:02:40

we capture out at pREPL, as long as you print in your REPL implementation this works correctly

dnolen22:02:46

same story for tap> on client

dnolen22:02:28

*tap-fn* is all you’ll need to override, just like *print-fn*

dnolen22:02:58

pREPL is nice and simple 🙂

bhauman22:02:05

this is good stuff 🙂

dnolen22:02:15

hrm actually, what I said about out is true, but *tap-fn* is a bit trickier

dnolen22:02:20

actually no *tap-fn* is easy 🙂

dnolen22:02:37

so REPLs can communicate that however they want, then in Clojure they just call tap> … done

dnolen22:02:52

so the pattern is same as forwarding out

bhauman22:02:13

there is a big difference here

bhauman22:02:49

for the clojure prepl I can send an eval that calls tap>

bhauman22:02:08

in cljs I presume there will be a macro?

dnolen22:02:22

it will work exactly like *print-fn*

dnolen22:02:29

REPLs have to handle it

dnolen22:02:35

on the Clojure side you print

dnolen22:02:55

and pREPL captures that because it rebound *out*

dnolen23:02:14

so it’ll be the same for tap

bhauman23:02:28

just to make sure we are talking about the same thing

bhauman23:02:42

in the clojure prepl I can eval (future (loop ... (tap> )))

bhauman23:02:53

to get some tooling going

dnolen23:02:03

tap> just a data solution to the logging problem

bhauman23:02:45

I get that

dnolen23:02:01

semantics are just that anyone that calls it with some data, it will just appear in pREPLs as :tap

dnolen23:02:08

there’s no difference for ClojureScript

dnolen23:02:22

REPLs need to construct support individually for tap> is what I’m saying

dnolen23:02:25

same as printing

bhauman23:02:53

so there will be ClojureScript tap>

dnolen23:02:01

yes sorry for not being clear 🙂

dnolen23:02:13

tap> will use *tap-fn* which normally not defined

bhauman23:02:52

yep I missunderstood your first statement

dnolen23:02:53

then when you read that back in your custom REPL you call tap> in Clojure

bhauman23:02:12

that makes sense

dnolen23:02:24

so it’s very straightforward, just a few lines of code

dnolen23:02:03

@bhauman actually this is simpler

dnolen23:02:34

it’s the client REPL code that calls add-tap to grab stuff

bhauman23:02:48

this makes more sense if I'm understanding you

bhauman23:02:07

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

bhauman23:02:26

but I'm not thinking hard enough about it right now

dnolen23:02:58

pREPL isn’t a remote REPL

bhauman23:02:59

but yes add-tap registers a listener

dnolen23:02:04

it’s just a programmatic REPL

bhauman23:02:11

yep I get it

dnolen23:02:25

and you can compose it with socket REPL if you like

dnolen23:02:27

but not neccessary

dnolen23:02:05

added the tap stuff to master

dnolen23:02:30

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

richiardiandrea23:02:04

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.

richiardiandrea23:02:29

I thought it was just an easy patch but it is probably not what I was imagining

dnolen23:02:54

@richiardiandrea Closure is supposed to handle that, but I think module-deps also does some work

richiardiandrea23:02:36

ok, so I will reopen the issue, it requires more digging