This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-03-12
Channels
- # aleph (10)
- # beginners (62)
- # boot (12)
- # cider (97)
- # cljs-dev (171)
- # clojars (1)
- # clojure (224)
- # clojure-italy (4)
- # clojure-nl (2)
- # clojure-russia (1)
- # clojure-spec (41)
- # clojure-uk (68)
- # clojured (7)
- # clojurescript (115)
- # community-development (4)
- # cursive (2)
- # data-science (1)
- # datomic (18)
- # duct (40)
- # emacs (1)
- # events (1)
- # fulcro (148)
- # funcool (2)
- # graphql (2)
- # immutant (3)
- # jobs (3)
- # keechma (1)
- # luminus (2)
- # numerical-computing (1)
- # off-topic (19)
- # om (6)
- # parinfer (10)
- # pedestal (15)
- # precept (86)
- # reagent (12)
- # ring (3)
- # ring-swagger (2)
- # shadow-cljs (42)
- # spacemacs (19)
- # specter (17)
- # sql (11)
- # tools-deps (78)
- # unrepl (62)
- # vim (28)
Every time I look at js.cljs
I am in awe by its simplicity.. maybe because I have been there quite a bit, I really like the fact that in one unique file it is possible to completely understand the whole compilation pipeline. For instance today I learned that when the language returned by load-fn is :js
basically :source
is ignored completely. This means that implementations can avoid a disk read.
A couple of potential post-1.10.x features in the queue now 🙂 - Support for Git deps in Shared AOT Cache (CLJS-2651) - Warn on private var use (CLJS-1702)
compiling replumb
with the new version feels super quick! big improvements
I'm not seeing a jira on this, but on 1.10.145, on a standard -m cljs.main
repl, I get a Exception in thread "main" java.lang.StringIndexOutOfBoundsException: String index out of range: -57
when entering a form like js/blah
where the the reference is not defined. Looks like the cause is cljs.repl/file-display
just clj -m cljs.main
with org.clojure/clojurescript {:mvn/version "1.10.145"}
in my global deps file
I can't repro that with 1.10.145 as well
cljs.user=> js/blah
ReferenceError: Can't find variable: blah
cljs.user=> *clojurescript-version*
"1.10.145"
@john Given that, one thing that might be worth trying is 1.10.145 with -co '{:aot-cache false}'
to see if there is something funky in your ~/.cljs
tree
@mfikes hmm, doing clj -m cljs.main -co '{:aot-cache false}'
now causes the terminal repl to exit without any stacktrace and the browser opens to the correct html content but the browser console says Failed to load resource: net::ERR_EMPTY_RESPONSE
I was wondering the same @john — whether you have some other dependency in the mix that might be doing something strange
trying in a fresh directory, same thing... Blowing away my caches would probably work, but then I'd probably lose the evidence...
right, yeah, 1.10.145 is acting strange on me too, with a blank deps files... I'll clear them
Ahh, maybe it is in the statck trace generation code... did I supply a patch that touched that recently?
in various environments, I'm getting
ReferenceError: "blah" is not defined
(NO_SOURCE_FILE <eval>:1:0)
On 1.10.145 I'm getting strange behavior with just clj -Sdeps '{:deps {org.clojure/clojurescript {:mvn/version "1.10.145"}}}' -m cljs.main
. Browser launches. No html content. repl hangs.
The REPL and main entry points document has been updated to match master https://gist.github.com/mfikes/bdbe214f03abac88ae384adb1ac26490
hmmm. My environment might be tainted... or did something change? Now when I try your example @mfikes clojure -Sdeps '{:deps {github-mfikes/cljs-main-rebel-readline {:git/url "
The browser never connects back to the repl. (on chrome)
@john I just tried that, with Chrome as my default browser, from a fresh directory in /tmp/
and it worked. Perhaps add -Srepro
?
strange, I don't know if I'm using -Srepro
right. I tried that and it didn't work. Same behavior. I wiped out the local directory and that fixed it.
I suspect (I haven't looked at the code), if you have an out
directory sitting there it might be used. This is definitely true if you have an index.html
there.
so if I go about switching between master and release, my artifacts for cljs may not get updated in out? Should I try to trace that down?
@bhauman My guess: :aot-cache
is broken (in some way), so removing its cache directory ~/.cljs/.aot-cache
fixed it for that user
It would be a defect if compilation artifacts derived from source not in JARs was put in the shared AOT cache
@bhauman Yep. FWIW, this patch extends that logic to git deps: https://dev.clojure.org/jira/browse/CLJS-2651
The Figwheel commenter perhaps had a JAR dep with a macro that had a side effect upon expansion or somesuch
@bhauman not sure about that user report - the only way to get into the cache is through compile-from-jar
that makes sense, perhaps the user above got it wrong as well, and drew the wrong conclusion
Documented :launch-browser
in REPL Options https://gist.github.com/mfikes/bdbe214f03abac88ae384adb1ac26490
It is interesting that -ro {:node-command "nodejs"}
won't get passed down to be used to start node (it appears that there are setup
opts
that differ from REPL options, and these are not controllable via cljs.main
(Not suggesting we do anything about this now. If it proves to be an issue, people will let us know.)
so, in my case, the file
being passed into file-display
in cljs.repl
is coming in as NO_SOURCE_FILE
It looks like in Clojure, when there's no source file, it just prints that blah in this context, compiling:(NO_SOURCE_PATH:0:0)
. Would similar behavior be desired here?
This seems to work:
clj -Srepro -Sdeps '{:deps {org.clojure/clojurescript {:git/url "
Seems about the simplest change. Though I'd still need to test for when there is a source file, it doesn't break on chrome.
@john If you've submitted a CA perhaps you could submit a patch to https://dev.clojure.org/jira/browse/CLJS-2653
If you are not familiar with how to do that: https://clojurescript.org/community/patches
Also be sure to not commit the auto-generated change to set the *clojurescript-version*
dyn vars
(Cool. Not speaking to the suitability of the patch; just indicating that this is how they are normally reviewed.)
@john Without digging into it too deeply, I wonder if the problem is in the mapped-stacktrace
fn (or somewhere producing a bad value for :file
) https://github.com/johnmn3/clojurescript/blob/9ef53ad2767b873dc2277bb7174877b084cf6746/src/main/clojure/cljs/repl.cljc#L172
My reading of that is "<NO_SOURCE_FILE>"
is a legal value, but "NO_SOURCE_FILE"
is not bueno.
The problem with conditionally handling the offensive :file
value is that other REPLs may have their own code that also expect a proper :file
value. (Thus arguing for rooting out where it went wrong.)
I'm actually not sure why the index is out of bounds.. perhaps it's just a simple error, and subs
should be returning "NO_SOURCE_FILE"
trimmed?
If the intention is to just get the file name out of the canonical path, I think there's a java method for that. I'll try that.
The problem could be over in cljs.stacktrace/chrome-st-el->frame
and if so, fixed down in there
(The architecture allows for flexibly parsing stack traces produced by different JavaScript environments, and my hunch is that the problem is not in the cljs.repl
code but in the code specific to the Chrome user agent.)
There are a boat load of "manual" tests for :chrome
in the comment, starting around here https://github.com/clojure/clojurescript/blob/master/src/main/cljs/cljs/stacktrace.cljc#L147
Looks like "NO_SOURCE_FILE" is initially passed in here: https://github.com/clojure/clojurescript/blob/e71471324502e4b8249591e82f0789c19370e456/src/main/clojure/cljs/repl.cljc#L339
And this would handle it https://github.com/clojure/clojurescript/blob/e71471324502e4b8249591e82f0789c19370e456/src/main/clojure/cljs/repl.cljc#L314
@john Right, the Safari initial exception is probably different enough to result in there being nothing to elide
cljs.user=> js/blah
ReferenceError: Can't find variable: blah
cljs.user=> (println (.-stack *e))
eval code
eval@[native code]
clojure$browser$repl$evaluate_javascript@http://localhost:9000/clojure/browser/repl.js:116:4
deliver@http://localhost:9000/goog/messaging/abstractchannel.js:141:21
xpcDeliver@http://localhost:9000/goog/net/xpc/crosspagechannel.js:734:19
messageReceived_@http://localhost:9000/goog/net/xpc/nativemessagingtransport.js:321:23
fireListener@http://localhost:9000/goog/events/events.js:744:25
handleBrowserEvent_@http://localhost:9000/goog/events/events.js:870:34
nil
Well that was all, just changing "NO_SOURCE_FILE_"
to "<NO_SOURCE_FILE>"
. If the above output is desired, I can send up a patch this evening.
@john That patch doesn't resolve the issue for me (at least with the way the ticket is written)
The issue appears to be a regression caused by https://github.com/clojure/clojurescript/commit/92ccc3b90a6aef944620856002f44cd4683dd5f8
But your patch helps by giving it a way to detect when to opt out of running the code in the branch temp-output-dir?
is true
in temp-output-dir?
(defn file-display
[file {:keys [output-dir temp-output-dir?]}]
(if (and temp-output-dir?
(not (string/starts-with? file "<")))
(let [canonicalize (fn [file] (.getCanonicalPath (io/file file)))]
(subs (canonicalize file) (inc (count (canonicalize output-dir)))))
file))
when combined with your patch, fixes it for me(That canonicalize stuff is new code, and probably isn't robust. It was just added with https://dev.clojure.org/jira/browse/CLJS-2610)
In what circumstance will the file name not be NO_SOURCE_FILE, when out is a temp dir? When we have an input file at the cli?
One place where you can get file information is for functions in the core library, for example (ffirst [1])
Clearly, my patch in CLJS-2610 is wrong in that it assumes file
is a something you can pass to (io/file ...)
So a minimal fix (that could be combined with yours is to add a bit that fixes the regression I introduced)
What if the subs
part was smart enough to deal with both situations, a file and a NO_SOURCE_FILE
On the surface, it seems like adding that extra check for "<"
is enough. (It certainly fixes things for me with js/blah
in Chrome.
user=> blah
CompilerException java.lang.RuntimeException: Unable to resolve symbol: blah in this context, compiling:(NO_SOURCE_PATH:0:0)
The file canonicalization stuff in CLJS-2610 was handling the case where you get a long path like
/private/var/folders/gx/nymj3l7x4zq3gxb97v2zwzb40000gn/T/out667248762303295388152139830015529/out/cljs/core.js
and it was (naively) trimming off the temp output dir from the beginning.
And tripping up on NO_SOURCE_FILE
case