<< Back to previous view

[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-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-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-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-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-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-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-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-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-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-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-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-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.





Generated at Sun Apr 20 01:16:09 CDT 2014 using JIRA 4.4#649-r158309.