what's the best way to use your locally built clojurescript jar in maven with -Srepro? :mvn/version doesn't appear to be pulling my latest local artifact... Does -Srepro pull from remote?

:mvn/version should work

In ClojureScript, if you do a script/build it will deploy to your local maven repo

Layer 8 error

How's this:

cljs.user=> js/blah
ReferenceError: blah is not defined
	 (<NO_SOURCE_FILE>)
cljs.user=> (ffirst [1])
Error: 1 is not ISeqable
	 cljs.core/seq (cljs/core.cljs:1221:20)
	 cljs.core/first (cljs/core.cljs:1230:16)
	 cljs$core$ffirst (cljs/core.cljs:1742:4)

LGTM

(defn file-display
  [file {:keys [output-dir temp-output-dir?]}]
  (if (and temp-output-dir? (not= "<NO_SOURCE_FILE>" file))
    (let [canonicalize (fn [file] (.getCanonicalPath (io/file file)))]
      (subs (canonicalize file) (inc (count (canonicalize output-dir)))))
    file))

In theory the value of file could have anything between the angle braces

hmm

There are bits of code here and there that check to see if it starts with "<"

All this stuff was written a couple of years before Spec came out, but this is all we have to go on 🙂 https://github.com/clojure/clojurescript/blob/7a5a65cb4d1eeca63746dd21e138ee9e56676ae4/src/main/clojure/cljs/repl.cljc#L172-L174

k I think I've got something

confusing how it worked at all. All canonical paths, when made as temp file, are coming back as /private/var/folder... whereas the :output-dir is always /var/folder..., so I don't see how the subs is working correctly... but I'm getting closer

ah nevermind

output-dir is getting canonicalized too, so it's getting a /private folder too. So, I'll probably just compare the directories, and if they're different, switch on that.

It's a little hairy 🙂

Yeah, backed out of that strategy. David's try catch suggestion is probably the simplest. Something like:

(defn file-display
  [file {:keys [output-dir temp-output-dir? repl-verbose]}]
  (if temp-output-dir?
    (let [canonicalize (fn [file] (.getCanonicalPath (io/file file)))]
      (try
        (subs (canonicalize file) (inc (count (canonicalize output-dir))))
        (catch Throwable e
          (when repl-verbose
            (println "Failed to canonicalize stacktrace")
            (println (Throwables/getStackTraceAsString e)))
          file)))
    file))

Though perhaps this wouldn't be considered a failing condition, worthy of verbose logging?

Right, that works too. I would probably not log anything. You could think of it as a "best effort" to try to shorten the paths shown.

k

@mfikes You think I should catch on java.lang.StringIndexOutOfBoundsException specifically and let it blow up otherwise?

I don't want to silence any necessarily loud errors here

Well, the call to subs is not meeting its precondition. Perhaps another way to fix it is to not even call it if the first string is too short.

The problem is that "too short" depends on whether the incoming file is actually a file or a string coming in

Because the only way to get the correct length off of the path in front of "<whatever>" is to .getLastIndexOf File.separator

Maybe even a call to starts-with? would make things cleaner

mmm

seems clean. I'll check it

It is really like "/foo/output/dir" and "/foo/output/dir/file" trigger the logic if 2nd starts with the 1st

right... that's the direction I was trying to go in, but the trailing file path confused me. I think starts-with? should work though.

Roughly logic like

(let [output-dir "/foo/output/dir"
      file "/foo/output/dir/file"]
 (if (clojure.string/starts-with? file output-dir)
  (subs file (inc (count output-dir)))
  file))

right

there we go:

(defn file-display
  [file {:keys [output-dir temp-output-dir?]}]
  (if temp-output-dir?
    (let [canonicalize (fn [file] (.getCanonicalPath (io/file file)))
          can-file (canonicalize file)
          can-out (canonicalize output-dir)]
      (if (.startsWith can-file can-out)
        (subs can-file (inc (count can-out)))
        (subs can-file (inc (.lastIndexOf can-file java.io.File/separator)))))
    file))

cljs.user=> js/blah
ReferenceError: blah is not defined
	 (<NO_SOURCE_FILE>)
cljs.user=> (ffirst [1])
Error: 1 is not ISeqable
	 cljs.core/seq (cljs/core.cljs:1221:20)
	 cljs.core/first (cljs/core.cljs:1230:16)
	 cljs$core$ffirst (cljs/core.cljs:1742:4)

Cool

k gotta nother patch up on https://dev.clojure.org/jira/browse/CLJS-2653

trying current cljs master hangs when compiling

bisecting blames https://github.com/clojure/clojurescript/commit/56c774be6227d51f4aa3a52571cb2640c7325db7

investigating…

@dnolen I figured out https://dev.clojure.org/jira/browse/CLJS-2639 will assign to me temporarily to put together a patch

@kommen For now you can work around by adding :cache-analysis true to your compiler options.

You may need to clear out ~/.cljs in order to recover

@mfikes thanks, I just had disabled aot-cache for now

That's another way to do it.

Candiates for closing: https://dev.clojure.org/jira/browse/CLJS-890 https://dev.clojure.org/jira/browse/CLJS-872 https://dev.clojure.org/jira/browse/CLJS-375 https://dev.clojure.org/jira/browse/CLJS-797

