<< Back to previous view

[CLJS-1070] top-level boolean inference does not work Created: 28/Feb/15  Updated: 30/Mar/15

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: 0.0-3115
Fix Version/s: Next

Type: Defect Priority: Minor
Reporter: David Nolen Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None


 Description   

Problem for using boolean Closure defines



 Comments   
Comment by Francis Avila [ 30/Mar/15 12:02 PM ]

I am unsure if this is the same issue, but forms like ^boolean (js/isFinite n) also do not seem to analyze correctly: if, and, and or will still emit a call to truth_.





[CLJS-1178] Compiler does not know Math ns is not not-native Created: 29/Mar/15  Updated: 29/Mar/15

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Minor
Reporter: Francis Avila Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: compiler

Attachments: Text File cljs-1178.patch    
Patch: Code

 Description   

With static-fns true, compiler will emit invocations of functions in the Math "namespace" with a conditional arity check or .call() because it does not know that the Math namespace is not not-native. Example with the fix function (advanced compilation, pseudo-names true):

function $cljs$core$fix$$($q$$28$$) {
  return 0 <= $q$$28$$ ? Math.floor.$cljs$core$IFn$_invoke$arity$1$ ? Math.floor.$cljs$core$IFn$_invoke$arity$1$($q$$28$$) : Math.floor.call(null, $q$$28$$) : Math.ceil.$cljs$core$IFn$_invoke$arity$1$ ? Math.ceil.$cljs$core$IFn$_invoke$arity$1$($q$$28$$) : Math.ceil.call(null, $q$$28$$);
}

With attached patch, the following is emitted instead:

function $cljs$core$fix$$($q$$28$$) {
  return 0 <= $q$$28$$ ? Math.floor($q$$28$$) : Math.ceil($q$$28$$);
}





[CLJS-1164] quot and rem are inefficient Created: 24/Mar/15  Updated: 29/Mar/15

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Enhancement Priority: Minor
Reporter: Francis Avila Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: math

Attachments: Text File cljs-1164.patch    
Patch: Code and Test

 Description   

The implementation of the quot and rem functions are needlessly complicated. Currently they are:

(defn quot [n d] (fix (/ (- n (js-mod n d)) d)))
(defn rem [n d] (- n (* d (quot n d))))

However all numbers in js are doubles already, so all this is unnecessary:

(defn quot [n d] (fix (/ n d)))
(defn rem [n d] (js-mod n d)))

Notice that "rem" is simply js-mod, and I'm not sure why no one noticed this before. I keep js-mod for now since a lot of code uses it, and if cljs ever grows a number tower the distinction may be important.

Patch attached, which also:

  • Creates a macro version of quot and rem.
  • Updates documentation for quot, rem, js-mod and mod for clarity.
  • Implement fix (private function to round to zero) with ES6 Math.trunc() if available.

Existing quot and rem tests pass, although there could be some better tests of edge cases (negative decimal num or div, NaN and +-Infinity args).



 Comments   
Comment by Francis Avila [ 24/Mar/15 12:27 PM ]

Better tests found rounding errors in my updated rem, which should stay as-is. (Not simply js-mod after all! Seems to round args first? Not obvious from the spec.) Changed quot however is correct and introduces less error than the current one. Will update patch and tests when I get a chance.

Comment by Francis Avila [ 29/Mar/15 12:39 AM ]

Working patch with tests attached. Tests expanded to cover floating-point cases. rem is now fundamentally the same as master (was more accurate than js-mod!!), but returns results consistent with js-mod for non-finite args or zero divisor.





[CLJS-1177] A compiler pass for JS dialects Created: 28/Mar/15  Updated: 28/Mar/15

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: 0.0-3126
Fix Version/s: None

Type: Enhancement Priority: Major
Reporter: David Nolen Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None


 Description   

There are now a variety of JS dialects, JSX, TypeScript etc. which need to be transformed first into regular JS before module processing. We should devise a standard way to deal with this. As we cannot predict what various dialects may arise in the future it's probably best to provide something like :preprocess-module option to cljs.closure/build.






[CLJS-1141] memoization of js-dependency-index and get-upstream-deps needs knobs Created: 18/Mar/15  Updated: 28/Mar/15

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: 0.0-3123
Fix Version/s: Next

Type: Enhancement Priority: Major
Reporter: David Nolen Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None

Attachments: Text File CLJS_1141.patch     Text File CLJS-1141-with-js-dep-caching-latest.patch    

 Description   

knobs should be exposed for more dynamic compilation environments like Figwheel which may desire to add dependencies to the classpath on the fly.



 Comments   
