<< Back to previous view

[CLJ-1420] ThreadLocalRandom instead of Math/random Created: 11/May/14  Updated: 20/Jun/14

Status: Open
Project: Clojure
Component/s: None
Affects Version/s: Release 1.7
Fix Version/s: Backlog

Type: Enhancement Priority: Minor
Reporter: Linus Ericsson Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: math, performance
Environment:

Requires Java >=1.7!


Attachments: Text File 0001-rand-using-ThreadLocalRandom-and-tests-for-random.patch    
Patch: Code
Approval: Vetted

 Description   

The standard Math.random() is thread-safe through being declared as a synchronized static method.

The patch uses java.util.concurrent.ThreadLocalRandom which actually seems to be two times faster than the ordinary Math.random() in a simple single threaded criterium.core/bench:

The reason I investigated the function at all was to be sure random-number generation was not a bottleneck when performance testing multithreaded load generation.

If necessary, one could of course make a conditional declaration (like in fj-reducers) based on the existence of the class java.util.concurrent.ThreadLocalRandom, if Clojure 1.7 is to be compatible with Java versions < 1.7



 Comments   
Comment by Linus Ericsson [ 11/May/14 11:05 AM ]

Benchmark on current rand (clojure 1.6.0), $ java -version
java version "1.7.0_51"
OpenJDK Runtime Environment (IcedTea 2.4.4) (7u51-2.4.4-0ubuntu0.13.10.1)
OpenJDK 64-Bit Server VM (build 24.45-b08, mixed mode)

:jvm-opts ^:replace [] (ie no arguments to the JVM)

(bench (rand 10))
Evaluation count : 1281673680 in 60 samples of 21361228 calls.
Execution time mean : 43.630075 ns
Execution time std-deviation : 0.420801 ns
Execution time lower quantile : 42.823363 ns ( 2.5%)
Execution time upper quantile : 44.456267 ns (97.5%)
Overhead used : 3.194591 ns

Found 1 outliers in 60 samples (1.6667 %)
low-severe 1 (1.6667 %)
Variance from outliers : 1.6389 % Variance is slightly inflated by outliers

Clojure 1.7.0-master-SNAPSHOT.

(bench (rand 10))
Evaluation count : 2622694860 in 60 samples of 43711581 calls.
Execution time mean : 20.474605 ns
Execution time std-deviation : 0.248034 ns
Execution time lower quantile : 20.129894 ns ( 2.5%)
Execution time upper quantile : 21.009303 ns (97.5%)
Overhead used : 2.827337 ns

Found 2 outliers in 60 samples (3.3333 %)
low-severe 2 (3.3333 %)
Variance from outliers : 1.6389 % Variance is slightly inflated by outliers

I had similar results on Clojure 1.6.0, and ran several different tests with similar results. java.util.Random.nextInt is suprisingly bad. The ThreadLocalRandom version of .nextInt is better, but rand-int can take negative integers, which would lead to some argument conversion for (.nextInt (ThreadLocalRandom/current) n) since it need upper and lower bounds instead of a simple multiplication of a random number [0,1).

CHANGE:

The (.nextDouble (ThreadLocalRandom/current) argument) is very quick, but cannot handle negative arguments. The speed given a plain multiplication is about 30 ns.

Comment by Linus Ericsson [ 11/May/14 12:44 PM ]

Added some simplistic tests to be sure that rand and rand-int accepts ratios, doubles and negative numbers of various kinds. A real test would likely include repeated generative testing, these tests are mostly for knowing that various arguments works etc.

Comment by Linus Ericsson [ 11/May/14 1:38 PM ]

0001-rand-using-ThreadLocalRandom-and-tests-for-random.patch contains the changed (rand) AND the test cases.

Comment by Alex Miller [ 11/May/14 5:45 PM ]

Clojure requires Java 1.6.0 so this will need to be reconsidered at a later date. We do not currently have any plans to bump the minimum required JDK in Clojure 1.7 although that could change of course.

Comment by Gary Fredericks [ 11/May/14 5:54 PM ]

I've always thought that the randomness features in general are of limited utility due to the inability to seed the PRNG, and that a clojure.core/rand dynamic var would be a reasonable way to do that.

Maybe both of these problems could be partially solved with a standard library? I started one at https://github.com/fredericksgary/four, but presumably a contrib library would be easier for everybody to standardize on.

Comment by Linus Ericsson [ 12/May/14 2:17 AM ]

Gary, I'm all for creating some well-thought out random-library, which could be a candidate for some library clojure.core.random if that would be useful.

Please have a look at http://code.google.com/p/javarng/ since that seems to do what you library four does (and more). Probably we could salvage either APIs, algorithms or both from this library.

I'll contact you via mail!

Comment by Gary Fredericks [ 20/Jun/14 10:21 AM ]

Come to think of it, a rand var in clojure.core shouldn't be a breaking change, so I'll just make a ticket for that to see how it goes. That should at the very least allow solving the concurrency issue with binding. The only objection I can think of is perf issues with dynamic vars?

Comment by Gary Fredericks [ 20/Jun/14 10:42 AM ]

New issue is at CLJ-1452.





[CLJ-1104] Concurrent with-redefs do not unwind properly, leaving a var permanently changed Created: 07/Nov/12  Updated: 26/Jul/13

Status: Open
Project: Clojure
Component/s: None
Affects Version/s: Release 1.4, Release 1.5
Fix Version/s: Backlog

Type: Enhancement Priority: Minor
Reporter: Jason Wolfe Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Environment:

Mac OS, Java 6


Attachments: Text File clj-1104-doc-unsafety-of-concurrent-with-redefs-v1.txt    
Patch: Code
Approval: Vetted

 Description   

On 1.4 and latest master:

user> (defn ten [] 10)
#'user/ten
user> (doall (pmap #(with-redefs [ten (fn [] %)] (ten)) (range 20 100)))
(20 21 22 23 24 25 34 27 28 29 30 31 32 33 34 35 36 37 38 39 39 35 42 43 44 45 48 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 79 87 88 89 90 91 92 93 94 95 97 92 98 99)
user> (ten)
79

Not sure if this is a bug per se, but the doc doesn't mention lack of concurrency safety and my expectation was that the original value would always be restored after any (arbitrarily interleaved) sequence of with-redefs calls.



 Comments   
Comment by Tim McCormack [ 07/Nov/12 8:50 PM ]

The with-redefs doc (v1.4.0) says "These temporary changes will be visible in all threads." That sounds non-thread-safe to me.

In general, changes to var root bindings are not thread safe.

Comment by Herwig Hochleitner [ 08/Nov/12 9:17 AM ]

As I understand it, with-redefs is mainly used in test suites to mock out vars. It was introduced when vars became static by default and a lot of testsuites had been using binding for mocking. Maybe the docstring should be amended with something along the lines of: When using this you have to ensure that only a single thread is interacting with redef'd vars.

Comment by Stuart Halloway [ 25/Nov/12 6:41 PM ]

Behavior find as is, doc string change would be fine.

Comment by Andy Fingerhut [ 25/Nov/12 6:57 PM ]

Patch clj-1104-doc-unsafety-of-concurrent-with-redefs-v1.txt dated Nov 25 2012 updates doc string of with-redefs to make it clear that concurrent use is unsafe.





[CLJ-892] sort changes its argument, if a Java array Created: 08/Dec/11  Updated: 26/Jul/13  Resolved: 18/May/12

Status: Closed
Project: Clojure
Component/s: None
Affects Version/s: Release 1.3, Release 1.4
Fix Version/s: Backlog, Release 1.5

Type: Enhancement Priority: Minor
Reporter: Stephen Compall Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: None
Environment:

java version "1.6.0_22"
OpenJDK Runtime Environment (IcedTea6 1.10.4) (6b22-1.10.4-0ubuntu1~11.04.1)
(clojure-version)
"1.4.0-alpha2"


Attachments: Text File clj-892-clarify-sort-sort-by-doc-strings-patch1.txt    
Patch: Code
Approval: Ok

 Description   

user> (let [a (to-array [32 11])]
(prn (seq a))
(sort a)
(prn (seq a)))
(32 11)
(11 32)
nil

Where the second line printed ought to be the same as the first.



 Comments   
Comment by Stuart Halloway [ 09/Dec/11 9:37 AM ]

This is an enhancement request, since the docs for sort make no promise one way or the other.

For performance, I prefer the current behavior, so another possibility is a clarifying doc string.

Comment by Andy Fingerhut [ 26/Mar/12 5:32 PM ]

clj-892-clarify-sort-sort-by-doc-strings-patch1.txt of Mar 26, 2012 applies cleanly to latest master on that date. Only doc string changes, to make it clear that by sort and sort-by will modify Java arrays given as arguments.





[CLJ-848] defn :or form does not warn you if you provide a vector instead of a map Created: 06/Oct/11  Updated: 26/Jul/13  Resolved: 25/Oct/11

Status: Closed
Project: Clojure
Component/s: None
Affects Version/s: Release 1.3
Fix Version/s: Backlog

Type: Enhancement Priority: Trivial
Reporter: Dave Barker Assignee: Unassigned
Resolution: Declined Votes: 0
Labels: None
Environment:

Clojure 1.3, Emacs 23, OSX Lion



 Description   

I had a problem defining a function today, I passed :or a vector instead of a map - everything seemed to work fine but later on I got a really puzzling "Null pointer exception".

raek helped me debug the problem and suggested opening this ticket. I think it would be useful if an exception was thrown on the :or line unless it's given a map.

Here are some examples

(defn broken-example [{:keys [i processor]
:or [processor identity]}]
(processor i))

(defn working-example [{:keys [i processor]
:or {processor identity}}]
(processor i))

(working-example {:i 1})
=> 1
(broken-example {:i 1})
=> Null pointer exception

Cheers, Dave.



 Comments   
Comment by Dave Barker [ 06/Oct/11 6:51 AM ]

Apologies, I meant to tag this as a minor issue instead of a major one!

Comment by Stuart Halloway [ 07/Oct/11 9:39 AM ]

Since vectors are associative, maybe using vectors for :or should just work?

(let [{noun 0
       verb 1
       obj 2
       :or [:n :v :o]}
      [:code :is]] obj)
Comment by Stuart Halloway [ 25/Oct/11 6:04 PM ]

Closing this until someone wants to make a principled argument for what should happen (see my previous comment)





[CLJ-826] Include drop, take, butlast from clojure.contrib.string (1.2) in clojure.string 1.3 Created: 08/Aug/11  Updated: 02/Dec/11  Resolved: 02/Dec/11

Status: Closed
Project: Clojure
Component/s: None
Affects Version/s: Backlog
Fix Version/s: Backlog

Type: Enhancement Priority: Minor
Reporter: Arthur Edelstein Assignee: Unassigned
Resolution: Declined Votes: 3
Labels: None

Attachments: File clj-826-add-take-drop-butlast.diff     File clj-826-add-take-drop-butlast-v3.diff     File clj-826-add-take-drop-butlast-with-versions.diff    
Patch: Code and Test
Waiting On: Matthew Lee Hinman

 Description   

From clojure.contrib.string 1.2, I have found myself using drop, take,
and butlast. (These are more than just wrappers for String/substring,
because they behave nicely when indices exceed the string length.) I
like these methods in part because they match the behavior of
corresponding sequence methods, but have better performance. This
makes optimizing (when needed) easier.



 Comments   
Comment by Matthew Lee Hinman [ 08/Aug/11 1:22 PM ]

Attached patch for adding the methods.

Comment by Matthew Lee Hinman [ 08/Aug/11 6:28 PM ]

I intentionally left out the {:added "_"} from the vars since I have no idea when this will be added.

This (as expected) causes this test to fail:
[java] FAIL in (public-vars-with-docstrings-have-added) (metadata.clj:42)
[java] expected: (= [] (remove (comp :added meta) public-vars-with-docstrings))
[java] actual: (not (= [] (#'clojure.string/butlast #'clojure.string/drop #'clojure.string/take)))

Which is easily remedied. If desired, let me know what version this will be added to and I'll submit a new patch with the :added metadata included.

Comment by Matthew Lee Hinman [ 12/Nov/11 4:29 PM ]

I have attached a patch with "1.4" as the added version now that 1.3 has been released.

Comment by Chouser [ 18/Nov/11 10:29 PM ]

The algorithms, docs, and tests look good. I think the functions would be better if they used clojure.core/subs like the rest of clojure.string does, instead of .substring. This is more idiomatic Clojure and allows you to avoid hinting the String arg.

When a new patch is uploaded, please remember to set the Patch field of this ticket to "Code and Test" and the Approval field to "Test". Hopefully this will lead to faster screening.

Comment by Matthew Lee Hinman [ 21/Nov/11 12:50 PM ]

Attached a patch that uses subs instead of .substring (clj-826-add-take-drop-butlast-v3.diff).

Comment by Stuart Halloway [ 02/Dec/11 9:14 AM ]

These fns were left out intentionally. Feel free to propose a contrib home for them, though.





[CLJ-806] clojure.test/are does not fail with insufficient arguments Created: 03/Jun/11  Updated: 16/Feb/12  Resolved: 16/Feb/12

Status: Closed
Project: Clojure
Component/s: None
Affects Version/s: Backlog
Fix Version/s: Backlog

Type: Defect Priority: Minor
Reporter: Stuart Sierra Assignee: Stuart Sierra
Resolution: Duplicate Votes: 0
Labels: None


 Description   

If clojure.test/are is given an argument set with missing parameters, it silently ignores the extra parameters at the end instead of failing.

Clojure 1.3.0-master-SNAPSHOT
user=> (use 'clojure.test)
nil
user=> (deftest foo (are [x y] (= x y) 1 1 2 2 3 4))
#'user/foo
user=> (foo)

FAIL in (foo) (NO_SOURCE_FILE:6)
expected: (= 3 4)
  actual: (not (= 3 4))
nil
user=> (deftest missing-argument (are [x y] (= x y) 1 1 2 2 3))
#'user/missing-argument
user=> (missing-argument)
nil  ;; doesn't fail


 Comments   
Comment by Tassilo Horn [ 16/Feb/12 11:43 AM ]

Duplicate of CLJ-931. (Well, basically the other way round, but CLJ-931 has a fix attached, so I close this one.)





[CLJ-785] Optimize / Created: 30/Apr/11  Updated: 13/May/11  Resolved: 13/May/11

Status: Closed
Project: Clojure
Component/s: None
Affects Version/s: None
Fix Version/s: Backlog

Type: Enhancement Priority: Major
Reporter: Alan Dipert Assignee: Unassigned
Resolution: Declined Votes: 0
Labels: None


 Description   

Optimization to / such that the & more version expands to equivalent of (/ x (reduce * y more)) rather than (reduce / (/ x y) more). There should be an inlined variant of & more as well.

This was originally part of CLJ-184, but was pulled out because it's big enough to be its own ticket. The rationale is that multiplies are significantly faster than divides on the JVM, and n-ary calls to / could be faster.

See "Java Multiplication (Much) Faster than Division" for background and Java benchmarks.



 Comments   
Comment by Alan Dipert [ 13/May/11 9:26 AM ]

We don't want to mess with the semantics of division at the bottom.





[CLJ-771] Move unchecked-prim casts to clojure.unchecked Created: 07/Apr/11  Updated: 03/Sep/13

Status: Open
Project: Clojure
Component/s: None
Affects Version/s: Backlog
Fix Version/s: Backlog

Type: Enhancement Priority: Minor
Reporter: Alexander Taggart Assignee: Alexander Taggart
Resolution: Unresolved Votes: 0
Labels: math

Attachments: Text File clj-771-move-unchecked-casts-patch-v5.txt     Text File move-unchecked-casts.patch     Text File move-unchecked-casts-v2.patch    
Patch: Code and Test
Approval: Vetted
Waiting On: Rich Hickey

 Description   

Per Rich's comment in CLJ-767:

Moving unchecked coercions into unchecked ns is ok



 Comments   
Comment by Alexander Taggart [ 29/Apr/11 3:41 PM ]

Requires that patch on CLJ-782 be applied first.

Comment by Stuart Sierra [ 31/May/11 10:43 AM ]

Applies on master as of commit 66a88de9408e93cf2b0d73382e662624a54c6c86

Comment by Rich Hickey [ 09/Dec/11 8:40 AM ]

still considering when to incorporate this

Comment by John Szakmeister [ 19/May/12 9:36 AM ]

v2 of the patch applies to master as of commit eccde24c7fb63679f00c64b3c70c03956f0ce2c3

Comment by Andy Fingerhut [ 07/Sep/12 12:40 AM ]

Patch clj-771-move-unchecked-casts-patch-v3.txt dated Sep 6 2012 is the same as Alexander Taggart's patch move-unchecked-casts.patch except that it has been updated to apply cleanly to latest Clojure master.

Comment by Andy Fingerhut [ 20/Oct/12 12:18 PM ]

Patch clj-771-move-unchecked-casts-patch-v4.txt dated Oct 20 2012 is the same as Alexander Taggart's patch move-unchecked-casts.patch except that it has been updated to apply cleanly to latest Clojure master.

Comment by Andy Fingerhut [ 01/Jan/13 11:37 AM ]

The patch clj-771-move-unchecked-casts-patch-v4.txt applies cleanly to latest master and passes all tests. Rich marked this ticket as Incomplete on Dec 9 2011 with the comment "still considering when to incorporate this" above. Is it reasonable to change it back to Vetted or Screened so it can be considered again, perhaps after Release 1.5 is made?

Comment by Andy Fingerhut [ 13/Feb/13 12:50 AM ]

Patch clj-771-move-unchecked-casts-patch-v5.txt dated Feb 12 2013 is the same as Alexander Taggart's patch move-unchecked-casts.patch except that it has been updated to apply cleanly to latest Clojure master.





[CLJ-765] Enhance clojure.java.shell/sh to accept more input types Created: 25/Mar/11  Updated: 26/Jul/13  Resolved: 06/May/11

Status: Closed
Project: Clojure
Component/s: None
Affects Version/s: None
Fix Version/s: Backlog

Type: Enhancement Priority: Minor
Reporter: Alexander Taggart Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: None

Attachments: Text File 0765-shell-2.patch     Text File shell.patch    
Patch: Code
Approval: Ok

 Description   

Currently clojure.java.shell/sh will only accept bytes or Strings as inputs to the subprocess's stdin.

Attached patch replaces code specific to byte[] and String with a call to clojure.java.io/copy, thus additionally accepting InputStreams, Readers, and Files as input.



 Comments   
Comment by Stuart Halloway [ 05/Apr/11 8:39 PM ]

second patch subsumes first, removes spurious imports.





[CLJ-753] clojure.string/replace-first returns nil with replacement fn when regex doesn't match Created: 11/Mar/11  Updated: 26/Jul/13  Resolved: 24/Aug/12

Status: Closed
Project: Clojure
Component/s: None
Affects Version/s: None
Fix Version/s: Backlog

Type: Defect Priority: Minor
Reporter: Stuart Sierra Assignee: Stuart Sierra
Resolution: Completed Votes: 2
Labels: None

Attachments: Text File 0001-clojure.string-replace-first-now-returns-the-origina.patch     Text File clojure-string-with-no-match-returns-original-2.patch     Text File clojure-string-with-no-match-returns-original.patch    
Patch: Code and Test
Approval: Vetted

 Description   

Originally reported by Takahiro Hozumi

With a function as the "replacement" argument, clojure.string/replace-first returns nil if there is no match, instead of returning the original string unchanged.

user=> (use 'clojure.string)
nil
user=> (replace-first "abcdef" "ghi" "jkl")
"abcdef"
user=> (replace-first "abcdef" #"ghi" "jkl")
"abcdef"
user=> (replace-first "abcdef" #"ghi" (fn [a] "jkl"))
nil


 Comments   
Comment by Federico Brubacher [ 21/Mar/11 7:36 AM ]

This is my patch for this issue. I have a CA signed. Any suggestions and i can try again. Federico

Comment by Chris Perkins [ 28/Nov/11 9:31 AM ]

Same fix as Frederico's patch, but also removes unnecessary allocation of a StringBuffer when there is no match, for both replace and replace first.

Comment by Chris Perkins [ 28/Nov/11 9:46 AM ]

Same again, but with docstring typo fixes too.

Comment by Steve Miner [ 28/Nov/11 10:12 AM ]

You should use StringBuilder instead of StringBuffer.

http://stackoverflow.com/questions/355089/stringbuilder-and-stringbuffer-in-java

Comment by Chris Perkins [ 28/Nov/11 10:37 AM ]

Yup, that's what I thought, but it turns out it doesn't work because java's Matcher/appendReplacement requires a StringBuffer, unfortunately.

Comment by Andy Fingerhut [ 28/Nov/11 5:09 PM ]

I've tested Chris's clojure-string-with-no-match-returns-original-2.patch against latest github Clojure as of this morning, and the tests pass. Cool that he found a straightforward performance improvement for the no match case. The code appears correct. I also verified that for the reason Chris mentions, StringBuilder will not work as a replacement for StringBuffer. At least there will never be any contention on the locks implementing the StringBuffer synchronization the way they are used here.

Comment by Stuart Sierra [ 29/Nov/11 8:45 AM ]

Vetted & moved to Approved Backlog.

Comment by Andy Fingerhut [ 12/Jan/12 12:06 AM ]

CLJ-870 has an attached proposed combined patch for this issue and that one.

Comment by Andy Fingerhut [ 18/Aug/12 12:09 PM ]

This issue should now be corrected with the patch, attached to CLJ-870, that was applied on Aug 18, 2012.

Comment by Stuart Sierra [ 24/Aug/12 7:41 AM ]

CLJ-753 patch applied for CLJ-870 addresses this one, too, applied Aug 18, 2012





[CLJ-733] Data Conveying Exception Created: 28/Jan/11  Updated: 26/Jul/13  Resolved: 09/Dec/11

Status: Closed
Project: Clojure
Component/s: None
Affects Version/s: None
Fix Version/s: Backlog

Type: Enhancement Priority: Minor
Reporter: Stuart Halloway Assignee: Stuart Halloway
Resolution: Completed Votes: 0
Labels: None

Attachments: Text File 0733-data-conveying-exception-2.patch     Text File 0733-data-conveying-exception.patch     Text File 0733-dec-2-edition.patch     Text File 0733-ExceptionInfo.patch     Text File 0733-with-ex-data-and-ex-info.patch     Text File 0733-with-map-check.patch    
Patch: Code and Test
Approval: Ok

 Description   

Problem: need to convey diagnostic information in an exception, and Java exceptions are poor for this because they don't have any place to put data. Having many apps write their own exceptions is unnecessary code bloat, and sometimes has compilation implications.

Choices made:

  • Naming it ExceptionInfo. Needs to tell the user that it carries data, without suggesting that there was a problem with data.
    • think we have to include Exception in the name, esp. for interop consumers.
  • Class of data member. IPersistentMap
  • Class of map input. IPersistentMap
  • Do not want to build anything to support conditional logic. (Use bindings for this).
  • Base class. RuntimeException is consistent with a dynamic language (don't want to impose checked exceptions).
  • print with data just after msg on first line
  • equality by identity (pretty much dictated by having exception as base class)
  • ex-info factory function
  • ex-data fn to get the data out
  • data and msg arguments required
  • data argument comes second
    • matches Java expectation of msg first, cause last
    • matches print order


 Comments   
Comment by Alan Dipert [ 28/Jan/11 2:47 PM ]

Looks good; Stu's patch was missing a forward declaration to print-defrecord. 0733-data-conveying-exception-2.patch adds one, and all tests pass.

Comment by Rich Hickey [ 31/Jan/11 12:42 PM ]

Looks like is-a to me. Why is exception a map?

Also, bad practice to merge non-namespace-qualified keys with something you don't originate - should have ns. Actually, why merge at all? Why not let higher-level exception reporting handle cause and message?

Is there a convention for nesting these, merging data?

Comment by Kevin Downey [ 19/Apr/11 3:41 PM ]

type checks for :type in metadata, might be nice if that worked on DCE's, maybe they should support metadata

Comment by Stuart Halloway [ 14/Oct/11 12:52 PM ]

Latest patch per discussion on IRC http://clojure-log.n01se.net/#11:12b . Note that I had to touch string representation in three places (Java, main, and repl). I think main is only used for repl anyway, so a future cleanup could have main and repl share printing code.

Comment by Rich Hickey [ 14/Oct/11 1:34 PM ]

Ctor arg order is a question.

Also, do we want to encourage making an exception w/o a message?

I think it should have been ex-data, in my last line on IRC, not ex-info

Will we have a fn to make these rather than encode the type via ctor call everywhere? Maybe that should be called ex-info. Same fn could be useful in cljs

Comment by Rich Hickey [ 14/Oct/11 1:51 PM ]

Also the description no longer describes the approach

Comment by Stuart Halloway [ 16/Oct/11 6:06 AM ]

Been back and forth on argument order, but I think msg/data/cause is best.

Comment by Rich Hickey [ 16/Oct/11 6:32 AM ]

Only issue I think is whether you are going to enforce a map (and not nil) be passed. Currently you don't, making your doc string for ex-data wrong - it returns .getData of ExceptionInfo objects, which may be nil. If we enforce non-nil map on the way in, then ex-data works as documented and people can catch the exception and branch on ex-data. That seems most useful.

Comment by Rich Hickey [ 16/Oct/11 6:40 AM ]

Also please mark as alpha, subject to change.

Comment by Alan Dipert [ 21/Oct/11 10:21 AM ]

Attached 0733-with-map-check.patch. Same as 0733-with-ex-data-and-ex-info.patch but added Alpha docstring and map check to ex-data per Rich's latest comment.

Comment by Rich Hickey [ 21/Oct/11 2:15 PM ]

Thanks. The nil check should probably go in the ExceptionInfo ctor, just to have the same enforcement should they be created from Java.

Comment by Stuart Sierra [ 02/Dec/11 9:20 AM ]

I think this line in clojure.repl/pst,

(when-let [info (ex-data e)] (str " " info))

should be using pr-str instead of str, although str on a map already quotes string keys/values, so maybe it's good enough.

Comment by Stuart Sierra [ 02/Dec/11 9:21 AM ]

Setting to 'Incomplete' pending response to 2 previous comments.

Comment by Stuart Halloway [ 02/Dec/11 10:07 AM ]

The dec 2 edition does the arg check in the constructor and uses pr-str, addressing the last two comments raised.

Comment by Stuart Halloway [ 02/Dec/11 10:32 AM ]

The dec 2 edition does the arg check in the constructor and uses pr-str, addressing the last two comments raised.

Comment by Stuart Sierra [ 03/Dec/11 12:06 PM ]

Screened & moved to Approved Backlog.

Comment by Hugo Duncan [ 05/Dec/11 4:53 PM ]

ex-info and ex-data seem rather terse names to me (exception-info and exception-data would be clearer, imho). Clojure seems to have a mixture of abbreviated names and full names, but it was my vague impression that most of the abbreviations stemmed from traditional lisp or java usage.





[CLJ-732] (keyword "") can be printed, but not read Created: 26/Jan/11  Updated: 29/Jul/11  Resolved: 29/Jul/11

Status: Closed
Project: Clojure
Component/s: None
Affects Version/s: Release 1.2
Fix Version/s: Backlog

Type: Defect Priority: Minor
Reporter: Zach Tellman Assignee: Unassigned
Resolution: Declined Votes: 0
Labels: None

Attachments: File clj-732.diff    
Approval: Incomplete
Waiting On: Rich Hickey

 Description   

user=> (keyword "")
:
user=> (prn-str *1)
":\n"
user=> (read-string *1)
java.lang.RuntimeException: java.lang.Exception: Invalid token: : (NO_SOURCE_FILE:0)

This obviously isn't a huge defect, but I'd argue that anything that can be printed should be readable.



 Comments   
Comment by Stuart Halloway [ 28/Jan/11 9:06 AM ]

Patch that throws IllegalArgumentException would be ok for this.

Comment by Stuart Halloway [ 05/Apr/11 8:57 PM ]

After a brief review of places that call intern, it appears that this problem might never be reached in the reader, only in user code calling (keyword ...). Does it make more sense to have the patch there, and a matching change for (symbol ...)?





[CLJ-731] Create macro to variadically unroll a combinator function definition Created: 26/Jan/11  Updated: 26/Jul/13

Status: Open
Project: Clojure
Component/s: None
Affects Version/s: None
Fix Version/s: Backlog

Type: Enhancement Priority: Minor
Reporter: Fogus Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None

Approval: Vetted

 Description   

Clojure contains a set of combinators that are implemented in a similar, but slightly different way. That is, they are implemented as a complete set of variadic overloads on both the call-side and also on the functions that they return. Visually, they all tend to look something like:

(defn foo
  ([f]
     (fn
       ([] do stuff...)
       ([x] do stuff...)
       ([x y] do stuff...)
       ([x y z] do stuff...)
       ([x y z & args] do variadic stuff...)))
  ([f1 f2]
     (fn
       ([] do stuff...)
       ([x] do stuff...)
       ([x y] do stuff...)
       ([x y z] do stuff...)
       ([x y z & args] do variadic stuff...)))
  ([f1 f2 f3]
     (fn
       ([] do stuff...)
       ([x] do stuff...)
       ([x y] do stuff...)
       ([x y z] do stuff...)
       ([x y z & args] do variadic stuff...)))
  ([f1 f2 f3 & fs]
     (fn
       ([] do stuff...)
       ([x] do stuff...)
       ([x y] do stuff...)
       ([x y z] do stuff...)
       ([x y z & args] do variadic stuff...))))

To build this type of function for each combinator is tedious and error-prone.

There must be a way to implement a macro that takes a "specification" of a combinator including:

1. name
2. docstring
3. do stuff template
4. do variadic stuff template

And builds something like the function foo above. This macro should be able to implement the current batch of combinators (assuming that http://dev.clojure.org/jira/browse/CLJ-730 is completed first for the sake of verification).



 Comments   
Comment by Stuart Halloway [ 28/Jan/11 9:03 AM ]

This seems useful. Rich, would you accept a patch?

Comment by Stuart Halloway [ 28/Jan/11 9:40 AM ]

Nevermind, just saw that Rich already suggested this on the dev list. Patch away.





[CLJ-730] Create test suite for functional fns (e.g. juxt, comp, partial, etc.) Created: 26/Jan/11  Updated: 26/Jul/13  Resolved: 18/May/12

Status: Closed
Project: Clojure
Component/s: None
Affects Version/s: None
Fix Version/s: Backlog, Release 1.5

Type: Task Priority: Minor
Reporter: Fogus Assignee: Fogus
Resolution: Completed Votes: 0
Labels: None

Attachments: Text File 0001-add-tests-for-complement-constantly-juxt-partial.patch    
Approval: Ok

 Description   

The tests in other_functions.clj for the combinator functions are tenuous in some cases (comp) and missing in others (juxt, partial, complement, and constantly). It would be nice to have a full suite of combinator tests moving forward.

I would be happy to write the needed tests.



 Comments   
Comment by Stuart Halloway [ 28/Jan/11 9:00 AM ]

Go for it, and mark them waiting for me when they are ready.

Comment by Federico Brubacher [ 22/Mar/11 11:07 AM ]

Michael, Stuart, Can I barge in with a patch? I would love to get feedback on this. I have CA signed already. Thanks
Federico





[CLJ-720] check that argument to keys/vals is a Map Created: 18/Jan/11  Updated: 28/Jan/11  Resolved: 28/Jan/11

Status: Closed
Project: Clojure
Component/s: None
Affects Version/s: Backlog
Fix Version/s: Backlog

Type: Enhancement Priority: Minor
Reporter: Stuart Sierra Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: None

Attachments: Text File keys-vals-type-1.patch     Text File keys-vals-type-2.patch    
Patch: Code and Test
Approval: Ok

 Description   

Current behavior:

  • If you call keys or vals on something that is not a Map, you do not get a ClassCastException until the KeySeq or ValSeq is consumed
  • Calling keys or vals on an empty collection of any type, even non-Map types, returns nil

The attached patch:

  • checks the type of the argument to keys and vals and throws IllegalArgumentException if it is neither java.util.Map nor null
  • changes tests for keys and vals to check that those functions throw IllegalArgumentException on empty collections that are not maps


 Comments   
Comment by Rich Hickey [ 20/Jan/11 7:50 AM ]

Please don't test for specific exception types - thanks

Comment by Stuart Sierra [ 20/Jan/11 7:59 AM ]

keys-vals-type-2.patch replaces previous. Tests check for Exception instead of IllegalArgumentException





[CLJ-466] Reflection incorrectly avoids "More than one matching method" exceptions Created: 27/Oct/10  Updated: 15/Nov/10  Resolved: 29/Oct/10

Status: Closed
Project: Clojure
Component/s: None
Affects Version/s: None
Fix Version/s: Backlog

Type: Defect
Reporter: Anonymous Assignee: Rich Hickey
Resolution: Duplicate Votes: 0
Labels: None


 Description   

From the google group:

The following correctly throws an IllegalArgumentException "More than one matching method" due to the nil resulting in ambiguity between two overloaded version of append.

(let [sb (StringBuilder.)]
  (.append sb nil))</code></pre>And yet the following, which uses reflection, works:
<pre><code>(def s nil)
(let [sb (StringBuilder.)]
  (.append sb s))
This is due to a divergence in method resolution between direct and reflected calls. Both examples should result in an exception due to ambiguity.



 Comments   
Comment by Assembla Importer [ 27/Oct/10 3:14 PM ]

Converted from http://www.assembla.com/spaces/clojure/tickets/466

Comment by Assembla Importer [ 27/Oct/10 3:14 PM ]

ataggart said: Simpler example of the problem.

Comment by Assembla Importer [ 27/Oct/10 3:14 PM ]

ataggart said: Fixed via patch at ticket #445.

Comment by Stuart Halloway [ 29/Oct/10 3:38 PM ]

See #445





[CLJ-464] RFE: Run FindBugs on Clojure source code Created: 22/Oct/10  Updated: 07/Oct/11  Resolved: 07/Oct/11

Status: Closed
Project: Clojure
Component/s: None
Affects Version/s: None
Fix Version/s: Backlog

Type: Enhancement
Reporter: Anonymous Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: None


 Description   

I ran FindBugs (http://findbugs.sourceforge.net/ExampleName) on a small Clojure program that I am writing and got multiple warnings on code from the clojure libraries.

It might be helpful to run this on the source code base. It might uncover some actual bugs .



 Comments   
Comment by Assembla Importer [ 22/Oct/10 4:56 AM ]

Converted from http://www.assembla.com/spaces/clojure/tickets/464

Comment by Rich Hickey [ 07/Oct/11 7:33 AM ]

It has been run. Unfortunately, it has reports numerous spurious errors (i.e. non-problems), so will never be clean.





[CLJ-463] Strip leading colons when creating keywords from single strings Created: 20/Oct/10  Updated: 19/Nov/10  Resolved: 19/Nov/10

Status: Closed
Project: Clojure
Component/s: None
Affects Version/s: None
Fix Version/s: Backlog

Type: Enhancement
Reporter: Anonymous Assignee: Chas Emerick
Resolution: Declined Votes: 0
Labels: None


 Description   

This seems unfortunate:

=> (-> :foo str keyword)
::foo

Symbols are far saner in this regard:

=> (-> 'foo str symbol)
foo

Simply stripping leading colons from strings prior to turning them into keywords should suffice. The 2-arity Keyword.intern method and clojure.core/keyword fn should be left intact, so as to provide an escape hatch for those that really do need colon-prefixed keywords.



 Comments   
Comment by Assembla Importer [ 20/Oct/10 4:44 AM ]

Converted from http://www.assembla.com/spaces/clojure/tickets/463
Attachments:
463-strip-keyword-colons.diff - https://www.assembla.com/spaces/clojure/documents/bKmJCu2_Wr36meeJe5cbLA/download/bKmJCu2_Wr36meeJe5cbLA

Comment by Assembla Importer [ 20/Oct/10 4:44 AM ]

cemerick said: [file:bKmJCu2_Wr36meeJe5cbLA]

Comment by Stuart Halloway [ 29/Oct/10 10:00 AM ]

I am uncomfortable with this. If I say (keyword "::foo"), what am I asking for? I almost wonder if this should throw an exception.

Comment by Rich Hickey [ 29/Oct/10 10:07 AM ]

I think (keyword "::foo") (and any more leading colons) should fail, and this patch should only strip one colon.

Comment by Chas Emerick [ 29/Oct/10 11:11 AM ]

Updated patch forthcoming.

Comment by Chas Emerick [ 19/Nov/10 10:07 AM ]

After thinking about this for a while, I've now reversed my position, and am in favor or retaining the current functionality. Thanks for the pushback.

As for throwing exceptions on colon-prefixed, un-namespaced keywords, I'm not certain that that's a good idea. People use keywords to hold all sorts of data, use them as map keys and lookup fns, etc.





[CLJ-461] require namespace implicitly Created: 16/Oct/10  Updated: 21/Jun/11  Resolved: 21/Jun/11

Status: Closed
Project: Clojure
Component/s: None
Affects Version/s: None
Fix Version/s: Backlog

Type: Enhancement Priority: Blocker
Reporter: Mike Hinchey Assignee: Mike Hinchey
Resolution: Declined Votes: 1
Labels: None


 Description   

Referencing a function with a fully-qualified namespace should work without first using require or use, similar to how a fully-qualified java class can be used without importing it.

It's a small change in Compiler that tries to call (require x) if the fully qualified classname is not found. This should give priority to the java class, which protects backwards compatibility. There is no runtime performance impact, only compile time (the first time the namespace is seen). The fact that code (the namespace) is loaded during compilation of a form is no different than loading code to look up a java class.

This makes it easier to write quick scripts as in the example below, also to use one-liners in the repl or ad hoc in code.

For example: java -cp src/clj/:classes clojure.main -e "(clojure.set/union #{1} #{2})"

Currently on master, this produces: Exception in thread "main" java.lang.ClassNotFoundException: clojure.set
but this works: java -cp src/clj/:classes clojure.main -e "(require 'clojure.set) (clojure.set/union #{1} #{2})"

Obviously, (use) would make the code shorter, but my goal is to make it implicit.

Discussion: http://groups.google.com/group/clojure-dev/t/69823ce63dd94a0c



 Comments   
Comment by Assembla Importer [ 17/Oct/10 9:37 PM ]

Converted from http://www.assembla.com/spaces/clojure/tickets/461
Attachments:
mh-461-require.patch - https://www.assembla.com/spaces/clojure/documents/cQSfQ22L8r37zxeJe5cbCb/download/cQSfQ22L8r37zxeJe5cbCb

Comment by Assembla Importer [ 17/Oct/10 9:37 PM ]

mikehinchey said: [file:cQSfQ22L8r37zxeJe5cbCb]: patch to fix #461

Comment by Assembla Importer [ 17/Oct/10 9:37 PM ]

mikehinchey said: The discussion shows some people want this, other's aren't sure. Attached the patch so people can try it out.

Comment by Stuart Sierra [ 12/Dec/10 4:06 PM ]

One problem I see: With this change, it becomes harder for code-reading tools to determine all the dependencies of a namespace without evaluating it. Right now, I can parse the "ns" declaration of any file and know its dependencies. (Obviously, this breaks if the file loads code outside of the "ns" declaration, but then static analysis is virtually impossible.)

With this change, the "ns" declaration no longer represents the complete set of dependencies for the namespace. I can try to read the whole file, but I have no way of knowing if "foo.bar.baz/quux" represents a namespace-qualified symbol or a static Java member, unless I evaluate it.

I think loading Java classes and loading Clojure namespaces are fundamentally different operations because classes, unlike namespaces, cannot change after they are loaded.

Comment by Paul Stadig [ 10/Jun/11 2:01 PM ]

Stuart,
On the first point: it is already hard for code-reading tools. One can (require 'something) outside of the ns form. There are also uses of eval, direct references to fully qualified classes, and other nefarious ways. You seem to have admitted this already, so I'm not quite sure what you are objecting to? Objection 1: OVERRULED.

On the second point: you already admitted above that the ns declaration doesn't represent the complete set of dependencies, so there is no "no longer" about it. It was just never the case. Secondly, "foo.bar.baz/quux" could be a static Java member, or a Clojure Var, but that is irrelevant to this patch. That was always the case, and the patch is about autoloading, not about interpreting to what "foo.bar.baz/quux" is referring. Objection 2: OVERRULED.

On the third point: again, I don't see the relevance of the fact that a namespace can be changed after it has been loaded but a class cannot. Again, the patch is about autoloading, and the immutability/mutability of namespaces vs. classes is orthogonal. Objection 3: OVERRULED.

Finally, the original ML thread that spawned this had a +1 from the following persons: myself, Christophe Grand, Phil Hagelberg, Laurent Petit, Steve Gilardi, Cosmin Stejerean, and Chas Emerick.

It had a -1 only from: you, Dimitry Gashinsky.

A negative comment from Stu Halloway, and a positive-ish comment from Chris Houser.

I say we move forward with this.

Comment by Kevin Downey [ 10/Jun/11 2:07 PM ]

I have serious reservations about the complexity this will add to the compiler. the current patch is no good, it will break for aot compilation.

Comment by Paul Stadig [ 10/Jun/11 2:21 PM ]

So I've been told that my tongue-in-cheek may not have translated well, but that was the intent. I apologize if that was the case.

My point is just to draw attention to this ticket again. It was discussed on the ML with several +1's and has been mentioned again in chat. I don't think any of the objections that Stuart Sierra raised are particularly relevant to the question of autoloading the namespace of a fully qualified var.

Has anyone tried the patch? Kevin Downey seems to think it will not work in the context of AOT.

Do we need a new patch?

Comment by Kevin Downey [ 10/Jun/11 2:27 PM ]

the patch doesn't actually cause code to load the required namespaces to be generated. it only loads the required namespaces during compilation, which is why it breaks aot. once you get into code generation for aot it gets complicated, where does the generated code go? do we want to try and emit it separately like the requires from an ns form or does it get emitted in the middle of the particular function being compiled. I think the first approach is desirable from a stand point of correctness, but carries with it a load of complexity.

Comment by Paul Stadig [ 10/Jun/11 3:00 PM ]

I think it gets emitted in the middle of a function, just like would happen now if you do (require 'clojure.set) (clojure.set/union ...)

Is there a benefit to having it emit separately like an ns form? Isn't the ns form just a macro that turns into calls to (require ...) which happen to be at the top of a file because that's where the ns form is?

Comment by Rich Hickey [ 21/Jun/11 6:41 PM ]

This is not a good idea, for many reasons, the simplest of which is: it makes loading a side effect of calling a function in a module. Since loading can have arbitrary effects, it shouldn't be implicit. This isn't warranted by the meager benefits it might provide.





[CLJ-455] Calculating large numbers results in java.math.BigIntegerArithmeticException Created: 08/Oct/10  Updated: 23/Oct/10  Resolved: 23/Oct/10

Status: Closed
Project: Clojure
Component/s: None
Affects Version/s: None
Fix Version/s: Backlog

Type: Defect
Reporter: Anonymous Assignee: Unassigned
Resolution: Declined Votes: 0
Labels: None


 Description   

(class (* 1000 1000 1000 1000 1000 1000 1000))
1.1 returns : java.math.BigInteger
1.3.0-alpha returns : java.math.BigIntegerArithmeticException integer overflow clojure.lang.Numbers.throwIntOverflow (Numbers.java:1575)



 Comments   
Comment by Assembla Importer [ 23/Oct/10 10:52 PM ]

Converted from http://www.assembla.com/spaces/clojure/tickets/455

Comment by Assembla Importer [ 23/Oct/10 10:52 PM ]

ataggart said: This is correct behavior with respect to 1.3.0 (yes, it's a breaking change).

If one wants to allow numbers larger than what fits in a long to flow out of math ops, one needs to explicitly start with a BigInt:

user=> (type 1N)
clojure.lang.BigInt
user=> (class (* 1000N 1000N 1000N 1000N 1000N 1000N 1000N))
clojure.lang.BigInt</code></pre>
If one wants to allow autopromotion, one can use the new "tick" math ops:
<pre><code>user=> (class (*' 1000 1000 1000 1000 1000 1000 1000))
clojure.lang.BigInt

NB: Rich suspects almost no one should need these ops, and if you think you do, you're probably wrong.





[CLJ-449] NullPointerException in clojure.stacktrace Created: 01/Oct/10  Updated: 05/Nov/10  Resolved: 05/Nov/10

Status: Closed
Project: Clojure
Component/s: None
Affects Version/s: None
Fix Version/s: Backlog

Type: Defect Priority: Blocker
Reporter: Stuart Sierra Assignee: Stuart Sierra
Resolution: Completed Votes: 0
Labels: None

Approval: Ok

 Description   

See http://groups.google.com/group/clojure-dev/browse_thread/thread/f4157c68df730bd9

  • clojure.stacktrace/print-trace-element tries to match StackTraceElement.getClass against a regex.
  • StackTraceElement.getClass returns null, so a NullPointerException gets thrown, totally obscuring the original exception.

Now, the null is supposedly impossible, according to the Javadocs for StackTraceElement. But in some rare cases it seems to happen.



 Comments   
Comment by Assembla Importer [ 01/Oct/10 2:08 PM ]

Converted from http://www.assembla.com/spaces/clojure/tickets/449
Attachments:
fix-stacktrace2.diff - https://www.assembla.com/spaces/clojure/documents/c_8vnCZyyr37CfeJe5cbLA/download/c_8vnCZyyr37CfeJe5cbLA

Comment by Assembla Importer [ 01/Oct/10 2:08 PM ]

stuart.sierra said: [file:c_8vnCZyyr37CfeJe5cbLA]: patch with ticket ref #

Comment by Stuart Halloway [ 29/Oct/10 9:53 AM ]

This may be moot given the work being done to unify all the different stacktraces, but as long as this code is still out there, it seems worth preventing occasional cryptic failures!





[CLJ-446] 1.3 alpha1 gives reflection warning in a case where 1.2 does not Created: 29/Sep/10  Updated: 09/Dec/11  Resolved: 09/Dec/11

Status: Closed
Project: Clojure
Component/s: None
Affects Version/s: None
Fix Version/s: Backlog

Type: Defect Priority: Minor
Reporter: Stuart Sierra Assignee: Unassigned
Resolution: Declined Votes: 0
Labels: None

Approval: Incomplete

 Description   

Feel free to reclassify this as something other than a bug if I've misclassified it.

Related Clojure Google group conversation: http://groups.google.com/group/clojure/browse_thread/thread/83c08f6c2f313c50#

When doing AOT compilation on the attached program nbody.clj with 1.2:

java -Dclojure.compile.path=. -cp clojure-1.2.0.jar:. clojure.lang.Compile nbody

there are no reflection warnings, and a more complex version of the program using the type Body runs quickly. When doing AOT compilation with 1.3 alpha1:

java -Dclojure.compile.path=. -cp clojure-1.3.0-alpha1.jar:. clojure.lang.Compile nbody

I see these reflection warnings, and a more complex version of the program using the type Body runs significantly more slowly, most likely due to the reflection warned about:

Reflection warning, nbody.clj:18 - reference to field x can't be resolved.
Reflection warning, nbody.clj:19 - reference to field y can't be resolved.

Changing the name of the file to nbod.clj and the first line to "(ns nbod", and making corresponding changes to the compilation commands above, causes the reflection warnings to go away in 1.3 alpha1.

Similarly, taking the original attached file nbody.clj and replacing the three occurrences of "nbody" that are not the namespace name with a different name like "nbod" (or probably any name other than "nbody") also causes the reflection warnings to go away in 1.3 alpha1.

In case it makes any difference, I was using Clojure jars pulled via Leiningen, and HotSpot 1.6.0_xxx JVMs on Mac OS X 10.5.8 and Ubuntu 10.4.

Admittedly, a change with very limited impact on typical Clojure users. I wanted to file a ticket in case this was an unwanted consequence of some desirable change in 1.3.



 Comments   
Comment by Assembla Importer [ 03/Oct/10 1:32 AM ]

Converted from http://www.assembla.com/spaces/clojure/tickets/446
Attachments:
nbody.clj - https://www.assembla.com/spaces/clojure/documents/auzfxEY2Or35j2eJe5cbCb/download/auzfxEY2Or35j2eJe5cbCb

Comment by Assembla Importer [ 03/Oct/10 1:32 AM ]

ataggart said: Fix available via #445.

Comment by Stuart Sierra [ 09/Dec/11 3:19 PM ]

Marking "Incomplete" because no patch is included.

Furthermore, I cannot reproduce the problem described using Clojure 1.3.0.





[CLJ-445] Method/Constructor resolution does not factor in widening conversion of primitive args Created: 29/Sep/10  Updated: 27/Jul/13

Status: In Progress
Project: Clojure
Component/s: None
Affects Version/s: None
Fix Version/s: Backlog

Type: Enhancement Priority: Major
Reporter: Alexander Taggart Assignee: Alexander Taggart
Resolution: Unresolved Votes: 3
Labels: None

Attachments: Text File clj-445-prim-conversion-update-2-patch.txt     Text File prim-conversion.patch     Text File prim-conversion-update-1.patch     Text File reorg-reflector.patch    
Approval: Vetted

 Description   

Problem:
When making java calls (or inlined functions), if both args and param are primitive, no widening conversion is used to locate the proper overloaded method/constructor.

Examples:

user=> (Integer. (byte 0))
java.lang.IllegalArgumentException: No matching ctor found for class java.lang.Integer (NO_SOURCE_FILE:0)
</code></pre>
The above occurs because there is no Integer(byte) constructor, though it should match on Integer(int).
<pre><code>user=> (bit-shift-left (byte 1) 1)
Reflection warning, NO_SOURCE_PATH:3 - call to shiftLeft can't be resolved.
2

In the above, a call is made via reflection to Numbers.shiftLeft(Object, Object) and its associated auto-boxing, instead of directly to the perfectly adequate Numbers.shiftLeft(long, int).

Workarounds:
Explicitly casting to the formal type.

Ancillary benefits of fixing:
It would also reduce the amount of method overloading, e.g., RT.intCast(char), intCast(byte), intCast(short), could all be removed, since such calls would pass to RT.intCast(int).



 Comments   
Comment by Assembla Importer [ 23/Oct/10 6:43 PM ]

Converted from http://www.assembla.com/spaces/clojure/tickets/445
Attachments:
fixbug445.diff - https://www.assembla.com/spaces/clojure/documents/b6gDSUZOur36b9eJe5cbCb/download/b6gDSUZOur36b9eJe5cbCb

Comment by Assembla Importer [ 23/Oct/10 6:43 PM ]

ataggart said: [file:b6gDSUZOur36b9eJe5cbCb]

Comment by Assembla Importer [ 23/Oct/10 6:43 PM ]

ataggart said: Also fixes #446.

Comment by Stuart Halloway [ 03/Dec/10 12:50 PM ]

The patch is causing a test failure

[java] Exception in thread "main" java.lang.IllegalArgumentException: 
     More than one matching method found: equiv, compiling:(clojure/pprint/cl_format.clj:428)

Can you take a look?

Comment by Stuart Halloway [ 28/Jan/11 12:30 PM ]

The failing test happens when trying to find the correct equiv for signature (Number, long). Is the compiler wrong to propose this signature, or is the resolution method wrong in not having an answer? (It thinks two signatures are tied: (Object, long) and (Number, Number).)

Exception in thread "main" java.lang.IllegalArgumentException: More than one matching method found: equiv, compiling:(clojure/pprint/cl_format.clj:428)
	at clojure.lang.Compiler.analyzeSeq(Compiler.java:6062)
	at clojure.lang.Compiler.analyze(Compiler.java:5866)
	at clojure.lang.Compiler.analyze(Compiler.java:5827)
	at clojure.lang.Compiler.analyzeSeq(Compiler.java:6050)
	at clojure.lang.Compiler.analyze(Compiler.java:5866)
	at clojure.lang.Compiler.access$100(Compiler.java:35)
	at clojure.lang.Compiler$LetExpr$Parser.parse(Compiler.java:5492)
	at clojure.lang.Compiler.analyzeSeq(Compiler.java:6055)
	at clojure.lang.Compiler.analyze(Compiler.java:5866)
	at clojure.lang.Compiler.analyzeSeq(Compiler.java:6043)
	at clojure.lang.Compiler.analyze(Compiler.java:5866)
	at clojure.lang.Compiler.analyzeSeq(Compiler.java:6043)
	at clojure.lang.Compiler.analyze(Compiler.java:5866)
	at clojure.lang.Compiler.analyze(Compiler.java:5827)
	at clojure.lang.Compiler$IfExpr$Parser.parse(Compiler.java:2372)
	at clojure.lang.Compiler.analyzeSeq(Compiler.java:6055)
	at clojure.lang.Compiler.analyze(Compiler.java:5866)
	at clojure.lang.Compiler.analyzeSeq(Compiler.java:6043)
	at clojure.lang.Compiler.analyze(Compiler.java:5866)
	at clojure.lang.Compiler.analyze(Compiler.java:5827)
	at clojure.lang.Compiler$InvokeExpr.parse(Compiler.java:3277)
	at clojure.lang.Compiler.analyzeSeq(Compiler.java:6057)
	at clojure.lang.Compiler.analyze(Compiler.java:5866)
	at clojure.lang.Compiler.analyze(Compiler.java:5827)
	at clojure.lang.Compiler$BodyExpr$Parser.parse(Compiler.java:5231)
	at clojure.lang.Compiler$LetExpr$Parser.parse(Compiler.java:5527)
	at clojure.lang.Compiler.analyzeSeq(Compiler.java:6055)
	at clojure.lang.Compiler.analyze(Compiler.java:5866)
	at clojure.lang.Compiler.analyzeSeq(Compiler.java:6043)
	at clojure.lang.Compiler.analyze(Compiler.java:5866)
	at clojure.lang.Compiler.analyze(Compiler.java:5827)
	at clojure.lang.Compiler$BodyExpr$Parser.parse(Compiler.java:5231)
	at clojure.lang.Compiler.analyzeSeq(Compiler.java:6055)
	at clojure.lang.Compiler.analyze(Compiler.java:5866)
	at clojure.lang.Compiler.analyze(Compiler.java:5827)
	at clojure.lang.Compiler$IfExpr$Parser.parse(Compiler.java:2385)
	at clojure.lang.Compiler.analyzeSeq(Compiler.java:6055)
	at clojure.lang.Compiler.analyze(Compiler.java:5866)
	at clojure.lang.Compiler.analyze(Compiler.java:5827)
	at clojure.lang.Compiler$BodyExpr$Parser.parse(Compiler.java:5231)
	at clojure.lang.Compiler$LetExpr$Parser.parse(Compiler.java:5527)
	at clojure.lang.Compiler.analyzeSeq(Compiler.java:6055)
	at clojure.lang.Compiler.analyze(Compiler.java:5866)
	at clojure.lang.Compiler.analyzeSeq(Compiler.java:6043)
	at clojure.lang.Compiler.analyze(Compiler.java:5866)
	at clojure.lang.Compiler.analyze(Compiler.java:5827)
	at clojure.lang.Compiler$IfExpr$Parser.parse(Compiler.java:2385)
	at clojure.lang.Compiler.analyzeSeq(Compiler.java:6055)
	at clojure.lang.Compiler.analyze(Compiler.java:5866)
	at clojure.lang.Compiler.analyze(Compiler.java:5827)
	at clojure.lang.Compiler$BodyExpr$Parser.parse(Compiler.java:5231)
	at clojure.lang.Compiler$LetExpr$Parser.parse(Compiler.java:5527)
	at clojure.lang.Compiler.analyzeSeq(Compiler.java:6055)
	at clojure.lang.Compiler.analyze(Compiler.java:5866)
	at clojure.lang.Compiler.analyzeSeq(Compiler.java:6043)
	at clojure.lang.Compiler.analyze(Compiler.java:5866)
	at clojure.lang.Compiler.analyze(Compiler.java:5827)
	at clojure.lang.Compiler$BodyExpr$Parser.parse(Compiler.java:5231)
	at clojure.lang.Compiler$FnMethod.parse(Compiler.java:4667)
	at clojure.lang.Compiler$FnExpr.parse(Compiler.java:3397)
	at clojure.lang.Compiler.analyzeSeq(Compiler.java:6053)
	at clojure.lang.Compiler.analyze(Compiler.java:5866)
	at clojure.lang.Compiler.analyzeSeq(Compiler.java:6043)
	at clojure.lang.Compiler.analyze(Compiler.java:5866)
	at clojure.lang.Compiler.access$100(Compiler.java:35)
	at clojure.lang.Compiler$DefExpr$Parser.parse(Compiler.java:480)
	at clojure.lang.Compiler.analyzeSeq(Compiler.java:6055)
	at clojure.lang.Compiler.analyze(Compiler.java:5866)
	at clojure.lang.Compiler.analyze(Compiler.java:5827)
	at clojure.lang.Compiler.eval(Compiler.java:6114)
	at clojure.lang.Compiler.load(Compiler.java:6545)
	at clojure.lang.RT.loadResourceScript(RT.java:340)
	at clojure.lang.RT.loadResourceScript(RT.java:331)
	at clojure.lang.RT.load(RT.java:409)
	at clojure.lang.RT.load(RT.java:381)
	at clojure.core$load$fn__1427.invoke(core.clj:5308)
	at clojure.core$load.doInvoke(core.clj:5307)
	at clojure.lang.RestFn.invoke(RestFn.java:409)
	at clojure.pprint$eval3969.invoke(pprint.clj:46)
	at clojure.lang.Compiler.eval(Compiler.java:6110)
	at clojure.lang.Compiler.load(Compiler.java:6545)
	at clojure.lang.RT.loadResourceScript(RT.java:340)
	at clojure.lang.RT.loadResourceScript(RT.java:331)
	at clojure.lang.RT.load(RT.java:409)
	at clojure.lang.RT.load(RT.java:381)
	at clojure.core$load$fn__1427.invoke(core.clj:5308)
	at clojure.core$load.doInvoke(core.clj:5307)
	at clojure.lang.RestFn.invoke(RestFn.java:409)
	at clojure.core$load_one.invoke(core.clj:5132)
	at clojure.core$load_lib.doInvoke(core.clj:5169)
	at clojure.lang.RestFn.applyTo(RestFn.java:143)
	at sun.reflect.GeneratedMethodAccessor11.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at clojure.lang.Reflector.invokeMatchingMethod(Reflector.java:77)
	at clojure.lang.Reflector.invokeInstanceMethod(Reflector.java:28)
	at clojure.core$apply.invoke(core.clj:602)
	at clojure.core$load_libs.doInvoke(core.clj:5203)
	at clojure.lang.RestFn.applyTo(RestFn.java:138)
	at sun.reflect.GeneratedMethodAccessor11.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at clojure.lang.Reflector.invokeMatchingMethod(Reflector.java:77)
	at clojure.lang.Reflector.invokeInstanceMethod(Reflector.java:28)
	at clojure.core$apply.invoke(core.clj:604)
	at clojure.core$use.doInvoke(core.clj:5283)
	at clojure.lang.RestFn.invoke(RestFn.java:409)
	at clojure.main$repl.doInvoke(main.clj:196)
	at clojure.lang.RestFn.invoke(RestFn.java:422)
	at clojure.main$repl_opt.invoke(main.clj:267)
	at clojure.main$main.doInvoke(main.clj:362)
	at clojure.lang.RestFn.invoke(RestFn.java:409)
	at clojure.lang.Var.invoke(Var.java:401)
	at clojure.lang.AFn.applyToHelper(AFn.java:163)
	at clojure.lang.Var.applyTo(Var.java:518)
	at clojure.main.main(main.java:37)
Caused by: java.lang.IllegalArgumentException: More than one matching method found: equiv
	at clojure.lang.Reflector.getMatchingParams(Reflector.java:639)
	at clojure.lang.Reflector.getMatchingParams(Reflector.java:578)
	at clojure.lang.Reflector.getMatchingMethod(Reflector.java:569)
	at clojure.lang.Compiler$StaticMethodExpr.<init>(Compiler.java:1439)
	at clojure.lang.Compiler$HostExpr$Parser.parse(Compiler.java:896)
	at clojure.lang.Compiler.analyzeSeq(Compiler.java:6055)
	... 115 more
Comment by Alexander Taggart [ 08/Feb/11 6:27 PM ]

In working on implementing support for vararg methods, I found a number of flaws with the previous solutions. Please disregard them.

I've attached a single patch (reflector-compiler-numbers.diff) which is a rather substantial overhaul of the Reflector code, with some enhancements to the Compiler and Numbers code.

The patch notes:

  • Moved reflection functionality from Compiler to Reflector.
  • Reflector supports finding overloaded methods by widening conversion, boxing conversion, and casting.
  • During compilation Reflector attempts to find best wildcard match.
  • Reflector refers to *unchecked-math* when reflectively invoking methods and constructors.
  • Both Reflector and Compiler support variable arity java methods and constructor; backwards compatible with passing an array or nil in the vararg slot.
  • Added more informative error messages to Reflector.
  • Added tests to clojure.test-clojure.reflector.
  • Altered overloaded functions of clojure.lang.Numbers to service Object/double/long params; fixes some ambiguity issues and avoids unnecessary boxing in some cases.
  • Patch closes issues 380, 440, 445, 666, and possibly 259 (not enough detail provided).
Comment by Alexander Taggart [ 10/Feb/11 7:35 PM ]

Updated patch to fix a bug where a concrete class with multiple identical Methods (e.g., one from an interface, another from an abstract class) would result in ambiguity. Now resolved by arbitrary selection (this is what the original code did as well albeit not explicitly).

Comment by Alexander Taggart [ 25/Feb/11 9:29 PM ]

Updated patch to work with latest master branch.

Comment by Stuart Halloway [ 06/Mar/11 1:54 PM ]

patch appears to be missing test file clojure/test_clojure/reflector.clj.

Comment by Alexander Taggart [ 06/Mar/11 2:39 PM ]

Bit by git.

Patch corrected to contain clojure.test-clojure.reflector.

Comment by Stuart Halloway [ 11/Mar/11 10:30 AM ]

Rich: I verified that the patch applied but reviewed only briefly, knowing you will want to go over this one closely.

Comment by Stuart Halloway [ 11/Mar/11 10:55 AM ]

After applying this patch, I am getting method missing errors:

java.lang.NoSuchMethodError: clojure.lang.Numbers.lt(JLjava/lang/Object;)

but only when using compiled code, e.g. the same code works in the REPL and then fails after compilation. Haven't been able to isolate an example that I can share here yet, but hoping this will cause someone to have an "a, hah" moment...

Comment by Alexander Taggart [ 02/Apr/11 12:55 PM ]

The patch now contains only the minimal changes needed to support widening conversion. Cleanup of Numbers overloads, etc., can wait until this patch gets applied. The vararg support is in a separate patch on CLJ-440.

Comment by Christopher Redinger [ 15/Apr/11 12:50 PM ]

Please test patch

Comment by Christopher Redinger [ 21/Apr/11 11:02 AM ]

FYI: Patch applies cleanly on master and all tests pass as of 4/21 (2011)

Comment by Christopher Redinger [ 22/Apr/11 9:57 AM ]

This work is too big to take into the 1.3 beta right now. We'll revisit for a future release.

Comment by Alexander Taggart [ 28/Apr/11 1:19 PM ]

To better facilitate understanding of the changes, I've broken them up into two patches, each with a number of isolable, incremental commits:

reorg-reflector.patch: Moves the reflection/invocation code from Compiler to Reflector, and eliminates redundant code. The result is a single code base for resolving methods/constructors, which will allow for altering that mechanism without excess external coordination. This contains no behaviour changes.

prim-conversion.patch: Depends on the above. Alters the method/constructor resolution process:

  • more consistent with java resolution, especially when calling pre-1.5 APIs
  • adds support for widening conversion of primitive numerics of the same category (this is more strict than java, and more clojuresque)
  • adds support for wildcard matches at compile-time (i.e., you don't need to type-hint every arg to avoid reflection).

This also provides a base to add further features, e.g., CLJ-666.

Comment by Alexander Taggart [ 29/Apr/11 3:01 PM ]

It's documented in situ, but here are the conversion rules that the reflector uses to find methods:

  1. By Type:
    • object to ancestor type
    • primitive to a wider primitive of the same numeric category (new)
  2. Boxing:
    • boxed number to its primitive
    • boxed number to a wider primitive of the same numeric category (new for Short and Byte args)
    • primitive to its boxed value
    • primitive to Number or Object (new)
  3. Casting:
    • long to int
    • double to float
Comment by Alexander Taggart [ 10/May/11 3:13 PM ]

prim-conversion-update-1.patch applies to current master.

Comment by Alexander Taggart [ 11/May/11 2:15 PM ]

Created CLJ-792 for the reflector reorg.

Comment by Stuart Sierra [ 17/Feb/12 2:29 PM ]

prim-conversion-update-1.patch does not apply as of f5bcf64.

Is CLJ-792 now a prerequisite of this ticket?

Comment by Alexander Taggart [ 17/Feb/12 3:15 PM ]

Yes, after the original patch was deemed "too big".

After this much time with no action from TPTB, feel free to kill both tickets.

Comment by Andy Fingerhut [ 20/Feb/12 2:04 PM ]

Again, not sure if this is any help, but I've tested starting from Clojure head as of Feb 20, 2012, applying clj-792-reorg-reflector-patch2.txt attached to CLJ-792, and then applying clj-445-prim-conversion-update-2-patch.txt attached to this ticket, and the result compiles and passes all but 2 tests. I don't know whether those failures are easy to fix or not, or whether issues may have been introduced with these patches.





[CLJ-438] case* and code walkers Created: 23/Sep/10  Updated: 13/Apr/12  Resolved: 13/Apr/12

Status: Closed
Project: Clojure
Component/s: None
Affects Version/s: None
Fix Version/s: Backlog

Type: Defect Priority: Blocker
Reporter: Assembla Importer Assignee: Unassigned
Resolution: Completed Votes: 1
Labels: None

Attachments: Text File 0001-Fix-error-case-in-eval-of-walk-macroexpand-all-outpu.patch    
Approval: Vetted

 Description   

Clojure 1.2.0-master-SNAPSHOT
user=> (use 'clojure.walk)
nil
user=> (eval (macroexpand-all '(case 1 1 :test)))
java.lang.ClassCastException: clojure.lang.PersistentVector cannot be cast to clojure.lang.MapEntry (NO_SOURCE_FILE:2)

user=> (macroexpand-all '(case 1 1 :test))
(let* [G__9 1]
(case* G__9 0 1 1 1
(throw (new java.lang.IllegalArgumentException (clojure.core/str "No matching clause: " G__9)))

{1 [1 :test]}

false))

The existing code walkers convert the embedded [1 :test] into a PersistentVector that the compiler doesn't accept.
(symbol-macrolet [x :test] (case 1 1 x)) fails in the same way.



 Comments   
Comment by Assembla Importer [ 01/Oct/10 10:47 AM ]

Converted from http://www.assembla.com/spaces/clojure/tickets/438

Comment by Colin Jones [ 01/Jan/11 4:13 PM ]

A post-order traversal for macroexpand-all seems more reliable here than pre-order, and does fix the issue.

The attached patch adds tests around this and updates macroexpand-all to use postwalk rather than prewalk.

Comment by Alexander Taggart [ 28/Feb/11 1:51 PM ]

This has been fixed in the patch on CLJ-426.

The CaseExpr parser now just treats the map value as a tuple by calling RT.first/second, rather than casting it to a MapEntry.

Comment by Colin Jones [ 10/Oct/11 9:28 AM ]

Confirming Alex's fix - this ticket can just get closed, I think.





[CLJ-436] Bug in clojure.contrib.json/read-json Created: 21/Sep/10  Updated: 01/Oct/10  Resolved: 01/Oct/10

Status: Closed
Project: Clojure
Component/s: None
Affects Version/s: None
Fix Version/s: Backlog

Type: Defect
Reporter: Anonymous Assignee: Unassigned
Resolution: Declined Votes: 0
Labels: None


 Description   

What (small set of) steps will reproduce the problem?
$ java -cp lib/clojure-1.2.0.jar:lib/clojure-contrib-1.2.0.jar clojure.main
Clojure 1.2.0
user=> (require 'clojure.contrib.json)
nil
user=> (clojure.contrib.json/read-json "")
java.lang.IllegalArgumentException: Value out of range for char: -1 (NO_SOURCE_FILE:0)
user=>

What is the expected output? What do you see instead?

Expected:

(if eof-error?
  (throw (EOFException. "JSON error (end-of-file)"))
  eof-value)

What version are you using?
1.2

Was this discussed on the group? If so, please provide a link to the discussion
[13:51] <na_ka_na> Hey guys I think there's a bug in clojure.contrib.json at line 116
[13:51] <na_ka_na> in clojure 1.2
[13:52] <na_ka_na> it has a (char i) and then checks for (= i -1) ... but (char -1) fails
[13:52] <na_ka_na> where can I report it ?
[13:53] <LauJensen> na_ka_na: assembla/support



 Comments   
Comment by Assembla Importer [ 01/Oct/10 3:32 PM ]

Converted from http://www.assembla.com/spaces/clojure/tickets/436

Comment by Assembla Importer [ 01/Oct/10 3:32 PM ]

donmullen said: Added ticket on clojure-contrib-99





[CLJ-431] with-junit-output should use with-test-out when writing header and testsuites tags Created: 07/Sep/10  Updated: 05/Nov/10  Resolved: 05/Nov/10

Status: Closed
Project: Clojure
Component/s: None
Affects Version/s: None
Fix Version/s: Backlog

Type: Defect Priority: Minor
Reporter: Assembla Importer Assignee: Stuart Sierra
Resolution: Completed Votes: 0
Labels: None

Approval: Ok

 Description   

Need to be able to use *test-out* and *out* independently within with-junit-output in order to be able to XML escape general test output while leaving report output (XML) alone.

with-junit-output currently precludes this because it doesn't use with-test-out when writing the header and testsuites tags. It assumes it will always be wrapped with with-test-out but this permenantly merges *test-out* and *out*



 Comments   
Comment by Assembla Importer [ 01/Oct/10 3:19 PM ]

Converted from http://www.assembla.com/spaces/clojure/tickets/431
Attachments:
fix431-1.diff - https://www.assembla.com/spaces/clojure/documents/a04XQYZzKr36OdeJe5cbCb/download/a04XQYZzKr36OdeJe5cbCb

Comment by Assembla Importer [ 01/Oct/10 3:19 PM ]

stuart.sierra said: [file:a04XQYZzKr36OdeJe5cbCb]: fix





[CLJ-424] instance? fails on deftype instance, when used from multiple files Created: 12/Aug/10  Updated: 28/Jan/11  Resolved: 28/Jan/11

Status: Closed
Project: Clojure
Component/s: None
Affects Version/s: None
Fix Version/s: Backlog

Type: Defect
Reporter: Anonymous Assignee: Unassigned
Resolution: Duplicate Votes: 0
Labels: None


 Description   

When instance? is called from two separate namespaces to test an instance of a user defined type, one of them fails

In the attached project, the following (identical) tests run correctly:

lein test instance-test.test.core
lein test instance-test.test.core2

but this fails:

lein test

For ease of reference, the attached project contains the following:

(ns instance-test.core)
(deftype MyType [a])
(defn make-my-type
[]
(MyType. nil))

(ns instance-test.test.core
(:use [instance-test.core] :reload-all)
(:use [clojure.test])
(:import instance-test.core.MyType))

(deftest test1
(is (instance? instance-test.core.MyType (make-my-type))))

(ns instance-test.test.core2
(:use [instance-test.core] :reload-all)
(:use [clojure.test])
(:import instance-test.core.MyType))

(deftest test1
(is (instance? instance-test.core.MyType (make-my-type))))



 Comments   
Comment by Assembla Importer [ 15/Oct/10 6:13 AM ]

Converted from http://www.assembla.com/spaces/clojure/tickets/424
Attachments:
instance-test.tar.gz - https://www.assembla.com/spaces/clojure/documents/dZGCvGPH4r37YjeJe5cbCb/download/dZGCvGPH4r37YjeJe5cbCb

Comment by Assembla Importer [ 15/Oct/10 6:13 AM ]

hugoduncan said: Removing :reload-all from the tests, causes the unexpected behaviour to disappear

Comment by Stuart Sierra [ 28/Jan/11 3:43 PM ]

I can confirm the described behavior with Clojure 1.2.0 and Leiningen 1.3.1.

But it shouldn't work at all, because "instance-test.core" is not a valid Java package name. This was fixed in CLJ-432.

With Clojure 1.3.0-alpha5, MyType's package name is correctly munged to "instance_test.core". Loading the test namespaces fails (as it should) with java.lang.ClassNotFoundException: instance-test.core.MyType.





[CLJ-419] LispReader uses Character.isWhitespace rather than Character.isSpaceChar Created: 04/Aug/10  Updated: 23/Oct/10  Resolved: 23/Oct/10

Status: Closed
Project: Clojure
Component/s: None
Affects Version/s: None
Fix Version/s: Backlog

Type: Defect
Reporter: Anonymous Assignee: Unassigned
Resolution: Declined Votes: 0
Labels: None


 Description   

Character.isWhitespace doesn't handle non-breaking space correctly. Apparently it's pretty ancient from The Olden Days Before People Knew How To Do Character Encodings.

In Java 1.5 Character.isSpaceChar was added, which handles supplementary characters the right way: http://download.oracle.com/javase/1.5.0/docs/api/java/lang/Character.html#isWhitespace(char)



 Comments   
Comment by Assembla Importer [ 23/Oct/10 3:03 PM ]

Converted from http://www.assembla.com/spaces/clojure/tickets/419

Comment by Assembla Importer [ 23/Oct/10 3:03 PM ]

stu said: Phil,

Please add an example and nag me to bump the priority if this is causing real and present pain.

Comment by Assembla Importer [ 23/Oct/10 3:03 PM ]

technomancy said: Eh; it's not causing real pain.

I would be OK with a WONTFIX if that's what is decided. Just thought it wouldn't hurt to have a record of it somewhere (even as a closed-as-invalid ticket), and I was in a particularly pedantic mood last night for some reason.

I ran across it because of an escaping bug in Wine where I wanted to treat "(use 'foo)(-main)" as a single token in bash but two still be valid Clojure code. But luckily I found a better workaround. I am OK with leaving it at lowest priority.

Comment by Assembla Importer [ 23/Oct/10 3:03 PM ]

djpowell said: Hmm, I'm not sure isSpaceChar is right - it doesn't seem to allow things like tabs and newlines. If you really wanted to support non-break-space, then it would probably be best to just use isWhitespace and add them as a special case.

Actually... I would quite like to see \ufeff treated as whitespace. It is the Unicode BOM. Some editors including Windows Notepad include the BOM at the start of UTF-8 files. The latest Unicode docs seem to recognise the UTF-8 BOM. By treating it as whitespace we can avoid any problems with it.

Comment by Assembla Importer [ 23/Oct/10 3:03 PM ]

technomancy said: Sounds like I had this not quite right; probably not worth worrying about.





[CLJ-416] improvments on agent Created: 30/Jul/10  Updated: 01/Mar/13  Resolved: 27/Nov/12

Status: Closed
Project: Clojure
Component/s: None
Affects Version/s: None
Fix Version/s: Backlog

Type: Enhancement
Reporter: Anonymous Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: None


 Description   

hi,i have some ideas to improve the agent system:
1.Agent's thread pool must use a custom ThreadFactory to new threads.Set new thread a system name and set it to be daemon.Thread's name would be used for debug or monitor.And set thread to be daemon asking user to shutdown agents explicitly.

2.Beacause agent's thread is daemon,so if a application doesn't use any agents,the thread pool must not started.I think the agent's thread pools should be lazy initialized.

3.I think agent must allow use to define a agent-own thread pool.That thread pool is only used by a agent,not global.just like:
(define a (agent :executor (java.util.concurrent.Executors/newFixedThreadPool 2)))
or
(set-executor! a (java.util.concurrent.Executors/newFixedThreadPool 2))
And then,a new function to shutdown agent's custom thread pool:
(shutdown-agent a)

Why do we need a custom thread pool?
First, the default thread pool is global, send use the thread pool
is a fixed size cpus +2, is likely to become the system bottleneck
sometime. Although you can use the send-off, use the cache thread
pool, but in a real world application, I can not use the cache thread
pool, which will introduce the risk of OutOfMemoryError, normally I
like to use a fixed-size thread pool.

Second, the actions which global thread pool execute are from a
variety of agents, the actions are not homogeneous, and can not
maximize the efficient use of the thread pool.

These are my suggestions on agent,thanks for this great language,i enjoy it.



 Comments   
Comment by Assembla Importer [ 24/Aug/10 6:42 PM ]

Converted from http://www.assembla.com/spaces/clojure/tickets/416

Comment by Timothy Baldridge [ 27/Nov/12 2:18 PM ]

Closing as "completed" as most of these requests are handled in 1.5 via the new send-via, and set executor functions.





[CLJ-415] smarter assert (prints locals) Created: 29/Jul/10  Updated: 03/Sep/13

Status: Open
Project: Clojure
Component/s: None
Affects Version/s: None
Fix Version/s: Backlog

Type: Enhancement Priority: Major
Reporter: Assembla Importer Assignee: Unassigned
Resolution: Unresolved Votes: 2
Labels: errormsgs

Attachments: Text File clj-415-assert-prints-locals-v1.txt    
Approval: Vetted
Waiting On: Rich Hickey

 Description   

Here is an implementation you can paste into a repl. Feedback wanted:

(defn ^{:private true} local-bindings
  "Produces a map of the names of local bindings to their values."
  [env]
  (let [symbols (map key env)]
    (zipmap (map (fn [sym] `(quote ~sym)) symbols) symbols)))

(defmacro assert
  "Evaluates expr and throws an exception if it does not evaluate to
 logical true."
  {:added "1.0"}
  [x]
  (when *assert*
    (let [bindings (local-bindings &env)]
      `(when-not ~x
         (let [sep# (System/getProperty "line.separator")]
           (throw (AssertionError. (apply str "Assert failed: " (pr-str '~x) sep#
                                          (map (fn [[k# v#]] (str "\t" k# " : " v# sep#)) ~bindings)))))))))


 Comments   
Comment by Assembla Importer [ 24/Aug/10 5:41 PM ]

Converted from http://www.assembla.com/spaces/clojure/tickets/415

Comment by Assembla Importer [ 24/Aug/10 5:41 PM ]

alexdmiller said: A simple example I tried for illustration:

user=> (let [a 1 b 2] (assert (= a b)))
#<CompilerException java.lang.AssertionError: Assert failed: (= a b)
 a : 1
 b : 2
Comment by Assembla Importer [ 24/Aug/10 5:41 PM ]

fogus said: Of course it's weird if you do something like:

(let [x 1 y 2 z 3 a 1 b 2 c 3] (assert (= x y)))
java.lang.AssertionError: Assert failed: (= x y)
 x : 1
 y : 2
 z : 3
 a : 1
 b : 2
 c : 3
 (NO_SOURCE_FILE:0)
</code></pre>

So maybe it could be slightly changed to:
<pre><code>(defmacro assert
  "Evaluates expr and throws an exception if it does not evaluate to logical true."
  {:added "1.0"}
  [x]
  (when *assert*
    (let [bindings (local-bindings &env)]
      `(when-not ~x
         (let [sep#  (System/getProperty "line.separator")
               form# '~x]
           (throw (AssertionError. (apply str "Assert failed: " (pr-str form#) sep#
                                          (map (fn [[k# v#]] 
                                                 (when (some #{k#} form#) 
                                                   (str "\t" k# " : " v# sep#))) 
                                               ~bindings)))))))))
</code></pre>

So that. now it's just:
<pre><code>(let [x 1 y 2 z 3 a 1 b 2 c 3] (assert (= x y)))
java.lang.AssertionError: Assert failed: (= x y)
 x : 1
 y : 2
 (NO_SOURCE_FILE:0)

:f

Comment by Assembla Importer [ 24/Aug/10 5:41 PM ]

fogus said: Hmmm, but that fails entirely for: (let [x 1 y 2 z 3 a 1 b 2 c 3] (assert (= [x y] [a c]))). So maybe it's better just to print all of the locals unless you really want to get complicated.
:f

Comment by Assembla Importer [ 24/Aug/10 5:41 PM ]

jawolfe said: See also some comments in:

http://groups.google.com/group/clojure-dev/browse_frm/thread/68d49cd7eb4a4899/9afc6be4d3f8ae27?lnk=gst&q=assert#9afc6be4d3f8ae27

Plus one more suggestion to add to the mix: in addition to / instead of printing the locals, how about saving them somewhere. For example, the var assert-bindings could be bound to the map of locals. This way you don't run afoul of infinite/very large sequences, and allow the user to do more detailed interrogation of the bad values (especially useful when some of the locals print opaquely).

Comment by Assembla Importer [ 24/Aug/10 5:41 PM ]

stuart.sierra said: Another approach, which I wil willingly donate:
http://github.com/stuartsierra/lazytest/blob/master/src/main/clojure/lazytest/expect.clj

Comment by Jeff Weiss [ 15/Dec/10 1:33 PM ]

There's one more tweak to fogus's last comment, which I'm actually using. You need to flatten the quoted form before you can use 'some' to check whether the local was used in the form:

(defmacro assert
  "Evaluates expr and throws an exception if it does not evaluate to logical true."
  {:added "1.0"}
  [x]
  (when *assert*
    (let [bindings (local-bindings &env)]
      `(when-not ~x
         (let [sep#  (System/getProperty "line.separator")
               form# '~x]
           (throw (AssertionError. (apply str "Assert failed: " (pr-str form#) sep#
                                          (map (fn [[k# v#]] 
                                                 (when (some #{k#} (flatten form#)) 
                                                   (str "\t" k# " : " v# sep#))) 
                                               ~bindings)))))))))
Comment by Stuart Halloway [ 04/Jan/11 8:31 PM ]

I am holding off on this until we have more solidity around http://dev.clojure.org/display/design/Error+Handling. (Considering, for instance, having all exceptions thrown from Clojure provide access to locals.)

When my pipe dream fades I will come back and screen this before the next release.

Comment by Stuart Halloway [ 28/Jan/11 1:14 PM ]

Why try to guess what someone wants to do with the locals (or any other context, for that matter) when you can specify a callback (see below). This would have been useful last week when I had an assertion that failed only on the CI box, where no debugger is available.

Rich, at the risk of beating a dead horse, I still think this is a good idea. Debuggers are not always available, and this is an example of where a Lisp is intrinsically capable of providing better information than can be had in other environments. If you want a patch for the code below please mark waiting on me, otherwise please decline this ticket so I stop looking at it.

(def ^:dynamic *assert-handler* nil)

(defn ^{:private true} local-bindings
  "Produces a map of the names of local bindings to their values."
  [env]
  (let [symbols (map key env)]
    (zipmap (map (fn [sym] `(quote ~sym)) symbols) symbols)))

(defmacro assert
  [x]
  (when *assert*
    (let [bindings (local-bindings &env)]
      `(when-not ~x
         (let [sep#  (System/getProperty "line.separator")
               form# '~x]
           (if *assert-handler*
             (*assert-handler* form# ~bindings)
             (throw (AssertionError. (apply str "Assert failed: " (pr-str form#) sep#
                                            (map (fn [[k# v#]] 
                                                   (when (some #{k#} (flatten form#)) 
                                                     (str "\t" k# " : " v# sep#))) 
                                                 ~bindings))))))))))
Comment by Jeff Weiss [ 27/May/11 8:16 AM ]

A slight improvement I made in my own version of this code: flatten does not affect set literals. So if you do (assert (some #{x} [a b c d])) the value of x will not be printed. Here's a modified flatten that does the job:

(defn symbols [sexp]
  "Returns just the symbols from the expression, including those
   inside literals (sets, maps, lists, vectors)."
  (distinct (filter symbol? (tree-seq coll? seq sexp))))
Comment by Andy Fingerhut [ 18/Nov/12 1:06 AM ]

Attaching git format patch clj-415-assert-prints-locals-v1.txt of Stuart Halloway's version of this idea. I'm not advocating it over the other variations, just getting a file attached to the JIRA ticket.





[CLJ-414] In latest clojure, empty list is neither true nor false Created: 24/Jul/10  Updated: 24/Aug/10  Resolved: 24/Aug/10

Status: Closed
Project: Clojure
Component/s: None
Affects Version/s: None
Fix Version/s: Backlog

Type: Defect
Reporter: Anonymous Assignee: Unassigned
Resolution: Declined Votes: 0
Labels: None


 Description   

In latest Clojure, compiled today:

user> (true? ())
false
user> (false? ())
false

This makes empty collections the only entities in Clojure which are neither true, nor false.
I'm fairly sure () used to be true – is this an intentional change? Googling reveals lots of warnings about the empty list not being false in Clojure.



 Comments   
Comment by Assembla Importer [ 24/Aug/10 12:35 AM ]

Converted from http://www.assembla.com/spaces/clojure/tickets/414

Comment by Assembla Importer [ 24/Aug/10 12:35 AM ]

bpsm said: You've confused true? and false? with boolean.

Clojure 1.0.1-alpha-SNAPSHOT
user=> (false? '())
false
user=> (true? '())
false
user=> (boolean '())
true
</code></pre>
<pre><code>Clojure 1.1.0
user=> (false? '())
false
user=> (true? '())
false
user=> (boolean '())
true
</code></pre>
<pre><code>Clojure 1.2.0-beta1
user=> (false? '())
false
user=> (true? '())
false
user=> (boolean '())
true

boolean converts its argument to either true or false. nil and false yield false, everything else yields true.
true? and false? do no such conversion, nor should they. Only true is true?. Only false is false?.





[CLJ-412] clojure.xml/emit, emit-element are not documented at clojure.org Created: 23/Jul/10  Updated: 24/Aug/10  Resolved: 24/Aug/10

Status: Closed
Project: Clojure
Component/s: None
Affects Version/s: None
Fix Version/s: Backlog

Type: Enhancement
Reporter: Anonymous Assignee: Unassigned
Resolution: Declined Votes: 0
Labels: None


 Description   

Neither function makes an appearance here:
http://clojure.github.com/clojure/clojure.xml-api.html
Despite the fact that neither appears to be private. Perhaps the doc generator just ignores all functions that have no doc comment?



 Comments   
Comment by Assembla Importer [ 24/Aug/10 12:34 AM ]

Converted from http://www.assembla.com/spaces/clojure/tickets/412

Comment by Assembla Importer [ 24/Aug/10 12:34 AM ]

stu said: If a var is (a) public (b) has a docstring and (c) has :added metadata, then the Clojure team is committed to supporting it. These vars don't meet the criteria. In the context of a broader overhaul of XML support these might become official APIs.

Comment by Assembla Importer [ 24/Aug/10 12:34 AM ]

bpsm said: That makes sense. I wasn't aware of those conventions. Perhaps the library should advertise itself as being only for XML reading:

--- a/src/clj/clojure/xml.clj
+++ b/src/clj/clojure/xml.clj
@@ -6,7 +6,7 @@
 ;   the terms of this license.
 ;   You must not remove this notice, or any other, from this software.
 
-(ns ^{:doc "XML reading/writing."
+(ns ^{:doc "XML reading."
        :author "Rich Hickey"}
   clojure.xml
   (:import (org.xml.sax ContentHandler Attributes SAXException)




[CLJ-411] clojure.xml/emit should be encoding-aware Created: 23/Jul/10  Updated: 01/Oct/10  Resolved: 01/Oct/10

Status: Closed
Project: Clojure
Component/s: None
Affects Version/s: None
Fix Version/s: Backlog

Type: Defect
Reporter: Anonymous Assignee: Unassigned
Resolution: Declined Votes: 0
Labels: None


 Description   

clojure.xml/emit blithely asserts that it's writing UTF-8 despite the fact that it's actually writing characters, not bytes. Encoding isn't actually decided until actual bytes are written. This forces clients using clojure.xml/emit to write XML back to disk to use UTF-8. They won't know to do that unless they actually peek at the implementation. This behavior isn't documented.

(defn emit [x]
  (println "<?xml version='1.0' encoding='UTF-8'?>")
  (emit-element x))


 Comments   
Comment by Assembla Importer [ 01/Oct/10 9:56 AM ]

Converted from http://www.assembla.com/spaces/clojure/tickets/411

Comment by Assembla Importer [ 01/Oct/10 9:56 AM ]

stu said: APIs without docstrings (like emit) are not supported.

We would welcome a redesign of the XML support that made this good enough to publicize and support.





[CLJ-409] SAXParserFactoryImpl is missing at unit testing time Created: 23/Jul/10  Updated: 24/Aug/10  Resolved: 24/Aug/10

Status: Closed
Project: Clojure
Component/s: None
Affects Version/s: None
Fix Version/s: Backlog

Type: Defect
Reporter: Anonymous Assignee: Unassigned
Resolution: Declined Votes: 0
Labels: None


 Description   

SAXParserFactoryImpl seems to be AWOL while clojure unit tests are running, but is present when clojure is started from the command line. WTF?

(ns clojure.test-clojure.clojure-xml
  (:use clojure.test)
  (:import [javax.xml.parsers SAXParserFactory])
  (:require [clojure.xml :as xml]))

(deftest sax-parser-factory-is-not-awol
  (is (SAXParserFactory/newInstance)))
</code></pre>
<pre><code>Tell ant to run the unit tests:

$ ant test

And get the following exception:

ERROR in (sax-parser-factory-is-not-awol) (SAXParserFactory.java:134)
expected: (SAXParserFactory/newInstance)
actual: javax.xml.parsers.FactoryConfigurationError: Provider
        org.apache.xerces.jaxp.SAXParserFactoryImpl not found
at javax.xml.parsers.SAXParserFactory.newInstance (SAXParserFactory.java:134)
   clojure.test_clojure.clojure_xml/fn (clojure_xml.clj:17)

Yet, when I run clojure from the command line and do the same thing,
all is well.

$ java -jar clojure.jar
Clojure 1.2.0-beta1
user=> (import 'javax.xml.parsers.SAXParserFactory)
javax.xml.parsers.SAXParserFactory
user=> (SAXParserFactory/newInstance)
#<SAXParserFactoryImpl org.apache.xerces.jaxp.SAXParserFactoryImpl@19381960>
user=>

See also:
http://github.com/bpsm/clojure/commits/409show



 Comments   
Comment by Assembla Importer [ 24/Aug/10 12:34 AM ]

Converted from http://www.assembla.com/spaces/clojure/tickets/409
Attachments:
show-409-on-oberon.txt - https://www.assembla.com/spaces/clojure/documents/aSijYaMmCr35jQeJe5cbLr/download/aSijYaMmCr35jQeJe5cbLr

Comment by Assembla Importer [ 24/Aug/10 12:34 AM ]

bpsm said: Provide link to my '409show' branch, which does what it says on the tin.

Comment by Assembla Importer [ 24/Aug/10 12:34 AM ]

stu said: This code works fine for me locally (Mac OS X). I would investigate a busted Ant setup, or getting a different version of Java, on your end.

I'll be looking through the rest of the XML tickets your filed this morning – thanks for taking the time!

Comment by Assembla Importer [ 24/Aug/10 12:34 AM ]

bpsm said: Thanks. I've seen this both on my Mac and Linux netbook (JDK 1.6.0_20), but I'm sitting in front of a machine I haven't tried to reproduce this on yet, so I'll give it a whirl here and report what I find.

Comment by Assembla Importer [ 24/Aug/10 12:34 AM ]

bpsm said: [file:aSijYaMmCr35jQeJe5cbLr]: demonstrates #409 on x64, Java1.6.0_20, ant 1.7.1

Comment by Assembla Importer [ 24/Aug/10 12:34 AM ]

bpsm said: I see the failure on my workstation as well, alas. I've attached a transcript including ant -diagnostics output. If it is my local setup at fault, I'm not sure what it could be. Perhaps something there will catch your eye.





[CLJ-408] clojure.xml emit does not properly escape attribute and element content Created: 23/Jul/10  Updated: 15/Nov/10  Resolved: 30/Oct/10

Status: Closed
Project: Clojure
Component/s: None
Affects Version/s: None
Fix Version/s: Backlog

Type: Defect
Reporter: Anonymous Assignee: Rich Hickey
Resolution: Declined Votes: 0
Labels: None


 Description   
(with-out-str
  (clojure.xml/emit-element {:tag :e :attrs nil :content "&"}))
</code></pre>
produces: <e>&</e>
correct would be: <e>&amp;</e>
This is true for both element content and attribute content. < and > are not escaped as well. Furthermore, apostrophe ( ' ) in an attribute value leads to broken xml:
<pre><code>
<e a='''/>


 Comments   
Comment by Assembla Importer [ 28/Sep/10 8:51 AM ]

Converted from http://www.assembla.com/spaces/clojure/tickets/408
Attachments:
408-escape-and-in-content-and-attribute-value.patch - https://www.assembla.com/spaces/clojure/documents/aBCHT2LZer34ioeJe5cbLr/download/aBCHT2LZer34ioeJe5cbLr

Comment by Assembla Importer [ 28/Sep/10 8:51 AM ]

bpsm said: Tests that demonstrate #408 are available at http://github.com/bpsm/test-clojure-xml.

Comment by Assembla Importer [ 28/Sep/10 8:51 AM ]

bpsm said: [file:aBCHT2LZer34ioeJe5cbLr]: see also http://github.com/bpsm/clojure/commits/fix408,410,277

Comment by Assembla Importer [ 28/Sep/10 8:51 AM ]

bpsm said: I saw rich's message about marking issues "ready for test" to get patches noticed. This was in connection with marking #410 as ready for test. This issue is joined at the hip with 410 and also has a patch ready.

Comment by Stuart Halloway [ 30/Oct/10 2:47 PM ]

emit is not part of Clojure's public API, and we don't want to grow a public API via an issue-driven random walk. If you are interested in this issue, please chime in on the design page for a new data.xml library: http://dev.clojure.org/display/DXML/Home





[CLJ-406] Typo in underive causes breaking in the resulting hierarchy Created: 22/Jul/10  Updated: 24/Aug/10  Resolved: 24/Aug/10

Status: Closed
Project: Clojure
Component/s: None
Affects Version/s: None
Fix Version/s: Backlog

Type: Defect
Reporter: Anonymous Assignee: Unassigned
Resolution: Declined Votes: 0
Labels: None


 Description   

There's a typo on line 4515 in core.clj, in the definition of underive:

{:parent ... }
; should be
{:parents ... }
</code></pre>
causing breakage in hierarchies which had relationships underived in them.

E.g.
<pre><code>
(derive ::foo ::bar)
(underive ::foo ::bar)
(derive ::foo ::bar)
; => NPE

#clojure discussion:

http://clojure-log.n01se.net/date/2010-07-21.html#20:54



 Comments   
Comment by Assembla Importer [ 24/Aug/10 6:31 PM ]

Converted from http://www.assembla.com/spaces/clojure/tickets/406

Comment by Assembla Importer [ 24/Aug/10 6:31 PM ]

stu said: Already discussed as a subset of #382.





[CLJ-395] "underive" corrupts ad hoc hierarchies. Created: 07/Jul/10  Updated: 24/Aug/10  Resolved: 24/Aug/10

Status: Closed
Project: Clojure
Component/s: None
Affects Version/s: None
Fix Version/s: Backlog

Type: Defect
Reporter: Anonymous Assignee: Unassigned
Resolution: Declined Votes: 0
Labels: None


 Description   

See transcript below, from 1.20-dev snapshot compiled about a week ago:

user=> (derive ::dad ::grandad)
nil
user=> (derive ::son ::dad)
nil
user=> (underive ::dad ::grandad)
nil
user=> (derive ::dad ::grandad)
java.lang.NullPointerException (NO_SOURCE_FILE:0)
user=> (derive ::foo ::bar)
java.lang.NullPointerException (NO_SOURCE_FILE:0)
user=>



 Comments   
Comment by Assembla Importer [ 24/Aug/10 11:06 AM ]

Converted from http://www.assembla.com/spaces/clojure/tickets/395

Comment by Assembla Importer [ 24/Aug/10 11:06 AM ]

stu said: Duplicates #382.





[CLJ-375] metadata literal enhancements Created: 08/Jun/10  Updated: 28/Sep/10  Resolved: 28/Sep/10

Status: Closed
Project: Clojure
Component/s: None
Affects Version/s: None
Fix Version/s: Backlog

Type: Enhancement
Reporter: Anonymous Assignee: Christophe Grand
Resolution: Completed Votes: 0
Labels: None


 Description   

1) Merge metadata literals (i.e. metadata on literal with metadata adds to it rather than replaces (but will replace same key))
^{:fred :ethel} ^{:ricky :lucy} foo yields metadata of {:fred :ethel, :ricky :lucy}

2) ^:a-keyword becomes {:a-keyword true} metadata



 Comments   
Comment by Assembla Importer [ 28/Sep/10 3:51 PM ]

Converted from http://www.assembla.com/spaces/clojure/tickets/375
Attachments:
0001-read-foo-bar-as-foo-true-bar-and-merge-existing-meta.patch - https://www.assembla.com/spaces/clojure/documents/dWhNbgCWKr34aBeJe5cbCb/download/dWhNbgCWKr34aBeJe5cbCb

Comment by Assembla Importer [ 28/Sep/10 3:51 PM ]

cgrand said: [file:dWhNbgCWKr34aBeJe5cbCb]: patch + test





[CLJ-371] dynamic defrecord definitions trumped by AOT versions in classpath Created: 02/Jun/10  Updated: 26/Jul/13  Resolved: 02/Dec/11

Status: Closed
Project: Clojure
Component/s: None
Affects Version/s: Backlog
Fix Version/s: Backlog

Type: Defect Priority: Minor
Reporter: Assembla Importer Assignee: Unassigned
Resolution: Declined Votes: 0
Labels: None

Approval: Vetted

 Description   

Symptom: Define a defrecord at the repl and you still see the old (AOT'd) defrecord.

In the attached project:
lein compile
lein repl

and enter the commands in the comment in src/defrecordissue/core.clj

Design Discussion here: http://dev.clojure.org/display/design/Dynamic+defrecord+definitions+trumped+by+AOT+versions+in+classpath



 Comments   
Comment by Assembla Importer [ 24/Aug/10 11:29 AM ]

Converted from http://www.assembla.com/spaces/clojure/tickets/371
Attachments:
defrecordissue.tar.gz - https://www.assembla.com/spaces/clojure/documents/aggm70BPir356HeJe5cbLr/download/aggm70BPir356HeJe5cbLr

Comment by Assembla Importer [ 24/Aug/10 11:29 AM ]

stu said: Rich: I understand the classloader situation that causes this. If you tell me what you think should happen instead I will make a patch.

Comment by Assembla Importer [ 24/Aug/10 11:29 AM ]

stu said: Updating tickets (#389, #371)

Comment by Assembla Importer [ 24/Aug/10 11:29 AM ]

cemerick said: AFAICT, this also affects protocol definitions, where the associated interface classfile is available on the classpath.

Comment by Christopher Redinger [ 15/Apr/11 12:57 PM ]

You said you'd make a patch if Rich said it needed on. Your move.

Comment by Stuart Halloway [ 15/Apr/11 6:25 PM ]

This behavior is to be expected, given Java's class loaders. If you want static classes, compile them onto your classpath. If you want reloadable classes, load them at runtime (preferable) from source.

The real place to fix this problem is in build tools and IDEs. When you are developing interactively, these tools should default to non-compilation of Clojure files. The Clojure/core team will fix this in a future version of the Clojure maven build tools.

Comment by Christopher Redinger [ 22/Apr/11 11:47 AM ]

Re-opening - we closed this thinking it would be handled via tooling. It seems we should fix this though.

Comment by Stuart Halloway [ 15/Nov/11 7:16 PM ]

I don't know of any appropriate action to take, other than to change tools.

Comment by Stuart Halloway [ 02/Dec/11 1:39 PM ]

no, really, declined





[CLJ-363] defn doesn't put the right metadata on its fn value Created: 27/May/10  Updated: 24/Aug/10  Resolved: 24/Aug/10

Status: Closed
Project: Clojure
Component/s: None
Affects Version/s: None
Fix Version/s: Backlog

Type: Defect
Reporter: Anonymous Assignee: Unassigned
Resolution: Declined Votes: 0
Labels: None


 Description   

duplicate of #270

user=> (defn foo {:bar :baz} [] 42)
#'user/foo
user=> (meta #'foo)
{:ns #<Namespace user>, :name foo, :file "NO_SOURCE_PATH", :line 221, :arglists ([]), :bar :baz}
user=> (meta foo)
{:ns #<Namespace user>, :name foo} ; the value has only the basic keys
user=> (defn foo {:lucy :ethel} [] 43)
#'user/foo
user=> (meta #'foo)
{:ns #<Namespace user>, :name foo, :file "NO_SOURCE_PATH", :line 224, :arglists ([]), :lucy :ethel}
user=> (meta foo) ; the value has the previous metadata
{:ns #<Namespace user>, :name foo, :file "NO_SOURCE_PATH", :line 221, :arglists ([]), :bar :baz}


 Comments   
Comment by Assembla Importer [ 24/Aug/10 8:20 AM ]

Converted from http://www.assembla.com/spaces/clojure/tickets/363

Comment by Assembla Importer [ 24/Aug/10 8:20 AM ]

cgrand said: Parent association with ticket #270 was added

Comment by Assembla Importer [ 24/Aug/10 8:20 AM ]

cgrand said: duplicate of #270





[CLJ-354] <= and >= comparisons against NaN return true Created: 22/May/10  Updated: 19/Mar/11  Resolved: 01/Oct/10

Status: Closed
Project: Clojure
Component/s: None
Affects Version/s: None
Fix Version/s: Backlog

Type: Defect
Reporter: Anonymous Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: None


 Description   

I would expect the attached clojure program to have the same output as the attached java program. However, their output differs. The following is a unidiff from the clojure output to the java output, i.e., each line beginning with a minus sign is what I would consider wrong output, and the corresponding line beginning with a plus sign is the correct output.

@@ -14,3 +14,3 @@

  • <= 0 NaN true
  • <= NaN 1 true
  • <= NaN NaN true
    + <= 0 NaN false
    + <= NaN 1 false
    + <= NaN NaN false
    @@ -22,3 +22,3 @@
  • >= 0 NaN true
  • >= NaN 1 true
  • >= NaN NaN true
    + >= 0 NaN false
    + >= NaN 1 false
    + >= NaN NaN false

Here Java follows IEEE 754; see also <http://java.sun.com/docs/books/jls/third_edition/html/expressions.html#153654>.

I suspect the bug is because clojure.lang.Numbers.lte(x,y) is implemented by negating the result of lt(y,x), and similarly for gte: <http://github.com/richhickey/clojure/blob/65ae4928119a50e892bc33e8cbb47a82ebef98ee/src/jvm/clojure/lang/Numbers.java#L193>.

This is with Clojure 1.2.0-master-SNAPSHOT (git hash 65ae4928119a50e892bc33e8cbb47a82ebef98ee).

I mentioned this on the Google group, but no-one commented anything: <http://groups.google.com/group/clojure/browse_thread/thread/623d7f50fafaa816>.



 Comments   
Comment by Assembla Importer [ 01/Oct/10 4:14 PM ]

Converted from http://www.assembla.com/spaces/clojure/tickets/354
Attachments:
nan-comparison.clj - https://www.assembla.com/spaces/clojure/documents/bSK-9AzyGr35jbeJe5cbLr/download/bSK-9AzyGr35jbeJe5cbLr
nan.java - https://www.assembla.com/spaces/clojure/documents/bSLbjAzyGr35jbeJe5cbLr/download/bSLbjAzyGr35jbeJe5cbLr
c-nan.txt - https://www.assembla.com/spaces/clojure/documents/bSLdpEzyGr35jbeJe5cbLr/download/bSLdpEzyGr35jbeJe5cbLr
j-nan.txt - https://www.assembla.com/spaces/clojure/documents/bSLft0zyGr35jbeJe5cbLr/download/bSLft0zyGr35jbeJe5cbLr

Comment by Assembla Importer [ 01/Oct/10 4:14 PM ]

stu said: This appears to be fixed in 1.3 master.

Comment by Jouni K. Seppänen [ 19/Mar/11 2:52 PM ]

Not fixed on current git master: the test program still prints e.g. <= 0 NaN true. Interestingly, (<= (float 0.0) Float/NaN) returns false, while (let [op <=] (op (float 0.0) Float/NaN)) returns true.

Comment by Alexander Taggart [ 19/Mar/11 6:44 PM ]

See CLJ-738.





[CLJ-350] namespace function NPE if namespace does not exist Created: 18/May/10  Updated: 01/Oct/10  Resolved: 01/Oct/10

Status: Closed
Project: Clojure
Component/s: None
Affects Version/s: None
Fix Version/s: Backlog

Type: Defect
Reporter: Anonymous Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: None


 Description   

The namespace function throws an NPE if the namespace of the symbol does not exist. For example:

(namespace ::x/y)
;=> NPE

The following patch changes corrects this. The resulting code throws an IllegalArgumentException with the message: "Namespace does not exist: x".

(Note: My Contributor's Agreement is in place, but since my request to join the Google clojure-dev group is still pending I decided to go ahead and submit the patch here.)

-David McNeil

====

From 5d65e5d9aabebf4ea5961e4e0bd8483618f8247e Mon Sep 17 00:00:00 2001
From: David McNeil <dem@dem-laptop.(none)>
Date: Sat, 15 May 2010 10:55:28 -0500
Subject: [PATCH] Avoid NPE and throw better exception if symbol's namespace does not exist.


src/jvm/clojure/lang/LispReader.java | 6 ++++--
1 files changed, 4 insertions, 2 deletions

diff --git a/src/jvm/clojure/lang/LispReader.java b/src/jvm/clojure/lang/LispReader.java
index 0bfae97..361b9cc 100644
— a/src/jvm/clojure/lang/LispReader.java
+++ b/src/jvm/clojure/lang/LispReader.java
@@ -302,9 +302,11 @@ private static Object matchSymbol(String s){
{
Symbol ks = Symbol.intern(s.substring(2));
Namespace kns;

  • if(ks.ns != null)
    + if(ks.ns != null) { kns = Compiler.namespaceFor(ks); - else + if(kns == null) + throw new IllegalArgumentException("Namespace does not exist: " + ks.ns); + } else
    kns = Compiler.currentNS();
    //auto-resolving keyword
    return Keyword.intern(kns.name.name,ks.name);

    • 1.6.3.3


 Comments   
Comment by Assembla Importer [ 01/Oct/10 4:45 PM ]

Converted from http://www.assembla.com/spaces/clojure/tickets/350

Comment by Assembla Importer [ 01/Oct/10 4:45 PM ]

david-mcneil said: This issue was addressed indirectly by ticket 334. Now the code behaves like this for keywords that reference non-existent namespaces:

(namespace ::x/y)

;=> java.lang.Exception: Invalid token: ::x/y

Seems that is fine, at least it is not an NPE.

-David

Comment by Assembla Importer [ 01/Oct/10 4:45 PM ]

donmullen said: This is fixed, as David indicated - ::x/y is an invalid token.

Current message is:

Exception Invalid token: ::x/y clojure.lang.LispReader.interpretToken (LispReader.java:286)

Exception Unmatched delimiter: ) clojure.lang.LispReader$UnmatchedDelimiterReader.invoke (LispReader.java:1039)





[CLJ-348] reify allows use of qualified name as method parameter Created: 13/May/10  Updated: 26/Jul/13

Status: Open
Project: Clojure
Component/s: None
Affects Version/s: None
Fix Version/s: Backlog

Type: Defect Priority: Minor
Reporter: Assembla Importer Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None

Approval: Vetted

 Description   

This should complain about using a fully-qualified name as a parameter:

(defmacro lookup []
`(reify clojure.lang.ILookup
(valAt [_ key])))

Instead it simply ignores that parameter in the method body in favour of clojure.core/key.



 Comments   
Comment by Assembla Importer [ 24/Aug/10 8:03 AM ]

Converted from http://www.assembla.com/spaces/clojure/tickets/348
Attachments:
0001-Add-a-test-for-348-reify-shouldn-t-accept-qualified-.patch - https://www.assembla.com/spaces/clojure/documents/d2xUJIxTyr36fseJe5cbLA/download/d2xUJIxTyr36fseJe5cbLA

Comment by Assembla Importer [ 24/Aug/10 8:03 AM ]

technomancy said: [file:d2xUJIxTyr36fseJe5cbLA]: A test to expose the unwanted behaviour

Comment by Assembla Importer [ 24/Aug/10 8:03 AM ]

richhickey said: I'm not sure the bug is what you say it is, or the resolution should be what you suggest. The true problem is the resolution of key when qualified. Another possibility is to ignore the qualifier there.

Comment by Assembla Importer [ 24/Aug/10 8:03 AM ]

technomancy said: Interesting. So it's not appropriate to require auto-gensym here? Why are the rules different for reify methods vs proxy methods?

> (defmacro lookup []
`(proxy [clojure.lang.ILookup] []
(valAt [key] key)))
> (lookup)

Can't use qualified name as parameter: clojure.core/key
[Thrown class java.lang.Exception]





[CLJ-346] (pprint-newline :fill) is not handled correctly Created: 12/May/10  Updated: 03/Sep/13

Status: Open
Project: Clojure
Component/s: None
Affects Version/s: None
Fix Version/s: Backlog

Type: Defect Priority: Minor
Reporter: Assembla Importer Assignee: Tom Faulhaber
Resolution: Unresolved Votes: 0
Labels: print

Approval: Vetted
Waiting On: Tom Faulhaber

 Description   

Filled pretty printing (where we try to fit as many elements on a line as possible) is being too aggressive as we can see when we try to print the following array:

user> (binding [*print-right-margin* 20] (pprint (int-array (range 10))))

Produces:

[0,
1,
2,
3,
4, 5, 6, 7, 8, 9]

Rather than

[0, 1, 2, 3, 4,
5, 6, 7, 8, 9]

or something like that. (I haven't worked through the exact correct representation for this case).

We currently only use :fill style newlines for native java arrays.



 Comments   
Comment by Assembla Importer [ 24/Aug/10 8:01 AM ]

Converted from http://www.assembla.com/spaces/clojure/tickets/346
Attachments:
0347-pprint-update-2.diff - https://www.assembla.com/spaces/clojure/documents/diLxv6y4Sr35GVeJe5cbLr/download/diLxv6y4Sr35GVeJe5cbLr

Comment by Assembla Importer [ 24/Aug/10 8:01 AM ]

stu said: [file:diLxv6y4Sr35GVeJe5cbLr]

Comment by Assembla Importer [ 24/Aug/10 8:01 AM ]

stu said: The second patch includes the first, and adds another test.

Comment by Assembla Importer [ 24/Aug/10 8:01 AM ]

tomfaulhaber said: This patch was attached to the wrong bug. It should be attached to bug #347. There is no fix for this bug yet.

Comment by Rich Hickey [ 05/Nov/10 8:07 AM ]

Is this current?

Comment by Stuart Halloway [ 29/Nov/10 8:48 PM ]

Tom, this patch doesn't apply, and I am not sure why. Can you take a look?





[CLJ-345] clojure.contrib.string.replace-str throws NPE on nil string Created: 10/May/10  Updated: 01/Oct/10  Resolved: 01/Oct/10

Status: Closed
Project: Clojure
Component/s: None
Affects Version/s: None
Fix Version/s: Backlog

Type: Defect
Reporter: Anonymous Assignee: Unassigned
Resolution: Declined Votes: 0
Labels: None


 Description   

Version: Clojure 1.2 / clojure-contrib 1.2

This call:

user=> (clojure.contrib.string/replace-str "a" "b" nil)
#<CompilerException java.lang.NullPointerException (NO_SOURCE_FILE:29)>

throws a NullPointerException when passed a nil string. It seems like more corner cases could be automatically handled by returning nil in this case rather than throwing an NPE. At the very least, it would be nice to update the docstring to state that s cannot be nil.



 Comments   
Comment by Assembla Importer [ 01/Oct/10 6:44 AM ]

Converted from http://www.assembla.com/spaces/clojure/tickets/345

Comment by Assembla Importer [ 01/Oct/10 6:44 AM ]

stu said: I evaluated this agains the latest version of the fn in clojre (e.g. clojure.string/replace).

The documentation string correctly lists legal parameters for replace as string, char, or fn, so an NPE is expected behavior.

Note also: the contrib versions of most string fns are deprecated.





[CLJ-342] Enhance (vector-of) to populate vector Created: 05/May/10  Updated: 26/Jul/13  Resolved: 20/Mar/11

Status: Closed
Project: Clojure
Component/s: None
Affects Version/s: None
Fix Version/s: Backlog

Type: Enhancement Priority: Minor
Reporter: Assembla Importer Assignee: Daniel Solano Gómez
Resolution: Completed Votes: 1
Labels: None

Attachments: Text File enhance-vector-of.patch     Text File updated-enhance-vector-of.patch    
Approval: Ok
Waiting On: Stuart Halloway

 Description   

As discussed on clojure-dev at <http://groups.google.com/group/clojure-dev/browse_thread/thread/97137884bb33f8ee>, I would like to enhance (vector-of) so that it can create a populated vector. There are two ways to do this:

1. Like vector, take an arbitrary number of arguments used to populate the array.
2. Like vec, take a collection and use it to populate the array.



 Comments   
Comment by Assembla Importer [ 28/Sep/10 8:57 AM ]

Converted from http://www.assembla.com/spaces/clojure/tickets/342
Attachments:
342-enhance-vector-of.patch - https://www.assembla.com/spaces/clojure/documents/ciVMWWwl8r35ypeJe5cbLr/download/ciVMWWwl8r35ypeJe5cbLr

Comment by Assembla Importer [ 28/Sep/10 8:57 AM ]

dsg said: [file:ciVMWWwl8r35ypeJe5cbLr]

Comment by Assembla Importer [ 28/Sep/10 8:57 AM ]

dsg said: I have attached a patch that implements the proposed enhancement. I am fairly certain it is not the absolutely highest performance implementation.

I have not taken a lot of time to thoroughly study the code, but I think there is probably a way to create the initial array and pass it as an argument to the constructor, which would avoid a lot of the cons calls.

Nonetheless, I think it is important enough to provide convenience of the interface. The implementation can always be changed later.

Comment by Assembla Importer [ 28/Sep/10 8:57 AM ]

richhickey said: You can't have it both ways. vector-of should be like vector, I think.

Comment by Daniel Solano Gómez [ 25/Feb/11 4:29 PM ]

I have updated my patch to reflect Rich's recommendation. vector-of now behaves similarly to vector.

Includes tests.

Comment by Rich Hickey [ 10/Mar/11 11:45 AM ]

For the 1,2,3 cases it's better to create an array of that size and .aset am into it, please. & rest case could bootstrap with 3-arg call as well.

Thanks.

Comment by Daniel Solano Gómez [ 10/Mar/11 2:02 PM ]

Updated patch to reflect Rich's suggestions.





[CLJ-339] Integer autopromotion error Created: 05/May/10  Updated: 01/Oct/10  Resolved: 01/Oct/10

Status: Closed
Project: Clojure
Component/s: None
Affects Version/s: None
Fix Version/s: Backlog

Type: Defect
Reporter: Anonymous Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: None


 Description   

From this thread:
http://groups.google.com/group/clojure/browse_thread/thread/db1ffbb36c7d6f48

user=>(def imax (Integer/MAX_VALUE))
user=>(+ imax imax)
4294967294

user=>(+ (Integer/MAX_VALUE) (Integer/MAX_VALUE))
java.lang.ArithmeticException: integer overflow (NO_SOURCE_FILE:0)

Also:
user=>(+ Integer/MAX_VALUE Integer/MAX_VALUE)
java.lang.ArithmeticException: integer overflow (NO_SOURCE_FILE:0)

user=> (+ (Integer/MAX_VALUE) imax)
4294967294

user=> (+ imax (Integer/MAX_VALUE))
4294967294

user=> (+ Integer/MAX_VALUE Integer/MAX_VALUE Integer/MAX_VALUE)
6442450941

Possibly a bug with inlining?



 Comments   
Comment by Assembla Importer [ 01/Oct/10 10:13 AM ]

Converted from http://www.assembla.com/spaces/clojure/tickets/339

Comment by Assembla Importer [ 01/Oct/10 10:13 AM ]

devlinsf said: Also, some more cases

user=> (- Integer/MAX_VALUE Integer/MAX_VALUE Integer/MAX_VALUE)
-2147483647

user=> (- Integer/MIN_VALUE Integer/MIN_VALUE)
0
user=> (- Integer/MAX_VALUE Integer/MIN_VALUE)
java.lang.ArithmeticException: integer overflow (NO_SOURCE_FILE:0)

user=> (- Integer/MAX_VALUE Integer/MIN_VALUE)
java.lang.ArithmeticException: integer overflow (NO_SOURCE_FILE:0)

user=> (- Integer/MIN_VALUE Integer/MAX_VALUE)
java.lang.ArithmeticException: integer overflow (NO_SOURCE_FILE:0)

user=> (* Integer/MIN_VALUE Integer/MAX_VALUE)
java.lang.ArithmeticException: integer overflow (NO_SOURCE_FILE:0)

user=> (* Integer/MAX_VALUE Integer/MAX_VALUE)
java.lang.ArithmeticException: integer overflow (NO_SOURCE_FILE:0)

user=> (* Integer/MAX_VALUE Integer/MAX_VALUE Integer/MAX_VALUE)
9903520300447984150353281023

Comment by Assembla Importer [ 01/Oct/10 10:13 AM ]

aredington said: When testing with ints, this behavior no longer happens as all arithmetic happens in longs.

When testing with longs, the overflow behavior occurs consistently, regardless of the involvement of vars or let bindings.





[CLJ-326] add :as-of option to refer Created: 30/Apr/10  Updated: 26/Jul/13

Status: In Progress
Project: Clojure
Component/s: None
Affects Version/s: None
Fix Version/s: Backlog

Type: Enhancement Priority: Minor
Reporter: Christophe Grand Assignee: Christophe Grand
Resolution: Unresolved Votes: 0
Labels: None

Approval: Vetted

 Description   

Discussed here: http://groups.google.com/group/clojure-dev/msg/74af612909dcbe56

:as-of allows library authors to specify a known subset of vars to refer from clojure (or any other library which would use :added metadata).

(ns foo (:refer-clojure :as-of "1.1")) is equivalent to (ns foo (:refer-clojure :only [public-documented-vars-which-already-existed-in-1.1]))



 Comments   
Comment by Assembla Importer [ 24/Aug/10 10:19 AM ]

Converted from http://www.assembla.com/spaces/clojure/tickets/326
Attachments:
add-as-of-to-refer.patch - https://www.assembla.com/spaces/clojure/documents/a8SumUvcOr37SmeJe5cbLA/download/a8SumUvcOr37SmeJe5cbLA

Comment by Assembla Importer [ 24/Aug/10 10:19 AM ]

cgrand said: [file:a8SumUvcOr37SmeJe5cbLA]: requires application of #325

Comment by Assembla Importer [ 24/Aug/10 10:19 AM ]

richhickey said: Do we still need this?





[CLJ-293] doto doc minor typo Created: 11/Apr/10  Updated: 24/Aug/10  Resolved: 24/Aug/10

Status: Closed
Project: Clojure
Component/s: None
Affects Version/s: None
Fix Version/s: Backlog

Type: Enhancement
Reporter: Anonymous Assignee: Timothy Pratley
Resolution: Completed Votes: 0
Labels: None

Approval: Ok

 Description   

doto doc has a small typo



 Comments   
Comment by Assembla Importer [ 24/Aug/10 4:23 PM ]

Converted from http://www.assembla.com/spaces/clojure/tickets/293
Attachments:
dotodoc.diff - https://www.assembla.com/spaces/clojure/documents/a_SYzart8r37u3eJe5aVNr/download/a_SYzart8r37u3eJe5aVNr





[CLJ-291] (take-nth 0 coll) redux... Created: 08/Apr/10  Updated: 27/Jul/13

Status: In Progress
Project: Clojure
Component/s: None
Affects Version/s: None
Fix Version/s: Backlog

Type: Enhancement Priority: Minor
Reporter: Assembla Importer Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None

Approval: Vetted

 Description   

I dont seem to be able make the old ticket uninvalid so here goes
(take-nth 0 coll) causes (at least on Solaris) infinite space and time consumption
It's not a printout error as the following code causes the problem too

(let [j 0
firstprod (apply * (doall (map #(- 1 %) (take-nth j (:props mix)))))]) ; from my parameter update function

I used jvisualvm and the jvm is doing some RNI call - no clojure code is running at all
If left alone it will crash the jvm with all heap space consumed
0 is an InvalidArgument for take-nth
I wouldnt mind if it produced an infinite lazy sequence of nils even though thats wrong
It doesnt do this though it actively destroys the JVM
Its a bug nasty destructive and it took me half a day to figure out what was going on
please let someone fix it!



 Comments   
Comment by Assembla Importer [ 17/Oct/10 9:47 AM ]

Converted from http://www.assembla.com/spaces/clojure/tickets/291
Attachments:
fixbug291.diff - https://www.assembla.com/spaces/clojure/documents/dfNhoS2Cir3543eJe5cbLA/download/dfNhoS2Cir3543eJe5cbLA

Comment by Assembla Importer [ 17/Oct/10 9:47 AM ]

bhurt said: Before this bug gets marked as invalid as well, let me point out that the problem here is that (take-nth 0 any-list) is a meaningless construction- the only question is what to do when this happens. IMHO, the correct behavior is to throw an exception.

Comment by Assembla Importer [ 17/Oct/10 9:47 AM ]

ataggart said: [file:dfNhoS2Cir3543eJe5cbLA]: throws IllegalArgumentException on negative step size

Comment by Stuart Halloway [ 29/Oct/10 10:36 AM ]

Does calling (take-nth 0 ...) cause the problem, or only realizing the result?

Comment by Chouser [ 29/Oct/10 11:06 AM ]

I'm not seeing a problem. Calling take-nth and even partially consuming the seq it returns works fine for me:

(take 5 (take-nth 0 [1 2 3]))
;=> (1 1 1 1 1)

Note however that it is returning an infinite lazy seq. The example in the issue description seems to include essentially (doall <infinite-lazy-seq>) which does blow the heap:

(doall (range))

This issue still strikes me as invalid.

Comment by Rich Hickey [ 29/Oct/10 11:06 AM ]

(take-nth 0 ...) returns an infinite sequence of the first item:

(take 12 (take-nth 0 [1 2 3]))
=> (1 1 1 1 1 1 1 1 1 1 1 1)

Is something other than this happening on Solaris?





[CLJ-288] Make clojure.core/merge-with accept a wider range of map types Created: 01/Apr/10  Updated: 24/Aug/12  Resolved: 24/Aug/12

Status: Closed
Project: Clojure
Component/s: None
Affects Version/s: None
Fix Version/s: Backlog

Type: Enhancement
Reporter: Anonymous Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: None


 Description   

The current implementation of merge-with works only with map types that implement the IFn protocol for key lookup. In particular, this means that it doesn't work with map-like types created with deftype. The attached patch replaces the call to the map by a call to clojure.core/get, which works on any map-like type.



 Comments   
Comment by Assembla Importer [ 24/Aug/10 10:11 AM ]

Converted from http://www.assembla.com/spaces/clojure/tickets/288
Attachments:
merge-with-enhancements.diff - https://www.assembla.com/spaces/clojure/documents/cIq-tspyur375WeJe5avMc/download/cIq-tspyur375WeJe5avMc

Comment by Stuart Sierra [ 24/Aug/12 7:40 AM ]

CLJ-288 patch dated 2010-05-27, from Konrad Hinsen, applied before Clojure 1.3.0 was released





[CLJ-287] (take-nth 0 coll) spins wheels on Solaris Created: 31/Mar/10  Updated: 24/Aug/10  Resolved: 24/Aug/10

Status: Closed
Project: Clojure
Component/s: None
Affects Version/s: None
Fix Version/s: Backlog

Type: Defect
Reporter: Anonymous Assignee: Unassigned
Resolution: Declined Votes: 0
Labels: None


 Description   

(take-nth 0 (range 5)) is a silly thing to do, but if you're anything like me then it inexorably fills heap space and cpu time by an infinite number of RMI calls.
I'm running Clojure 1.1.0-master-SNAPSHOT under Java 1.6R17 on Solaris 10 and I watched it fill up to 56GB
I think it should raise an exception instead but Im too new to clojure to recommend one. Sorry
Cheers
Simon



 Comments   
Comment by Assembla Importer [ 24/Aug/10 10:10 AM ]

Converted from http://www.assembla.com/spaces/clojure/tickets/287
Attachments:
take-nth.diff - https://www.assembla.com/spaces/clojure/documents/awDmNUpz4r34FheJe5aVNr/download/awDmNUpz4r34FheJe5aVNr

Comment by Assembla Importer [ 24/Aug/10 10:10 AM ]

bhurt said: [file:awDmNUpz4r34FheJe5aVNr]: Proposed patch to fix this ticket

Comment by Assembla Importer [ 24/Aug/10 10:10 AM ]

stu said: Hi Simon,

If you set the print-length you can prevent runaway sequences from trying to print. Try the following, and if still blows up please re-open or file a new bug:

(set! *print-length* 10)
 (take-nth 0 (range 5))

Cheers,
Stu

Comment by Assembla Importer [ 24/Aug/10 10:10 AM ]

bhurt said: I think the real problem is that (take-nth 0 some-list) is invalid. It's nonsensical in a deep way- take every 0th element? If you glanced at my patch, all I did was validate the arguments and throw an exception if the n argument is not positive, rather than returning an infinite list. I mean, a similar problem shows up if you do (count (take-nth 0 (range 5))).





[CLJ-284] Cannot cast 0xFF to a byte (fails range check) Created: 24/Mar/10  Updated: 28/Sep/10  Resolved: 28/Sep/10

Status: Closed
Project: Clojure
Component/s: None
Affects Version/s: None
Fix Version/s: Backlog

Type: Enhancement
Reporter: Anonymous Assignee: Unassigned
Resolution: Declined Votes: 0
Labels: None


 Description   

Prompted by a thread on the clojure group.

The recently added range checking to casts/coercions adversely affects a common usage of the byte cast to pull the 8 LSBs of an integer. Since the numerical representation of a byte is signed in java, the Byte.MIN_VALUE</code> and <code>Byte.MAX_VALUE</code> used in the range check of <code>clojure.lang.RT.byteCast() do not allow for integer values up to 0xFF.



 Comments   
Comment by Assembla Importer [ 28/Sep/10 1:05 PM ]

Converted from http://www.assembla.com/spaces/clojure/tickets/284
Attachments:
ubyte.diff - https://www.assembla.com/spaces/clojure/documents/b_MyyAn4mr34xSeJe5avMc/download/b_MyyAn4mr34xSeJe5avMc

Comment by Assembla Importer [ 28/Sep/10 1:05 PM ]

ataggart said: [file:b_MyyAn4mr34xSeJe5avMc]: Adds a ubyte coercion when the resulting byte should be considered unsigned, thus inputs of 0-255 are acceptable

Comment by Assembla Importer [ 28/Sep/10 1:05 PM ]

ataggart said: Patch provided to add a ubyte coercion:

<pre>user=> 0xFF
255
user=> (Integer/toBinaryString 0xFF)
"11111111"
user=> (byte 0xFF)
java.lang.IllegalArgumentException: Value out of range for byte: 255 (NO_SOURCE_FILE:0)
user=> (ubyte 0xFF)
-1
user=> (ubyte 256)
java.lang.IllegalArgumentException: Value out of range for unsigned byte: 256 (NO_SOURCE_FILE:0)
</pre>

Comment by Assembla Importer [ 28/Sep/10 1:05 PM ]

richhickey said: This is really a subset of #441

Comment by Assembla Importer [ 28/Sep/10 1:05 PM ]

ataggart said: Agreed.





[CLJ-283] recur ignores rest args Created: 17/Mar/10  Updated: 24/Aug/10  Resolved: 24/Aug/10

Status: Closed
Project: Clojure
Component/s: None
Affects Version/s: None
Fix Version/s: Backlog

Type: Defect
Reporter: Anonymous Assignee: Unassigned
Resolution: Declined Votes: 0
Labels: None


 Description   

When you recur inside a function, the arguments are not assigned as expected:

(defn weird [& b]
(println b)
(when (< (first b) 2)
(recur (inc (first b)))))

(weird 1)

The first time it runs, b is a seq, but the second time it's just an integer.

After some discussion I found out this is because there's no way to apply recur, so technically making recur act as a normal function call means you can't pass a seq of args in. While this is arguably a decent workaround, it leads to very confusing, undocumented behaviour; at the very least it should be tracked in an issue until a better solution can be found.



 Comments   
Comment by Assembla Importer [ 24/Aug/10 7:55 AM ]

Converted from http://www.assembla.com/spaces/clojure/tickets/283

Comment by Assembla Importer [ 24/Aug/10 7:55 AM ]

stu said: Recur doesn't re-enter the function, it just goes back to the top (the vararging doesn't happen again). Since b is a collection coming in, recur with a collection and you will be fine.

(defn weird [& b]
  (println b)
  (when (< (first b) 2)
    (recur (cons (inc (first b)) (rest b)))))

I find this intuitive, but when I launch the Assembla FAQ feel free to add an item for this if you like.

Comment by Assembla Importer [ 24/Aug/10 7:55 AM ]

technomancy said: > I find this intuitive, but when I launch the Assembla FAQ feel free to add an item for this if you like.

OK. Anecdotally I asked four other seasoned Clojure users what they thought was going on here and only one had an explanation, so most folks are going to think this is an unintended result when they see it. I don't know if it's FA enough to qualify this for a FAQ, but even having this closed issue show up in search results is an improvement.

I know internally there's a difference between calling a function and executing the body of a function, but up till this point I considered that an implementation detail.





[CLJ-279] Numbers as keys in maps must be of the same class to match Created: 10/Mar/10  Updated: 28/Sep/10  Resolved: 28/Sep/10

Status: Closed
Project: Clojure
Component/s: None
Affects Version/s: None
Fix Version/s: Backlog

Type: Defect
Reporter: Anonymous Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: None


 Description   

In maps, numbers need to be of the same class to match:

({(BigInteger. "1") "one"} 1) => nil
({(Long. "1") "one"} 1) => nil
({(Integer. "1") "one"} 1) => "one"

although:

(= (BigInteger. "1") 1) => true
(= (Long. "1") 1) => true



 Comments   
Comment by Assembla Importer [ 28/Sep/10 9:23 AM ]

Converted from http://www.assembla.com/spaces/clojure/tickets/279





[CLJ-274] cannot close over mutable fields (in deftype) Created: 23/Feb/10  Updated: 03/Sep/13

Status: Open
Project: Clojure
Component/s: None
Affects Version/s: None
Fix Version/s: Backlog

Type: Defect Priority: Major
Reporter: Anonymous Assignee: Unassigned
Resolution: Unresolved Votes: 1
Labels: deftype

Approval: Vetted

 Description   

Simplest case:

user=>
(deftype Bench [#^{:unsynchronized-mutable true} val]
Runnable
(run [_]
(fn [] (set! val 5))))

java.lang.IllegalArgumentException: Cannot assign to non-mutable: val (NO_SOURCE_FILE:5)

Functions should be able to mutate mutable fields in their surrounding deftype (just like inner classes do in Java).

Filed as bug, because the loop special form expands into a fn form sometimes:

user=>
(deftype Bench [#^{:unsynchronized-mutable true} val]
Runnable
(run [_]
(let [x (loop [] (set! val 5))])))
java.lang.IllegalArgumentException: Cannot assign to non-mutable: val (NO_SOURCE_FILE:9)



 Comments   
Comment by Assembla Importer [ 01/Oct/10 9:35 AM ]

Converted from http://www.assembla.com/spaces/clojure/tickets/274

Comment by Assembla Importer [ 01/Oct/10 9:35 AM ]

donmullen said: Updated each run to [_] for new syntax.

Now gives exception listed.

Comment by Assembla Importer [ 01/Oct/10 9:35 AM ]

richhickey said: We're not going to allow closing over mutable fields. Instead we'll have to generate something other than fn for loops et al used as expressions. Not going to come before cinc





[CLJ-255] add denominator and numerator fns for Ratio Created: 29/Jan/10  Updated: 28/Sep/10  Resolved: 28/Sep/10

Status: Closed
Project: Clojure
Component/s: None
Affects Version/s: None
Fix Version/s: Backlog

Type: Enhancement
Reporter: Anonymous Assignee: Kevin Downey
Resolution: Completed Votes: 0
Labels: None


 Description   

currently the only way to get the denominator or numerator is via the exposed fields of the Ratio class.

On Thu, Jan 21, 2010 at 7:57 AM, Jacek Generowicz
<jacek.generowicz@googlemail.com> wrote:
> Clojure has a Ratio type; presumably there should be an easy way to
> find the numerator and denominator of a Ratio object.
>
> I didn't have much luck on clojure.org or with find-doc, but
>
> (show 1/2)
>
> taught me that there are numerator and denominator methods on Ratio's
> underlying Java implementation, so I can now do:
>
> (.numerator 1/2) ; => 1
> (.denominator 1/2) ; => 2
>
> Is there a more direct way? (Not that this is bad! But you can't
> use .numerator as a first-order function (though #(.numerator %) is
> still pretty damn good).)
>
> In general, do you have any hints on how to go about looking for
> useful Clojure functions which work with certain Clojure types ?
>



 Comments   
Comment by Assembla Importer [ 28/Sep/10 7:07 AM ]

Converted from http://www.assembla.com/spaces/clojure/tickets/255
Attachments:
ratio-fns.diff - https://www.assembla.com/spaces/clojure/documents/cyO2hUdrir3749eJe5aVNr/download/cyO2hUdrir3749eJe5aVNr

Comment by Assembla Importer [ 28/Sep/10 7:07 AM ]

hiredman said: [file:cyO2hUdrir3749eJe5aVNr]: add denominator and numerator fns

Comment by Assembla Importer [ 28/Sep/10 7:07 AM ]

hiredman said: Duplicated association with ticket #254 was added

Comment by Assembla Importer [ 28/Sep/10 7:07 AM ]

hiredman said: (In [[r:5772be9fc5ac9ddf92b727908c20b9aab971224a]]) numerator and denominator fns for Ratios, refs #255

Signed-off-by: Rich Hickey <richhickey@gmail.com>

Branch: master





[CLJ-251] macroexpand should respect :inline Created: 28/Jan/10  Updated: 07/Oct/11  Resolved: 07/Oct/11

Status: Closed
Project: Clojure
Component/s: None
Affects Version/s: None
Fix Version/s: Backlog

Type: Enhancement
Reporter: Anonymous Assignee: Unassigned
Resolution: Declined Votes: 0
Labels: None


 Description   

macroexpand and macroexpand-1 currently do not respect the :inline metadata of
functions. For example you currently see:

(macroexpand '(+ 1 2))
;=> (+ 1 2)

Instead, macroexpand should return something like:

;=> (. clojure.lang.Numbers (add 1 2))

...depending of course on the exact definition of +'s :inline fn.



 Comments   
Comment by Assembla Importer [ 24/Aug/10 6:06 AM ]

Converted from http://www.assembla.com/spaces/clojure/tickets/251





[CLJ-250] debug builds Created: 27/Jan/10  Updated: 23/Oct/13

Status: Open
Project: Clojure
Component/s: None
Affects Version/s: Release 1.2
Fix Version/s: Backlog

Type: Enhancement Priority: Minor
Reporter: Stuart Halloway Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: build

Approval: Vetted
Waiting On: Rich Hickey

 Description   

This ticket includes two patches:

  1. a patch to set assert when clojure.lang.RT loads, based on the presence of system property clojure.debug
  2. expand error messages in assert to include local-bindings</code> (a new macro which wraps the implicit <code>&env)

Things to consider before approving these patches:

  1. should there be an easy Clojure-level way to query if debug is enabled? (checking assert isn't the same, as debug should eventually drive other features)
  2. assertions will now be off by default – this is a change!
  3. is the addition of the name local-bindings to clojure.core cool?


 Comments   
Comment by Assembla Importer [ 24/Aug/10 6:05 AM ]

Converted from http://www.assembla.com/spaces/clojure/tickets/250
Attachments:
add-clojure-debug-flag.patch - https://www.assembla.com/spaces/clojure/documents/aUWn50c64r35E-eJe5aVNr/download/aUWn50c64r35E-eJe5aVNr
assert-report-locals.patch - https://www.assembla.com/spaces/clojure/documents/aUWqLSc64r35E-eJe5aVNr/download/aUWqLSc64r35E-eJe5aVNr

Comment by Stuart Halloway [ 07/Dec/10 8:23 PM ]

Ignore the old patches. Considering the following implementation, please review and then move ticket to waiting on Stu:

  1. RT will check system property "clojure.debug", default to false
  2. property will set the root binding for the current *assert*, plus a new *debug* flag. (Debug builds can and will drive other things than just asserts.)
  3. does Compile.java need to push *assert* or *debug* as thread local bindings, or can they be root-bound only when compiling clojure?
  4. will add *debug* binding to clojure.main/with-bindings. Anywhere else?
  5. build.xml should not have to change – system properties will flow through (and build.xml may not be around much longer anyway)
  6. once we agree on the approach, I will ping maven plugin and lein owners so that they flow the setting through
  7. better assertion messages will be a separate ticket
  8. what is the interaction between *debug* and *unchecked-math*? Change checks to (and *unchecked-math* (not *debug*))}?
Comment by Rich Hickey [ 08/Dec/10 11:00 AM ]

#3 - root bound only
#4 - should not be in with-bindings for same reason as #3 - we don't want people to set! *debug* nor *assert*
#8 - yes, wrapping that in a helper fn

#6 - my biggest reservation is that this isn't yet informed by maven best practices

Comment by Stuart Sierra [ 08/Dec/10 2:09 PM ]

System properties can be passed through Maven, so I do not anticipate this being a problem.

However, I would prefer *assert* to remain true by default.

Comment by Chas Emerick [ 09/Dec/10 7:19 AM ]

SS is correct about this approach not posing any issue for Maven. In addition, the build could easily be set up to always emit two jars, one "normal", one "debug".

I'd suggest that, while clojure.debug might have broad effect, additional properties should be available to provide fine-grained control over each of the additional "debug"-related parameterizations that might become available in the future.


I'd like to raise a couple of potentially tangential concerns (after now thinking about assertions for a bit in the above context), some or all of which may simply be a result of my lack of understanding in various areas.

Looking at where assert is used in core.clj (only two places AFAICT: validating arguments to derive and checking pre- and post-conditions in fn), it would seem unwise to make it false by default. i.e. non-Named values would be able to get into hierarchies, and pre- and post-conditions would simply be ignored.

It's my understanding that assertions (talking here of the JVM construct, from which Clojure reuses AssertionError) should not be used to validate arguments to public API functions, or used to validate any aspect of a function's normal operation (i.e. "where not to use assertions"). That would imply that derive should throw IllegalArugmentException when necessary, and fn pre- and post-conditions should perhaps throw IllegalStateException – or, in any case, something other than AssertionError via assert. This would match up far better with most functions in core using assert-args rather than assert, the former throwing IllegalArgumentException rather than AssertionError.

That leads me to the question: is assert (and *assert*) intended to be a Clojure construct, or a quasi-interop form?

If the former, then it can roughly have whatever semantics we want, but then it seems like it should not be throwing AssertionError.

If the latter, then AssertionError is appropriate on the JVM, but then we need to take care that assertions can be enabled and disabled at runtime (without having to switch around different builds of Clojure), ideally using the host-defined switches (e.g. -ea and friends) and likely not anything like *assert*. I don't know if this is possible or practical at this point (I presume this would require nontrivial compiler changes).


Hopefully the above is not water under the bridge at this point. Thank you in advance for your forbearance.

Comment by Rich Hickey [ 09/Dec/10 8:08 AM ]

Thanks for the useful input Chas. Nothing is concluded yet. I think we should step back and look at the objective here, before moving forward with a solution. Being a dynamic language, there are many things we might want to validate about our programs, where the cost of checking is something we are unwilling to pay in production.

Being a macro, assert has the nice property that, should *assert* not be true during compilation, it generates nil, no conditional test at all. Thus right now it is more like static conditional compilation.

Java assert does have runtime toggle-ability, via -ea as you say. I haven't looked at the bytecode generated for Java asserts, but it might be possible for Clojure assert to do something similar, if the runtime overhead is negligible. It is quite likely that HotSpot has special code for eliding the assertion bytecode given a single check of some flag. I'm just not sure that flag is Class.desiredAssertionStatus.

Whether this turns into changes in assert or pre/post conditions, best practices etc is orthogonal and derived. Currently we don't have a facility to run without the checks. We need to choose between making them disappear during compilation (debug build) or runtime (track -ea) or both. Then we can look at how that is reflected in assert/pre-post and re-examine existing use of both. The "where not to use assertions" doc deals with them categorically, but in not considering their cost, seems unrealistic IMO.

I'd appreciate it if someone could look into how assert is generated and optimized by Java itself.

Comment by Chas Emerick [ 09/Dec/10 5:04 PM ]

Bytecode issues continue to be above my pay grade, unfortunately…

A few additional thoughts in response that you may or may not be juggling already:

assert being a macro makes total sense for what it's doing. Trouble is, "compile-time" is a tricky concept in Clojure: there's code-loading-time, AOT-compile-time, and transitively-AOT-compile-time. Given that, it's entirely possible for an application deployed to a production environment that contains a patchwork of code or no code produced by assert usages in various libraries and namespaces depending upon when those libs and ns' were loaded, AOT-compiled, or their dependents AOT-compiled, and the value of *assert* at each of those times. Of course, this is the case for all such macros whose results are dependent upon context-dependent state (I think this was a big issue with clojure.contrib.logging, making it only usable with log4j for a while).

What's really attractive about the JVM assertion mechanism is that it can be parameterized for a given runtime on a per-package basis, if desired. Reimplementing that concept so that assert can be *ns*-sensitive seems like it'd be straightforward, but the compile-time complexity already mentioned remains, and the idea of having two independently-controlled assertion facilities doesn't sound fun.

I know nearly nothing about the CLR, but it would appear that it doesn't provide for anything like runtime-controllable assertions.

Comment by Stuart Halloway [ 29/Dec/10 3:17 PM ]

The best (dated) evidence I could find says that the compiler sets a special class static final field $assertionsDisabled based on the return of desiredAssertionStatus. HotSpot doesn't do anything special with this, dead code elimination simply makes it go away. The code indeed compiles this way:

11: getstatic #6; //Field $assertionsDisabled:Z
14: ifne 33
17: lload_1
18: lconst_0
19: lcmp
20: ifeq 33
23: new #7; //class java/lang/AssertionError
26: dup
27: ldc #8; //String X should be zero
29: invokespecial #9; //Method java/lang/AssertionError."<init>":(Ljava/lang/Object;)V
32: athrow

Even if we were 100% sure that assertion removal was total, I would still vote for a separate Clojure-level switch, for the following reasons:

  1. I have a real and pressing need to disable some assertions, and I don't need the Java interop at all. Arguably others will be in the same boat.
  2. there will be multiple debugging facilities over time, and having a top-level debug switch is convenient for Clojure users.
  3. Java dis/enabling via command line flags is still possible as a separate feature. We could add this later as a (small) breaking change to our assert, or have a separate java-assert interop form. I am on the fence about which way to go here.
  4. I believe it is perfectly fine to throw an AssertionError from a non-Java-assertion-form. We don't believe in a world of a static exception hierarchy, and an assertion in production is a critical failure no matter what you call it. Even Scala does it http://daily-scala.blogspot.com/2010/03/assert-require-assume.html

Rich: awaiting your blessing to move forward on this.

Comment by Rich Hickey [ 07/Jan/11 9:42 AM ]

The compiler sets $assertionsDisabled when, in static init code? Is there special support in the classloader for it? Is there a link to the best dated evidence you found?

Comment by Stuart Halloway [ 07/Jan/11 9:51 AM ]
  1. Yes, in static init code
  2. There is no special support in the classloader, per Brian Goetz (private correspondence) last week. But dead code elimination is great: "The run-time cost of disabled assertions should indeed be zero for compiled code"
Comment by Stuart Halloway [ 07/Jan/11 9:57 AM ]

Link: Google "java assert shirazi". (Not posting link because I can't tell in 10 secs whether it includes my session information.)

Comment by Alexander Kiel [ 14/Mar/13 1:28 PM ]

Is there anything new on this issue? I also look for a convenient way to disable assertions in production.

Comment by Michał Łopuszyński [ 11/Oct/13 4:21 AM ]

I am also interested in any news on this issue.
Convenient way to enable/disable assertions at runtime (preferably via -ea/-da options) would be a great feature!

Comment by Michał Łopuszyński [ 23/Oct/13 3:12 AM ]

Btw. there is a library for runtime-toggable assertions available via clojars
https://github.com/pjstadig/assertions
This helped me a great deal.





[CLJ-238] Make re-pattern accept multiple arguments to concatenate them. Created: 05/Jan/10  Updated: 07/Oct/11  Resolved: 07/Oct/11

Status: Closed
Project: Clojure
Component/s: None
Affects Version/s: None
Fix Version/s: Backlog

Type: Enhancement
Reporter: Anonymous Assignee: Nicolas Buduroi
Resolution: Declined Votes: 0
Labels: None


 Description   

This would help concatenating multiple regular expressions. The attached patch simply converts all arguments to a string and then pass that string to re-pattern. Currently if you're trying to concatenate literal regular expressions, you're force to use the str function. It's not much extra code, but given the similarity between re-pattern and str, I thought it would be nice to have them behave the same way. e.g.:

(re-pattern (apply str (map (partial format "%s{%s}") [\a \b \c \d \e] (iterate inc 1))))
would become
(apply re-pattern (map (partial format "%s{%s}") [\a \b \c \d \e] (iterate inc 1)))

It only save one call to str, so it might not warrant the extra code in the end.



 Comments   
Comment by Assembla Importer [ 28/Sep/10 7:06 AM ]

Converted from http://www.assembla.com/spaces/clojure/tickets/238
Attachments:
0001-Changed-re-pattern-to-accept-multiple-arguments-to-c.patch - https://www.assembla.com/spaces/clojure/documents/barzR2-Jyr3OGheJe5aVNr/download/barzR2-Jyr3OGheJe5aVNr

Comment by Assembla Importer [ 28/Sep/10 7:06 AM ]

richhickey said: Could you please put an example of what the enhancement would let you do, in the description? Thanks.

Comment by Assembla Importer [ 28/Sep/10 7:06 AM ]

richhickey said: I don't see the need for this





[CLJ-237] Adding a :only-keys destructuring option, that throws an exception if there's extra key(s). Created: 01/Jan/10  Updated: 17/Feb/12  Resolved: 17/Feb/12

Status: Closed
Project: Clojure
Component/s: None
Affects Version/s: None
Fix Version/s: Backlog

Type: Enhancement
Reporter: Anonymous Assignee: Nicolas Buduroi
Resolution: Declined Votes: 0
Labels: None


 Description   

While discussing the issue that prompted ticket [[ticket:236]] on clojure-dev, Richard Newman suggested modifying map destructuring to incorporate a :only-keys. It works exactly like :keys but raises an exception if the destructured map contains other keys. The attached patch shows a possible implementation.



 Comments   
Comment by Assembla Importer [ 28/Sep/10 7:05 AM ]

Converted from http://www.assembla.com/spaces/clojure/tickets/237
Attachments:
0001-Added-only-keys-destructuring-option-like-keys-but-t.patch - https://www.assembla.com/spaces/clojure/documents/bEnEvg-I4r3OA7eJe5afGb/download/bEnEvg-I4r3OA7eJe5afGb

Comment by Assembla Importer [ 28/Sep/10 7:05 AM ]

budu said: [file:bEnEvg-I4r3OA7eJe5afGb]: Add :only-keys destructuring option

Comment by Assembla Importer [ 28/Sep/10 7:05 AM ]

richhickey said: Could someone please review this patch? I'm ok with the idea in general, but it seems strange that the :only test would only be available for (non-renaming) :keys destructuring

Comment by Assembla Importer [ 28/Sep/10 7:05 AM ]

chouser@n01se.net said: One drawback to any such checking is it may prevent code written for a future version of the function that takes more named args from working at all with a previous version of the function. For example 'ref' now accepts :min-history. Code that uses that now would probably work fine with versions of ref that didn't support that knob, but if they checked to prevent extra args they would fail unnecessarily.

Comment by Assembla Importer [ 28/Sep/10 7:05 AM ]

budu said: Good point, didn't think about that! We could recommend the use of :keys in early development and :only-keys when APIs become very stable.

Comment by Assembla Importer [ 28/Sep/10 7:05 AM ]

richhickey said: I don't see the need for this

Comment by Stuart Sierra [ 17/Feb/12 2:15 PM ]

Declined. There has been limited support for this ticket. It changes the concept of destructuring to include something more like validation, which it was not intended to support.





[CLJ-212] Direct linking breaks clojure.contrib.repl-ln. Created: 30/Nov/09  Updated: 24/Aug/10  Resolved: 24/Aug/10

Status: Closed
Project: Clojure
Component/s: None
Affects Version/s: None
Fix Version/s: Backlog

Type: Defect
Reporter: Anonymous Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: None


 Description   

Direct linking (commit 4d08439a9cf79f34a730714f12edd5959aae126e) breaks clojure.contrib.repl-ln.

To reproduce, run the following in the standard REPL:
(require 'clojure.contrib.repl-ln) (clojure.contrib.repl-ln/repl)

Expected output (obtained with commit 98366f353463afdc195b9b8fdf9d220bca7d0d6a):
nil
1:2 user=>

Result with commit 4d08439a9cf79f34a730714f12edd5959aae126e:
nil
java.lang.NullPointerException (NO_SOURCE_FILE:0)

The NullPointerException happens in clojure.contrib.repl-ln/prompt-hook where (private :prompt) returns nil.



 Comments   
Comment by Assembla Importer [ 24/Aug/10 5:22 AM ]

Converted from http://www.assembla.com/spaces/clojure/tickets/212





[CLJ-211] Support arbitrary functional destructuring via -> and ->> Created: 17/Nov/09  Updated: 27/Jul/13

Status: In Progress
Project: Clojure
Component/s: None
Affects Version/s: None
Fix Version/s: Backlog

Type: Enhancement Priority: Minor
Reporter: Assembla Importer Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None

Approval: Vetted

 Description   

Support arbitrary functional destructuring, that is the use of
any function in any destructuring form to help unpack data in
arbitrary ways.

The discussion began here:
http://clojure-log.n01se.net/date/2009-11-17.html#09:31c

The attached patch implements the spec described here:
http://clojure-log.n01se.net/date/2009-11-17.html#10:50a

That is, the following examples would now work:

user=> (let [(-> str a) 1] a)
"1"

user=> (let [[a (-> str b) c] [1 2]] (list a b c))
(1 "2" nil)

user=> (let [(->> (map int) [a b]) "ab"] (list a b))
(97 98)



 Comments   
Comment by Assembla Importer [ 28/Sep/10 6:57 AM ]

Converted from http://www.assembla.com/spaces/clojure/tickets/211
Attachments:
destructuring-fns.diff - https://www.assembla.com/spaces/clojure/documents/aHWQ_W06Kr3O89eJe5afGb/download/aHWQ_W06Kr3O89eJe5afGb

Comment by Assembla Importer [ 28/Sep/10 6:57 AM ]

chouser@n01se.net said: [file:aHWQ_W06Kr3O89eJe5afGb]: [PATCH] Support -> and ->> in destructuring forms.

Comment by Assembla Importer [ 28/Sep/10 6:57 AM ]

cgrand said: I think the current patch suffers from the problem described here http://groups.google.com/group/clojure-dev/msg/80ba7fad2ff04708 too.

Comment by Assembla Importer [ 28/Sep/10 6:57 AM ]

richhickey said: so, don't use syntax-quote, just use clojure.core/->

Comment by Assembla Importer [ 28/Sep/10 6:57 AM ]

chouser@n01se.net said: Only -> and ->> are actually legal here anyway – if you've locally bound foo to -> there's not really any good reason to think (fn [(foo inc a)] a) should work. And if you've redefined -> or ->> to mean something else in your ns, do we need to catch that at compile time, or is it okay to emit the rearranged code and see what happens?

In short, would '#{> ->> clojure.core/> clojure.core/->>} be sufficient?

Comment by Assembla Importer [ 28/Sep/10 6:57 AM ]

cgrand said: Only -> and ->> are legal here but what if they are aliased or shadowed? Instead of testing the symboil per se I would check, if:

  • the symbol is not in &env
  • the symbol resolve to #'clojure.core/> or #'clojure.core/>>
(when-not (&env (first b)) (#{#'clojure.core/-> #'clojure.core/->>} (resolve (first b))))

but it requires to change destructure's sig to pass the env around

Comment by Stuart Halloway [ 03/Dec/10 1:03 PM ]

Rich: Are you assigned to this by accident? If so, please deassign yourself.





[CLJ-178] Reloading core.clj from REPL fails with print-method exception Created: 24/Aug/09  Updated: 26/Jul/13  Resolved: 28/Sep/10

Status: Closed
Project: Clojure
Component/s: None
Affects Version/s: None
Fix Version/s: Backlog

Type: Defect
Reporter: Anonymous Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: None


 Description   

Example REPL session:

(in-ns 'clojure.core)
(def source-file "/path/to/clojure/src/clj/clojure/core.clj")
(load-string (slurp source-file))
</code></pre>

Result:
<pre><code>
java.lang.IllegalArgumentException: No method in multimethod 'print-method' for dispatch value: class clojure.lang.Var
Exception in thread "main" java.lang.IllegalArgumentException: No method in multimethod 'print-method' for dispatch value: class java.lang.String
        at clojure.lang.MultiFn.getFn(MultiFn.java:115)
        at clojure.lang.MultiFn.invoke(MultiFn.java:161)
        at clojure.core$pr_on__1315.invoke(Unknown Source)
        at clojure.core$pr__1318.invoke(Unknown Source)
        at clojure.lang.AFn.applyToHelper(AFn.java:173)
        at clojure.lang.RestFn.applyTo(RestFn.java:137)
        at clojure.core$apply__183.doInvoke(Unknown Source)
        at clojure.lang.RestFn.invoke(RestFn.java:428)
        at clojure.core$print__1332.doInvoke(Unknown Source)
        at clojure.lang.RestFn.invoke(RestFn.java:413)
        at clojure.core$printf__2285.doInvoke(Unknown Source)
        at clojure.lang.RestFn.invoke(RestFn.java:428)
        at clojure.main$repl_prompt__6713.invoke(main.clj:41)
        at clojure.main$repl__6737.doInvoke(main.clj:199)
        at clojure.lang.RestFn.invoke(RestFn.java:426)
        at clojure.main$repl_opt__6777.invoke(main.clj:251)
        at clojure.main$main__6812.doInvoke(main.clj:338)
        at clojure.lang.RestFn.invoke(RestFn.java:402)
        at clojure.lang.Var.invoke(Var.java:355)
        at clojure.lang.AFn.applyToHelper(AFn.java:171)
        at clojure.lang.Var.applyTo(Var.java:476)
        at clojure.main.main(main.java:37)


 Comments   
Comment by Assembla Importer [ 28/Sep/10 3:34 PM ]

Converted from http://www.assembla.com/spaces/clojure/tickets/178

Comment by Assembla Importer [ 28/Sep/10 3:34 PM ]

stu said: Core is special, and it may be that this is not possible in general (across all combinations of source/compilation that could be extant on the classpath). Here's what I get with today's master:

java.lang.IllegalArgumentException: Can't define method not in interfaces: nth (gvec.clj:83)
Comment by Assembla Importer [ 28/Sep/10 3:34 PM ]

stu said: Notes:

  • Moving print-initialized to the top of core.clj does not fix this problem
  • You can avoid this problem by putting the clojure src and classes directories (and not the compiled clojure.jar on your classpath), and compiling only the java bits
  • Disregard my previous comment, that was local weirdness in my environment.

I am ok with the workaround but if there is an easy fix let's make it.

Comment by Assembla Importer [ 28/Sep/10 3:34 PM ]

richhickey said: works in 1.3 master





[CLJ-176] structs printed with *print-dup* true cannot be read Created: 18/Aug/09  Updated: 24/Aug/10  Resolved: 24/Aug/10

Status: Closed
Project: Clojure
Component/s: None
Affects Version/s: None
Fix Version/s: Backlog

Type: Defect
Reporter: Anonymous Assignee: Unassigned
Resolution: Declined Votes: 0
Labels: None


 Description   
(defstruct thing :a :b)
(def my-thing (struct thing 1 2))
(def s (binding [*print-dup* true] (pr-str my-thing)))
s 
;;=> "#=(clojure.lang.PersistentStructMap/create {:a 1, :b 2})"
(read-string s)
;;=> java.lang.IllegalArgumentException:
;;   No matching method found: create


 Comments   
Comment by Assembla Importer [ 24/Aug/10 6:14 AM ]

Converted from http://www.assembla.com/spaces/clojure/tickets/176

Comment by Assembla Importer [ 24/Aug/10 6:14 AM ]

stu said: This is not going to be fixed in the short or medium term. Please ping me if you have a compelling use case though.





[CLJ-147] Bug: Compile-time NPE on set! of non-existent field [for 1.0] Created: 09/Jul/09  Updated: 15/Nov/10  Resolved: 12/Nov/10

Status: Closed
Project: Clojure
Component/s: None
Affects Version/s: None
Fix Version/s: Backlog

Type: Defect
Reporter: Anonymous Assignee: Unassigned
Resolution: Duplicate Votes: 0
Labels: None


 Description   

The bug described in #142 also exists in Clojure 1.0.0



 Comments   
Comment by Assembla Importer [ 24/Aug/10 6:54 AM ]

Converted from http://www.assembla.com/spaces/clojure/tickets/147

Comment by Assembla Importer [ 24/Aug/10 6:54 AM ]

chouser@n01se.net said: Parent association with ticket #142 was added

Comment by Alexander Redington [ 12/Nov/10 10:07 AM ]

This duplicate of #142 has been resolved.

Latest from head:

user=> (set! (.foo "fred") 47)
IllegalArgumentException No matching field found: foo for class java.lang.String clojure.lang.Reflector.setInstanceField (Reflector.java:257)
user=>





[CLJ-132] Agents printed at the REPL do not always reflect their value Created: 19/Jun/09  Updated: 24/Aug/10  Resolved: 24/Aug/10

Status: Closed
Project: Clojure
Component/s: None
Affects Version/s: None
Fix Version/s: Backlog

Type: Defect
Reporter: Anonymous Assignee: Unassigned
Resolution: Declined Votes: 0
Labels: None


 Description   

Starting with a fresh REPL and entering the following:

(def counter (agent 0))
(defn add1 [x] (inc x))
(send counter add1)
;; repeat many times
(send counter add1)

The representation printed at the REPL will not always display the correct value for the agent (e.g. the second call to `send` would print #<Agent@743fba: 1>). This appears to happen only in the first few calls to `send` before the value eventually "catches up". This behavior of course never occurs with `send-off`. This appears to only affect the printed value and not the actual value, but can still cause confusion.

My setup is as follows:
Mac OSX 10.5
Clojure 1.0.0
Running with `java -server -cp $CP jline.ConsoleRunner clojure.lang.Repl $*` where $CP points to clojure.jar, clojure-contrib.jar, and jline.jar

This also occurs with a fresh build of Clojure 1.1.0-alpha-SNAPSHOT from github.

-m



 Comments   
Comment by Assembla Importer [ 24/Aug/10 7:46 AM ]

Converted from http://www.assembla.com/spaces/clojure/tickets/132

Comment by Assembla Importer [ 24/Aug/10 7:46 AM ]

stu said: I don't think this is a bug – there is no "correct value for the agent" as seen from the calling thread. There is a race condition when viewing agents at the REPL, and this is by design.

Comment by Assembla Importer [ 24/Aug/10 7:46 AM ]

fogus said: I understand why it happens, but it might be worthwhile to at least document this condition and/or consider removing the print of the value. In some cases reporting nothing is better than potentially incorrect information. Or is it enough to just say, "it's correct eventually or at least most of the time"?

-m





[CLJ-122] GC Issue 118: Patch to add :svn to *clojure-version* Created: 17/Jun/09  Updated: 24/Aug/10  Resolved: 24/Aug/10

Status: Closed
Project: Clojure
Component/s: None
Affects Version/s: None
Fix Version/s: Backlog

Type: Defect
Reporter: Anonymous Assignee: Unassigned
Resolution: Declined Votes: 0
Labels: None


 Description   
Reported by miki.tebeka, May 16, 2009

Attached is a patch to add :svn to *clojure-version*.
In order for it to work do "svn ps svn:keywords Revision
src/clj/clojure/core.clj"

This way when people report problem in clojure, we can know the exact
revision they are talking about.


 Comments   
Comment by Assembla Importer [ 24/Aug/10 6:45 AM ]

Converted from http://www.assembla.com/spaces/clojure/tickets/122
Attachments:
clojure.diff - https://www.assembla.com/spaces/clojure/documents/dXnrtCw4qr3RbzeJe5afGb/download/dXnrtCw4qr3RbzeJe5afGb

Comment by Assembla Importer [ 24/Aug/10 6:45 AM ]

oranenj said: [file:dXnrtCw4qr3RbzeJe5afGb]

Comment by Assembla Importer [ 24/Aug/10 6:45 AM ]

richhickey said: Updating tickets (#8, #19, #30, #31, #126, #17, #42, #47, #50, #61, #64, #69, #71, #77, #79, #84, #87, #89, #96, #99, #103, #107, #112, #113, #114, #115, #118, #119, #121, #122, #124)





[CLJ-121] GC Issue 117: FAQ Page has formatting errors Created: 17/Jun/09  Updated: 13/Apr/12  Resolved: 13/Apr/12

Status: Closed
Project: Clojure
Component/s: None
Affects Version/s: None
Fix Version/s: Backlog

Type: Defect Priority: Minor
Reporter: Assembla Importer Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: None

Approval: Vetted

 Description   
Reported by miki.tebeka, May 13, 2009

The FAQ page (http://code.google.com/p/clojure/wiki/FAQ) has several
formatting errors:

* "How do I call a Java method that takes a variable number of arguments?"
is missing a space to make it a header.
* The link to SICP showing the URL


 Comments   
Comment by Assembla Importer [ 24/Aug/10 6:45 AM ]

Converted from http://www.assembla.com/spaces/clojure/tickets/121

Comment by Assembla Importer [ 24/Aug/10 6:45 AM ]

richhickey said: Updating tickets (#8, #19, #30, #31, #126, #17, #42, #47, #50, #61, #64, #69, #71, #77, #79, #84, #87, #89, #96, #99, #103, #107, #112, #113, #114, #115, #118, #119, #121, #122, #124)

Comment by Stuart Halloway [ 03/Dec/10 11:56 AM ]

Can I move the FAQ over the Confluence, and then change the old Google code page to link over?

Comment by Rich Hickey [ 03/Dec/10 11:58 AM ]

Yes, thanks





[CLJ-120] GC Issue 116: partition with pad Created: 17/Jun/09  Updated: 02/Dec/11  Resolved: 02/Dec/11

Status: Closed
Project: Clojure
Component/s: None
Affects Version/s: None
Fix Version/s: Backlog

Type: Enhancement
Reporter: Anonymous Assignee: Stephen C. Gilardi
Resolution: Declined Votes: 0
Labels: None


 Description   
Reported by dimi...@gashinsky.com, May 09, 2009

;; A lot of times I needed a padding option on the partition. This is
;; my attempt to solve this problem. Any suggestions are welcome. I
;; hope this patch or something similar will make its way into the
;; core.

Some discussion that happened here:
http://groups.google.com/group/clojure/browse_frm/thread/6fcc1dd999a5ec02?tvc=1
was integrated into the patch.


 Comments   
Comment by Assembla Importer [ 28/Sep/10 7:52 AM ]

Converted from http://www.assembla.com/spaces/clojure/tickets/120
Attachments:
partition-with-pad.patch - https://www.assembla.com/spaces/clojure/documents/ctfCdww4qr3RbzeJe5afGb/download/ctfCdww4qr3RbzeJe5afGb
part.clj - https://www.assembla.com/spaces/clojure/documents/ckiilEyzqr3PTqeJe5afGb/download/ckiilEyzqr3PTqeJe5afGb
part.clj - https://www.assembla.com/spaces/clojure/documents/dmo9mEyzWr3QuceJe5aVNr/download/dmo9mEyzWr3QuceJe5aVNr
partition-with-pad-2.diff - https://www.assembla.com/spaces/clojure/documents/bolonky_8r3RY8eJe5afGb/download/bolonky_8r3RY8eJe5afGb
ticket-120.patch - https://www.assembla.com/spaces/clojure/documents/bnWYoqzBKr3RKeeJe5afGb/download/bnWYoqzBKr3RKeeJe5afGb

Comment by Assembla Importer [ 28/Sep/10 7:52 AM ]

oranenj said: [file:ctfCdww4qr3RbzeJe5afGb]

Comment by Assembla Importer [ 28/Sep/10 7:52 AM ]

chouser@n01se.net said: It looks to me like the 3- and 4-arg bodies could be combined resulting in less code and no significant loss of performance. A pad of nil could be treated the same as no pad supplied, which would be different from a numeric pad (including 0).

Comment by Assembla Importer [ 28/Sep/10 7:52 AM ]

scgilardi said: By "combined" do you mean that the 3 argument version should call the 4 argument version with an explicit pad of nil?

Currently, the 3 argument version does no padding. Instead it stops as soon as there are less than n args left:

user=> (partition 3 [1 2 3 4])
((1 2 3))
</code></pre>

In contrast, the 4 argument version with a pad of nil produces (untested):
<pre><code>user=> (partition 3 nil [1 2 3 4])
((1 2 3) (4 nil nil))

Interpreting nil passed to the 4 argument version as a request to get the behavior of the 3 argument version looks wrong to me. There would be no way to express both a desire for padding and that the padding value should be nil.

Comment by Assembla Importer [ 28/Sep/10 7:52 AM ]

scgilardi said: Looking into the issue further, I see I made a mistake in my previous comment. The padding is given as a sequence, not a value. However, the key difference between the 3 and 4 arg versions remains. The 3 argument version never returns a "short" sequence at the end. The 4 arg version can.

Along the lines of your suggestion, we could combine the two by changing the 4 arg version to interpret a pad value of "[]" to mean "return a short sequence at the end if necessary" and a pad value of "nil" to mean "never return a short sequence". This would involve interpreting "nil" different from "the empty sequence" where in many other contexts they're equivalent. I'm not sure whether or not saving some code is a good trade for introducing that subtle difference.

Comment by Assembla Importer [ 28/Sep/10 7:52 AM ]

chouser@n01se.net said: I had also mistaken pad to be a number. I think you're right, producing different behavior when pad is an empty seq vs. nil is just asking for trouble. Thanks for taking a second look.

Comment by Assembla Importer [ 28/Sep/10 7:52 AM ]

importer said: (In [[r:e0e8326871983be5615f5c0bc9dbf66140c7017f]]) add optional pad argument to partition. Fixes #120

Signed-off-by: Chouser <chouser@n01se.net>

Branch: master

Comment by Assembla Importer [ 28/Sep/10 7:52 AM ]

digash said: The original version was using nil but Rich suggested not do it that way.
For different revisions take a look at this gist http://gist.github.com/109002

Comment by Assembla Importer [ 28/Sep/10 7:52 AM ]

chouser@n01se.net said: Thanks for that link. Your final solution (not using nil) is already committed, but we should get those tests into clojure-test once it's location has been settled.

Comment by Assembla Importer [ 28/Sep/10 7:52 AM ]

richhickey said: The new partition has this behavior:

user=> (partition 3 1 nil (range 10))
((0 1 2) (1 2 3) (2 3 4) (3 4 5) (4 5 6) (5 6 7) (6 7 8) (7 8 9) (8 9))
user=> (partition 3 1 [42] (range 10))
((0 1 2) (1 2 3) (2 3 4) (3 4 5) (4 5 6) (5 6 7) (6 7 8) (7 8 9) (8 9 42))

It seems to me that with a step of one it should never use the pad, and, more generally, once it has produced one partition containing the last element of the coll it should be done.

Comment by Assembla Importer [ 28/Sep/10 7:52 AM ]

richhickey said: An alternative rule is that every step within the supplied coll is yielded, padding as supplied, which would mean ending with:

(7 8 9) (8 9) (9)
(7 8 9) (8 9 42) (9 42)
Comment by Assembla Importer [ 28/Sep/10 7:52 AM ]

scgilardi said: [file:ckiilEyzqr3PTqeJe5afGb]: proposed alternative (see my comment)

Comment by Assembla Importer [ 28/Sep/10 7:52 AM ]

scgilardi said: I've uploaded part.clj which is another possible alternative. It handles a step of 1 without using the pad. Some invariants in the partitions it produces for the 4 argument case:

  • for a step size of n, if you provide n - 1 objects in the padding sequence, all output sequences will be of size n
  • for a step size n, the output sequences will begin with elements at offsets 0, n, 2n, 3n, ... in the original sequence until no such element exists.

Some outputs:

user=> (part/partition 3 1 nil (range 10))
((0 1 2) (1 2 3) (2 3 4) (3 4 5) (4 5 6) (5 6 7) (6 7 8) (7 8 9))
user=> (part/partition 3 1 [42] (range 10))
((0 1 2) (1 2 3) (2 3 4) (3 4 5) (4 5 6) (5 6 7) (6 7 8) (7 8 9))
---
user=> (part/partition 3 2 nil (range 9))
((0 1 2) (2 3 4) (4 5 6) (6 7 8) (8))
user=>  (part/partition 3 2 [42] (range 9))
((0 1 2) (2 3 4) (4 5 6) (6 7 8) (8 42))
user=> (part/partition 3 2 [42 43] (range 9))
((0 1 2) (2 3 4) (4 5 6) (6 7 8) (8 42 43))
---
user=> (part/partition 3 4 nil (range 6))
((0 1 2) (4 5))
user=> (part/partition 3 4 nil (range 7))
((0 1 2) (4 5 6))
user=> (part/partition 3 4 nil (range 8))
((0 1 2) (4 5 6))
user=> (part/partition 3 4 nil (range 9))
((0 1 2) (4 5 6) (8))
---
user=> (part/partition 3 3 [42 43] (range 3))
((0 1 2))
user=> (part/partition 3 3 [42 43] (range 4))
((0 1 2) (3 42 43))
user=> (part/partition 3 3 [42 43] (range 5))
((0 1 2) (3 4 42))
user=> (part/partition 3 3 [42 43] (range 6))
((0 1 2) (3 4 5))
user=> (part/partition 3 3 [42 43] (range 7))
((0 1 2) (3 4 5) (6 42 43))
</code></pre>

Here's the relevant portion of the code:

<pre><code>  ([n step pad coll]
     (lazy-seq
      (when-let [s (seq coll)]
        (let [p (take n s)]
          (cond (= n (count p))
                (cons p (partition n step pad (drop step s)))
                (>= step (count p))
                (list (take n (concat p pad)))))))))

Please see part.clj for details and a test program.

Comment by Assembla Importer [ 28/Sep/10 7:52 AM ]

scgilardi said: Ugh, the second "invariant" I listed doesn't hold for step = 1. It appears to hold for other step values. Perhaps part.clj will still be useful to someone in coming up with a better solution.

Comment by Assembla Importer [ 28/Sep/10 7:52 AM ]

richhickey said: I don't see why step of 1 should get special treatment. If the rule is the second one (yield partitions as long as step offsets are present in original coll), then

(part/partition 3 1 nil (range 10))
should end with:
(7 8 9) (8 9) (9)
Comment by Assembla Importer [ 28/Sep/10 7:52 AM ]

scgilardi said: This one appears to work:

([n step pad coll]
     (lazy-seq
      (when-let [s (seq coll)]
        (cons
         (take n (concat s pad))
         (partition n step pad (drop step s)))))))
</code></pre>

<pre><code>user=> (run part)
n = 3, pad = nil
:max 5 :step 1 ((0 1 2) (1 2 3) (2 3 4) (3 4) (4))
:max 6 :step 1 ((0 1 2) (1 2 3) (2 3 4) (3 4 5) (4 5) (5))
:max 7 :step 1 ((0 1 2) (1 2 3) (2 3 4) (3 4 5) (4 5 6) (5 6) (6))
:max 8 :step 1 ((0 1 2) (1 2 3) (2 3 4) (3 4 5) (4 5 6) (5 6 7) (6 7) (7))
:max 9 :step 1 ((0 1 2) (1 2 3) (2 3 4) (3 4 5) (4 5 6) (5 6 7) (6 7 8) (7 8) (8))

:max 5 :step 2 ((0 1 2) (2 3 4) (4))
:max 6 :step 2 ((0 1 2) (2 3 4) (4 5))
:max 7 :step 2 ((0 1 2) (2 3 4) (4 5 6) (6))
:max 8 :step 2 ((0 1 2) (2 3 4) (4 5 6) (6 7))
:max 9 :step 2 ((0 1 2) (2 3 4) (4 5 6) (6 7 8) (8))

:max 5 :step 3 ((0 1 2) (3 4))
:max 6 :step 3 ((0 1 2) (3 4 5))
:max 7 :step 3 ((0 1 2) (3 4 5) (6))
:max 8 :step 3 ((0 1 2) (3 4 5) (6 7))
:max 9 :step 3 ((0 1 2) (3 4 5) (6 7 8))

:max 5 :step 4 ((0 1 2) (4))
:max 6 :step 4 ((0 1 2) (4 5))
:max 7 :step 4 ((0 1 2) (4 5 6))
:max 8 :step 4 ((0 1 2) (4 5 6))
:max 9 :step 4 ((0 1 2) (4 5 6) (8))

n = 3, pad = [42 43]
:max 5 :step 1 ((0 1 2) (1 2 3) (2 3 4) (3 4 42) (4 42 43))
:max 6 :step 1 ((0 1 2) (1 2 3) (2 3 4) (3 4 5) (4 5 42) (5 42 43))
:max 7 :step 1 ((0 1 2) (1 2 3) (2 3 4) (3 4 5) (4 5 6) (5 6 42) (6 42 43))
:max 8 :step 1 ((0 1 2) (1 2 3) (2 3 4) (3 4 5) (4 5 6) (5 6 7) (6 7 42) (7 42 43))
:max 9 :step 1 ((0 1 2) (1 2 3) (2 3 4) (3 4 5) (4 5 6) (5 6 7) (6 7 8) (7 8 42) (8 42 43))

:max 5 :step 2 ((0 1 2) (2 3 4) (4 42 43))
:max 6 :step 2 ((0 1 2) (2 3 4) (4 5 42))
:max 7 :step 2 ((0 1 2) (2 3 4) (4 5 6) (6 42 43))
:max 8 :step 2 ((0 1 2) (2 3 4) (4 5 6) (6 7 42))
:max 9 :step 2 ((0 1 2) (2 3 4) (4 5 6) (6 7 8) (8 42 43))

:max 5 :step 3 ((0 1 2) (3 4 42))
:max 6 :step 3 ((0 1 2) (3 4 5))
:max 7 :step 3 ((0 1 2) (3 4 5) (6 42 43))
:max 8 :step 3 ((0 1 2) (3 4 5) (6 7 42))
:max 9 :step 3 ((0 1 2) (3 4 5) (6 7 8))

:max 5 :step 4 ((0 1 2) (4 42 43))
:max 6 :step 4 ((0 1 2) (4 5 42))
:max 7 :step 4 ((0 1 2) (4 5 6))
:max 8 :step 4 ((0 1 2) (4 5 6))
:max 9 :step 4 ((0 1 2) (4 5 6) (8 42 43))

nil
user=>
Comment by Assembla Importer [ 28/Sep/10 7:52 AM ]

scgilardi said: [file:dmo9mEyzWr3QuceJe5aVNr]: improved version

Comment by Assembla Importer [ 28/Sep/10 7:52 AM ]

richhickey said: This looks fine to me, do you want to make up a patch Steve?

Comment by Assembla Importer [ 28/Sep/10 7:52 AM ]

scgilardi said: [file:bolonky_8r3RY8eJe5afGb]: modified per comments

Comment by Assembla Importer [ 28/Sep/10 7:52 AM ]

scgilardi said: The patch includes and updated doc string, the new 4 argument case, and a change to the whitespace in the 3 argument case for consistent indentation with the 4 argument case (current emacs clojure-mode). I can provide a patch that doesn't touch the 3 argument case whitespace if desired.

Comment by Assembla Importer [ 28/Sep/10 7:52 AM ]

richhickey said: I think the doc should be even more explicit, something like:

... do not overlap. If no pad argument is supplied, will produce only complete partitions of size n, possibly not including items at the end if the size of coll is not a multiple of n. If the pad argument is supplied, will produce a partition at every offset present in the supplied collection, using the pad elements as necessary to pad trailing partitions up to n items each. If pad is nil or a collection containing fewer than n-1 items, ...

Comment by Assembla Importer [ 28/Sep/10 7:52 AM ]

scgilardi said: How about this:

"Returns a lazy seq of lazy subseqs of coll, each of (nominally) n
  items. The subseqs begin at offsets 0, step, 2*step, etc. in coll. If
  step is not supplied, it defaults to n yielding adjacent, non-overlapping
  subseqs. If pad is not supplied, produces only complete subseqs of n
  items, possibly not including some items at the end of coll. If pad is
  supplied, produces a subseq at every offset present in coll, using any
  available items from pad to pad shorter subseqs up to n items. If pad is
  a seq of at least n-1 items, produces only complete padded subseqs of n
  items. If pad is shorter (or nil) trailing padded subseqs may be
  shorter."

I adopted the mathematical terminology that the partition is the operation (the division into parts) and that the individual pieces are not "partitions", but something else: part, block, chunk, or as I propose here, subseq. I like subseq because it embodies succinctly the fact that the items from coll are always kept sequential.

Comment by Assembla Importer [ 28/Sep/10 7:52 AM ]

richhickey said: I'm now convinced we are cramming 2 functions into one, and would prefer to see this new functionality as a new function:

(take-subs n coll)
(take-subs n step coll)

'padding' isn't a necessary concept, as we have concat. take implies the possible partial subseqs. Also take-subs can yield a lazy seq of lazy seqs, but partition can't.

Comment by Assembla Importer [ 28/Sep/10 7:52 AM ]

scgilardi said: [file:bnWYoqzBKr3RKeeJe5afGb]: take-subs + tests

Comment by Assembla Importer [ 28/Sep/10 7:52 AM ]

scgilardi said: OK, paddiing isn't necessary because the same thing can be accomplished by using concat to append a padding sequence of exactly n-1 items to coll before processing it with partition.

partition can't return lazy subseqs because it counts them which (in the general case) will realize them.

ticket-120.patch contains modified docs for partition, removed arity 4 case from partition, take-subs implemented, tests for take-subs based on tests for partition, enhanced one sub-test for partition.

Comment by Assembla Importer [ 28/Sep/10 7:52 AM ]

digash said: I like the new take-subs, but I cannot figure out how to use concat instead of partition without counting it and realizing the whole sequence.
The initial motivation was to use partition with destructuring and creating matrix from a sequences. I do not see an easy way to reproduce this case with the new implementation.

The old implementation:
(for [[a b c] (partition 3 3 (repeat 0) [1 2 3 4])] [a b c]) ==> ([1 2 3] [4 0 0])

The new implementation:
(take 10 (let [coll [1 2 3 4] p 3] (take (/ (count coll) p) (for [[a b c] (take-subs p (concat coll (repeat 0)))] [a b c])))) ==> ([1 2 3] [4 0 0])

Comment by Assembla Importer [ 28/Sep/10 7:52 AM ]

scgilardi said: Here are two options for how I would write the example using the most recent patch:

user=> (for [[a b c] (partition 3 (concat [1 2 3 4] (take 3 (repeat 0))))] [a b c])
([1 2 3] [4 0 0])
user=> (for [[a b c] (partition 3 (concat [1 2 3 4] [0 0 0]))] [a b c])
([1 2 3] [4 0 0])
user=> 
</code></pre>or in the general case:
<pre><code>user=> (defn padded-partition
[n pad coll]
(partition n (concat coll (take (dec n) pad))))
#'user/padded-partition
user=> (for [[a b c] (padded-partition 3 (repeat 0) [1 2 3 4])] [a b c])
([1 2 3] [4 0 0])
user=>
Comment by Assembla Importer [ 28/Sep/10 7:52 AM ]

scgilardi said: My first code example above was incorrect. For proper operation with all combinations of n and step, the concatenated padding seq needs to be exactly n-1 in length.

Here's the correction:

user=> (for [[a b c] (partition 3 (concat [1 2 3 4] (take 2 (repeat 0))))] [a b c])
([1 2 3] [4 0 0])
user=> (for [[a b c] (partition 3 (concat [1 2 3 4] [0 0]))] [a b c])
([1 2 3] [4 0 0])
user=>
Comment by Chouser [ 18/Nov/11 11:20 PM ]

partition has a pad argument now. Can this be closed?

Comment by Stuart Halloway [ 02/Dec/11 12:17 PM ]

partition has pad now





[CLJ-118] GC Issue 114: version.properties in branch/1.0 is inaccurate Created: 17/Jun/09  Updated: 20/Jul/12  Resolved: 20/Jul/12

Status: Closed
Project: Clojure
Component/s: None
Affects Version/s: None
Fix Version/s: Backlog

Type: Enhancement
Reporter: Anonymous Assignee: Unassigned
Resolution: Declined Votes: 0
Labels: None


 Description   
Reported by hlship, May 04, 2009

The version.properties in the 1.0 branch generates snapshot releases.
Ideally, there should be a tags/1.0 branch that locks down the 1.0 release.
Context: trying to build a 1.0 release artifact for the Maven repository.

Comment 1 by richhickey, May 04, 2009

Do you believe this advice was erroneous?

http://groups.google.com/group/clojure/msg/cb46994561dbc732

Comment 2 by hlship, May 05, 2009

I'm bothered that the 1.0 release is a 1.0 release, but not really.  Either its a
final release or its not. Saying its still a snapshot when you've broadcasted to the
world that its final seems very odd to me.

On the mailing list, I espoused the "Apache Way", which is to not get hung up on a
"1.0.0" number, but keep releasing.  If "1.0.2" has bugs, fix them and release
"1.0.3".  If that is finally stable, announce "Clojure 1.0 is version 1.0.3". Let the
release prove itself valid.

Older Tapestry releases were based on the "line in the sand" approach ... and always
ended up requiring a flurry of dot release bug fixes.


 Comments   
Comment by Assembla Importer [ 24/Aug/10 3:45 AM ]

Converted from http://www.assembla.com/spaces/clojure/tickets/118

Comment by Assembla Importer [ 24/Aug/10 3:45 AM ]

richhickey said: Updating tickets (#8, #19, #30, #31, #126, #17, #42, #47, #50, #61, #64, #69, #71, #77, #79, #84, #87, #89, #96, #99, #103, #107, #112, #113, #114, #115, #118, #119, #121, #122, #124)





[CLJ-114] GC Issue 110: clojure version number patch Created: 17/Jun/09  Updated: 24/Aug/10  Resolved: 24/Aug/10

Status: Closed
Project: Clojure
Component/s: None
Affects Version/s: None
Fix Version/s: Backlog

Type: Defect
Reporter: Anonymous Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: None


 Description   
Reported by laurent....@gmail.com, Apr 26, 2009

Patch with the necessary changes to handle version numbering for clojure:

 * a src/clj/clojure/version.properties file
 * this version.properties file is the reference for version numbers. It is
on the classpath so it can be seen by clojure at runtime. It is in a
subdirectory of clojure-the-project so any tool can refer to it relatively
to the installation of clojure.

 * I've added the necessary code to clojure to load clojure version number
at startup time


I've also added function (clojure.core/clojure-version) that will return a
string representing the version from the structured *clojure-version* map.
The algorithm here is simple: 
<MAJOR>.<MINOR>[.<INCREMENT>][-<QUALIFIER>][-SNAPSHOT]

 * I've changed the ant build.xml so that it creates fully qualified names
with version attributes for the generated jars.
 * Note on the :interim attribute: to protect the person who makes releases
from itself, instead of considering :interim to be true if there is the
"true" string in the properties file, I've made the opposite choice:
interim is true for any value other than "false". So if there is a typo in
version.properties (e.g. tru instead of true), then the release will be
marked as interim, and that will not be a big deal. In the other case, it
would be a big deal if an official release was made accidentally instead of
an interim.

* finally, pom.xml file is now generated from ant as part of the classic
init step.

Note: I strongly suggest that the clojure.version.interim property remains
true in svn, so that it's not possible to inadvertently release a version
"too early".

Comment 1  by richhickey, Apr 27, 2009

I can't apply the patch due to missing pom-template.xml?

Also, could you just put the contents of core_version.clj into core.clj? I'd rather
not have another file just for this.

Thanks!

Comment 2 by laurent....@gmail.com, Apr 27, 2009

OK, core_version.clj content back into core.clj.

There was a problem with pom-template.xml probably because I tried on my local
working copy to make a svn rename pom.xml pom-template.xml, and somehow the svn diff
command did not like that.

What I've done in the current patch is first svn remove pom.xml then svn add
pom-template.xml.

Comment 3  by richhickey, Apr 27, 2009

patch applied- svn 1357 - thanks!

Status: Accepted
Comment 4 by scgilardi, May 12, 2009

(clojure-version) for 1.0 has a trailing "-". The intention (as noted above in the
issue) is that when the qualifier is absent, there should be no "-". The current
setup is reading a blank qualifier as an empty string, but checking later for nil
rather than nil or the empty string.

Clojure 1.0.0-
user=> *clojure-version*
{:major 1, :minor 0, :incremental 0, :qualifier ""}
user=> (clojure-version)
"1.0.0-"
user=> 



Comment 5 by laurent....@gmail.com, May 12, 2009

OK, a mistake on my part.

Rich, I also see you have made implicitly the "incremental" attribute mandatory in
trunk (since you apply Integer/valueOf on it without checking for nullity or string
emptyness).

If it is intentional, I can also add in the corrective patch a modified build.xml
that verifies this (incremental being mandatory) when building with ant, or I can
change the patch to keep the "incremental" attribute optional.

Waiting for your answer before creating the patch.


 Comments   
Comment by Assembla Importer [ 24/Aug/10 12:45 AM ]

Converted from http://www.assembla.com/spaces/clojure/tickets/114
Attachments:
clojure-version.patch - https://www.assembla.com/spaces/clojure/documents/aKO9q2w4mr3Od2eJe5aVNr/download/aKO9q2w4mr3Od2eJe5aVNr
clojure-version2.patch - https://www.assembla.com/spaces/clojure/documents/aKO_-6w4mr3Od2eJe5aVNr/download/aKO_-6w4mr3Od2eJe5aVNr

Comment by Assembla Importer [ 24/Aug/10 12:45 AM ]

oranenj said: [file:aKO9q2w4mr3Od2eJe5aVNr]

Comment by Assembla Importer [ 24/Aug/10 12:45 AM ]

oranenj said: [file:aKO_-6w4mr3Od2eJe5aVNr]: on comment 2

Comment by Assembla Importer [ 24/Aug/10 12:45 AM ]

richhickey said: Updating tickets (#8, #19, #30, #31, #126, #17, #42, #47, #50, #61, #64, #69, #71, #77, #79, #84, #87, #89, #96, #99, #103, #107, #112, #113, #114, #115, #118, #119, #121, #122, #124)





[CLJ-89] GC Issue 85: In a defn, arglists metadata becomes the first (unexpected?) symbol Created: 17/Jun/09  Updated: 24/Aug/10  Resolved: 24/Aug/10

Status: Closed
Project: Clojure
Component/s: None
Affects Version/s: None
Fix Version/s: Backlog

Type: Defect
Reporter: Anonymous Assignee: Unassigned
Resolution: Declined Votes: 0
Labels: None


 Description   
Reported by jochu0, Feb 22, 2009

> What (small set of) steps will reproduce the problem?

(:arglists (meta (defn arglists broken-arglist ([a] a) ([a b] b))))
(broken-arglist)

> What is the expected output? What do you see instead?

I would expect ([a] [a b]) if not an error.

> What version are you using?

Using the latest clojure (r1298) and also likely to exist before lazy-seq.

> Was this discussed on the group? If so, please provide a link to the
discussion:

http://groups.google.com/group/clojure/browse_thread/thread/bafdb169330a9344


 Comments   
Comment by Assembla Importer [ 24/Aug/10 3:45 AM ]

Converted from http://www.assembla.com/spaces/clojure/tickets/89

Comment by Assembla Importer [ 24/Aug/10 3:45 AM ]

richhickey said: Updating tickets (#8, #19, #30, #31, #126, #17, #42, #47, #50, #61, #64, #69, #71, #77, #79, #84, #87, #89, #96, #99, #103, #107, #112, #113, #114, #115, #118, #119, #121, #122, #124)

Comment by Assembla Importer [ 24/Aug/10 3:45 AM ]

stu said: On the latest master I see what I think is the expected error:

(:arglists (meta (defn arglists broken-arglist ([a] a) ([a b] b))))
java.lang.IllegalArgumentException: Don't know how to create ISeq from: clojure.lang.Symbol




[CLJ-87] GC Issue 83: PersistentArrayMap trust the reader (map literals) too much Created: 17/Jun/09  Updated: 24/Aug/10  Resolved: 24/Aug/10

Status: Closed
Project: Clojure
Component/s: None
Affects Version/s: None
Fix Version/s: Backlog

Type: Defect
Reporter: Anonymous Assignee: Rich Hickey
Resolution: Completed Votes: 0
Labels: None


 Description   
Reported by karmazilla, Feb 17, 2009

What (small set of) steps will reproduce the problem?

PersistentArrayMap gets it wrong:

user=> {1 1 1 1 1 1 2 2}
{1 1, 1 1, 1 1, 2 2}

What is the expected output? What do you see instead?

But PersistentHashMap gets it right:

user=> (hash-map 1 1 1 1 1 1 2 2)
{1 1, 2 2}

What version are you using?

rev 1286.

Was this discussed on the group? If so, please provide a link to the 
discussion:
http://groups.google.com/group/clojure/browse_thread/
thread/5a38a6b61b09e025

Please provide any additional information below.

PersistentArrayMap seems to be the culprits. Line 65 to 73. They should 
probably assoc the individual items like PersistentHashMap do, I guess.


 Comments   
Comment by Assembla Importer [ 24/Aug/10 12:45 AM ]

Converted from http://www.assembla.com/spaces/clojure/tickets/87
Attachments:
map-literals-error.diff - https://www.assembla.com/spaces/clojure/documents/cJ9rlAc4Gr36CjeJe5aVNr/download/cJ9rlAc4Gr36CjeJe5aVNr

Comment by Assembla Importer [ 24/Aug/10 12:45 AM ]

richhickey said: Updating tickets (#8, #19, #30, #31, #126, #17, #42, #47, #50, #61, #64, #69, #71, #77, #79, #84, #87, #89, #96, #99, #103, #107, #112, #113, #114, #115, #118, #119, #121, #122, #124)

Comment by Assembla Importer [ 24/Aug/10 12:45 AM ]

hiredman said: [file:cJ9rlAc4Gr36CjeJe5aVNr]: add error detect to reader

Comment by Assembla Importer [ 24/Aug/10 12:45 AM ]

hiredman said: patch adds some error detection to the map literal reader. covers the above case and also {:a}

Comment by Assembla Importer [ 24/Aug/10 12:45 AM ]

devlinsf said: Could this issue be promoted to "Release - Bug Fix"?

Comment by Assembla Importer [ 24/Aug/10 12:45 AM ]

richhickey said: (In [[r:e6e39d5931fbdf3dfa68cd2d059b8e26ce45c965]]) catch duplicate map keys for literals and hash- and array-map calls. Fixes #87

Branch: master





[CLJ-84] GC Issue 81: compile gen-class fail when class returns self Created: 17/Jun/09  Updated: 27/Jul/13

Status: In Progress
Project: Clojure
Component/s: None
Affects Version/s: Backlog
Fix Version/s: Backlog

Type: Defect Priority: Minor
Reporter: Assembla Importer Assignee: Rich Hickey
Resolution: Unresolved Votes: 0
Labels: None

Approval: Vetted
Waiting On: Chouser

 Description   
Reported by davidhaub, Feb 14, 2009

When attempting to compile the following program, clojure fails with a
ClassNotFoundException.  It occurs because one of the methods returns the
same class that is being generated.  If the returnMe method below is
changed to return an Object, the compile succeeds.

Beware when testing! If the classpath contains a class file (say from a
prior successful build when the returnMe method was changed to return an
object), the compile will succeed.  Always clear out the
clojure.compile.path prior to compiling.

;badgenclass.clj
(ns badgenclass
  (:gen-class
     :state state
     :methods
     [[returnMe [] badgenclass]]
     :init init))
(defn -init []
  [[] nil])

(defn -returnMe [this]
  this)

#!/bin/sh
rm -rf classes
mkdir classes
java -cp lib/clojure.jar:classes:. -Dclojure.compile.path=classes \
clojure.lang.Compile badgenclass


Comment 1 by chouser, Mar 07, 2009

Attached is a patch that accepts strings or symbols for parameter and return class
names, and generates the appropriate bytecode without calling Class/forName.  It
fixes this issue, but because 'ns' doesn't resolve :gen-class's arguments, class
names aren't checked as early anymore.  :gen-class-created classes with invalid
parameter or return types can even be instantiated, and no error will be reported
until the broken method is called.

One possible alternative would be to call Class/forName on any symbols given, but
allow strings to use the method given by this patch.  To return your own type, you'd
need a method defined like:

  [returnMe [] "badgenclass"]

Any thoughts?


 Comments   
Comment by Assembla Importer [ 28/Sep/10 5:09 PM ]

Converted from http://www.assembla.com/spaces/clojure/tickets/84
Attachments:
genclass-allow-unresolved-classname.patch - https://www.assembla.com/spaces/clojure/documents/cWS6Aww30r3RbzeJe5afGb/download/cWS6Aww30r3RbzeJe5afGb

Comment by Assembla Importer [ 28/Sep/10 5:09 PM ]

oranenj said: [file:cWS6Aww30r3RbzeJe5afGb]: on comment 1

Comment by Assembla Importer [ 28/Sep/10 5:09 PM ]

richhickey said: Updating tickets (#8, #19, #30, #31, #126, #17, #42, #47, #50, #61, #64, #69, #71, #77, #79, #84, #87, #89, #96, #99, #103, #107, #112, #113, #114, #115, #118, #119, #121, #122, #124)

Comment by Stuart Halloway [ 30/Oct/10 11:58 AM ]

The approach take in the initial patch (delaying resolution of symbols into classes) is fine: gen-class makes no promise about when this happens, and the dynamic approach feels more consistent with Clojure. I think the proposed (but not implemented) use of string/symbol to control when class names are resolved is a bad idea: magical and not implied by the types.

Needed:

  • update the patch to apply cleanly
  • consider whether totype could live in clojure.reflect.java. (Beware load order dependencies.)
Comment by Chouser [ 30/Oct/10 9:29 PM ]

Wow, 18-month-old patch, back to haunt me for Halloway'een

So what does it mean that the assignee is Rich, but it's waiting on me?

Comment by Stuart Halloway [ 01/Nov/10 9:17 AM ]

I am using Approval = Incomplete plus Waiting On = Someone to let submitters know that there is feedback waiting, and that they can move the ticket forward by acting on it. The distinction is opportunity to contribute (something has been provided to let you move forward) vs. expectation of contribution.





[CLJ-69] GC Issue 66: Add "keyset" to Clojure; make .keySet for APersistentMap return IPersistentSet Created: 17/Jun/09  Updated: 27/Jul/13

Status: In Progress
Project: Clojure
Component/s: None
Affects Version/s: Backlog
Fix Version/s: Backlog

Type: Enhancement Priority: Minor
Reporter: Assembla Importer Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None

Approval: Vetted

 Description   
Reported by wolfe.a.jason, Feb 04, 2009

Describe the feature/change.

Add "keyset" to Clojure; make .keySet for APersistentMap return an
IPersistentSet

Was this discussed on the group? If so, please provide a link to the
discussion:

http://groups.google.com/group/clojure/browse_thread/thread/66e708e477ae992f/ff3d8d588068b60e?hl=en#ff3d8d588068b60e

-----------------------------------------------------

A patch is attached.  Some notes:

I chose to add a "keyset" function, rather than change the existing "keys",
so as to avoid breaking anything.

The corresponding RT.keyset function just calls .keySet on the argument.
I would have liked to have "keyset" return an IPersistentSet even when
passed a (non-Clojure) java.util.Map, but this seems impossible to do in
sublinear time because of essentially the same limitation mentioned in the
above thread (the Map interface does not support getKey() or entryAt()) --
assuming, again, that "get" is supposed to return the actual (identical?)
key in a set, and not just an .equal key.

I then changed the implementation of .keySet for APersistentMap to
essentially copy APersistentSet.  A more concise alternative would have
been to extend APersistentSet and override the .get method, but that made
me a bit nervous (since if APeristentSet changed this could break). 

Anyway, this is my first patch for the Java side of Clojure, and I'm not
yet solid on the conventions and aesthetics, so
comments/questions/criticisms/requests for revisions are very welcome.


 Comments   
Comment by Assembla Importer [ 28/Sep/10 7:00 AM ]

Converted from http://www.assembla.com/spaces/clojure/tickets/69
Attachments:
keyset.patch - https://www.assembla.com/spaces/clojure/documents/dKgE6mw3Gr3O2PeJe5afGb/download/dKgE6mw3Gr3O2PeJe5afGb

Comment by Assembla Importer [ 28/Sep/10 7:00 AM ]

oranenj said: [file:dKgE6mw3Gr3O2PeJe5afGb]

Comment by Assembla Importer [ 28/Sep/10 7:00 AM ]

richhickey said: Updating tickets (#8, #19, #30, #31, #126, #17, #42, #47, #50, #61, #64, #69, #71, #77, #79, #84, #87, #89, #96, #99, #103, #107, #112, #113, #114, #115, #118, #119, #121, #122, #124)

Comment by Stuart Halloway [ 03/Dec/10 1:12 PM ]

patch not in correct format





[CLJ-61] GC Issue 57: Compiler internal error when expanding macro: class not found Created: 17/Jun/09  Updated: 24/Aug/10  Resolved: 24/Aug/10

Status: Closed
Project: Clojure
Component/s: None
Affects Version/s: None
Fix Version/s: Backlog

Type: Defect
Reporter: Anonymous Assignee: Unassigned
Resolution: Declined Votes: 0
Labels: None


 Description   
Reported by tuomas.lukka, Jan 29, 2009
 
------------------------------

What (small set of) steps will reproduce the problem?

Run the following code:

(defmacro b [] (let [ x (fn [] []) ] x))
(def a (fn [] (b)))


What is the expected output? What do you see instead?

I'd expect it to either pass or give a proper error. What I get
is

Exception in thread "main" java.lang.ExceptionInInitializerError (test.clj:2)
 at clojure.lang.Compiler$DefExpr.eval(Compiler.java:308)
 at clojure.lang.Compiler.eval(Compiler.java:4147)
 at clojure.lang.Compiler.load(Compiler.java:4470)
 at clojure.lang.Compiler.loadFile(Compiler.java:4437)
 at clojure.lang.Script.main(Script.java:65)
Caused by: java.lang.ExceptionInInitializerError
 at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
 at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
 at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
 at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
 at java.lang.Class.newInstance0(Class.java:355)
 at java.lang.Class.newInstance(Class.java:308)
 at clojure.lang.Compiler$FnExpr.eval(Compiler.java:3218)
 at clojure.lang.Compiler$DefExpr.eval(Compiler.java:297)
 ... 4 more
Caused by: java.lang.RuntimeException: java.lang.ClassNotFoundException:
clojure.core$b__1$x__3
 at clojure.lang.RT.readString(RT.java:1192)
 at clojure.core$a__7.<clinit>(test.clj:2)
 ... 12 more
Caused by: java.lang.ClassNotFoundException: clojure.core$b__1$x__3
 at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
 at java.security.AccessController.doPrivileged(Native Method)
 at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
 at clojure.lang.DynamicClassLoader.findClass(DynamicClassLoader.java:52)
 at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
 at java.lang.ClassLoader.loadClass(ClassLoader.java:252)
 at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)
 at java.lang.Class.forName0(Native Method)
 at java.lang.Class.forName(Class.java:247)
 at clojure.lang.RT.classForName(RT.java:1506)
 at clojure.lang.LispReader$EvalReader.invoke(LispReader.java:908)
 at clojure.lang.LispReader$DispatchReader.invoke(LispReader.java:530)
 at clojure.lang.LispReader.read(LispReader.java:143)
 at clojure.lang.RT.readString(RT.java:1188)
 ... 13 more


What version are you using?

20081217

Was this discussed on the group? If so, please provide a link to the
discussion:

no


 Comments   
Comment by Assembla Importer [ 24/Aug/10 3:44 AM ]

Converted from http://www.assembla.com/spaces/clojure/tickets/61

Comment by Assembla Importer [ 24/Aug/10 3:44 AM ]

richhickey said: Updating tickets (#8, #19, #30, #31, #126, #17, #42, #47, #50, #61, #64, #69, #71, #77, #79, #84, #87, #89, #96, #99, #103, #107, #112, #113, #114, #115, #118, #119, #121, #122, #124)

Comment by Assembla Importer [ 24/Aug/10 3:44 AM ]

stu said: The code appears to run correctly against current master.





[CLJ-50] GC Issue 46: callable defstruct (PersistentStructMap$Def extends AFn) Created: 17/Jun/09  Updated: 15/Nov/10  Resolved: 15/Nov/10

Status: Closed
Project: Clojure
Component/s: None
Affects Version/s: None
Fix Version/s: Backlog

Type: Enhancement
Reporter: Anonymous Assignee: Unassigned
Resolution: Declined Votes: 0
Labels: None


 Description   
Reported by chouser, Jan 15, 2009
Describe the feature/change.

This much works already:
(defstruct rect :width :height)
(struct rect 5 10)  ==> {:width 5, :height 10}

With the included patch you can also:
(rect 5 10)  ==> {:width 5, :height 10}

Was this discussed on the group? If so, please provide a link to the
discussion:

http://groups.google.com/group/clojure/browse_thread/thread/12a138ad58ff6c36/b20b68ef939fccf7

Comment 1 by chouser, Jan 15, 2009
Forgot the patch attachment.
 structmap-def-extends-restfn.patch
923 bytes Download


 Comments   
Comment by Assembla Importer [ 24/Aug/10 2:44 PM ]

Converted from http://www.assembla.com/spaces/clojure/tickets/50
Attachments:
structmap-def-extends-restfn.patch - https://www.assembla.com/spaces/clojure/documents/aFFlyCw3qr3R14eJe5aVNr/download/aFFlyCw3qr3R14eJe5aVNr

Comment by Assembla Importer [ 24/Aug/10 2:44 PM ]

cemerick said: [file:aFFlyCw3qr3R14eJe5aVNr]

Comment by Assembla Importer [ 24/Aug/10 2:44 PM ]

richhickey said: Updating tickets (#8, #19, #30, #31, #126, #17, #42, #47, #50, #61, #64, #69, #71, #77, #79, #84, #87, #89, #96, #99, #103, #107, #112, #113, #114, #115, #118, #119, #121, #122, #124)

Comment by Assembla Importer [ 24/Aug/10 2:44 PM ]

richhickey said: I'm not sure I want to touch structmaps prior to implements

Comment by Chouser [ 14/Nov/10 9:22 PM ]

This ticket has survived almost two years, two bug tracker migrations[1] and now who uses structs anymore? Records have essentially this syntax for their ctors. I nominate this ticket be closed as "wontfix" or equivalent.

[1]: http://code.google.com/p/clojure/issues/detail?id=46





[CLJ-47] GC Issue 43: Dead code in generated bytecode Created: 17/Jun/09  Updated: 26/Aug/13

Status: Open
Project: Clojure
Component/s: None
Affects Version/s: None
Fix Version/s: Backlog

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

Approval: Vetted

 Description   
Reported by Levente.Santha, Jan 11, 2009
The bug was described in detail in this thread: http://groups.google.com/
group/clojure/browse_thread/thread/81ba15d7e9130441

For clojure.core$last__2954.invoke the correct bytecode would be (notice 
the removed "goto    65" after "41:  goto    0"):

public java.lang.Object invoke(java.lang.Object)   throws 
java.lang.Exception;
  Code:
   0:   getstatic       #22; //Field const__0:Lclojure/lang/Var;
   3:   invokevirtual   #37; //Method clojure/lang/Var.get:()Ljava/lang/
Object;
   6:   checkcast       #39; //class clojure/lang/IFn
   9:   aload_1
   10:  invokeinterface #41,  2; //InterfaceMethod clojure/lang/IFn.invoke:
(Ljava/lang/Object;)Ljava/lang/Object;
   15:  dup
   16:  ifnull  44
   19:  getstatic       #47; //Field java/lang/Boolean.FALSE:Ljava/lang/
Boolean;
   22:  if_acmpeq       45
   25:  getstatic       #22; //Field const__0:Lclojure/lang/Var;
   28:  invokevirtual   #37; //Method clojure/lang/Var.get:()Ljava/lang/
Object;
   31:  checkcast       #39; //class clojure/lang/IFn
   34:  aload_1
   35:  invokeinterface #41,  2; //InterfaceMethod clojure/lang/IFn.invoke:
(Ljava/lang/Object;)Ljava/lang/Object;
   40:  astore_1
   41:  goto    0
   44:  pop
   45:  getstatic       #26; //Field const__1:Lclojure/lang/Var;
   48:  invokevirtual   #37; //Method clojure/lang/Var.get:()Ljava/lang/
Object;
   51:  checkcast       #39; //class clojure/lang/IFn
   54:  aload_1
   55:  aconst_null
   56:  astore_1
   57:  invokeinterface #41,  2; //InterfaceMethod clojure/lang/IFn.invoke:
(Ljava/lang/Object;)Ljava/lang/Object;
   62:  areturn

Our JIT reported incorrect stack size along the basic block introduced by 
the unneeded goto.
The bug was present in SVN rev 1205.


 Comments   
Comment by Assembla Importer [ 08/Oct/10 10:21 AM ]

Converted from http://www.assembla.com/spaces/clojure/tickets/47

Comment by Assembla Importer [ 08/Oct/10 10:21 AM ]

richhickey said: Updating tickets (#8, #19, #30, #31, #126, #17, #42, #47, #50, #61, #64, #69, #71, #77, #79, #84, #87, #89, #96, #99, #103, #107, #112, #113, #114, #115, #118, #119, #121, #122, #124)

Comment by Assembla Importer [ 08/Oct/10 10:21 AM ]

aredington said: This appears to still be a problem with the generated bytecode in 1.3.0. Examining the bytecode for last, the problem has moved to invokeStatic:

<pre>
public static java.lang.Object invokeStatic(java.lang.Object) throws java.lang.Exception;
Code:
0: aload_0
1: invokestatic #50; //Method clojure/core$next.invokeStatic:(Ljava/lang/Object;)Ljava/lang/Object;
4: dup
5: ifnull 25
8: getstatic #56; //Field java/lang/Boolean.FALSE:Ljava/lang/Boolean;
11: if_acmpeq 26
14: aload_0
15: invokestatic #50; //Method clojure/core$next.invokeStatic:(Ljava/lang/Object;)Ljava/lang/Object;
18: astore_0
19: goto 0
22: goto 30
25: pop
26: aload_0
27: invokestatic #59; //Method clojure/core$first.invokeStatic:(Ljava/lang/Object;)Ljava/lang/Object;
30: areturn
</pre>

Line number 22 is an unreachable goto given the prior goto on line 19.





[CLJ-17] GC Issue 13: validate in (keyword s) and (symbol s) Created: 17/Jun/09  Updated: 07/Oct/11  Resolved: 07/Oct/11

Status: Closed
Project: Clojure
Component/s: None
Affects Version/s: None
Fix Version/s: Backlog

Type: Enhancement
Reporter: Anonymous Assignee: Unassigned
Resolution: Declined Votes: 0
Labels: None


 Description   
Reported by richhickey, Dec 17, 2008
Make sure they create readable keywords/symbols

Comment 1 by p...@hagelb.org, Apr 27, 2009
Could this be done with a regex, or should it try to confirm the name using the reader?
Comment 2 by p...@hagelb.org, Apr 27, 2009
I've implemented this in the attached patch. One thing that could be improved is that
invalid names simply raise an Exception, though it seems LispReader's ReaderException
would be more appropriate. I wasn't sure how to raise that though since it needs a
line number; it's not clear how to get the current line number.

The patch is still an improvement on the current state of things, though I'd
appreciate a tip as to how to raise the right exception.

I've also attached a patch to the test suite that ensures (symbol s) and (keyword s)
work properly in the context of invalid names. I can re-submit this to the contrib
project if that's desired if the core patch is accepted.
 0001-Test-invalid-symbol-keyword-names-raise-exceptions.patch
1.6 KB Download
Comment 3 by p...@hagelb.org, Apr 27, 2009
Last patch had a problem; used things like defn- etc. before they were defined in
core.clj. This attachment fixes that.
 validate-symbol-keyword-names.patch
2.1 KB Download
Comment 4 by p...@hagelb.org, Jun 13 (3 days ago)
This exists as a git branch too now: 
http://github.com/technomancy/clojure/tree/validate-symbols-issue-13


 Comments   
Comment by Assembla Importer [ 28/Sep/10 6:50 AM ]

Converted from http://www.assembla.com/spaces/clojure/tickets/17
Attachments:
0001-Test-invalid-symbol-keyword-names-raise-exceptions.patch - https://www.assembla.com/spaces/clojure/documents/cpC-Qow3ar3P8LeJe5afGb/download/cpC-Qow3ar3P8LeJe5afGb
validate-symbol-keyword-names.patch - https://www.assembla.com/spaces/clojure/documents/cpDbtWw3ar3P8LeJe5afGb/download/cpDbtWw3ar3P8LeJe5afGb
17-validate-keywords-symbols.diff - https://www.assembla.com/spaces/clojure/documents/d61sHuVFer3OGKeJe5afGb/download/d61sHuVFer3OGKeJe5afGb

Comment by Assembla Importer [ 28/Sep/10 6:50 AM ]

cemerick said: [file:cpC-Qow3ar3P8LeJe5afGb]

Comment by Assembla Importer [ 28/Sep/10 6:50 AM ]

cemerick said: [file:cpDbtWw3ar3P8LeJe5afGb]

Comment by Assembla Importer [ 28/Sep/10 6:50 AM ]

richhickey said: Updating tickets (#8, #19, #30, #31, #126, #17, #42, #47, #50, #61, #64, #69, #71, #77, #79, #84, #87, #89, #96, #99, #103, #107, #112, #113, #114, #115, #118, #119, #121, #122, #124)

Comment by Assembla Importer [ 28/Sep/10 6:50 AM ]

technomancy said: These patches no longer cleanly apply. Working on an updated version.

Comment by Assembla Importer [ 28/Sep/10 6:50 AM ]

technomancy said: [file:d61sHuVFer3OGKeJe5afGb]: test and implementation

Comment by Assembla Importer [ 28/Sep/10 6:50 AM ]

richhickey said: I just wonder if we can afford the overhead of this validation all the time

Comment by Assembla Importer [ 28/Sep/10 6:50 AM ]

richhickey said: Anyone have any bright ideas on how to avoid the overhead?

Comment by Assembla Importer [ 28/Sep/10 6:50 AM ]

cemerick said: I'm sure this was brought up a long time ago in prior discussions, but: should validity of symbols and keywords even be defined? Insofar as libraries use them for naming things, especially as read from external representations (e.g. XML, RDF, SGML, etc), it seems like any validation would be an entirely artificial limitation.

For my money, having keywords and symbols print in a failsafe-readable way, e.g. #|symbol with whitespace| (maybe checking at print-time to see if the more common printing is suitable, as would be most common) would:

  • guarantee that symbols and keywords are readably printable
  • not limit libraries from using keywords and such in very convenient ways
  • provide a pleasant shortcut for using symbols and keywords that might not be "valid", but still somehow necessary
Comment by Rich Hickey [ 07/Oct/11 8:03 AM ]

Runtime validation off the table for perf reasons. cemerick's suggestion that arbitrary symbol support will render them valid is sound, but arbitrary symbol support is a different ticket/idea.





[CLJ-5] Unintuitive error response in clojure 1.0 Created: 17/Jun/09  Updated: 18/Apr/14

Status: Open
Project: Clojure
Component/s: None
Affects Version/s: None
Fix Version/s: Backlog

Type: Enhancement Priority: Minor
Reporter: Assembla Importer Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: errormsgs

Attachments: File clj-5-destructure-error.diff     Text File CLJ-5.patch    
Patch: Code and Test
Approval: Vetted

 Description   

The following broken code:

(let [[x y] {}] x)

provides the following stack trace:

Exception in thread "main" java.lang.UnsupportedOperationException: nth not supported on this type: PersistentArrayMap (test.clj:0)
at clojure.lang.Compiler.eval(Compiler.java:4543)
at clojure.lang.Compiler.load(Compiler.java:4857)
at clojure.lang.Compiler.loadFile(Compiler.java:4824)
at clojure.main$load_script__5833.invoke(main.clj:206)
at clojure.main$script_opt__5864.invoke(main.clj:258)
at clojure.main$main__5888.doInvoke(main.clj:333)
at clojure.lang.RestFn.invoke(RestFn.java:413)
at clojure.lang.Var.invoke(Var.java:346)
at clojure.lang.AFn.applyToHelper(AFn.java:173)
at clojure.lang.Var.applyTo(Var.java:463)
at clojure.main.main(main.java:39)
Caused by: java.lang.UnsupportedOperationException: nth not supported on this type: PersistentArrayMap
at clojure.lang.RT.nth(RT.java:800)
at clojure.core$nth__3578.invoke(core.clj:873)
at user$eval__1.invoke(test.clj:1)
at clojure.lang.Compiler.eval(Compiler.java:4532)
... 10 more

The message "nth not supported on this type" while correct doesn't make the cause of the error very clear. Better error messages when destructuring would be very helpful.



 Comments   
Comment by Assembla Importer [ 24/Aug/10 10:44 AM ]

Converted from http://www.assembla.com/spaces/clojure/tickets/5

Comment by Eugene Koontz [ 11/Nov/11 7:36 PM ]

Please see the attached patch which produces a (hopefully more clear) error message as shown below (given the broken code shown in the original bug report):

Clojure 1.4.0-master-SNAPSHOT
user=> (let [x 42 y 43] (+ x y))
85
user=> (let [[x y] {}] x)
UnsupportedOperationException left side of binding must be a symbol (found a PersistentVector instead).  clojure.lang.Compiler.checkLet (Compiler.java:6545)
user=>

In addition, this patch checks the argument of (let) as shown below:

user=> (let 42)
UnsupportedOperationException argument to (let)  must be a vector (found a Long instead).  clojure.lang.Compiler.checkLet (Compiler.java:6553)
Comment by Eugene Koontz [ 11/Nov/11 7:38 PM ]

Patch produced by doing git diff against commit ba930d95fc (master branch).

Comment by Eugene Koontz [ 13/Nov/11 11:24 PM ]

Sorry, this patch is wrong: it assumes that the left side of the binding is wrong - the [x y] in :

(let [[x y] {}] x)

because [x y] is a vector, when in fact, the left side is fine (per http://clojure.org/special_forms#let : "Clojure supports abstract structural binding, often called destructuring, in let binding lists".)

So it's the right side (the {}) that needs to be checked and flagged as erroneous, not the [x y].

Comment by Carin Meier [ 30/Nov/11 12:15 PM ]

Add patch better-error-for-let-vector-map-binding

This produces the following:

(let [[x y] {}] x)
Exception map binding to vector is not supported

There are other cases that are not handled by this though — like binding vector to a set

user=> (let [[x y] #{}] x)
UnsupportedOperationException nth not supported on this type: PersistentHashSet

Wondering if it might be better to try convert the map to a seq to support? Although this might be another issue.

Thoughts?

Comment by Aaron Bedra [ 30/Nov/11 7:12 PM ]

This seems too specific. Is this issue indicative of a larger problem that should be addressed? Even if this is the only case where bindings produce poor error messages, all the cases described above should be addressed in the patch.

Comment by Carin Meier [ 16/Dec/11 7:47 AM ]

Unfortunately, realized that this still does not cover the nested destructuring cases. Coming to the conclusion, that my approach above is not going to work for this.

Comment by Carin Meier [ 28/Apr/12 10:46 PM ]

File: clj-5-destructure-error.diff

Added support for nested destructuring errors

let [[[x1 y1][x2 y2]] [[1 2] {}]]
;=> UnsupportedOperationException let cannot destructure class clojure.lang.PersistentArrayMap.
Comment by Kevin Downey [ 18/Apr/14 1:45 AM ]

I am not wild about that error message, let can destructure a map fine.

If there error message were to change, I would prefer to get something like "sequential destructing not supported on maps".

I actually like the "nth not supported" error message, because it is exactly the problem, nth, used by sequential destructuring, doesn't work on maps.

it conveys exactly what the problem is if you know how destructing works and what nth means, where as "UnsupportedOperationException let cannot destructure class clojure.lang.PersistentArrayMap" seems misleading when you are in the know





Generated at Wed Jul 30 16:33:10 CDT 2014 using JIRA 4.4#649-r158309.