https://dev.clojure.org/jira/browse/CLJS-1070

@kommen probably need to memoize

@dnolen not sure. trying to build a demo, a simple app compiles fine with cljs.build.api, but get’s stuck in validate-inputs* with when building it with figwheel-sidecar.repl-api/start-figwheel!

@kommen try master

first, for dep graph stuff if you don’t memoize it’s easy to get into situations where it takes forever

oh though if this something simple then there’s maybe a bug

@kommen the check is quite simple https://github.com/clojure/clojurescript/blob/master/src/main/clojure/cljs/module_graph.cljc#L114-L125

so maybe worth reviewing that to see if there’s a problem

other thing is if you can dump inputs, then we can use that as the test case

@dnolen best way to dump the inputs?

honestly I would just hack the ClojureScript compiler and dump inputs before we call validate-inputs

install that locally and use it

then attach that edn file to a ticket

I’m sure the problem is trivial whatever it is

that said - building tests with ClojureScript uses parallel build so I’m surprised that didn’t catch something simple

trying to dump the inputs, that’s quite a blob. would the :requires and :provides keys be sufficient for the test?

I've been testing Reagent with advanced optimized build and looks like there are few cases (at least with ReactDOM/server) where Closure breaks React code 😕

@kommen yep

@dnolen here you go https://dev.clojure.org/jira/browse/CLJS-2656

thanks

Small fix for npm link: https://dev.clojure.org/jira/browse/CLJS-2658

I've found an issue with source mapping ClojureScript code, but I'm not quite sure where the issue is:

(ns source-map-test2.core)

;; (defonce conn
;;   (repl/connect ""))

(defn test-fn
  [one-one]
  (let [two-two 2]
    ((fn rebind [] one-one))
    (js-debugger)))

(test-fn 1)

compiles to:

// Compiled by ClojureScript 1.9.946 {}
goog.provide('source_map_test2.core');
goog.require('cljs.core');
source_map_test2.core.test_fn = (function source_map_test2$core$test_fn(one_one) {
    var two_two = (2);
    ((function (two_two) {
        return (function source_map_test2$core$test_fn_$_rebind() {
            return one_one;
        });
    })(two_two))
        .call(null);

    debugger;

    return null;
});
source_map_test2.core.test_fn.call(null, (1));

//# sourceMappingURL=core.js.map

If you look at the locals, one-one is resolved twice to the two values

But the non sourcemapped version shows up correctly

I notice the Source map spec says that we always must have 1, 4, or 5 values, but in the generated source maps I see lines with 2 and 3 values:

{"version":3,"file":"<snip>/source-map-test2\/out\/source_map_test2\/core.js","sources":["core.cljs"],"lineCount":18,"mappings":
";
  AAAA;
  ;
  AAKA,gCAAA,hCAAMA,wEACHC;
  AADH,AAEE,cAAA,VAAMC;
  AAAN,AACE,AAAB;
  ;
  AAAA,AAAcD;
  ;
  ;
  ;
  AACf,AAAA;
  ;AAAA
  ;
  ;AAEJ,wCAAA,xCAACD"
,"names":["source-map-test2.core\/test-fn","one-one","two-two"]}

Can this effect line numbers in the console as well?

@danielcompton I believe, this is a bug in chrome devtools, nothing to do with cljs: https://github.com/binaryage/dirac/issues/53

as a side note: speaking about better chrome devtools interaction, it would help if generated javascript could be processed by jsbeautify or something similar which would break long lines into “natural” javascript linebreaks, this would help to place breakpoints and in general interact with devtools debugger (aka “inline breakpoints”) - because for some reason they have some assumptions about the shape of underlying javascript, they treat it as line-based source file and scan N-lines up or have limits on how many inline breakpoints they scan per-line and similar hard-coded line-based limits, compounded with source-mapping bugs this can cause some problems when trying to use devtools debugger with cljs-generated javascript

@darwin good idea

Running code through jsbeautify or such would probably make builds measurably slower, but it should be easy to add some newlines to compiler output?

@juhoteperi I agree that performance is an issue here, I was thinking about a toggle or something optional. Also note that this would be used in dev-time only. And applied to incremental builds most of the time.

Yeah, that could work.

have you tried prettier? it is fast enough that I have it hooked into the save function of my editor

But if it is possible to find certain cases which produce code which is hard to debug, I think it would be easy to add some newlines to output. Like, I think in function calls all arguments are currently written to single line, but they could be easily split to several lines.

whatever works, best would be some in-process java library, which would do the job without spawning a new process

@juhoteperi newlines would help, but I don’t believe this would be a future-proof solution, all future contributors would have to think about newlines for this to not degrade again, but I’m with you here that it is maybe better to improve this at least a bit with this low-hanging-fruit than not at all

I think compiler part doesn't change that often so probably wouldn't be much work keep this working okay

what do you guys think about adding some hook in compiler options as a :post-build step? user could then specify a shell command to run on produced js artifacts

maybe something like this exists already?

preprocess is quite similar but pre hook

(and only for foreign lib files)