Comment by Bruce Hauman [ 21/Mar/15 3:51 PM ]

A patch that caches upstream dependencies in the compiler env.

Comment by Bruce Hauman [ 21/Mar/15 3:59 PM ]

Actually I'm going to submit another patch that includes the memoize calls in js-deps.

Comment by Bruce Hauman [ 28/Mar/15 12:50 PM ]

New patch that moves cljs.js-deps memoization to current env/compiler as well as get-upstream-deps.

Unfortunately there is a circular dep between cljs.env and cljs.js-deps, if we want to cache in env/compiler. I overcame this with a resolve.

Compile performance is either completely unchanged or slightly improved based on several test runs.

Comment by Bruce Hauman [ 28/Mar/15 2:22 PM ]

Hold off on this. Its not behaving as expected. Doesn't seem to be caching in certain situations.

Comment by David Nolen [ 28/Mar/15 2:26 PM ]

Thanks for the update. This will definitely not land until after the pending REPL/piggieback release anyhow.

Comment by Bruce Hauman [ 28/Mar/15 2:44 PM ]

Yeah there is an obvious bug and a subtle one. Hopefully will finish it up soonish.

Comment by Bruce Hauman [ 28/Mar/15 3:43 PM ]

Alright, this latest patch works. There was a subtle memoizing nil value bug.





[CLJS-1175] CLJS defmulti doesn't exhibit same defonce behavior as Clojure's defmulti, suggesting an even better reloading behavior Created: 27/Mar/15  Updated: 28/Mar/15  Resolved: 28/Mar/15

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: 0.0-3126
Fix Version/s: Next

Type: Defect Priority: Major
Reporter: Bruce Hauman Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: None


 Description   

I just noticed that the redefinition of a defmulti completely destroys the dispatch table associated with it.

This is not the case in Clojure.
http://dev.clojure.org/jira/browse/CLJ-900
https://github.com/clojure/clojure/commit/1b8d5001ba094053b24c55829994785be422cfbf

I actually think the better behavior is to create a new MultiFn with the new options and steal the dispatch table state from the current MultiFn.

I think this is the least surprising behavior.



 Comments   
Comment by David Nolen [ 27/Mar/15 1:32 PM ]

defmulti in Clojure has defonce semantics. I don't think we need to do anything at all beyond that. Patch welcome for this.

Comment by David Nolen [ 28/Mar/15 12:29 PM ]

fixed https://github.com/clojure/clojurescript/commit/380c8b19c5fada55c40759063a4a23332bc7fdf8





[CLJS-1176] Push node.js REPL output through *out* and *err* Created: 27/Mar/15  Updated: 28/Mar/15  Resolved: 28/Mar/15

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: 0.0-3126
Fix Version/s: Next

Type: Enhancement Priority: Major
Reporter: Chas Emerick Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None

Attachments: File CLJS-1176.diff    
Patch: Code

 Description   

The node.js REPL environment currently lets the child node process inherit the JVM's stdout/err. This is bad for nREPL, and for any other setup where one would like to rebind *out* and/or *err* in order to redirect content print ed by ClojureScript code. Turning off the inheritance and pumping output from the process to *out* and *err* should be straightforward.

Related nREPL/piggieback issue: https://github.com/cemerick/piggieback/issues/41



 Comments   
Comment by Chas Emerick [ 28/Mar/15 5:10 AM ]

Patch attached. Node REPL now sends output to *out* and *err*.

Comment by David Nolen [ 28/Mar/15 12:07 PM ]

fixed https://github.com/clojure/clojurescript/commit/a7f2a85d9df15e912dff71a8c95529bcfe459882





[CLJS-1174] Simple warning if a namespace with dashes not found but a file path with dashes exists Created: 27/Mar/15  Updated: 27/Mar/15

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: 0.0-3126
Fix Version/s: Next

Type: Enhancement Priority: Major
Reporter: David Nolen Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None





[CLJS-1173] standard way to identify types originating from ClojureScript Created: 27/Mar/15  Updated: 27/Mar/15

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: 0.0-3126
Fix Version/s: Next

Type: Defect Priority: Major
Reporter: David Nolen Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None





[CLJS-742] Compilation with :output-file option set fails Created: 03/Jan/14  Updated: 27/Mar/15

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: 0.0-3115
Fix Version/s: Next

Type: Defect Priority: Trivial
Reporter: Timothy Pratley Assignee: Timothy Pratley
Resolution: Unresolved Votes: 0
Labels: None

Attachments: File CLJS-742.diff    
Patch: Code

 Description   

./bin/cljsc hello.cljs '{:output-file "foo.js"}'

