<< Back to previous view

[CLJS-1318] Fix typo in documentation of `specify` Created: 22/Jun/15  Updated: 08/Feb/16  Resolved: 04/Feb/16

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

Type: Enhancement Priority: Trivial
Reporter: Yehonathan Sharvit Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: docstring

Attachments: Text File CLJS-1318.patch     Text File patch.txt    
Patch: Code

 Description   

Fix typo in documentation of `specify`



 Comments   
Comment by Yehonathan Sharvit [ 22/Jun/15 6:27 AM ]

here is a patch that fixes the doc of `specify`

Comment by Mike Fikes [ 31/Jan/16 3:07 PM ]

Hey Yehonathan, the patch attached to this ticket isn't in the correct format. See https://github.com/clojure/clojurescript/wiki/Patches

Comment by Yehonathan Sharvit [ 01/Feb/16 12:40 AM ]

Attach a patch with the appropriate format

Comment by Mike Fikes [ 01/Feb/16 5:32 PM ]

LGTM and patch applies cleanly.

Comment by David Nolen [ 04/Feb/16 3:55 PM ]

Applied thanks, Yehonathan please remember to send in your CA thanks.

Comment by Mike Fikes [ 04/Feb/16 8:42 PM ]

Confirmed fixed with cljs.jar and downstream bootstrap.

Comment by Yehonathan Sharvit [ 08/Feb/16 12:58 AM ]

@david CA signed.





[CLJS-1560] cljs.reader/read-string doesn't read records that are printed Created: 05/Feb/16  Updated: 05/Feb/16  Resolved: 05/Feb/16

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

Type: Enhancement Priority: Minor
Reporter: Daniel Compton Assignee: Unassigned
Resolution: Declined Votes: 0
Labels: None


 Description   

I'm not sure if this is a bug, or feature enhancement, but there is a difference between how Clojure reads records that have been printed, and how ClojureScript does with cljs.reader/read-string.

In Clojure

user=> (defrecord myrec [a b])
user.myrec
user=> (pr-str (->myrec 1 2))
"#user.myrec{:a 1, :b 2}"
user=> (read-string (pr-str (->myrec 1 2)))
#user.myrec{:a 1, :b 2}

In ClojureScript

cljs.user=> (defrecord myrec [a b])
cljs.user/myrec
cljs.user=> (pr-str (->myrec 1 2))
"#cljs.user.myrec{:a 1, :b 2}"
cljs.user=> (cljs.reader/read-string "#cljs.user.myrec{:a 1, :b 2}")
Could not find tag parser for cljs.user.myrec in ("inst" "uuid" "queue" "js")
...
;; Add a tag parser
cljs.user=> (cljs.reader/register-tag-parser! "cljs.user.myrec" map->myrec)
nil
cljs.user=> (cljs.reader/read-string "#cljs.user.myrec{:a 1, :b 2}")
#cljs.user.myrec{:a 1, :b 2}

The proposed solution to this would be to register a tag parser when a defrecord is created. However after reading http://stackoverflow.com/questions/24661655/clojure-clojurescript-clojure-core-read-string-clojure-edn-read-string-and-c, it seems like perhaps the error is in my understanding and cljs.reader/read-string should be expected to behave more like clojure.edn/read-string. If this is the case, it might be good to update the docstrings for cljs.reader to make this distinction clearer.



 Comments   
Comment by David Nolen [ 05/Feb/16 2:36 PM ]

There isn't a good way to make this work due to the nature of advanced compilation. Those names won't exist. If we created some kind of lookup table that would defeat dead code elimination of unused records.





[CLJS-1550] Enhance docstring for extend-type wrt type-sym Created: 22/Jan/16  Updated: 04/Feb/16  Resolved: 04/Feb/16

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

Type: Enhancement Priority: Major
Reporter: Mike Fikes Assignee: David Nolen
Resolution: Completed Votes: 1
Labels: docstring

Attachments: Text File CLJS-1550.patch    
Patch: Code

 Description   

At times, people will use js/String, or not have a way to know about the semantics of default, etc.

Add copy to the docstring along the lines:

type-sym may be
   * default, meaning the definitions will apply for any value, unless an extend-type exists for one of the more specific cases below.
   * nil, meaning the definitions will apply for the nil value.
   * any of object, boolean, number, string, array, or function, indicating the definitions will apply for values of the associated base JavaScript types. Note that, for example, string should be used instead of js/String.
   * a JavaScript type not covered by the previous list, such as js/RegEx.
   * a type defined by deftype or defrecord.


 Comments   
Comment by Mike Fikes [ 22/Jan/16 5:38 PM ]

Attached patch produces this output:

cljs.user=> (doc extend-type)
-------------------------
cljs.core/extend-type
([type-sym & impls])
Macro
  Extend a type to a series of protocols. Useful when you are
  supplying the definitions explicitly inline. Propagates the
  type as a type hint on the first argument of all fns.

  type-sym may be

   * default, meaning the definitions will apply for any value,
     unless an extend-type exists for one of the more specific
     cases below.
   * nil, meaning the definitions will apply for the nil value.
   * any of object, boolean, number, string, array, or function,
     indicating the definitions will apply for values of the
     associated base JavaScript types. Note that, for example,
     string should be used instead of js/String.
   * a JavaScript type not covered by the previous list, such
     as js/RegExp.
   * a type defined by deftype or defrecord.

  (extend-type MyType
    ICounted
    (-count [c] ...)
    Foo
    (bar [x y] ...)
    (baz ([x] ...) ([x y & zs] ...))

nil
Comment by David Nolen [ 04/Feb/16 4:09 PM ]

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

Comment by Mike Fikes [ 04/Feb/16 8:58 PM ]

Confirmed fixed with cljs.jar and downstream cljs.js client.





[CLJS-1551] Self-host: assert-args dormant in macros Created: 22/Jan/16  Updated: 04/Feb/16  Resolved: 04/Feb/16

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

Type: Defect Priority: Minor
Reporter: Mike Fikes Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: bootstrap

Attachments: Text File CLJS-1551-1.patch    
Patch: Code and Test

 Description   

In bootstrap ClojureScript, if you invoke a macro that employs assert-args, the arguments will not be checked. An example of this would be

(let [a])

In JVM-based ClojureScript, this triggers:

Caused by: java.lang.IllegalArgumentException: let requires an even number of forms in binding vector

In bootstrap ClojureScript, the macroexpansion blindly succeeds, but then the analyzer processes

(let* [a])
and emits a warning

bindings must be vector of even number of elements at line 1

The root cause of this is that the {let} macro is making use of the {assert-args} macro, and in bootstrap ClojureScript, since the {let} macro is being processed as ClojureScript, the {assert-args} macro must be in a "higher" stage.

I did an experiment that moved this to a higher stage and, indeed {(let [a])} results in an exception being thrown in bootstrap indicating:

let requires an even number of forms in binding vector

I haven't yet produced a minimal repro, but I suspect this will be possible with the self-host unit tests.



 Comments   
Comment by Mike Fikes [ 23/Jan/16 10:42 AM ]

Minimal repro, in the form of a self-host unit test:

(deftest test-CLJS-1551
  (cljs/eval-str st
    "(if-let [x true y true] 3)"
    nil
    {:eval node-eval}
    (fn [{:keys [error value]}]
      (is (nil? value))
      (is (= "if-let requires exactly 2 forms in binding vector at line 1 " (ex-message (ex-cause error))))))
  (cljs/eval-str st
    "(if-let [x true] 1 2 3)"
    nil
    {:eval node-eval}
    (fn [{:keys [error value]}]
      (is (nil? value))
      (is (= "if-let requires 1 or 2 forms after binding vector at line 1 " (ex-message (ex-cause error))))))
  (cljs/eval-str st
    "(if-let '(x true) 1)"
    nil
    {:eval node-eval}
    (fn [{:keys [error value]}]
      (is (nil? value))
      (is (= "if-let requires a vector for its binding at line 1 " (ex-message (ex-cause error)))))))
Comment by Mike Fikes [ 23/Jan/16 10:52 AM ]

The attached patch (version 1) adds an entirely new namespace to solve the problem, and as such probably requires extra thought / review. It passes tests and you can also see that it works for regular bootstrap if you do `script/noderepljs` and evaluate

(for [a (range) b] 3)

In this case, the top level exception is still {clojure.lang.ExceptionInfo}, but the root cause changes to {clojure.lang.ExceptionInfo} instead of the previous {java.lang.IllegalArgumentException}. (This difference is due to the use of ex-info in assert-args, and is unlikely to be problematic, but calling it out specifically.)

Comment by David Nolen [ 04/Feb/16 4:07 PM ]

fixed https://github.com/clojure/clojurescript/commit/8f7b1d02d113e49965ebcfe418454b93ba45a6e5

Comment by Mike Fikes [ 04/Feb/16 8:56 PM ]

Confirmed fixed with downstream cljs.js client, and confirmed no regression with cljs.jar.





[CLJS-1552] doc for & should match fn Created: 27/Jan/16  Updated: 04/Feb/16  Resolved: 04/Feb/16

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

Type: Defect Priority: Minor
Reporter: Mike Fikes Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: docstring

Attachments: Text File CLJS-1552.patch    
Patch: Code

 Description   

If you do (doc &) the intent is that the doc for fn would be displayed.

Currently you get synthetically constructed (but empty) doc as if fn is a special form.

cljs.user=> (doc &)
-------------------------
fn
Special Form
  nil

  Please see http://clojure.org/special_forms#fn

nil


 Comments   
Comment by Mike Fikes [ 27/Jan/16 9:00 AM ]

With the patch, and exercising doc facility from another namespace:

cljs.user=> (ns foo.core)
nil
foo.core=> (require '[cljs.repl :refer-macros [doc]])
nil
foo.core=> (doc &)
-------------------------
cljs.core/fn
([& sigs])
Macro
  params => positional-params* , or positional-params* & next-param
  positional-param => binding-form
  next-param => binding-form
  name => symbol

  Defines a function

nil
Comment by David Nolen [ 04/Feb/16 4:05 PM ]

fixed https://github.com/clojure/clojurescript/commit/89ec69f06919afaa102a078606dc0ab8b1015fb5

Comment by Mike Fikes [ 04/Feb/16 8:54 PM ]

Confirmed fixed with cljs.jar.





[CLJS-1488] cljs.repl/source Cannot read source of cljs functions that use #js reader Created: 21/Nov/15  Updated: 04/Feb/16  Resolved: 04/Feb/16

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

Type: Defect Priority: Minor
Reporter: Tony Kay Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None
Environment:

OSX


Attachments: Text File CLJS-1488.patch    
Patch: Code

 Description   

The clsj.repl/source function fails to pull source for cljs that uses #js reader tag. Reports "No reader found for tag".

To reproduce, try (source str).



 Comments   
Comment by Mike Fikes [ 29/Jan/16 8:49 PM ]

I've added a patch to bind the needed reader capability.

Comment by David Nolen [ 04/Feb/16 4:02 PM ]

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

Comment by Mike Fikes [ 04/Feb/16 8:53 PM ]

Confirmed fixed with cljs.jar.





[CLJS-1557] Make special-symbol? return true for catch and finally Created: 31/Jan/16  Updated: 04/Feb/16  Resolved: 04/Feb/16

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

Type: Enhancement Priority: Minor
Reporter: Mike Fikes Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None

Attachments: Text File CLJS-1557.patch    
Patch: Code

 Description   

In Clojure,

(special-symbol? 'catch)
and
(special-symbol? 'finally)
both evaluate to true.

Do this in ClojureScript

1. for consistency
2. because cljs.tools.reader (tools.reader-1.0.0-alpha3) makes use of special-symbol? and without this change syntax quoting doesn't work properly, making it difficult to write bootstrapped macros

With respect to the second item above

`(try (catch) (finally))

evaluates to

(try (cljs.user/catch) (cljs.user/finally))

if using cljs.tools.reader tools.reader-1.0.0-alpha3 with bootstrap ClojureScript.



 Comments   
Comment by David Nolen [ 04/Feb/16 3:59 PM ]

fixed https://github.com/clojure/clojurescript/commit/609400910e983849e5b7932a4b7d0b0dda465df6

Comment by Mike Fikes [ 04/Feb/16 8:50 PM ]

Confirmed fixed with cljs.jar and downstream cljs.js client. In particular, using tools.reader-1.0.0-alpha3,

`(try (catch) (finally))

syntax quotes properly.





[CLJS-1542] Self-host: cljs/compile-str not handling errors properly Created: 10/Jan/16  Updated: 04/Feb/16  Resolved: 04/Feb/16

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

Type: Defect Priority: Minor
Reporter: Matt Huebert Assignee: Mike Fikes
Resolution: Completed Votes: 0
Labels: bootstrap

Attachments: Text File CLJS-1542.patch    
Patch: Code and Test

 Description   

cljs/compile-str throws on some errors which cljs/eval[-str] handles gracefully.

Example: on `(fn [] (let [x 7 y] (prn y)))`, cljs/eval-str returns:

{:message "Could not eval eval-str", :data {:tag :cljs/analysis-error}, :cause #error {:message "bindings must be vector of even number of elements at line 1 ", :data {:file nil, :line 1, :column 8, :tag :cljs/analysis-error}}}

whereas cljs/compile-str throws:

Uncaught Error: No method in multimethod 'cljs.compiler/emit*' for dispatch value:
cljs$core$throw_no_method_error @ core.cljs:9611
cljs.core.MultiFn.call.G_10698_2 @ core.cljs:9626
cljs.core.MultiFn.call.G__10698 @ core.cljs:9613
cljs$compiler$emit @ compiler.cljc:170
(anonymous function) @ js.cljs:630
cljs$js$compile_str_STAR__$_compile_loop @ js.cljs:630
cljs$js$compile_str_STAR_ @ js.cljs:603
cljs.js.compile_str.cljs$core$IFn$_invoke$arity$5 @ js.cljs:674
cljs$js$compile_str @ js.cljs:644
(anonymous function) @ core.cljs:28

Minimal example: https://github.com/mhuebert/mies-cljs.js



 Comments   
Comment by Mike Fikes [ 31/Jan/16 9:33 PM ]

If you use cljs.js/compile-str on a form that cannot be analyzed, then the analysis error is wrapped, but inadvertently passed on to compilation as an AST structure. This results in the compiler derailing because it tries to process a nil :op.

The fix is to employ the same pattern used in cljs.js/eval-str, namely: Wrap successful analysis in a {:value ast} map, and then additionally check for an :error key in the result and cb early, otherwise extract the :value and continue on to compilation.

With the patch this error should be produced:

#error {:message "Could not compile ", :data {:tag :cljs/analysis-error}, :cause #error {:message "bindings must be vector of even number of elements at line 1 ", :data {:file nil, :line 1, :column 8, :tag :cljs/analysis-error}}}
Comment by David Nolen [ 04/Feb/16 3:57 PM ]

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

Comment by Mike Fikes [ 04/Feb/16 8:44 PM ]

Confirmed fixed with downstream bootstrapped client.





[CLJS-620] Warnings are generated when using a macro in argument position Created: 14/Oct/13  Updated: 04/Feb/16  Resolved: 04/Feb/16

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

Type: Defect Priority: Minor
Reporter: Julien Eluard Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: None

Attachments: File CLJS-620.diff     Text File CLJS-620.patch    
Patch: Code

 Description   

Using a macro in argument position (e.g. (map macro [])) generates a warning:
WARNING: Use of undeclared Var test/node at line 4 src/test.cljs

Find a reproduction project here.



 Comments   
Comment by Jozef Wagner [ 15/Oct/13 3:30 AM ]

and what would you like, a better warning? Clojurescript allows same name for macro and for function, so you can both have macro + and fn +. Macro version will be used when is first in the list, fn version otherwise.

Comment by Jonas Enlund [ 15/Oct/13 3:38 AM ]

For reference, Clojure generates the following error message:

user=> (map when [])
CompilerException java.lang.RuntimeException: Can't take value of a macro: #'clojure.core/when, compiling:(NO_SOURCE_PATH:1:1)

The "obvious" approach would be to add

(when-let [m (get-expander sym env)]
  (throw (error env (str "Can’t take value of a macro: " m))))

to resolve-var[1]. Unfortunately this doesn’t work in ClojureScript due to the way inlining works. A simple workaround is to add {:inline true} metadata to macros that are later redefined as functions in core.cljs and check for invalid macro usage like this:

(when-let [m (get-expander sym env)]
  (and (-> m meta :inline not)    
       (throw (error env (str "Can’t take value of a macro: " m)))))

Another approach would perhaps be to rethink how inlining works as it seems kind of brittle to have macros in cljs/core.clj with the same name as functions in cljs/core.cljs (especially since both namespaces are auto-imported. Is cljs.core/inc a function, a macro, or both?). Maybe there’s a better way?

[1] https://github.com/clojure/clojurescript/blob/master/src/clj/cljs/analyzer.clj#L193

Comment by Julien Eluard [ 15/Oct/13 6:23 AM ]

My bad, didn't realize it didn't make sense. Of course it's obvious now. I was confused by recent changes around function/macro name validation.
Now the warning could probably be improved a little but that doesn't seem very important. The Clojure warning is not that much better.

Comment by David Nolen [ 15/Oct/13 11:58 AM ]

We're not going to change how inlining works - the whole point is that we can reuse the same names. Adding :inline metadata seems like a promising way to warn of incorrect usage of inlining macros.

Comment by Mike Fikes [ 01/Feb/16 6:34 PM ]

Attaching CLJS-620.patch for comment.

It may at least improve things by producing the warning regarding it being a macro.

cljs.user=> (map when [])
WARNING: Can't take value of macro cljs.core/when at line 1 <cljs repl>
()

One advantage of the patch is it is pretty small.

A disadvantage is that it kind-of overloads the existing :undeclared-var warning. (The alternative would be to introduce a completely new warning that is emitted in exactly this situation.)

Comment by David Nolen [ 04/Feb/16 3:53 PM ]

fixed https://github.com/clojure/clojurescript/commit/58cd6be66877ba43d1642138360b916de0983917

Comment by Mike Fikes [ 04/Feb/16 8:41 PM ]

Confirmed fixed with cljs.jar and downstream bootstrap.





[CLJS-1499] Circular dependency checking for nses that self-require Created: 01/Dec/15  Updated: 04/Feb/16  Resolved: 04/Feb/16

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

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


 Description   

Currently triggers StackOverflow



 Comments   
Comment by Mike Fikes [ 29/Jan/16 8:17 PM ]

I believe we can close this one:

(ns foo.core
  (:require foo.core))

yields

cljs.user=> (require 'foo.core)
clojure.lang.ExceptionInfo: Assert failed: Circular dependency detected, cljs.user -> foo.core -> foo.core

with the changes made for CLJS-1537.





[CLJS-1424] (def) or (defn) will throw an obscure exception Created: 14/Aug/15  Updated: 04/Feb/16  Resolved: 04/Feb/16

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

Type: Defect Priority: Minor
Reporter: Sean Grove Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: cljs


 Description   

Simply trying to compile `(def)` will throw an exception: "Caused by: clojure.lang.ArityException: Wrong number of args (1) passed to: analyzer/eval1440/fn-1441/pfn-1442"

While obviously not a valid construct, the error could be significantly more descriptive, and also show the line number where it happened.

A similar issue happens with `(defn)`: "Caused by: clojure.lang.ExceptionInfo: Wrong number of args (2) passed to: core/defn--12230"



 Comments   
Comment by Mike Fikes [ 29/Jan/16 9:03 PM ]

FWIW, the defn case is a little better now with CLJS-1516, reporting 0 args passed:

cljs.user=> (defn)
clojure.lang.ExceptionInfo: Wrong number of args (0) passed to: core/defn--3475 at line 1 <cljs repl> {:file "<cljs repl>", :line 1, :column 1, :tag :cljs/analysis-error}




[CLJS-1554] AbstractMethodError trying to deftype with Object Created: 31/Jan/16  Updated: 04/Feb/16  Resolved: 04/Feb/16

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

Type: Defect Priority: Major
Reporter: James Laver Assignee: Unassigned
Resolution: Declined Votes: 0
Labels: bug, interop
Environment:

clojure 1.7, clojurescript 1.7.228



 Description   

I get this obscure message trying to upgrade timbre to cljs 1.7.228 (from 0.0.2727) and I have no idea what's changed.

java.lang.AbstractMethodError: Method cljsbuild/compiler/SourcePaths._find_sources(Ljava/lang/Object;)Ljava/lang/Object; is abstract, compiling/private/var/folders/k6/glc05svd5d194k8kgqfwkrph0000gn/T/form-init382463497803898384.clj:1:124)

Code that triggers it is here:
https://github.com/jjl/automat/blob/cljc/src/automat/fsm.cljc#L25

I've eliminated my cljc as being the cause by bumping the clojurescript version on the original code and seeing the same error.



 Comments   
Comment by Thomas Heller [ 31/Jan/16 8:05 AM ]

You also need to upgrade the lein-cljsbuild version, not sure what is current but I believe at least 1.1.1 is required.

Comment by James Laver [ 31/Jan/16 9:02 AM ]

Ah, thanks. That's working now.





[CLJS-1545] Add option to ignore JCS_UNSAFE_THIS warning Created: 14/Jan/16  Updated: 04/Feb/16  Resolved: 04/Feb/16

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

Type: Enhancement Priority: Minor
Reporter: Daniel Compton Assignee: Unassigned
Resolution: Declined Votes: 0
Labels: None


 Description   

When using https://github.com/binaryage/dirac, we get this warning with a prod build.

com.google.javascript.jscomp.LoggerErrorManager println
WARNING: ../parts/devtools/sanity_hints.js:108: WARNING - dangerous use of this in static method devtools.sanity_hints.type_error_to_string
var self = this;

Is it possible to extend :closure-warnings to add JSC_UNSAFE_THIS to the set of warnings that we can enable/disable? Details on the warnings: https://developers.google.com/closure/compiler/docs/error-ref?hl=en#warn

JSC_UNSAFE_THIS is defined at https://github.com/google/closure-compiler/blob/v20151015/src/com/google/javascript/jscomp/CollapseProperties.java#L88-L90



 Comments   
Comment by David Nolen [ 18/Jan/16 2:46 PM ]

Patch welcome.

Comment by Antonin Hildebrand [ 01/Feb/16 9:19 AM ]

This was actually a problem in cljs-devtools code.

After reading https://developers.google.com/closure/compiler/docs/limitations?hl=en I was able to get rid of the warning with this change:

https://github.com/binaryage/cljs-devtools/commit/e5fad13e4565ddeac59ed06cfe551455b47303f2

But Daniel, this points out another issue in your build setup. You should not be compiling and requiring cljs-devtools in :advanced builds of your project. cljs-devtools is designed for development mode only, it cannot work under :advanced because of CLJS-1249.





[CLJS-741] seq error message readability is not optimal Created: 02/Jan/14  Updated: 04/Feb/16  Resolved: 04/Feb/16

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

Type: Enhancement Priority: Trivial
Reporter: Julien Eluard Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: None

Attachments: Text File cljs_741.patch    

 Description   

When calling seq on an invalid type an errr with following message is thrown: :keywordis not ISeqable.

Adding a space between the argument and the message improves the readability.



 Comments   
Comment by David Nolen [ 02/Jan/14 12:58 PM ]

Excellent thanks!

Comment by Mike Fikes [ 02/Feb/16 5:57 PM ]

The attached patch no longer applies owing to source file name changes.

Comment by Mike Fikes [ 02/Feb/16 6:04 PM ]

We can close, this has already been addressed: https://github.com/clojure/clojurescript/commit/f9a33372a9122f940310588435e210312da685f9





Generated at Thu Feb 11 13:24:15 CST 2016 using JIRA 4.4#649-r158309.