<< Back to previous view

[CLJS-687] error/warning when deftype/record constructor used as a function Created: 19/Nov/13  Updated: 19/Nov/13  Resolved: 19/Nov/13

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

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


 Comments   
Comment by David Nolen [ 19/Nov/13 5:11 PM ]

fixed,https://github.com/clojure/clojurescript/commit/792b2b87c9982a76093fcc3278dd246e8672627b





[CLJS-410] support ^:expose annotation Created: 28/Oct/12  Updated: 19/Nov/13  Resolved: 19/Nov/13

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

Type: Enhancement Priority: Minor
Reporter: David Nolen Assignee: Unassigned
Resolution: Declined Votes: 0
Labels: None

Attachments: Text File CLJS-410.patch    

 Description   
(def ^:export m 1)
(defn foo [g]
  (g m))

Because of constant propagation GClosure may replace m in foo with 1. It may be better to for :export to implicitly :expose but we need to check the output.

http://developers.google.com/closure/compiler/docs/js-for-compiler



 Comments   
Comment by Olle Martensson [ 22/Jul/13 5:33 AM ]

def annotated with ^:export is now implicitly treated as an exposed property by the closure compiler.

The goog.exportSymbol part for def seemed to be redundant and thus removed.

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

There are workaround for this.





[CLJS-735] Set literal and hash-set cleanup Created: 28/Dec/13  Updated: 30/Dec/13  Resolved: 30/Dec/13

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

Type: Defect Priority: Minor
Reporter: Logan Campbell Assignee: Unassigned
Resolution: Declined Votes: 0
Labels: None
Environment:

Clojurescript 0.0-2127


Attachments: Text File cljs-735-dead-code-cleanup.patch    

 Description   

Some sets drop values, causing loss of data.

The smallest example I've been able to find is:

#{[1 4] [2 4] [3 4] [0 3] [1 3] [2 3] [3 3] [3 2] [4 2]}
Drops: [1 4] [3 4] [1 3] [3 3]

hash-set also drops values. Though they are different.

(hash-set [1 4] [2 4] [3 4] [0 3] [1 3] [2 3] [3 3] [3 2] [4 2])
Drops: [2 4] [0 3] [2 3] [3 2]

Re-ordering the values appears to make no difference.

I have found no instance where sorted-set drops values.



 Comments   
Comment by Francis Avila [ 29/Dec/13 6:04 PM ]

This is a bug in PersistentHashSet.fromArray that causes every other item to be skipped when the input is longer than the PersistentArrayMap.HASHMAP_THRESHOLD (which is 8). Demonstration:

ClojureScript:cljs.user> (hash-set [0] [1] [2] [3] [4] [5] [6] [7] [8])
#{[2] [4] [6] [8] [0]}
ClojureScript:cljs.user> (hash-set [0] [1] [2] [3] [4] [5] [6] [7])   
#{[1] [2] [3] [4] [5] [6] [7] [0]}

Working on a patch and test.

Comment by Francis Avila [ 29/Dec/13 6:11 PM ]

Nevermind, looks like David fixed this already.

Comment by Francis Avila [ 29/Dec/13 8:02 PM ]

Some dead code was left in PersistentHashSet.fromArray (no-clone arg and arr let-binding). Attached a patch that cleans this up.

Comment by David Nolen [ 30/Dec/13 8:51 AM ]

Thanks for the patch but remember we need CAs to apply them.

The current hash-set construction implementation misses an optimization opportunity. We could build hash-sets much faster if we know that we have only unique constants at compile time.

Comment by David Nolen [ 30/Dec/13 8:52 AM ]

Need to implement the hash-set construction optimization, the old removed approach is faster when we know we have a set literal containing only constants.





Generated at Mon Jul 28 17:52:13 CDT 2014 using JIRA 4.4#649-r158309.