Expected:
a file called foo.js

Actual:
Compiler throws an internal error

Notes:
The correct option is :output-to
:output-file might be removable (it is broken, nobody is using it?)
Further analysis required to determine if it is useful to keep.



 Comments   
Comment by Timothy Pratley [ 03/Jan/14 12:14 PM ]

Fixes handling of compiling one IJavaScript or many

Comment by Timothy Pratley [ 08/Oct/14 11:03 PM ]

Patch is attached, updating ticket to reflect that

Comment by David Nolen [ 27/Mar/15 7:44 AM ]

Can we get a patch rebased to master? Thanks.





[CLJS-808] Warning from `find-classpath-lib` mistakenly included in generated source Created: 02/Jun/14  Updated: 27/Mar/15  Resolved: 27/Mar/15

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: 0.0-3115
Fix Version/s: Next

Type: Defect Priority: Major
Reporter: Joshua Ballanco Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: None
Environment:

clojurescript 0.0-r2227
target: node


Attachments: Text File warn-with-out-str-fix.patch    
Patch: Code

 Description   

When compiling for node.js, `find-classpath-lib` generates a warning because `cljs/nodejs.js` doesn't contain a `goog.provide` declaration. However, this warning ends up being emitted into the JS files being generated (caused by a call to `with-out-str`), later causing a critical failure in the Closure compiler.

To reproduce:

  • `lein new cljs-node buggy`
  • Update clojurescript to r2227, lein-cljsbuild to 1.0.3
  • `lein cljsbuild once`

Result:

  • Multiple warnings
  • Generated "buggy.js" file contains only node.js shebang

Fix:

  • The simplest patch (attached) is to rebind `out` to `err` when emitting a warning
  • A better fix would be to write a function for error printing that wraps this idiom
  • Ideally, cljs/nodejs.js should have a `goog.provides` line added to prevent the warning in the first place


 Comments   
Comment by David Nolen [ 02/Jun/14 7:45 AM ]

A patch that adds a goog.provide to the file is preferred, thanks!

Comment by David Nolen [ 27/Mar/15 7:42 AM ]

fixed https://github.com/clojure/clojurescript/commit/9cddd7581c5cdacfe4f4f20274aed61cd3cfc7cb





[CLJS-1144] Expose MultiFn assessors Created: 18/Mar/15  Updated: 27/Mar/15  Resolved: 27/Mar/15

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: 0.0-3123
Fix Version/s: Next

Type: Enhancement Priority: Major
Reporter: Joel Holdbrooks Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: None

Attachments: Text File 1144.patch    

 Description   

The MultiFn fields default-dispatch-val and dispatch-fn are useful in some cases. It would be nice to have accessors for these fields instead of having to use property access directly.



 Comments   
Comment by Joel Holdbrooks [ 18/Mar/15 12:31 PM ]

Added patch

Comment by David Nolen [ 27/Mar/15 7:35 AM ]

fixed https://github.com/clojure/clojurescript/commit/4eebd45bd82f40c8e656d97ee996ed91c48a3ec5





[CLJS-1172] Determine if practical to supply main entry points for all standard REPLs Created: 26/Mar/15  Updated: 27/Mar/15  Resolved: 27/Mar/15

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: 0.0-3126
Fix Version/s: Next

Type: Task Priority: Major
Reporter: David Nolen Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None


 Comments   
Comment by David Nolen [ 27/Mar/15 5:21 AM ]

fixed https://github.com/clojure/clojurescript/commit/9d7ee61070ba50dce283dea2b4c5caceaf8002cc





[CLJS-1171] map clojure.repl/doc, clojure.repl/source, clojure.repl/dir Created: 26/Mar/15  Updated: 27/Mar/15  Resolved: 27/Mar/15

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: 0.0-3126
Fix Version/s: Next

Type: Defect Priority: Major
Reporter: David Nolen Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None


 Comments   
Comment by David Nolen [ 27/Mar/15 5:02 AM ]

fixed https://github.com/clojure/clojurescript/commit/a8809d7030a82943d40094aeffa84c0f573630e9





[CLJS-1170] expose macroexpand & macroexpand-1 at the REPL Created: 26/Mar/15  Updated: 27/Mar/15  Resolved: 27/Mar/15

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: 0.0-3126
Fix Version/s: Next

Type: Defect Priority: Major
Reporter: David Nolen Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None


 Comments   
Comment by David Nolen [ 27/Mar/15 4:58 AM ]

fixed https://github.com/clojure/clojurescript/commit/f58861149dac8a8e61e34414903ed43c01acbe91





