<< Back to previous view

[CLJS-853] ^:metadata not working on fns (Cljs 0.0-2322) Created: 10/Sep/14  Updated: 10/Sep/14

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

Type: Defect Priority: Minor
Reporter: Peter Taoussanis Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: bug, metadata
Environment:

Clojure: 1.7.0-alpha2
ClojureScript: 0.0-2322
tools.reader: 0.8.8



 Description   

Hi there, just ran into some unexpected behaviour:

;;; Clojure
(meta ^:foo [])                      ; {:foo true}
(meta ^:foo (fn []))                  ; {:foo true}
(meta (with-meta []    {:foo true})) ; {:foo true}
(meta (with-meta (fn []) {:foo true})) ; {:foo true}

;;; ClojureScript 0.0-2322
(meta ^:foo [])                      ; {:foo true}
(meta ^:foo (fn []))                  ; nil         <--
(meta (with-meta []    {:foo true})) ; {:foo true}
(meta (with-meta (fn []) {:foo true})) ; {:foo true}

Also tried with a random set of older dependencies:
Clojure: 1.6.0
ClojureScript: 0.0-2277
tools.reader: 0.8.5

Same result, so this seems to have been around for a while.
Does this seem like it might be a Cljs or tools.reader bug?
Shall I file somewhere else?

Thanks a lot, cheers!



 Comments   
Comment by David Nolen [ 10/Sep/14 5:44 PM ]

Definitely a bug and a patch is most welcome.





[CLJS-840] Different behaviour for read-string in clojure and clojurescript Created: 12/Aug/14  Updated: 10/Sep/14  Resolved: 10/Sep/14

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

Type: Defect Priority: Major
Reporter: Robin Heggelund Hansen Assignee: Unassigned
Resolution: Declined Votes: 0
Labels: bug
Environment:

Clojure 1.6.0
ClojureScript 2280



 Description   

The following works in clojure: (read-string "{:weapons (:20)}")
But gives following error in cljs: "TypeError: Cannot read property '0' of null"



 Comments   
Comment by Francis Avila [ 12/Aug/14 4:17 PM ]

Duplicate of CLJS-677.

Comment by David Nolen [ 10/Sep/14 5:50 PM ]

As far as I know this is not supported see the reader page on clojure.org





[CLJS-819] cljs.reader cannot handle character classes beginning with slashes in regex literals Created: 20/Jun/14  Updated: 01/Jul/14  Resolved: 01/Jul/14

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

Type: Defect Priority: Critical
Reporter: Ziyang Hu Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: bug, cljs, reader

Attachments: Text File cljs-819.patch    

 Description   

cljs.user> (cljs.reader/read-string "#\"\\s\"")
Compilation error: Error: Unexpected unicode escape \s



 Comments   
Comment by Ziyang Hu [ 20/Jun/14 10:03 AM ]

