Fork me on GitHub
#planck
<
2017-07-21
>
moxaj15:07:18

@mfikes if you have planck at hand, could you try evaluating (require 'clojure.tools.reader) in the repl? Throws for me in lumo, but I have a hunch it's a bug upstream

bfabry15:07:42

@moxaj

cljs.user=> (require 'clojure.tools.reader)
nil

moxaj15:07:14

@bfabry might need a fairly recent clojurescript, forgot to add

bfabry15:07:16

sorry should've given all

11326-storage:link_dataflow bfabry$ planck
Planck 2.5.0
ClojureScript 1.9.562
    Docs: (doc function-name-here)
          (find-doc "part-of-name-here")
  Source: (source function-name-here)
    Exit: Control+D or :cljs/quit or exit or quit
 Results: Stored in vars *1, *2, *3, an exception in *e

cljs.user=> (require 'clojure.tools.reader)
nil

moxaj15:07:03

yes, I have my eyes on CLJS-2069, which was fixed in 1.9.655

mfikes15:07:17

@moxaj It is broken with Planck against ClojureScript master:

cljs.user=> (require 'clojure.tools.reader)
No such macros namespace: cljs.tools.reader, could not locate cljs/tools/reader.clj or cljs/tools/reader.cljc
cljs.user=> *clojurescript-version*
"1.9.820"

moxaj15:07:57

alright, thanks for checking, gonna log a jira

mfikes15:07:17

@moxaj Perhaps a minimal self-host repro can be trivially produced with https://clojurescript.org/community/reporting-bootstrap-issues

moxaj15:07:37

I was looking at one of your self host tickets

moxaj15:07:32

(require 'cljs.js)

(cljs.js/eval-str (cljs.js/empty-state)
                  "(ns cljs.user (:require [clojure.tools.reader]))"
                  nil
                  {:eval cljs.js/js-eval}
                  println)

moxaj15:07:36

I think this is good enough?

mfikes15:07:44

@moxaj Right, that is a more complicated regression where you actually need to handle code loading. I bet the single-form version on the site works for this, since it is just a require form.

mfikes15:07:16

Yes, if that repro’s. A slightly more minimal version is to replace the ns with (require 'clojure.tools.reader)

moxaj15:07:34

that repros for me, in lumo at least

moxaj15:07:46

and lumo shouldn't interfere in that, so probably not lumo specific

mfikes15:07:50

You may need to add :context :expr

mfikes15:07:50

You want to ensure it repros with java -jar cljs.jar -m cljs.repl.nashorn ideally

moxaj16:07:00

@mfikes I think I got it:

(require 'cljs.js)

(cljs.js/eval-str (cljs.js/empty-state)
                  "(require 'clojure.x)"
                  nil
                  {:eval cljs.js/js-eval
                   :load (fn [{:keys [name macros]} cb]
                           (cb (when (and (= name 'cljs.x)
                                          (not macros))
                                 {:lang   :clj
                                  :source "(ns cljs.x)"})))}
                  println)

moxaj16:07:05

with this, it repros in nashorn

moxaj16:07:11

hope i'm using load-fn right, thinking of the (not macros) part. I'd assume this should not trigger loading cljs.x as a macros namespaces (but it tries to, hence the error)

mfikes16:07:32

Hmm @moxaj, what you are doing there is returning ‘cljs.x for ‘clojure.x

mfikes16:07:48

That’s not how cljs.js actually works

mfikes16:07:22

It will first try loading 'clojure.x and that is supposed to fail, and then cljs.js will fall back to 'cljs.x

moxaj16:07:38

(and (= name 'cljs.x))

moxaj16:07:50

it'll fail at the first try

mfikes16:07:50

Oh, right 🙂

moxaj16:07:17

with verbose, I see the exact same debug messages as with lumo

mfikes16:07:18

So, with that small repo, it should be possible to bisect now 🙂

mfikes16:07:38

Or, more importantly, we should be able to see whether your repro successfully worked in the past

mfikes16:07:58

Just download an older cljs.jar and try it

moxaj16:07:29

yep, i'll try 1.9.562

mfikes16:07:25

Interestingly, you can see a hint of how it derails in 1.9.660:

(cljs.js/eval-str (cljs.js/empty-state)
                  "(require 'clojure.x)"
                  nil
                  {:eval cljs.js/js-eval
                   :load (fn [{:keys [name macros]} cb]
           (prn name macros)
                           (cb (when (and (= name 'cljs.x)
                                          (not macros))
                                 {:lang   :clj
                                  :source "(ns cljs.x)"})))}
                  println)
clojure.x nil
cljs.x true
{:error #error {:message No such macros namespace: cljs.x, could not locate cljs/x.clj or cljs/x.cljc, :data {:tag :cljs/analysis-error}}}
nil

mfikes16:07:51

It seems to jump to falling back to a macros namespace!

mfikes16:07:21

That aint right 🙂

moxaj16:07:47

that's what I see in lumo and 1.9.671 as well

mfikes16:07:54

But yes, @moxaj I think that’s a good minimal (REPL-driven) repro, very useful for bisecting on as well

moxaj16:07:59

that true shouldn't be there

mfikes16:07:22

Yes, I bet in 1.9.562 it trys with a falsey value for macros

moxaj16:07:53

oh, if I wasn't on windows 😞. I don't see any windows equivalent for script/clean && script/bootstrap && rm -rf .cljs_node_repl && script/noderepljs

moxaj16:07:06

there's a repljs.bat, but that's it

mfikes16:07:30

There is script\bootstrap.ps1, and yes, script\repljs.bat. You can probably figure out the way to remove the .cljs_node_repl tree, and the one last bit missing is a Windows version of script/clean

moxaj16:07:15

seems easy enough to port

mfikes16:07:20

Oh, just look at the contents of script/clean @moxaj , you could probably write a bat file that does that

mfikes16:07:34

It is just deleting various trees

mfikes18:07:15

Awesome. Great job!

moxaj18:07:04

wouldn't it be nice if the scripts were cljs scripts ran with planck/lumo 🙂 would be really meta

mfikes18:07:55

Right! Planck does that, especially for the scripts that drive its tests.

mfikes18:07:58

But, that would be a dep in ClojureScript that wouldn’t be desired, I would guess. It would make the script portable, on the other hand 🙂

moxaj18:07:14

there could be a small shell/powershell script which bootstraps planck/lumo, which then would bootstrap cljs

mfikes18:07:27

I am intrigued with the implication of Alex Miller’s deps talk might be with respect to easily firing up Clojure-based scripts.

moxaj18:07:45

is that published online somewhere? really looking forward to watching it

moxaj18:07:48

oh, misread your sentence, you haven't seen it either

mfikes19:07:04

Right, I’m awaiting them to start flowing onto YouTube

anmonteiro20:07:16

@mfikes last year it took a couple months