[CLJS-1169] cannot use REPL load-file on files that declare single segment namespaces Created: 26/Mar/15  Updated: 26/Mar/15  Resolved: 26/Mar/15

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: 0.0-3126
Fix Version/s: Next

Type: Defect Priority: Major
Reporter: David Nolen Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: None


 Description   

While not encouraged for projects, being able to do this when trying thing out is convenient.



 Comments   
Comment by David Nolen [ 26/Mar/15 9:19 PM ]

fixed by b17edea679fab22bafb949f0cffb01c1c55d33c9





[CLJS-288] Compilation of unordered collections Created: 31/May/12  Updated: 25/Mar/15  Resolved: 25/Mar/15

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Trivial
Reporter: Brandon Bloom Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: None


 Description   

Given:

(defn f [x] (println x) x)

{(f 5) (f 10), (f :x) (f :y)}

Clojure produces:

5
10
:x
:y

{5 10, :x :y}

ClojureScript produces:

5
:x
10
:y

{5 10, :x :y}

 Comments   
Comment by Brandon Bloom [ 16/Aug/12 9:28 PM ]

See also: CLJ-1043

I realized that this problem is actually only partially solvable as is. We could assign the interleaved keys and values to locals before constructing the map. Unfortunately, that doesn't solve a bigger underlying problem: The reader returns unordered sets and maps.

Comment by David Nolen [ 31/Aug/12 9:23 AM ]

Is this actually a problem?

Comment by Brandon Bloom [ 23/Sep/12 7:40 PM ]

See discussion at http://dev.clojure.org/jira/browse/CLJ-1043?focusedCommentId=29526#comment-29526

Comment by Brandon Bloom [ 25/Mar/15 8:08 PM ]

See discussion at CLJ-1043





[CLJS-1168] REPL fails to find .js files in :libs Created: 25/Mar/15  Updated: 25/Mar/15

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: Next, 0.0-3126
Fix Version/s: Next

Type: Defect Priority: Major
Reporter: Daniel Skarda Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Environment:

org.clojure/clojurescript 0.0-3149
Tested with both basic clojurescript REPL and new com.cemerick/piggieback 0.2.0-20150324.120715-1



 Description   

We use Google E2E library for encryption. This library is written using Google Closure.
The library is stored locally in a directory ("closure-libs/e2e") and we pass :libs ["closure-libs/e2e"] to the compiler.

Compilation of our project works fine. Compiler does find the library without problems in all optimization modes.

Recently we have problem with REPL. With same parameters, REPL fails to load the library:

java.lang.IllegalArgumentException: Namespace e2e.async.Result does not exist
at cljs.closure$source_for_namespace.invoke(closure.clj:501)
at cljs.repl$load_namespace.invoke(repl.clj:181)
at cljs.repl$load_dependencies.invoke(repl.clj:201)
at cljs.repl$evaluate_form.invoke(repl.clj:444)
at cljs.repl$eval_cljs.invoke(repl.clj:527)
at cljs.repl$repl_STAR_$read_eval_print__4890.invoke(repl.clj:783)
at cljs.repl$repl_STAR_$fn_4896$fn_4903.invoke(repl.clj:821)
at cljs.repl$repl_STAR_$fn__4896.invoke(repl.clj:820)
at cljs.compiler$with_core_cljs.invoke(compiler.clj:951)
at cljs.repl$repl_STAR_.invoke(repl.clj:785)
at cryptelo.dev.cljs.env$eval11953.invoke(02b7dffab3345931421313ec2fe5d506990ab5e5-init.clj:1)

I spent long time investigating the issue (which is not easy given jungle of compiler and repl option maps, bindings of global variables etc).

What I found:

  • compiler finds the library without problem, all our tests invoked from the command line pass
  • both basic cljs REPL and piggieback (0.2.0 experimental branch) fails to find the library
  • :libs files are not copied to :output-dir
  • at the beginning, repl calls default-compiler-env with options
  • default-compiler-options run js-dependency-index, which scans all libraries and stores it in compiler atom
  • strace proves that clojurescript finds closure-libs/e2e/deps.js and reads it
  • calling (js-dependency-index {:libs ["closure-lib/e2e"]}) proves that the e2e.async.Result was found

But:

  • library-dependencies stores file path as URL in {:url ...}
  • source-for-namespace (from error stack) finds the file, but expects relative path with key :file

This is where my investigation stops. I am sure that fix would be probably easy, but I do not know all details of information cljs stores about .js files. Moreover I do not know why it works in compiler and not in REPL. Probably compiler does not open file and passes
it as a argument to Google Closure, while REPL actually wants to load the file itself.