This in particular means that (cljs.reader/read-string (str [#"\s"])) won't work

Comment by Francis Avila [ 25/Jun/14 11:46 AM ]

Patch and test.

Comment by David Nolen [ 01/Jul/14 9:25 PM ]

fixed https://github.com/clojure/clojurescript/commit/32259c5ff3f86ea086ae3949403df80c2f518c7e





[CLJS-812] Recurring from a case statement emits invalid JavaScript Created: 09/Jun/14  Updated: 13/Jun/14  Resolved: 13/Jun/14

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

Type: Defect Priority: Critical
Reporter: Luke VanderHart Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: bug, compiler


 Description   

In 0.2227, compiling the following form produces syntactically invalid JavaScript:

(defn reproduce
  [value]
  (case value
    :a (recur :b)
    :b 0))

Yields:

bug_repro_test.reproduce = (function reproduce(value) {
    while (true) {
        var G__5832 = (((value instanceof cljs.core.Keyword)) ? value.fqn : null);
        var caseval__5833;
        switch (G__5832) {
            case "b":
                caseval__5833 = 0
                break;
            case "a":
                caseval__5833 = {
                    var G__5834 = cljs.core.constant$keyword$67;
                    value = G__5834;
                    continue;
                }

                break;
            default:
                caseval__5833 = (function () {
                    throw (new Error(("No matching clause: " + cljs.core.str.cljs$core$IFn$_invoke$arity$1(value))))
                })()
        }
        return caseval__5833;
        break;
    }
});

When evaluated in any JavaScript environment (including the Google Closure compiler) environment, this yields a syntax error in this code:

caseval__5833 = {
                    var G__5834 = cljs.core.constant$keyword$67;
                    value = G__5834;
                    continue;
                }


 Comments   
Comment by David Nolen [ 10/Jun/14 7:56 AM ]

Good catch. I suspect that throw may be similarly problematic.

Comment by David Nolen [ 13/Jun/14 3:59 PM ]

fixed in master https://github.com/clojure/clojurescript/commit/cc11c7996ba8522d6767fb45df2f76e20e4c1773





[CLJS-796] (get [42] nil) => 42 Created: 11/Apr/14  Updated: 14/Apr/14  Resolved: 14/Apr/14

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

Type: Defect Priority: Major
Reporter: Alex Coventry Assignee: Unassigned
Resolution: Declined Votes: 0
Labels: bug
Environment:

r2156



 Comments   
Comment by Francis Avila [ 12/Apr/14 9:23 PM ]

This is a duplicate of CLJS-728 and is fixed by this commit, which is included in r2197 and above.





[CLJS-740] undeclared-ns warnings are broken Created: 02/Jan/14  Updated: 17/Jan/14  Resolved: 17/Jan/14

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

Type: Defect Priority: Minor
Reporter: Erik Ouchterlony Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: Compiler, bug, patch,

Attachments: File fix-undeclared-ns-warnings.diff    
Patch: Code

 Description   

In the recent versions of cljs, the undeclared-ns warnings have stopped working. This patch seems to be the culprit.



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

Great thanks!

Comment by David Nolen [ 07/Jan/14 10:32 AM ]

CLJS-615

Comment by David Nolen [ 17/Jan/14 9:26 AM ]

fixed, https://github.com/clojure/clojurescript/commit/b8cf302b1500e88e0602e72fa6aec6f7328a1a00





[CLJS-737] tool.reader can't handle white-space Created: 30/Dec/13  Updated: 09/Jan/14  Resolved: 09/Jan/14

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

Type: Defect Priority: Minor
Reporter: Andrew Zures Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: bug
Environment:

MBP running lion 10.7.5


Attachments: Text File 0001-Bump-tools.reader-version-to-0.8.3.patch     PNG File Screen Shot 2013-12-30 at 4.40.47 PM.png     PNG File Screen Shot 2013-12-30 at 4.41.14 PM.png     PNG File Screen Shot 2013-12-30 at 4.44.42 PM.png    

 Description   

I believe the tool.reader (may some other part of ClojureScript) cannot handle a file with a large amount of white space. I have a cljx generated file with nothing but a namespace and about 300-400 lines of white-space. The entire file is simply a namespace and whitespace (file attached shows white-space in red). I get a stackoverflow error arising mainly from clojure.tools.reader$read.invoke(reader.clj:727). I have screenshots of the beginning and end of the stackoverflow attached. If I remove the whitespace, ClojureScript will compile, which leads me to believe it is the white space that is the cause of the issue.



 Comments   
Comment by Nicola Mometto [ 30/Dec/13 5:13 PM ]

Updating to tools.reader >=0.8.1 should fix this issue.

Comment by Nicola Mometto [ 30/Dec/13 5:21 PM ]

Attached a patch that bumps tools.reader to the lastest version (0.8.3)

Can you apply this and verify that it solves the issue?

Remeber you'll have to clean the lib/ folder form old tools.reader jars.

Comment by David Nolen [ 09/Jan/14 5:17 PM ]

fixed, https://github.com/clojure/clojurescript/commit/e85e63115eb5dbd6971919b4c2bfb9124b277212





[CLJS-716] Lookup for Date keys does not work in PersistentMaps and PersistentSets Created: 06/Dec/13  Updated: 12/Mar/14

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

Type: Defect Priority: Minor
Reporter: Sunil Gunisetty Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: bug
Environment:

Clojurescript version "0.0-2080"
Browser : Firefox 25.0.1
: Chrome 31.0.1650.63



 Description   

Lookup of js/Date objects fails, if there are more than 8 elements in the map. Works correctly if the map contains 8 elements or less.

Examples :

1. Map with more than 8 elements

cljs.user> (def test-map
{
:a 1
:b 2
#inst "2013-12-19T05:00:00.000-00:00" 3
:d 4
:e 5
#inst "2013-12-06T05:00:00.000-00:00" 6
:g 7
:h 8
:i 9
:j 10
})

cljs.user> (test-map #inst "2013-12-19T05:00:00.000-00:00")
nil

2. Map with 8 elements

cljs.user> (def test-map
{
:a 1
:b 2
#inst "2013-12-19T05:00:00.000-00:00" 3
:d 4
:e 5
#inst "2013-12-06T05:00:00.000-00:00" 6
:g 7
:h 8
})

cljs.user> (test-map #inst "2013-12-19T05:00:00.000-00:00")
3



 Comments   
Comment by David Nolen [ 06/Dec/13 5:07 PM ]

This is because JS Dates don't hash consistently, http://dev.clojure.org/jira/browse/CLJS-523





[CLJS-697] top-level symbol reference doesn't get an automatically inserted ns-name Created: 23/Nov/13  Updated: 23/Nov/13  Resolved: 23/Nov/13

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

Type: Defect Priority: Major
Reporter: Limbo Peng Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: Compiler, bug, namespace
Environment:

org.clojure/clojurescript "0.0-2030"



 Description   

I'm trying to use a Node.js module (with nested namespaces) in ClojureScript - the code goes like this:

(ns myapp)
(def evernote (js/require "evernote"))
(def token "TOKEN")
(defn do-sth []
  (let [client (evernote.Evernote.Client. (js-obj "token" token))]
    (.log js/console client)))
(do-sth)

which gets compiled (with :simple optimization) to:

var myapp = {}
myapp.evernote = require("evernote")
myapp.token = "TOKEN"
myapp.do_sth = function() {
  var a = new evernote.Evernote.Client({token:myapp.token})
  return console.log(a)
}
myapp.do_sth()

which will obviously fail with error "Uncaught ReferenceError: evernote is not defined".



 Comments   
Comment by David Nolen [ 23/Nov/13 11:55 PM ]

fixed, https://github.com/clojure/clojurescript/commit/d4bf88269e1d96468a19fd481f32628d4eafec9d





[CLJS-685] Cannot call method 'fromArray' of undefined -- Clojurescript 0.0-2030 Created: 17/Nov/13  Updated: 26/Nov/13  Resolved: 22/Nov/13

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

Type: Defect Priority: Minor
Reporter: John Chijioke Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: Compiler, bug, errormsgs
Environment:

Linux 3.2.0-52-generic x86_64 GNU/Linux, java 1.7, clojure 1.5.1



 Description   

Clojurescript 0.0-2030

This line from compile cljs.core is causing problems:

cljs.core.PersistentQueue.EMPTY = (new cljs.core.PersistentQueue(null, 0, null, cljs.core.with_meta(cljs.core.PersistentVector.EMPTY, cljs.core.PersistentArrayMap.fromArray([new cljs.core.Keyword(null, "end-line", "end-line", 2693041432), 3820, new cljs.core.Keyword(null, "end-column", "end-column", 3799845882), 69], true)), 0));

error message: Uncaught TypeError: Cannot call method 'fromArray' of undefined.

That's the first mention of fromArray in that file. I don't know if it's an ordering problem.



 Comments   
Comment by John Chijioke [ 17/Nov/13 11:10 PM ]

I solved it by replacing [] with cljs.core.PersistentVector.EMPTY. I think this must be a reader problem.

Comment by David Nolen [ 17/Nov/13 11:32 PM ]

This ticket needs more details, how can this error be reproduced?

Comment by Peter Taoussanis [ 22/Nov/13 3:03 AM ]

Hi, I'm seeing the same problem with tools.reader 0.8.0.

Any Clojurescript file (even an empty file) will produce the error.

Clojure: 1.6.0-alpha2
Clojurescript: 0.0-2030
Cljsbuild: 1.0.0
tools.reader: 0.8.0

Tried `lein cljsbuild clean`.

Problem is resolved by dropping back to tools.reader 0.7.10.

Update: have created an issue on the tools.reader GitHub page: https://github.com/clojure/tools.reader/issues/7

Update 2: this isn't something specific to Cljs 0.0-2030 btw, tools.reader 0.8.0 seems to produce the same error against at least Cljs 0.0-2060, 0.0-2027, 0.0-2024.

Comment by Nicola Mometto [ 22/Nov/13 6:49 AM ]

tools.reader 0.8.0 introduces end-column/end-line metadata, this needs to be elided as per line/column to avoid this bootstrapping issue.

Comment by David Nolen [ 22/Nov/13 8:02 AM ]

fixed, http://github.com/clojure/clojurescript/commit/36d401797f85c99794eef8a71239641930c36871

Comment by Peter Taoussanis [ 22/Nov/13 10:30 AM ]

Thanks a lot David, Nicola - much appreciated! Cheers

Comment by John Chijioke [ 26/Nov/13 6:32 AM ]

Thanks David. Cheers!





[CLJS-608] re-seq does not terminate in some cases Created: 06/Oct/13  Updated: 17/Oct/13  Resolved: 17/Oct/13

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

Type: Defect Priority: Major
Reporter: Russell Mull Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: bug
Environment:

Clojurescript 1913


Attachments: File re-seq-20131017.diff    

 Description   

re-matches behaves as expected:

;; clojure:
(re-matches #"\s*" "") ;; ""

;; clojurescript:
(re-matches #"\s*" "") ;; ""

re-seq does not:

;; clojure:
(re-seq #"\s*" "") ;; ("")

;; clojurescript:
(re-seq #"\s*" "") ;; infinite sequence of ""


 Comments   
Comment by Travis Thieman [ 17/Oct/13 12:34 PM ]

Patch: 20131017

Always allow one pass through the string, but terminate the lazy sequence if the end of the string is reached after the first match.

Comment by David Nolen [ 17/Oct/13 1:28 PM ]

We should have a test in the patch, thanks!

Comment by Travis Thieman [ 17/Oct/13 2:34 PM ]

Patch revised with test added

Comment by David Nolen [ 17/Oct/13 2:44 PM ]

fixed, http://github.com/clojure/clojurescript/commit/e483c4a63560cd9df4c96722beaf390006e50b9e





[CLJS-598] (js->clj nil) => Type Error Created: 25/Sep/13  Updated: 26/Sep/13  Resolved: 26/Sep/13

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

Type: Defect Priority: Minor
Reporter: Michael O. Church Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: bug
Environment:

This happened both on my local ClojureScript and in the online version: http://himera.herokuapp.com/index.html .


Attachments: Text File 0001-Argument-order-fix-in-js-clj.patch    
Patch: Code

 Description   

(js->clj nil) throws a type error instead of returning nil. This is because the satisfies? function is being used with the wrong argument order.



 Comments   
Comment by David Nolen [ 26/Sep/13 9:52 AM ]

fixed, http://github.com/clojure/clojurescript/commit/9f5df0965957e012d4ec86944abba056ccd8ecc2





[CLJS-575] cljsc.bat emit FileNotFoundException when compile samples in windows Created: 25/Aug/13  Updated: 19/Jun/14

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

Type: Defect Priority: Major
Reporter: Park Sang Kyu Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: Compiler, bug, patch
Environment:

in windows 7


Attachments: File cljsc.bat.diff     File cljsc-path.bat    
Patch: Code

 Description   

cljsc.bat emit FileNotFoundException when it compile samples of the ClojureScript project in windows like below.

------------------------------------------------
Exception in thread "main" java.io.FileNotFoundException: Could not locate cljs/closure__init.class
or cljs/closure.clj on classpath:
------------------------------------------------

It is caused by lack of a backslash in the end of path of the system environment variable, %CLOJURESCRIPT_HOME% set by a user.
In the case CLASSPATH is set to "C:\\clojure\clojurescriptsrc\clj;C:\\clojure\clojurescriptsrc\cljs" and this make it impossible for javac to find cljs/clojure.clj file.

So it can be solved by adding a backslash to the path of %CLOJURESCRIPT_HOME%.

I attached the patched file, "cljsc-path.bat"



 Comments   
Comment by David Nolen [ 04/Sep/13 11:04 PM ]

Can we please get a proper git diff thanks (and please send in your CA)! Also would be nice to get Windows users to check this out.

Comment by Park Sang Kyu [ 15/Sep/13 3:16 AM ]

git diff

Comment by David Nolen [ 05/Oct/13 11:55 AM ]

Thank you! Have you sent in your CA? http://clojure.org/contributing

Comment by Park Sang Kyu [ 19/Jun/14 10:24 AM ]

Yes i have sent my CA.

Comment by David Nolen [ 19/Jun/14 10:27 AM ]

Excellent, the patch is not correctly formatted. Can we get a new patch that conforms to http://github.com/clojure/clojurescript/wiki/Patches





[CLJS-573] checkboxes 'indeterminate' attribute gets munged in advanced mode Created: 19/Aug/13  Updated: 21/Aug/13  Resolved: 21/Aug/13

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

Type: Defect Priority: Major
Reporter: Xavi Caballé Assignee: Unassigned
Resolution: Declined Votes: 0
Labels: Compiler, bug
Environment:

ClojureScript 0.0-1853, Clojure 1.5.1, Java 1.6.0_51, OS X 10.7.5



 Description   

HTML5 defines an indeterminate attribute for checkboxes
http://www.w3.org/TR/html5/forms.html#checkbox-state-(type=checkbox)
Trying to set this attribute with ClojureScript
(set! (.-indeterminate checkbox-element) true))
doesn't work when compiling in advanced mode.

Looking at the generated JavaScript code, I see that the indeterminate property gets munged. I don't know which externs files the ClojureScript compiler uses by default, but the indeterminate property is not referenced in Closure Compiler's externs for HTML5
https://code.google.com/p/closure-compiler/source/browse/externs/html5.js

In my project I've worked around this by adding this to my own externs file

/** @type {boolean} */
HTMLInputElement.prototype.indeterminate;

but I guess this should be "built-in" into the ClojureScript compiler (or Google's Closure Compiler)?



 Comments   
Comment by Jozef Wagner [ 19/Aug/13 6:26 AM ]

This issue should be addressed in the Closure Compiler bugtracker

Until they fix it, you can use your own externs file (tutorial), which is a perfectly valid approach.

Comment by Xavi Caballé [ 21/Aug/13 5:09 AM ]

ok, thanks.
I just submitted a patch to fix this in the Closure Compiler
https://code.google.com/p/closure-compiler/issues/detail?id=1068





[CLJS-516] PersistentArrayMap keys uniqueness Created: 05/Jun/13  Updated: 19/Nov/13  Resolved: 19/Nov/13

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

Type: Defect Priority: Minor
Reporter: Sergey Kupriyanov Assignee: Michał Marczyk
Resolution: Completed Votes: 1
Labels: bug

Attachments: Text File 0001-CLJS-516-make-array-map-work-as-if-by-assoc.patch    

 Description   

PersistentArrayMap does not check the uniqueness of keys at init.

PersistentHashSet also affected.

cljs.user> (array-map 1 10 2 20 1 100)
{1 10, 2 20, 1 100}

cljs.user> (hash-set 1 1 2 3)
#{1 1 2 3}

Simple (dirty?) workaround - init map by assoc.

(defn array-map
  [& keyvals]
  (apply assoc cljs.core.PersistentArrayMap/EMPTY keyvals))


 Comments   
Comment by David Nolen [ 05/Jun/13 8:40 AM ]

Yes that solution is likely too slow. Clojure already solved this problem, we should probably port the existing solution.

Comment by David Nolen [ 04/Sep/13 11:08 PM ]

See CLJS-583 and CLJS-584

Comment by Michał Marczyk [ 05/Sep/13 1:29 AM ]

Fix and test, independent of CLJS-583 and CLJS-584.

From the commit message:

The approach taken is to (1) pour input into an array (or extract internal array with IndexedSeq), (2) construct output array by copying from the first array while checking for duplicates, (3) install output array in new array map.

Clojure does all that, except it also makes an initial pass over the array constructed in (1) to check if there are any duplicate keys. If in fact there are none, it skips (2) and just uses the original array in (3).

Crucially, there is a reason for this in Clojure which is absent in ClojureScript, namely if a new array is to be constructed, its length must be known ahead of time, so the check-for-duplicates loop also counts the number of unique items. In JS-land we can simply grow an array. Since presumably nobody's going to construct huge array maps ("slightly larger than the threshold" might make sense; a lot larger would totally kill performance), I don't think we'd gain much by avoiding the allocation, and if there are duplicates, it's good not to have to pay the price by doing the quadratic scan for duplicates twice.

I chose to pour non-IndexedSeq varargs into arrays so that the quadratic looping would be over an array rather than a seq.

Comment by Michał Marczyk [ 20/Sep/13 8:48 PM ]

Patch against current master.

Comment by David Nolen [ 19/Nov/13 9:24 PM ]

fixed by CLJS-584 - https://github.com/clojure/clojurescript/commit/d929ae942bc2859cc7b684334affc1b590173f88 and CLJS-583 https://github.com/clojure/clojurescript/commit/fe9b5577cd9b9784d0c0c75edccc4441c99ee924





[CLJS-485] clojure.string/replace ignores regex flags Created: 12/Mar/13  Updated: 19/Mar/14

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

Type: Defect Priority: Minor
Reporter: Esa Virtanen Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: bug, patch, test

Attachments: Text File 0001-Take-regex-flags-m-i-into-account-in-clojure.string-.patch    
Patch: Code and Test

 Description   

The replace function in namespace clojure.string ignores regex flag provided in the match pattern. For example:

CLJS
clojure.string/replace "I am NOT matched" #"(?i)not " "")
=> "I am NOT matched"
CLJ
clojure.string/replace "I am NOT matched" #"(?i)not " "")
=> "I am matched"

The attached patch fixes this by parsing the m and i flags, if set, from the match object, instead of explicitly setting only "g".



 Comments   
Comment by Chas Emerick [ 19/Mar/14 9:29 AM ]

I can confirm the bug. The attached patch applies cleanly, and works as expected.

Esa, sorry for the long delay (this one must have slipped through the cracks)! Could you please submit a contributor's agreement, so that your patch can be merged? More info is here:

http://clojure.org/contributing





[CLJS-476] Reading a value from a module does not work if the module is def'ed Created: 22/Feb/13  Updated: 19/Nov/13  Resolved: 19/Nov/13

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

Type: Defect Priority: Minor
Reporter: Paul Gearon Assignee: Unassigned
Resolution: Declined Votes: 0
Labels: Compiler, bug, scope
Environment:

Clojure 1.5.0-RC16
Clojurescript 0.0-1586
java version "1.7.0_04"
Java(TM) SE Runtime Environment (build 1.7.0_04-b21)
Java HotSpot(TM) 64-Bit Server VM (build 23.0-b21, mixed mode)
OSX Mountain Lion 10.8.2



 Description   

Referring to a value in a module can have a scoping issue when using the "static accessor" operator of module/VALUE_NAME. The static accessor works if the module is loaded into a local value but not if def'ed. This example uses the mmap module for Node.js, and successfully reads the PROT_READ value:

(ns stat.core)
(defn -main []
  (let [m (js/require "mmap")]
    (println "value: " m/PROT_READ)))
(set! *main-cli-fn* -main)

This correctly prints "value: 1"

However, if the value for m is def'ed instead, then the compiler assumes that the reference to m is local to the function and therefore not defined:

(ns stat.core)
(def m (js/require "mmap"))
(defn -main []
  (println "value: " m/PROT_READ))
(set! *main-cli-fn* -main)

/Users/pag/src/test/clj/stat/target/stat.js:12836
  return cljs.core.println.call(null, "value: ", m.PROT_READ)
                                                 ^
ReferenceError: m is not defined
    at Function.stat.core._main (/Users/pag/src/test/clj/stat/target/stat.js:12836:50)
    at cljs.core.apply.b (/Users/pag/src/test/clj/stat/target/stat.js:5621:14)
    at cljs.core.apply.a (/Users/pag/src/test/clj/stat/target/stat.js:5656:18)
    at Object.<anonymous> (/Users/pag/src/test/clj/stat/target/stat.js:12844:17)
    at Module._compile (module.js:449:26)
    at Object.Module._extensions..js (module.js:467:10)
    at Module.load (module.js:356:32)
    at Function.Module._load (module.js:312:12)
    at Module.runMain (module.js:492:10)
    at process.startup.processNextTick.process._tickCallback (node.js:244:9)

In this case, the value of m.PROT_READ should have been stat.core.m.PROT_READ.

On the other hand, using . syntax fixes the scoping issue:

(ns stat.core)
(def m (js/require "mmap"))
(defn -main []
  (println "value: " (.-PROT_READ m)))
(set! *main-cli-fn* -main)


 Comments   
Comment by David Nolen [ 19/Nov/13 9:26 PM ]

the slash syntax is reserved for real CLJS namespaces for everything else the dot syntax must be used.





[CLJS-475] Node.js target fails with optimizations set to :none or :whitespace Created: 21/Feb/13  Updated: 29/Jul/13

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

Type: Defect Priority: Minor
Reporter: Paul Gearon Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: Compiler, bug
Environment:

Clojure 1.5.0-RC16
Clojurescript 0.0-1586
java version "1.7.0_04"
Java(TM) SE Runtime Environment (build 1.7.0_04-b21)
Java HotSpot(TM) 64-Bit Server VM (build 23.0-b21, mixed mode)
OSX Mountain Lion 10.8.2


Attachments: GZip Archive out-none.tar.gz     GZip Archive out-whitespace.tar.gz     File pr.js-none     File pr.js-whitespace    

 Description   

Compiling a hello world program for Node.js works fine if using optimizations of :advanced or :simple, but if using :none or :whitespace then an error will be reported for either "goog undefined" or "goog.string" undefined respectively.

The program is shown here:

(ns pr.core)
(defn -main []
  (println "Hello World!"))
(set! *main-cli-fn* -main)

This program is in src/cljs/pr/core.cljs. The repl line used to compile is:

(cljs.closure/build "src/cljs" {:output-to "src/js/pr.js" :target :nodejs :pretty-print true :optimizations :none})

When compiled with optimizations of :none, the output is:

$ node src/js/pr.js 

/Users/pag/src/test/clj/pr/src/js/pr.js:1
(function (exports, require, module, __filename, __dirname) { goog.addDependen
                                                              ^
ReferenceError: goog is not defined
    at Object.<anonymous> (/Users/pag/src/test/clj/pr/src/js/pr.js:1:63)
    at Module._compile (module.js:449:26)
    at Object.Module._extensions..js (module.js:467:10)
    at Module.load (module.js:356:32)
    at Function.Module._load (module.js:312:12)
    at Module.runMain (module.js:492:10)
    at process.startup.processNextTick.process._tickCallback (node.js:244:9)

When running with optimizations of :whitespace the output is:

$ node src/js/pr.js 

/Users/pag/src/test/clj/pr/src/js/pr.js:493
goog.string.Unicode = {NBSP:"\u00a0"};
                    ^
TypeError: Cannot set property 'Unicode' of undefined
    at Object.<anonymous> (/Users/pag/src/test/clj/pr/src/js/pr.js:493:21)
    at Module._compile (module.js:449:26)
    at Object.Module._extensions..js (module.js:467:10)
    at Module.load (module.js:356:32)
    at Function.Module._load (module.js:312:12)
    at Module.runMain (module.js:492:10)

When running with optimizations of either :simple or :advanced, the output is:

$ node src/js/pr.js 
Hello World!

I have included the two javascript output files that match the above errors.



 Comments   
Comment by Paul Gearon [ 21/Feb/13 4:40 PM ]

Remaining generated files

Comment by David Nolen [ 25/Feb/13 3:46 PM ]

This is a known bug. We need goog.require/provide to actually mean something to Node.js. I'm not sure how this can be made to work. I've been hoping for a patch for this since ClojureScript was first announced, but I haven't seen anything yet.





[CLJS-464] `get-in` not behaving like Clojure when accessing non-existing inner maps Created: 26/Jan/13  Updated: 27/Jul/13  Resolved: 28/Jan/13

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

Type: Defect Priority: Major
Reporter: Roman Gonzalez Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: bug
Environment:

Gentoo 64, oracle-jvm


Attachments: Text File get-in-fix.patch    

 Description   

In Clojurescript:
(get-in {:a {:b 1}} [:a :b :c])
=> Error: 1 is not an instance of ILookup

In Clojure:
(get-in {:a {:b 1}} [:a :b :c])
=> nil



 Comments   
Comment by Roman Gonzalez [ 26/Jan/13 11:01 PM ]

Code and Test patch v1

Comment by David Nolen [ 27/Jan/13 5:25 PM ]

Isn't this a duplicate of CLJS-458? That's been fixed in master.

Comment by Roman Gonzalez [ 28/Jan/13 10:06 PM ]

Hey David,

Thanks for your prompt reply, I tested latest version of github's master with the test-case I added and got this error.

```shell
Testing with V8
out/core-advanced-test.js:1: Error: No protocol method ILookup.-lookup defined for type number: 2
function d(a){throw a;}var e=void 0,f=!0,g=null,h=!1;function aa(){return func
^
Error: No protocol method ILookup.-lookup defined for type number: 2
at Error (<anonymous>)
at t (out/core-advanced-test.js:5:962)
at Function.ab [as c] (out/core-advanced-test.js:11:239)
at Function.wd [as c] (out/core-advanced-test.js:49:60)
at Function.Dc [as h] (out/core-advanced-test.js:36:58)
at Nk.l.Da (out/core-advanced-test.js:176:128)
at Function.Bb [as h] (out/core-advanced-test.js:16:342)
at Function.Ye [as h] (out/core-advanced-test.js:65:210)
at Function.Lj [as c] (out/core-advanced-test.js:164:27)
at Eu (out/core-advanced-test.js:602:398)

SPIDERMONKEY_HOME not set, skipping SpiderMonkey tests
JSC_HOME not set, skipping JavaScriptCore tests
Tested with 1 out of 3 possible js targets
```

The test case is:

```gitdiff
diff --git a/test/cljs/cljs/core_test.cljs b/test/cljs/cljs/core_test.cljs
index 2d1d2f3..bf3f7bb 100644
— a/test/cljs/cljs/core_test.cljs
+++ b/test/cljs/cljs/core_test.cljs
@@ -656,6 +656,7 @@
(assert (= 1 (get-in [{:foo 1}, {:foo 2}] [0 :foo])))
(assert (= 4 (get-in [{:foo 1 :bar [{:baz 1}, {:buzz 2}]}, {:foo 3 :bar [{:baz 3}, {:buzz 4}]}]
[1 :bar 1 :buzz])))
+ (assert (nil? (get-in {:foo {:bar 2}} [:foo :bar :baz])))

;; arrays
(let [a (to-array [1 2 3])]
```

In case github's master is not the latest one, and test works on master, please discard this message.

Cheers.

Comment by David Nolen [ 28/Jan/13 10:39 PM ]

fixed, http://github.com/clojure/clojurescript/commit/2b21e9d5b09cdd09f2831d11810fa2c5ae4f14b1





[CLJS-434] ClojureScript compiler prepends "self__" to defmulti forms when metadata in form of ^:field. Created: 01/Dec/12  Updated: 20/Jan/13

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

Type: Defect Priority: Minor
Reporter: Andrew Mcveigh Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: bug
Environment:

Mac OS X (10.7), java version "1.6.0_37", leiningen 2 preview 10, cljsbuild 0.2.9.
clojure/clojurescript master 01 December 2012 - 5ac1503



 Description   

Using the def form, with the specific metadata ^:field causes the cljs compiler
to prepend "self__" to the output js form.

The browser (latest chrome/firefox) does not recognize "self__".

Test Case: Tested against master: 5ac1503
-------------

(ns test-def)

(def ^:foo e identity)
e
; test_def.e = cljs.core.identity;
; test_def.e;

(def ^:field f identity)
f
; test_def.f = cljs.core.identity;
; self__.test_def.f;
; Uncaught ReferenceError: self__ is not defined

https://gist.github.com/4185793



 Comments   
Comment by Brandon Bloom [ 01/Dec/12 5:37 PM ]

code tags

Comment by David Nolen [ 20/Jan/13 12:54 AM ]

This one is a bit annoying. We should probably use namespaced keywords internally.





[CLJS-426] subvec function not behaving consitently with invalid subranges Created: 22/Nov/12  Updated: 27/Jul/13  Resolved: 23/Nov/12

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

Type: Defect Priority: Major
Reporter: Roman Gonzalez Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: bug, patch
Environment:

Ubuntu precise 64 bits, Mac OS X Lion


Attachments: Text File cljs_subvec.patch     Text File cljs_subvec_revised1.patch     Text File cljs_subvec_revised.patch    
Patch: Code and Test

 Description   

When using the subvec function with a as a parameter vector and a range that is not in the original vector, the function returns a value:

(subvec [1 2 3] 0 4) => [1 2 3 nil]

However, when using with seqs, it works as it supposed to:

(subvec (range 3) 0 4) => ERROR: Index out of bounds

This is because the validation of ranges is not happening at build time of the subvec type, this bug contains a patch that adds a new private `build-subvec` function into cljs.core.



 Comments   
Comment by Roman Gonzalez [ 22/Nov/12 5:05 PM ]

Patch for bug

Comment by David Nolen [ 23/Nov/12 2:51 PM ]

This mostly looks good but there is a typo in the patch:

(build-subvec. meta (-assoc v v-pos val) ...
Comment by Roman Gonzalez [ 23/Nov/12 3:09 PM ]

Revised patch, removing small typo

Comment by Roman Gonzalez [ 23/Nov/12 3:18 PM ]

Removing useless ^:mutable meta on function parameter

Comment by David Nolen [ 23/Nov/12 3:25 PM ]

fixed, http://github.com/clojure/clojurescript/commit/ee25599abb214074cbeefe37b399038d70c6ab89





[CLJS-420] Unexpected behavior with dispatch on Keyword via protocols Created: 18/Nov/12  Updated: 08/Sep/13  Resolved: 08/Sep/13

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

Type: Defect Priority: Minor
Reporter: Max Penet Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: bug, enhancement


 Description   

At the moment if you create a protocol and expect it to be able to dispatch on keywords you need to do it in js/String, trying to extend on cljs.core.Keyword doesn't work as keywords are just Strings.

See https://gist.github.com/4104635



 Comments   
Comment by David Nolen [ 18/Nov/12 3:14 PM ]

This is a known issue which will have to wait for if and when Keywords and Symbols become proper types in ClojureScript.

Extending js/Object is not recommended, if you actually need to add functionality to the base JS native types the convention is different from Clojure: default instead of Object, string instead of js/String. Please refer to core.cljs if you want more examples.

Comment by Max Penet [ 18/Nov/12 3:27 PM ]

Thanks for the pointer about default and string, I didn't know about that.

I reported the issue at the demand of bbloom. It does seem to be difficult to address without taking a (major) performance hit unfortunately.

Comment by David Nolen [ 08/Sep/13 6:27 PM ]

Made moot by CLJS-576





[CLJS-394] PersistentTreeSet lookup bug Created: 15/Oct/12  Updated: 27/Jul/13  Resolved: 15/Oct/12

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

Type: Defect Priority: Major
Reporter: Erik Ouchterlony Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: bug, patch

Attachments: File bugfix-PersistentTreeSet-lookup.diff    
Patch: Code and Test

 Description   

The lookup function in PersistentTreeSet behaves differently in clojurescript than in clojure when a custom comparison function is used. If two elements are evaluated as equal, one of then is in the set and we do a lookup on the other, clojure returns the element in the set, whereas clojurescript returns the lookup element.

(let [compare-quot-2 #(compare (quot %1 2) (quot %2 2))
s (sorted-set-by compare-quot-2 1)]
(get s 0))

Should return: 1
Returns: 0



 Comments   
Comment by David Nolen [ 15/Oct/12 10:02 PM ]

fixed, http://github.com/clojure/clojurescript/commit/409fcc9a824668207953b2bc47d40aaab85191d3





[CLJS-393] sebseq and sorted-set-by Created: 13/Oct/12  Updated: 27/Jul/13  Resolved: 18/Oct/12

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

Type: Defect Priority: Major
Reporter: Erik Ouchterlony Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: bug

Attachments: File bugfix-PersistentTreeMap.diff    

 Description   

ClojureScript:cljs.user> (subseq (sorted-set-by <= 1 2 3 4 5) >= 2 <= 4)
"Error evaluating:" (subseq (sorted-set-by <= 1 2 3 4 5) >= 2 <= 4) :as "cljs.core.subseq.call(null,cljs.core.sorted_set_by.call(null,cljs.core.LTEQ,1,2,3,4,5),cljs.core.GTEQ,2,cljs.core.LTEQ,4);\n"
org.mozilla.javascript.JavaScriptException: Error: No protocol method IMapEntry.-key defined for type null: (cljs/core.cljs#211)
at cljs/core.cljs:211 (anonymous)
at cljs/core.cljs:203 (_key)
at cljs/core.cljs:5535 (key)
at cljs/core.cljs:2479 (anonymous)
at cljs/core.cljs:1791 (lazy_seq_value)
at cljs/core.cljs:1840 (anonymous)
at cljs/core.cljs:238 (_seq)
at cljs/core.cljs:343 (seq)
at cljs/core.cljs:817 (anonymous)
at cljs/core.cljs:854 (anonymous)
at cljs/core.cljs:857 (anonymous)
at cljs/core.cljs:868 (anonymous)
at cljs/core.cljs:5925 (anonymous)
at cljs/core.cljs:5937 (anonymous)
at <cljs repl>:1 (anonymous)
at <cljs repl>:1



 Comments   
Comment by Erik Ouchterlony [ 17/Oct/12 5:23 PM ]

I've done some further analysis on this problem and found three different issues:

  1. The sorted-set-by in cljs doesn't support ordinary boolean operators, only comparison functions with values -1,0,1.
  2. Bug in PersistentTreeSet lookup. Resolved in CLJS-394
  3. Bug in PersistentTreeMap -sorted-seq-from. I have attached a patch that seems to resolve the issue.
Comment by David Nolen [ 17/Oct/12 9:25 PM ]

So does the patch address both 1 & 3 or only 3?

Comment by Erik Ouchterlony [ 18/Oct/12 2:48 AM ]

Only 3.

Comment by Erik Ouchterlony [ 18/Oct/12 6:04 AM ]

Here is a patch for the third issue.

Comment by Erik Ouchterlony [ 18/Oct/12 4:21 PM ]

I found a small bug in the last patch, so I attached a new one. This patch handles both the remaining issues.

Comment by David Nolen [ 18/Oct/12 5:44 PM ]

fixed, http://github.com/clojure/clojurescript/commit/e3ed0e7b69f9522e8759d0a6567afabb2a98d949





[CLJS-392] Documentation says CLJS can open connections to the REPL server from a "file://" source, and you can't Created: 09/Oct/12  Updated: 27/Jul/13  Resolved: 24/Oct/12

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

Type: Defect Priority: Trivial
Reporter: Nahuel Greco Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: bug, docs, documentation
Environment:

ClojureScript 0.0-1450



 Description   

At https://github.com/clojure/clojurescript/wiki/The-REPL-and-Evaluation-Environments there is the following paragraph:

"This is a problem for the browser-connected REPL because FireFox and Chrome both view opening a file from the file system and connecting to localhost:9000 as different domains.
(...)
Fortunately, Google has also run into this problem and has created something called a CrossPageChannel. Without going into the details, this allows an iframe served from one domain (the REPL) to communicate with the parent page which was served from another domain (the application server)."

From what I tested, you CANT connect to the REPL server at "http://localhost:9000/repl" if you initially loaded the page using the "file://" protocol. But you can if you loaded it from the same hostname on another port using "http://". The documentation is wrong, and also it needs to be clarified on what you really can change from the initial domain, like the port, without broking the REPL connection (or link to a CrossPageChannel documentation page with the details on what same-origin policy checks it can overcome).



 Comments   
Comment by David Nolen [ 23/Oct/12 7:00 PM ]

Are you unable to edit the wiki?

Comment by Nahuel Greco [ 24/Oct/12 9:27 AM ]

I didn't know the wiki had public write permissions. Also I don't know the exact CrossPageChannel limitations.

Comment by David Nolen [ 24/Oct/12 10:37 AM ]

The limitation is that it won't work with file://. We now provide a simple webserver that will serve the files present in the directory where you started browser REPL. If you goto http://localhost:9000/ we will serve index.html if it is present.

Comment by Nahuel Greco [ 24/Oct/12 10:47 AM ]

So CrossPageChannel overcomes the "same origin policy" for different ports, but not for different protocols. Thanks for the clarification.

Comment by David Nolen [ 24/Oct/12 2:48 PM ]

No problem, closing this one.





[CLJS-376] `case` doesn't match quoted symbols Created: 07/Sep/12  Updated: 27/Jul/13  Resolved: 07/Sep/12

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

Type: Defect Priority: Major
Reporter: Shantanu Kumar Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: bug
Environment:

ClojureScript



 Description   

It works fine in the Clojure 1.4.0 REPL:

user=> (let [a 'a] (case a nil :nil '& :amp :none))
:none
user=> (let [a '&] (case a nil :nil '& :amp :none))
:amp
user=> (let [a 'b] (case a nil :nil 'b :b :none))
:b

But in the CLJS Rhino REPL this is what I see:

ClojureScript:cljs.user> (let [a 'a] (case a nil :nil '& :amp :none))
:none
ClojureScript:cljs.user> (let [a '&] (case a nil :nil '& :amp :none))
:none
ClojureScript:cljs.user> (let [a 'b] (case a nil :nil 'b :b :none))
:none


 Comments   
Comment by David Nolen [ 07/Sep/12 4:48 PM ]

This did reveal a bug though the ticket description does have a user error. The tests for case can only be literals - you should not quote the test values. For example the following is how symbols should be tested:

(let [a '&] (case a nil :nil & :amp :none))

The above code that quotes the test is actually equivalent to:

(let [a '&] (case a nil :nil (quote &) :amp :none))

Which happens to work but probably isn't intended.

With the coming patch CLJS now works as Clojure.

Comment by David Nolen [ 07/Sep/12 4:49 PM ]

Fixed, http://github.com/clojure/clojurescript/commit/c8e301a9b058f81bb599026a07f97ccdf4441730





[CLJS-363] `format` %s behavior is incorrect for keyword, symbol etc. Created: 29/Aug/12  Updated: 27/Jul/13  Resolved: 29/Aug/12

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

Type: Defect Priority: Major
Reporter: Shantanu Kumar Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: bug
Environment:

ClojureScript Rhino REPL



 Description   

On the Clojure REPL, `format` works fine:

user=> (format "foo%s" :s) 
"foo:s" 
user=> (format "foo%s" 's) 
"foos"

However, on the CLJS REPL (Rhino), the output is different:

ClojureScript:cljs.user> (format "foo%s" :s) 
"foo 's" 
ClojureScript:cljs.user> (format "foo%s" 's) 
"foo 's"

Reference: http://groups.google.com/group/clojure/browse_thread/thread/b253d810536a4046



 Comments   
Comment by David Nolen [ 29/Aug/12 7:54 PM ]

fixed, http://github.com/clojure/clojurescript/commit/bf0622a594473c9a6de57fe3b5d10e0419fc7a2a





[CLJS-359] `with-meta` does not work on function objects Created: 25/Aug/12  Updated: 27/Jul/13  Resolved: 21/Nov/12

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

Type: Defect Priority: Major
Reporter: Shantanu Kumar Assignee: David Nolen
Resolution: Completed Votes: 1
Labels: bug
Environment:

CLJS Rhino-REPL and during Compilation


Attachments: Text File CLJS-359-v1.patch     Text File CLJS-359-v2.patch    
Patch: Code and Test

 Description   

`with-meta` does not working on function objects in CLJS. Compilation fails with the following error:

Error: No protocol method IWithMeta.-with-meta defined for type function: function { return x; }

I tried it out on the REPL and found the following:

---------- BEGIN: repl-rhino ----------
ClojureScript:cljs.user> (with-meta #(do :foo) {:foo :bar})
"Error evaluating:" (with-meta (fn* [] (do :foo)) {:foo :bar}) :as "cljs.core.with_meta.call(null,(function (){\nreturn \"\\uFDD0'foo\";\n}),cljs.core.ObjMap.fromObject([\"\\uFDD0'foo\"],{\"\\uFDD0'foo\":\"\\uFDD0'bar\"}));\n"
org.mozilla.javascript.JavaScriptException: Error: No protocol method IWithMeta.-with-meta defined for type function:
function () { return "\ufdd0'foo"; }
(cljs/core.cljs#222)
at cljs/core.cljs:222 (anonymous)
at cljs/core.cljs:214 (_with_meta)
at cljs/core.cljs:806 (with_meta)
at <cljs repl>:2 (anonymous)
at <cljs repl>:2

nil
---------- END: repl-rhino ----------

Reference: https://groups.google.com/forum/?fromgroups=#!topic/clojure/pRO-5IlilNM



 Comments   
Comment by David Nolen [ 29/Aug/12 9:52 AM ]

We could create a fn wrapper type of some kind that implements all the supported arities of IFn (this means the compiler needs to guarantee that args past 20 are collected into an array-seq) that include the extra meta fields. Seems doable.

Comment by Paul deGrandis [ 28/Sep/12 3:21 PM ]

I have created that exact function wrapper - it's in Shoreleave. We can move it into CLJS proper if you like.

https://github.com/shoreleave/shoreleave-core/blob/master/src/shoreleave/efunction.cljs

Comment by David Nolen [ 28/Sep/12 3:24 PM ]

That's nice but would prefer to have as little overhead as possible.

Comment by Paul deGrandis [ 28/Sep/12 3:27 PM ]

ala unrolling the invoke call?

More than happy to start pulling together a patch.

Comment by David Nolen [ 28/Sep/12 3:34 PM ]

Yes there's actually an existing ticket for that. Thanks. We also need compiler support for function invocations when there's more then 20 arguments - though that's a different existing ticket.

Comment by Paul deGrandis [ 22/Oct/12 7:50 AM ]

I was just waiting on CLJS-365 to be completed. Did you think of a better approach than the deftype-wrapper? More than happy to push on this.

Comment by David Nolen [ 23/Oct/12 6:36 PM ]

I thought about this some more - this patch is really about adding metadata to functions at runtime - static metadata on defs are stored in cljs.analyzer/namespaces. Given that it's runtime I think your simple patch is actually OK, we can't generally optimize functions like that anyway since we won't have that kind of information available.

Comment by Brandon Bloom [ 21/Nov/12 3:29 PM ]

Patch adds a Function type and extends js/function to support metadata. There is now an Fn marker protocol.

Patch also includes an additional commit to fix the behavior of the this variable for IFn definitions.

Not tested on JavaScriptCore.

Comment by Brandon Bloom [ 21/Nov/12 4:16 PM ]

v2 of patch improves speed of fn? and utilizes reify to avoid creating an explicit Function type

Comment by David Nolen [ 21/Nov/12 4:21 PM ]

fixed, http://github.com/clojure/clojurescript/commit/6ce3b1cef3824fd36e75402f5a8ed5053252b15e





[CLJS-339] (inc nil) returns 1 instead of throwing an exception Created: 23/Jul/12  Updated: 29/Jul/13  Resolved: 29/Jul/13

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

Type: Defect Priority: Minor
Reporter: Evan Mezeske Assignee: Unassigned
Resolution: Declined Votes: 0
Labels: bug


 Description   

(inc nil) => 1 in ClojureScript
(inc nil) => raise NullPointerException in Clojure

I think that Clojure's behavior (throwing) makes more sense in this context.



 Comments   
Comment by Evan Mezeske [ 23/Jul/12 12:44 AM ]

I observe that in my JS console, "undefined + 1 => NaN" but "null + 1 => 1". I assume this has something to do with this issue.

Comment by David Nolen [ 23/Jul/12 12:30 PM ]

Do you have any suggestions on how to make this work without slowing arithmetic down? If not I'm inclined to close this as Won't Fix.

Comment by Evan Mezeske [ 23/Jul/12 12:50 PM ]

I do not. I haven't had a chance to put a lot of thought into it, though.

I consider this kind of problem to be rather insidious. Null is not a number, and treating it as zero will lead to nasty bugs creeping into people's code.

A historical anecdote: the C function "int atoi(char* s)" takes a string and returns the number it represents. However, if the string can't be converted, it returns zero (which could also be a valid result for e.g. the string "0"). Technically, it's possible to distinguish "0 meaning error" and "0 meaning 0" by taking additional steps after the function call, but in practice people forget to do this. Thus, atoi is universally a disaster. I have literally seen the lights go off in a warehouse due to atoi's poor design (I used to work in building control).

Treating null as zero will result in similar problems. Someone forgets to check the result of a computation, it's null, and the program silently continues as if nothing is wrong. Hello, data corruption.

So I seriously urge you to not close this as Won't Fix, even if a performant solution is not yet obvious. IMHO it's worth more thought.

Comment by David Nolen [ 23/Jul/12 12:56 PM ]

Closing as Won't Fix doesn't mean we don't care, but this issue is simply a symptom of something much larger - punting on numerics. A ticket is the wrong place for this discussion as it has many nuances. It should be a part of a larger design for ClojureScript numerics. Without that larger discussion this ticket is likely to get stuck in limbo.

Comment by Evan Mezeske [ 23/Jul/12 12:59 PM ]

Fair enough! I thought Won't Fix had stronger implications than that. Do you know if there's already a design doc that addresses numerics? Or should I start one?

Comment by Fogus [ 23/Jul/12 1:04 PM ]

One place that this has burned me, that may warrant a separate card is

(update-in some-map [:foo :bar] inc)
where the key at that location did not exist. I would have preferred an exception rather than an broken 1.

Comment by Evan Mezeske [ 23/Jul/12 1:09 PM ]

@Fogus: Huh, that is the exact same use-case that burned me – I was using update-in/inc on a nested map. The default value for my [:foo :bar] was, in fact, supposed to be zero, so it silently worked for me. But when I moved that code from the client in my webapp (ClojureScript) to the server (Clojure), I found out that my original implementation was wonky.

Comment by David Nolen [ 23/Jul/12 1:17 PM ]

It doesn't seem to me that you could do that safely without fnil + 0. I too hate JS's silent failures around numerics. Been hoping someone would tackle this challenge with gusto.

Comment by Evan Mezeske [ 23/Jul/12 1:21 PM ]

@David Nolen: Yeah, fnil would do the job. In my case, I was calling update-in on what I thought was an initialized map, but it was actually nil. update-in initialized each level of nesting with an empty map, and then inc was called on nil. My fix was simply to initialize the nested maps like I meant to.

Comment by Fogus [ 23/Jul/12 1:21 PM ]

David,
That was ultimately the solution, so I suppose we need to start advocating this pattern so that others might avoid the same fate.

Comment by David Nolen [ 29/Jul/13 11:32 PM ]

tickets of this nature aren't going anywhere without a fairly serious design pass on CLJS numerics.





[CLJS-338] Incorrect implementation of IReduce by ArrayChunk Created: 22/Jul/12  Updated: 29/Jul/13

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

Type: Defect Priority: Minor
Reporter: Anton Frolov Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: bug


 Description   
(reduce + (array-chunk (array 1 2 3 4) 1 3)) => 2 (instead of 5)
(reduce + 0 (array-chunk (array 1 2 3 4) 1 3)) => 3 (instead of 5)
(reduce + (array-chunk (array 1 2 3 4) 1 1)) => 2 (instead of 0)

In src/cljs/cljs/core.cljs, line #1817:

(deftype ArrayChunk [arr off end]
  ;; ...
  IReduce
  (-reduce [coll f]
    (ci-reduce coll f (aget arr off) (inc off))) ;; should be (if (< off end) (ci-reduce coll f (aget arr off) 1) 0)
  (-reduce [coll f start]
    (ci-reduce coll f start off))) ;; should be (ci-reduce coll f start 0)


 Comments   
Comment by David Nolen [ 14/Aug/12 6:29 AM ]

Thanks for the report. ArrayChunk is an implementation detail - do these conditions actually arise?





[CLJS-309] Bug - Typo in commit "Tagged literals in the CLJS compiler and first blush tests " Created: 08/Jun/12  Updated: 08/Jun/12  Resolved: 08/Jun/12

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

Type: Defect Priority: Major
Reporter: Raphaël AMIARD Assignee: Unassigned
Resolution: Declined Votes: 0
Labels: bug

Attachments: Text File fix-data-readers-typo.patch    
Patch: Code

 Description   

I'm pretty sure there is a typo in this commit,

cljs-data-readers is declared, but then data-readers is bound in compile-file, which makes compilation fail

Patch attached



 Comments   
Comment by Fogus [ 08/Jun/12 8:43 AM ]

I'm unable to reproduce this. Do you mind posting the steps that you ran to see the error?
Thank you.

Comment by Raphaël AMIARD [ 08/Jun/12 10:48 AM ]

Sorry, i failed to follow the implications of CLJ-890, the bug was related to my configuration, and the binding valid.





[CLJS-262] vector-seq optimizations introduced un-conj-able sequence Created: 18/May/12  Updated: 27/Jul/13  Resolved: 18/May/12

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

Type: Defect Priority: Major
Reporter: Brian Taylor Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: bug


 Description   

Due to changes introduced in commit ddd7fa3d960b0fe32083d3cb35ff064e968d53c4 "attempting to optimize seq on vectors" the following code will fail with the an error:

(conj (rest [1 2]) 4)

The error is "No protocol method ICollection.-conj defined for type object: [object Object]" and the object in question is the reify result returned by vector-seq.



 Comments   
Comment by David Nolen [ 18/May/12 9:58 PM ]

fixed, http://github.com/clojure/clojurescript/commit/1d20ac061199a0acd3a1fe5ae08579edb255f377





[CLJS-183] The pop function in PersistentVector is buggy Created: 18/Apr/12  Updated: 27/Jul/13  Resolved: 19/Apr/12

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

Type: Defect Priority: Major
Reporter: Erik Ouchterlony Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: bug

Attachments: File fix-persistentvector-pop.diff     File fix-persistentvector-pop.diff     File fix-persistentvector-pop-with-tests.diff    

 Description   

Example:

(conj (pop [1 2]) 3) => [1 2]



 Comments   
Comment by Nicola Mometto [ 18/Apr/12 10:22 AM ]

this patch fixes pop

Comment by Laszlo Török [ 19/Apr/12 2:38 AM ]

Hi,

good catch, but why not simply:

(PersistentVector. meta (dec cnt) shift root (.slice tail 0 -1))
;; you don't need to aclone and splice, .slice returns a new array

Comment by Nicola Mometto [ 19/Apr/12 3:48 AM ]

right, using slice is even faster.
patch updated

Comment by Laszlo Török [ 19/Apr/12 6:01 AM ]

Nice, thank you!

Could you please add a test that covers the issue?

e.g.

(assert (= (vec (range 33))
(-> (vec (range 33))
(pop)
(pop)
(conj 31)
(conj 32))))

Comment by Nicola Mometto [ 19/Apr/12 10:15 AM ]

sure, here it is

Comment by David Nolen [ 19/Apr/12 10:31 PM ]

Fixed, https://github.com/clojure/clojurescript/commit/053b7fd9cbb0a24617592f490893d6a746e54ec7





[CLJS-162] cljs.core/str behavior not consistent with clojure Created: 15/Mar/12  Updated: 27/Jul/13  Resolved: 19/Mar/12

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

Type: Defect Priority: Trivial
Reporter: Roman Gonzalez Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: bug
Environment:

This is the behavior on rhino repl, haven't tested on browser


Attachments: Text File CLJS-162_1.patch     Text File CLJS-162_2.patch     Text File CLJS-162.patch    

 Description   

When running the cljs.core/str function with symbols or keywords the output is not the same as in clojure

ClojureScript:cljs.user> (str "hello" :world)
"hello?'world"

The same happens with symbols, it seems the characters used internally for figuring out if a string is a keyword or symbol are not being escaped correctly on the cljs.core/str function.



 Comments   
Comment by Roman Gonzalez [ 15/Mar/12 9:18 PM ]

Added check of symbols and keywords on the private cljs.core/str* function

Comment by David Nolen [ 16/Mar/12 11:57 AM ]

The patch looks good but some tests fail now. Can you address that? Thanks!

Comment by Roman Gonzalez [ 16/Mar/12 11:55 PM ]

Thanks for checking this out David, I didn't read the developer wiki (my bad), I added a few tests and added a new small function that will allow both str* and str to behave correctly, cheers.

Note: Use CLJS-162_1.patch

Comment by Roman Gonzalez [ 19/Mar/12 5:45 PM ]

New patch which just replicates the StringBuffer code from `str*` into the `str` implementation.

Comment by David Nolen [ 19/Mar/12 9:25 PM ]

Fixed, https://github.com/clojure/clojurescript/commit/ec75a897fc7069176aff81e2df91b848c26af1c8





Generated at Wed Sep 17 02:38:26 CDT 2014 using JIRA 4.4#649-r158309.