Hope you have all information to fix the problem.

Thank you.



 Comments   
Comment by David Nolen [ 25/Mar/15 8:49 AM ]

Please do not include piggieback information when reporting issues to JIRA. We do not consider downstream tooling here at all. Will take a look, thanks for the report!





[CLJS-1167]  Using (require 'namespace.core :reload) causes "too much recursion" - one process only. Created: 24/Mar/15  Updated: 24/Mar/15

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: 0.0-3126
Fix Version/s: None

Type: Defect Priority: Minor
Reporter: J David Eisenberg Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Environment:

Linux Fedora 21, openjdk version "1.8.0_31"


Attachments: File m060.tgz    

 Description   

At shell prompt, using "mies" from github: lein new mies m060
In core.cljs uncomment: (repl/connect "http://localhost:9000/repl")
In core.cljs add (defn doubled [x] (* 2 x))
At shell prompt: scripts/build # finishes successfully
At shell prompt: scripts/brepl

This will generate two warnings about goog.next.xpc.TransportNames and goog.net.xpc.CfgFields

In browser, connect to localhost:9000

In REPL: (require 'm060.core)
In REPL: (in-ns 'm060.core)
In REPL: (doubled 10) ;; this works correctly

In core.cljs, add: (defn tripled [x] (* 3 x))
in REPL: (require 'm060.core :reload)

browser shows "too much recursion" error twice (in Firefox)
in REPL: (tripled 10) ;; also works correctly

in core.cljs, add: (defn quad [x] (* 4 x))

in REPL: (require 'm060.core :reload)
Internal error: Too much recursion
Many repetitions of clojure$browser$repl$bootstrapgoog.require (out/clojure/browser/repl.cljs:158:33)


Note: this error can be avoided by replacing the (repl/connect "http://localhost:9000/repl") by
(defonce conn (repl/connect "http://localhost:9000/repl")) ;; as in quick start guide






[CLJS-1166] Browser REPL stacktraces unprocessed if explicit IP used Created: 24/Mar/15  Updated: 24/Mar/15

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: 0.0-3126
Fix Version/s: None

Type: Defect Priority: Major
Reporter: Mike Fikes Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Environment:

QuickStart Browser REPL OS X Safari (other browsers as well)



 Description   

Go through the Quick Start but change the repl/connect form to use an explicit IP instead of localhost. (In this case the IP I am trying is indeed the same host, if that matters.)

(defonce conn
  (repl/connect "http://10.96.82.207:9000/repl"))

Then connect to the REPL using the explicit IP http://10.96.82.207:9000.

The REPL will function properly but stacktraces are not properly processed. Here is an example (generated using Safari):

ClojureScript:cljs.user> (ffirst [1])
Error: 1 is not ISeqable
cljs$core$seq@http://10.96.82.207:9000/out/cljs/core.js:4667:17
cljs$core$first@http://10.96.82.207:9000/out/cljs/core.js:4697:22
cljs$core$ffirst@http://10.96.82.207:9000/out/cljs/core.js:5774:23


eval code
eval@[native code]
http://10.96.82.207:9000/out/clojure/browser/repl.js:42:271
clojure$browser$repl$evaluate_javascript@http://10.96.82.207:9000/out/clojure/browser/repl.js:45:4
http://10.96.82.207:9000/out/clojure/browser/repl.js:242:173
deliver@http://10.96.82.207:9000/out/goog/messaging/abstractchannel.js:142:21
xpcDeliver@http://10.96.82.207:9000/out/goog/net/xpc/crosspagechannel.js:733:19
messageReceived_@http://10.96.82.207:9000/out/goog/net/xpc/nativemessagingtransport.js:321:23
fireListener@http://10.96.82.207:9000/out/goog/events/events.js:741:25
handleBrowserEvent_@http://10.96.82.207:9000/out/goog/events/events.js:862:34
http://10.96.82.207:9000/out/goog/events/events.js:276:42





[CLJS-1165] Support for multiple source directories in cljs.closure/build and watch Created: 24/Mar/15  Updated: 24/Mar/15

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Minor
Reporter: Daniel Skarda Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None


 Description   

Quick-Start wiki page describes build and watch as functions with source (directory) as first argument

However more complex projects have multiple source paths (eg "src/cljs", "test/cljs" or cljx output "target/generated/cljs" and in future also "src/cljc").

Maybe I am missing some important point of a puzzle but I do not see a way how to (for example) build or watch multiple directories. Should we extend these function to support vectors of directories?






Generated at Tue Mar 31 01:40:18 CDT 2015 using JIRA 4.4#649-r158309.