<< Back to previous view

[CLJ-6] GC Issue 1: :validator as keyword arg for ref/atom/agent 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: None

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


 Description   
Reported by richhickey, Dec 14, 2008
switch to keyword args for reference ctors:
(ref val & options)
(atom va & options)
(agent val & options)

Comment 1 by richhickey, Dec 17, 2008
(No comment was entered for this change.)
Labels: -Priority-Medium Priority-High
Comment 2 by richhickey, Dec 17, 2008
(No comment was entered for this change.)
Status: Accepted
Comment 3 by richhickey, Dec 17, 2008
(No comment was entered for this change.)
Owner: ---
Comment 4 by richhickey, Jan 05, 2009
svn 1193
Status: Fixed


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

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





[CLJ-11] GC Issue 7: Make syntax-quote Classname. aware 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: None

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


 Description   
Reported by richhickey, Dec 17, 2008
should turn into fully.qualified.Classname.

Comment 1 by m...@kotka.de, Jan 02, 2009
The attached patch fixes this issue. It checks for Symbol w/o namespace and a trailing dot.
Then the dot is removed, the Symbol resolved and the dot added again.

The second patch fixes a related issue with .methodName Symbols: those were also resolved
when in fact they should not have been. So the patch checks for Symbols w/o namespace
and a leading dot. Those Symbols are simply left alone and quoted as is.

The second patch should be applied after the first.
 issue-7.diff
785 bytes Download
 issue-7a.diff
611 bytes Download
Comment 2 by richhickey, Jan 07, 2009
Patches applied svn 1202 - thanks!
Status: Fixed


 Comments   
Comment by Assembla Importer [ 24/Aug/10 2:44 PM ]

Converted from http://www.assembla.com/spaces/clojure/tickets/11
Attachments:
issue-7.diff - https://www.assembla.com/spaces/clojure/documents/dAAAIgw28r3PSteJe5afGb/download/dAAAIgw28r3PSteJe5afGb
issue-7a.diff - https://www.assembla.com/spaces/clojure/documents/dAADmKw28r3PSteJe5afGb/download/dAADmKw28r3PSteJe5afGb

Comment by Assembla Importer [ 24/Aug/10 2:44 PM ]

cemerick said: [file:dAAAIgw28r3PSteJe5afGb]

Comment by Assembla Importer [ 24/Aug/10 2:44 PM ]

cemerick said: [file:dAADmKw28r3PSteJe5afGb]





[CLJ-12] GC Issue 8: :default as keyword arg to defmulti 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: None

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


 Description   
Reported by richhickey, Dec 17, 2008
rather than positional arg

Comment 1 by richhickey, Dec 17, 2008
(No comment was entered for this change.)
Status: Accepted
Comment 2 by richhickey, Dec 17, 2008
(No comment was entered for this change.)
Owner: ---
Comment 3 by m...@kotka.de, Jan 05, 2009
Attached is a patch, which turns the default dispatch value from a positional argument
into a keyword argument. The syntax is:

(defmulti name dispatch-fn :default dispatch-value)

Uses of the old syntax throw an exception pointing to the new syntax.
 issue-8.diff
1.4 KB Download
Comment 4 by m...@kotka.de, Jan 11, 2009
Another update of the patch, also including docstring and metadata support, similar to defn.

This was brought up several times on the list. Eg. in the thread:

http://groups.google.com/group/clojure/tree/browse_frm/thread/21af6e0431ae2e63/f7751913e875953f?
rnum=11&_done=%2Fgroup%2Fclojure%2Fbrowse_frm%2Fthread%2F21af6e0431ae2e63%2Ff7751913e875953f%
3F#doc_b5a6f9049a2ff250
 issue-8.diff
2.5 KB Download
Comment 5 by richhickey, Jan 22, 2009
Patch applied - svn 1226 - thanks!
Status: Fixed


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

Converted from http://www.assembla.com/spaces/clojure/tickets/12
Attachments:
issue-8.diff - https://www.assembla.com/spaces/clojure/documents/d_WTlyw28r3Qr1eJe5aVNr/download/d_WTlyw28r3Qr1eJe5aVNr
issue-8-1.diff - https://www.assembla.com/spaces/clojure/documents/d_WV5iw28r3Qr1eJe5aVNr/download/d_WV5iw28r3Qr1eJe5aVNr

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

cemerick said: [file:d_WTlyw28r3Qr1eJe5aVNr]

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

cemerick said: [file:d_WV5iw28r3Qr1eJe5aVNr]





[CLJ-1] Add chunk support to map filter et al Created: 13/Jun/09  Updated: 24/Aug/10  Resolved: 24/Aug/10

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

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


 Description   

add conditional logic to test for chunked seq and handle specially



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

Converted from http://www.assembla.com/spaces/clojure/tickets/1
Attachments:
chunked-doseq.diff - https://www.assembla.com/spaces/clojure/documents/dyQbLWIiCr3RSfeJe5aVNr/download/dyQbLWIiCr3RSfeJe5aVNr
chunked-doseq-v2.diff - https://www.assembla.com/spaces/clojure/documents/ayZsEAIHer3OuReJe5afGb/download/ayZsEAIHer3OuReJe5afGb
chunked-concat.diff - https://www.assembla.com/spaces/clojure/documents/ddNltiJ1Gr3Q4TeJe5aVNr/download/ddNltiJ1Gr3Q4TeJe5aVNr
chunked-for.diff - https://www.assembla.com/spaces/clojure/documents/d1Zsv2Ke4r3QR8eJe5afGb/download/d1Zsv2Ke4r3QR8eJe5afGb

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

chouser@n01se.net said: [file:dyQbLWIiCr3RSfeJe5aVNr]: doseq with chunked seq support

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

chouser@n01se.net said: Is it ok to call chunk-rest before chunk-first is consumed?

Anyway, I must have done something terribly wrong. The doseq in chunked-doseq.diff passes all existing tests, but runs dramatically slower than the old doseq on both chunked and non-chunked seqs.

I didn't test performance until after I'd attached the patch, otherwise I would have kept it to myself.

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

chouser@n01se.net said: [file:ayZsEAIHer3OuReJe5afGb]: Add chunked seq support to doseq, v2

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

chouser@n01se.net said: file:chunked-doseq-v2.diff should be good to go. It's in the same performance ballpark as the pre-chunk doseq for unchunked seqs, and noticeably faster for chunked seqs. It passes all existing tests.

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

chouser@n01se.net said: (In [[r:1abb7a56de1678321054af7fce183184f06974dd]]) Add chunked seq support to doseq, v2. Refs #1

Branch: master

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

chouser@n01se.net said: set approval back to 'none', awaiting patches for more functions.

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

chouser@n01se.net said: [file:ddNltiJ1Gr3Q4TeJe5aVNr]: Add chunked seq support to concat

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

chouser@n01se.net said: [file:aIu4XoJ1Kr3OYMeJe5afGb]: Add chunked seq support to concat

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

chouser@n01se.net said: Added chunked seq support to concat: file:chunked-concat.diff

Because concat had been defined before any of the chunk fns, I moved the the chunk fns to much earlier in core.clj than they were. This also required changing 'chunk-cons' to use static methods directly instead of core fns.

This patch includes a commit to fix an issue in the chunked doseq, where seq was called on chunk-rest too early. When combinded with chunked concat this caused some laziness tests to fail.

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

chouser@n01se.net said: [file:d1Zsv2Ke4r3QR8eJe5afGb]: Add support for chunked seqs to 'for'

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

chouser@n01se.net said: (In [[r:dbe1710652618c842e513760e985c2219d71926b]]) delay seq on chunk-rest in doseq

doseq was calling seq on chunk-rest too early. When combinded with chunked
concat this caused some laziness tests to fail. Refs #1

Branch: master

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

chouser@n01se.net said: (In [[r:4af9fcf218c04db9b38fb4ce35591f1ff17a4f15]]) Add chunked seq support to concat

concat is defined early, so I moved the the chunk fns up which required
changing 'chunk-cons' to use static methods directly instead of core fns.
Refs #1

Branch: master

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

chouser@n01se.net said: (In [[r:14316ae2110a779ffc8ac9c3da3f1c41852c4289]]) Add support for chunked seqs to 'for'. Refs #1

Branch: master





[CLJ-10] GC Issue 6: Include condp in clojure.core 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: None

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


 Description   
Reported by m...@kotka.de, Dec 17, 2008
fcase from clojure.contrib is planned to be included in clojure.core
as condp. Currently there are two suggestions, on how to implement
this.

The attached patch proposes the following form:

(condp predicate expr
  test-expr result-expr
  ...)

For each pair test-expr and result-expr the predicate will
be called in the form (predicate test-expr result-expr). If
the predicate returns true, the result-expr is executed.

Using the vector binding form as known from let and friends
one might also assign the result of the call to predicate to
a local which may be used in the result-expr.

(condp [local predicate] expr
  test-expr result-expr
  ...)

If the number of test-expr result-expr pairs is odd, then
the last clause is evaluated, in case no previous clause was
chosen by the predicate. If the number of pairs is even,
an exception is thrown.

Furthermore the following changes to cond are proposed
to implement functionality similar to clojure.contrib.cond-let.

(cond
  [local test-expr] result-expr
  ...)

In case the test-expr in cond is a vector the first item is
used as the name of local which is bound to result of the
test-expr (second item in the vector) in result-expr.

This patch is backward-compatible.

Additionally another solution using templates was proposed
on the google group. More information on this proposal
may be found in the following thread:

http://groups.google.com/group/clojure/browse_thread/thread/19544014a89f24e9/dfdecc1bc
8330785?lnk=gst&q=stab+condp#dfdecc1bc8330785

 cond-condp.patch
2.9 KB Download
Comment 1 by richhickey, Dec 17, 2008
You meant: (predicate test-expr expr) right?

I think we should take any changes to cond off the table at present. 

It would be nicer if condp could do binding on a per-clause basis, as you did for
cond, but doing it the same way would rule out vectors as test exprs (with predicates
like nth, I guess).

The alternative is Scheme's:

test-expr => result-fn

where result-fn is a fn of one arg, passed the result of the predicate.

This can end up being more compact. I guess in Clojure we'd use a keyword:

test-expr :> result-fn

Comment 2 by m...@kotka.de, Dec 18, 2008
Modified the implementation. The syntax is now as follows:

(condp predicate expr
  test-expr result-expr
  test-expr :> result-expr
  ...)

In the first case result-expr is evaluated and its result is returned
if (predicate test-expr expr) returns non-nil/non-false.

In the second case, result-expr is expected to evaluate to a function
of one argument, which is passed the result of the predicate call.
Again: only if the result of the predicate call is non-nil/non-false.

In case there is a single clause at the end which does not fit the above
patterns it is taken as default in case no test-expr yields a success.
If no such default is given an exception is thrown.

The patterns may be freely mixed.

Cond is not modified.
 condp.diff
2.6 KB Download
Comment 3 by richhickey, Dec 21, 2008
In the end I found these patches too complex and wrote my own, thanks for the input!
svn 1180
Status: Done


 Comments   
Comment by Assembla Importer [ 24/Aug/10 2:44 PM ]

Converted from http://www.assembla.com/spaces/clojure/tickets/10
Attachments:
cond-condp.patch - https://www.assembla.com/spaces/clojure/documents/cYdAoCw28r3PSteJe5afGb/download/cYdAoCw28r3PSteJe5afGb
condp.diff - https://www.assembla.com/spaces/clojure/documents/cYdDdIw28r3PSteJe5afGb/download/cYdDdIw28r3PSteJe5afGb

Comment by Assembla Importer [ 24/Aug/10 2:44 PM ]

cemerick said: [file:cYdAoCw28r3PSteJe5afGb]

Comment by Assembla Importer [ 24/Aug/10 2:44 PM ]

cemerick said: [file:cYdDdIw28r3PSteJe5afGb]





[CLJ-13] GC Issue 9: Not all *vars* have doc strings 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: None

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


 Description   
Reported by richhickey, Dec 17, 2008
Need to audit and fix

Comment 1 by richhickey, Dec 17, 2008
(No comment was entered for this change.)
Owner: ---
Comment 2 by mmcgrana, Jan 05, 2009
Possible audit method for public clojure.core *vars missing doc strings:

(prn
  (let [publics (ns-publics 'clojure.core)
        stared  (filter #(re-find #"^\*" (str (first %))) publics)
        undoced (remove #(:doc (meta (second %))) stared)]
    (map first undoced)))

=> (*compile-path* *ns* *allow-unresolved-vars* *macro-meta* ...
Comment 3 by chouser, Jan 09, 2009
For Vars interned via Java code, there's no original 'def' statement
where docstrings can be added.  Should a block of statments like
following be added to the end of clojure/core.clj ?

(alter-meta! #'*compile-path* assoc :doc
  "Specifies the directory where 'compile' will write out .class
  files.  This directory must be in the classpath for 'compile' to
  work.")

Comment 4 by richhickey, Jan 10, 2009
That seems right to me
Comment 5 by Chousuke, Jan 18, 2009
Here is a patch that adds at least *some* documentation for some of the variables.
It's missing a few that I did not know the purpose for, though.

--
Jarkko
 var-doc.patch
2.5 KB Download
Comment 6 by richhickey, Jan 22, 2009
Patch applied - svn 1225 - thanks!
Status: Fixed


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

Converted from http://www.assembla.com/spaces/clojure/tickets/13
Attachments:
var-doc.patch - https://www.assembla.com/spaces/clojure/documents/aC6tlAw3ar3Qr1eJe5aVNr/download/aC6tlAw3ar3Qr1eJe5aVNr

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

cemerick said: [file:aC6tlAw3ar3Qr1eJe5aVNr]





[CLJ-3] Test ticket Created: 16/Jun/09  Updated: 24/Aug/10  Resolved: 24/Aug/10

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

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


 Description   

this is a test ticket



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

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





[CLJ-14] GC Issue 10: remove all #=()s from non-dup prints 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: None

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


 Description   
Reported by richhickey, Dec 17, 2008
Need to audit and fix

Comment 1 by richhickey, Dec 17, 2008
(No comment was entered for this change.)
Owner: ---
Comment 2 by chouser, Jan 09, 2009
Currently:

user=> (java.util.HashMap. {:a 1})
#=(java.util.HashMap. {:a 1})

What's the desired output?  Perhaps the unreadable:

#<java.util.HashMap. {:a 1}>

Comment 3 by richhickey, Jan 10, 2009
Yes, the unreadable form is good
Comment 4 by chouser, Jan 10, 2009
All occurrences of #= are in RT.java and core_print.clj.

In core_print.clj, all occurrences of #= are in print-dup methods,
except for one occurrence in the print-ctor function.  print-ctor is
in turn used only in print-dup methods, except for 3 print-method's
for Java set, map, and collection types.  The attached patch removes
those print-method's, causing the default method to be used, which
generates informative output for humans but which is not readable by
LispReader.

In RT.java, #= is generated by the print() method when
PRINT_INITIALIZED is unbound or false, for Class and Var objects.
Changing these to print non-dup style output makes the Clojure compile
process throw exceptions, so I'm guess these need to stay the way they
are.

For the record, these outputs can be tested at the REPL like this:

(defmacro pre-init [x]
  `(binding [clojure.core/print-initialized false]
    (clojure.lang.RT/print ~x *out*)
    (println)))

user=> (pre-init Integer)
#=java.lang.Integer
nil
user=> (pre-init #'filter)
#=(var clojure.core/filter)
nil

--The janitor
 remove-hash-equals.patch
1.7 KB Download
Comment 5 by richhickey, Jan 14, 2009
Patch applied, svn 1209 - thanks!
Status: Fixed


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

Converted from http://www.assembla.com/spaces/clojure/tickets/14
Attachments:
remove-hash-equals.patch - https://www.assembla.com/spaces/clojure/documents/a7a0y0w3ar3PSteJe5afGb/download/a7a0y0w3ar3PSteJe5afGb

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

cemerick said: [file:a7a0y0w3ar3PSteJe5afGb]





[CLJ-7] GC Issue 2: gen-class - :exposes should expose static fields as static methods 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: None

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


 Description   
Reported by richhickey, Dec 14, 2008
right now it doesn't look at type of field, and always generates instance
methods

Comment 1 by richhickey, Dec 17, 2008
(No comment was entered for this change.)
Owner: ---
Comment 2 by richhickey, Dec 18, 2008
(No comment was entered for this change.)
Labels: Priority-High
Comment 3 by chouser, Mar 06, 2009
The attached patch was tested using this gen-class call:

  (ns clojure.contrib.test-clojure.gen-class
    (:gen-class
      :extends javax.swing.border.TitledBorder
      :exposes {TEXT_SPACING {:get getSpacing :set setSpacing}
                title {:get getString :set setString}}))

Then:

  (compile 'clojure.contrib.test-clojure.gen-class)
  (def x (clojure.contrib.test_clojure.gen_class. "hi"))

  (.getString x)  ==> "hi"
  (.setString x "yo")
  (.getString x)  ==> "yo"

  (.getSpacing x)
  ==> java.lang.IncompatibleClassChangeError: Expected non-static field
clojure.contrib.test_clojure.gen_class.TEXT_SPACING (NO_SOURCE_FILE:0)

With the patch applied, .getString and .setString work the same, but now:

  (clojure.contrib.test_clojure.gen_class/getSpacing)  ==> 2
  (clojure.contrib.test_clojure.gen_class/setSpacing 10)
  ==> java.lang.IllegalAccessError (NO_SOURCE_FILE:0)

This last error is because the static field is final.

--Chouser
 genclass-exposes-statics.patch
2.2 KB Download
Comment 4 by richhickey, Apr 12, 2009
Patch applied - r1345 - thanks!
Status: Fixed


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

Converted from http://www.assembla.com/spaces/clojure/tickets/7
Attachments:
genclass-exposes-statics.patch - https://www.assembla.com/spaces/clojure/documents/dvSatqw24r3PSteJe5afGb/download/dvSatqw24r3PSteJe5afGb

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

cemerick said: [file:dvSatqw24r3PSteJe5afGb]





[CLJ-9] GC Issue 5: Allow single classes in import 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: None

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


 Description   
Reported by m...@kotka.de, Dec 17, 2008
Currently import expects lists of a packages with classes, which should be imported
from the given package.

(import '(package ClassA ClassB ...) ...)

Sometimes however one just wants to import a single class from a package, but
one still has to specify the list form:

(import '(package ClassA))

use/require also allow a similar style of prefix list. However, they also allow a
shortcut in case one requires only one lib with a given prefix. The attached
patch modifies import to allow also this style of shortcut:

(import 'package.ClassA)

This change would be backward compatible.


 modified-import.patch
1.3 KB Download
Comment 1 by m...@kotka.de, Dec 17, 2008
I'm sorry for the dupe. The proxy gave me an error message, so I submitted again...
Also sorry for the wrong categorisation. Should be Enhancement not Defect...
Comment 2 by richhickey, Dec 17, 2008
(No comment was entered for this change.)

Comment 3 by richhickey, Dec 17, 2008
 Issue 4  has been merged into this issue.
Comment 4 by richhickey, Dec 17, 2008
(No comment was entered for this change.)
Owner: richhickey
Comment 5 by richhickey, Dec 17, 2008
I think the conditional here should test for symbol? rather than seq?, i.e. reverse
the condition. We should avoid hardwiring lists when possible.
Comment 6 by m...@kotka.de, Dec 19, 2008
Ok. Checks for symbol? now and if branches reversed. 
 modified-import.patch
1.3 KB Download
Comment 7 by richhickey, Dec 21, 2008
patch applied (svn 1179) - thanks!
Status: Done


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

Converted from http://www.assembla.com/spaces/clojure/tickets/9
Attachments:
modified-import.patch - https://www.assembla.com/spaces/clojure/documents/bRbEa2w28r3P8LeJe5afGb/download/bRbEa2w28r3P8LeJe5afGb

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

cemerick said: [file:bRbEa2w28r3P8LeJe5afGb]





[CLJ-20] GC Issue 16: Pretty printing 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: Release 1.2

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

Approval: Ok

 Description   
Reported by richhickey, Dec 17, 2008
A rudimentary pprint
Some efforts have been posted to group, no consensus yet


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

Converted from http://www.assembla.com/spaces/clojure/tickets/20
Attachments:
add-pprint.diff - https://www.assembla.com/spaces/clojure/documents/aPTaMOvS8r36QjeJe5cbCb/download/aPTaMOvS8r36QjeJe5cbCb
add-pprint.diff - https://www.assembla.com/spaces/clojure/documents/aXqnnYvS8r3630eJe5cbLA/download/aXqnnYvS8r3630eJe5cbLA
verify-added-metadata-for-pprint-api.patch - https://www.assembla.com/spaces/clojure/documents/dtjKrQvVCr36mfeJe5cbLr/download/dtjKrQvVCr36mfeJe5cbLr

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

richhickey said: Should now be - move pprint to clojure.jar

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

richhickey said: Updating tickets (#8, #42, #113, #2, #20, #94, #96, #104, #119, #124, #127, #149, #162)

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

tomfaulhaber said: We'll address this by moving the version of pprint from contrib into clojure for 1.2.

The plan is:

1. Remove the gen-class requirement from pprint (see ticket 81 in clojure)

2. Create a branch of clojure that includes:

  • The clojure.contrib.pprint tree less the examples directory (I'll put these in their own github project for the moment).
  • A new doc directory for the supporting docs that get picked up by autodoc (this is broken right now, but I'm about to fix it).
  • tests moved from contrib to clojure tests

3. Create a patch that matches my branch. Add it to the ticket.

4. Commit the patch once it's reviewed

5. Update contrib to point back to clojure with the appropriate deprecation warnings.

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

tomfaulhaber said: [file:aPTaMOvS8r36QjeJe5cbCb]: The patch that add clojure.pprint

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

tomfaulhaber said: [file:aXqnnYvS8r3630eJe5cbLA]: The patch that adds clojure.pprint

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

stu said: [file:dtjKrQvVCr36mfeJe5cbLr]

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

stu said: The following vars are the doc'ed, public API. These are the same as contrib, minus earmuffs on code-dispatch and simple-dispatch.

*print-base*
*print-miser-width*
*print-pprint-dispatch*
*print-pretty*
*print-radix*
*print-right-margin*
*print-suppress-namespaces*
cl-format
code-dispatch
formatter
formatter-out
fresh-line
get-pretty-writer
pp
pprint
pprint-indent
pprint-logical-block
pprint-newline
pprint-tab
set-pprint-dispatch
simple-dispatch
with-pprint-dispatch
write
write-out
Comment by Assembla Importer [ 24/Aug/10 6:44 AM ]

stu said: Tom's patch looks good. My patch simply adds a test for :added metadata.

Don't forget: We'll need a separate code change to refer some vars at the repl.





[CLJ-4] test ticket 2 Created: 16/Jun/09  Updated: 24/Aug/10  Resolved: 24/Aug/10

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

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


 Description   

a second test ticket



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

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





[CLJ-18] GC Issue 14: make RT.ROOT_CLASSLOADER load on demand, possibly never if AOT compiled 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: None

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


 Description   
Reported by richhickey, Dec 17, 2008
To enable applets and other situations not supporting custom classloaders
or dynamic classloading

Comment 1 by richhickey, Dec 17, 2008
(No comment was entered for this change.)
Labels: -Type-Defect Type-Enhancement
Comment 2 by richhickey, Jan 07, 2009
svn 1201
Status: Fixed


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

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





[CLJ-16] GC Issue 12: improve doc for contains? 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: None

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


 Description   
Reported by richhickey, Dec 17, 2008
Explain the behavior of contains? for vectors, i.e. associative

Comment 1 by richhickey, Dec 18, 2008
(No comment was entered for this change.)
Labels: Priority-High
Comment 2 by chouser, Jan 09, 2009
Expands both 'contains?' and 'some' docstrings.
 contains-docs.patch
1.3 KB Download
Comment 3 by richhickey, Jan 14, 2009
patch applied, svn 1214 - thanks!
Status: Fixed


 Comments   
Comment by Assembla Importer [ 24/Aug/10 2:44 PM ]

Converted from http://www.assembla.com/spaces/clojure/tickets/16
Attachments:
contains-docs.patch - https://www.assembla.com/spaces/clojure/documents/bU13Y0w3ar3Qr1eJe5aVNr/download/bU13Y0w3ar3Qr1eJe5aVNr

Comment by Assembla Importer [ 24/Aug/10 2:44 PM ]

cemerick said: [file:bU13Y0w3ar3Qr1eJe5aVNr]





[CLJ-26] GC Issue 22: Make sure all integer ops return smallest representation 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: None

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


 Description   
Reported by richhickey, Dec 28, 2008
Right now not all integers that can be represented as longs are, leading to
cases of different representations of integers of same value, and the
resulting problems for hashCode.

Comment 1 by christophe.grand, Dec 29, 2008
added LongOps 
uncommented the two lines in reduce(BigInteger)
 LongOps.patch
4.9 KB Download
Comment 2 by richhickey, Dec 29, 2008
Thanks! I'm having some problems applying the patch. I get a LongOps class with
several opsWith(LongOps) entries and other errors.

Would it be possible to produce a patch/diff with more context?
Comment 3 by christophe.grand, Dec 29, 2008
diff -u5 this time, hoping it works better for you than plain svn diff.
 LongOps.diff
5.6 KB Download
Comment 4 by richhickey, Dec 29, 2008
Patch applied - svn 1190 - thanks!
Status: Fixed


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

Converted from http://www.assembla.com/spaces/clojure/tickets/26
Attachments:
LongOps.diff - https://www.assembla.com/spaces/clojure/documents/czfSXuw3er3P8LeJe5afGb/download/czfSXuw3er3P8LeJe5afGb
LongOps.patch - https://www.assembla.com/spaces/clojure/documents/czfVTsw3er3P8LeJe5afGb/download/czfVTsw3er3P8LeJe5afGb

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

cemerick said: [file:czfSXuw3er3P8LeJe5afGb]

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

cemerick said: [file:czfVTsw3er3P8LeJe5afGb]





[CLJ-23] GC Issue 19: Unquote not in syntax-quote yield (unquote x) 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: None

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


 Description   
Reported by richhickey, Dec 23, 2008
Currently yields an Unquote object
clojure/unquote would remain undefined, thus would still be error if
evaluated, but user macros could use for escaping

Comment 1 by richhickey, Dec 23, 2008
added svn 1184
Status: Fixed


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

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





[CLJ-29] GC Issue 25: ClassNotFoundException when loading a clojure app under the Android vm 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: None

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


 Description   
Reported by va3pip, Dec 29, 2008
What (small set of) steps will reproduce the problem?
Compile and run a clojure based Android app under the emulator.  While
loading, it'll throw a clojure.core__init class not found exception. A good
sample clojure Android app is at: 
    http://github.com/Nafai77/helloandroid/tree/master

What is the expected output? What do you see instead?
It should be able to find clj based classes

What version are you using?
svn 1191

Please provide any additional information below.
I've attached a patch to RT.java that changes classForName() and
loadClassForName() to try the default classloader if DynamicClassLoader
fails to find the requested class.  I probably overlooked some corner case
with these 2 changes, so I'll expect you'll fix/change this patch :) - but
I'll send in a CA tomorrow anyways, just in case.  Note: it still won't run
the app as there's a VerifyError with StringBuilder.append() - for details,
see:   http://paste.lisp.org/display/72811

 dalvikvm.patch
791 bytes Download
Comment 1 by richhickey, Dec 30, 2008
svn 1192
Status: Fixed


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

Converted from http://www.assembla.com/spaces/clojure/tickets/29
Attachments:
dalvikvm.patch - https://www.assembla.com/spaces/clojure/documents/dFLbLCw3er3R14eJe5aVNr/download/dFLbLCw3er3R14eJe5aVNr

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

cemerick said: [file:dFLbLCw3er3R14eJe5aVNr]





[CLJ-25] GC Issue 21: bigdec truncates rational 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: None

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


 Description   
Reported by tomfaulhaber, Dec 28, 2008
The clojure.core/bigdec function truncates rationals to ints:

(bigdec 1/2) => 0M

As opposed to:

(bigdec 0.5) => 0.5M

This happens because rationals fall into the number? case in bigdec which
converts the rational to a long before converting to BigDecimal.

I'm not sure that this behavior is completely wrong (since there's no way
to specify the behavior of 1/3 in the current API, for instance), but we
should probably at least document it.


Comment 1 by jbondeson, Jan 30, 2009
I discussed this along with another issue here:
http://groups.google.com/group/clojure/browse_thread/thread/1f8029b8556ce851/9b7538b192490097?lnk=gst&q=ratio#9b7538b192490097

(bigdec (/ 1 3)) should probably behave exactly like (/ 1M 3) which throws an
ArithmeticException unless you are inside a "with-precision" block.

I have attached a rather simple fix for this to have Ratio -> BigDecimal conversion
behave like this.
 bigdec-ratio.diff
521 bytes Download
Comment 2 by richhickey, Feb 09, 2009
fixed in svn 1257 - thanks!
Status: Fixed


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

Converted from http://www.assembla.com/spaces/clojure/tickets/25
Attachments:
bigdec-ratio.diff - https://www.assembla.com/spaces/clojure/documents/b-hcCaw3er3Qr1eJe5aVNr/download/b-hcCaw3er3Qr1eJe5aVNr

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

cemerick said: [file:b-hcCaw3er3Qr1eJe5aVNr]





[CLJ-24] GC Issue 20: release-pending-sends 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: None

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


 Description   
Reported by richhickey, Dec 23, 2008
Agents in perpetual loops would like to send actions that don't wait for
current action completion

Comment 1 by richhickey, Dec 23, 2008
added in svn 1185
Status: Fixed


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

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





[CLJ-28] GC Issue 24: Remove hard search for .class files in RT.load 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: None

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


 Description   
Reported by richhickey, Dec 29, 2008
On Android, class can be loadable without accessible .class file, so no
.class or .clj is not an error. Must try to load speculatively in that case.

Comment 1 by richhickey, Dec 29, 2008
svn 1188
Status: Fixed


 Comments   
Comment by Assembla Importer [ 24/Aug/10 2:44 PM ]

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





[CLJ-27] GC Issue 23: mod (modulo) operator 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: None

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


 Description   
Reported by mark.engelberg, Dec 28, 2008
mod (modulo) is similar to rem, but the result will always have the same
positive/negative sign as the second input:

(mod 2 5) -> 2
(mod 2 -5) -> -3
(mod -2 5) -> 3
(mod -2 -5) -> -2

Note that rem always has a result whose sign matches the first input:
(rem 2 5) -> 2
(rem 2 -5) -> 2
(rem -2 5) -> -2
(rem -2 -5) -> -2

So mod and rem yield the same answer if both inputs are positive, or both
are negative.  However, when the signs are mixed, they differ.

Sample code:
(defn mod [a b]
  (if (or (< a 0 b) (< b 0 a))
    (+ (rem a b) b)
    (rem a b)))
Comment 1 by achim.passen, Dec 29, 2008
A patch that adds mod and sgn
 mod-sgn.diff
6.9 KB Download
Comment 2 by richhickey, Jan 07, 2009
hmm... Mark's sample code looks much simpler - anything wrong with it?
Comment 3 by achim.passen, Jan 08, 2009
Not at all, it's functionally equivalent. I implemented it in Java mainly to be consistent with the other basic math 
op implementations. The Java version seems to be a tick faster (~500ms vs ~600ms on 100000 pairs of 
randomly typed random numbers here).

Attached is a simplified patch which adds LongOps support and gets rid of signum.


 r1205+mod.diff
4.9 KB Download
Comment 4 by richhickey, Jan 22, 2009
Added Mark's version, SVN 1227 - thanks!
Status: Fixed
Comment 6 by timothypratley, Feb 12, 2009
Yet another 'fixed' version:
(mod 9 -3) -> 0
(mod 4.5 2) -> 0.5
 mod-fix.patch
759 bytes Download
Comment 7 by richhickey, Feb 23, 2009
patch applied - svn 1302 - thanks!


 Comments   
Comment by Assembla Importer [ 24/Aug/10 2:44 PM ]

Converted from http://www.assembla.com/spaces/clojure/tickets/27
Attachments:
mod-fix.patch - https://www.assembla.com/spaces/clojure/documents/c5Ksw6w3er3PSteJe5afGb/download/c5Ksw6w3er3PSteJe5afGb
r1205mod.diff - https://www.assembla.com/spaces/clojure/documents/c5KveQw3er3PSteJe5afGb/download/c5KveQw3er3PSteJe5afGb
mod-sgn.diff - https://www.assembla.com/spaces/clojure/documents/c5KxFww3er3PSteJe5afGb/download/c5KxFww3er3PSteJe5afGb

Comment by Assembla Importer [ 24/Aug/10 2:44 PM ]

cemerick said: [file:c5Ksw6w3er3PSteJe5afGb]

Comment by Assembla Importer [ 24/Aug/10 2:44 PM ]

cemerick said: [file:c5KveQw3er3PSteJe5afGb]

Comment by Assembla Importer [ 24/Aug/10 2:44 PM ]

cemerick said: [file:c5KxFww3er3PSteJe5afGb]





[CLJ-32] GC Issue 28: Substraction sometimes yields wrong result due to IntegerOps.Negate overflow (with 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: None

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


 Description   
Reported by olov.lassus, Jan 02, 2009
Negating Integer.MIN_VALUE overflows but should return a BigInteger.  
It also affects binary subtraction since Clojure implements it using  
negation and addition. The overflow occurs silently without throwing  
an exception.

These examples trigger the flaw:

user=> (- -2147483648)
-2147483648

user=> (- -1 -2147483648)
-2147483649


The attached patch apply cleanly against trunk r1195. Same examples after
applying it:

user=> (- -2147483648)
2147483648

user=> (- -1 -2147483648)
2147483647

 detect_negate_overflow.patch
507 bytes Download
Comment 1 by richhickey, Jan 07, 2009
fixed in svn 1203
Status: Fixed


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

Converted from http://www.assembla.com/spaces/clojure/tickets/32
Attachments:
detect_negate_overflow.patch - https://www.assembla.com/spaces/clojure/documents/aC6MlEw3ir3Qr1eJe5aVNr/download/aC6MlEw3ir3Qr1eJe5aVNr

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

cemerick said: [file:aC6MlEw3ir3Qr1eJe5aVNr]





[CLJ-30] GC Issue 26: agent error queue 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: Release 1.2

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

Approval: Ok

 Description   
Reported by richhickey, Jan 01, 2009
Route agent errors to a queue

Comment 1 by chouser, May 26, 2009
The attached patch allows agents to have an error-callback, which could be used to
route errors to one or more queues.

Example usage:

user=> (send-off (agent nil
                   :error-callback (fn [a es]
                                     (.printStackTrace (first es))
                                     (clear-agent-errors a)))
                 (fn f [_]
                   (Thread/sleep 1000)
                   (send-off *agent* f)))
#<Agent@5dd2b9b7: nil>
user=> (shutdown-agents)
nil
user=>
java.lang.RuntimeException: Error executing action user$eval__394$f__399@63d87b85
        at clojure.lang.Agent$Action.execute(Agent.java:63)
        at clojure.lang.Agent$Action.doRun(Agent.java:107)
        at clojure.lang.Agent$Action.run(Agent.java:118)
        at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
        at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
        at java.lang.Thread.run(Thread.java:619)
Caused by: java.util.concurrent.RejectedExecutionException
        at
java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:1760)
        at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:767)
        at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:658)
        at clojure.lang.Agent$Action.execute(Agent.java:57)
        ... 5 more

 error-callback.patch
3.9 KB Download


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

Converted from http://www.assembla.com/spaces/clojure/tickets/30
Attachments:
error-callback.patch - https://www.assembla.com/spaces/clojure/documents/dY6WBiw3er3R14eJe5aVNr/download/dY6WBiw3er3R14eJe5aVNr
agent-error-handler-v1.diff - https://www.assembla.com/spaces/clojure/documents/cwEwcA_RSr3RpIeJe5aVNr/download/cwEwcA_RSr3RpIeJe5aVNr

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

cemerick said: [file:dY6WBiw3er3R14eJe5aVNr]

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 ]

richhickey said: could you please name them set/get-agent-error-callback and mark them as experimental? thanks

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

richhickey said: <pre>could you please name them set/get-agent-error-callback and mark them as experimental? thanks></pre>

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

richhickey said: could you please name them set/get-agent-error-callback and mark them as experimental? thanks

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

chouser@n01se.net said: <pre>I was under the impression this patch had some significant
flaws:

http://clojure-log.n01se.net/date/2009-05-26.html#11:22-11:50

Specific issues:

  • error handlers using clear-agent-errors
  • the error being a seq instead of a single error
  • no way for the handler to know what the action or action
    args were (needed to re-run the action)

Is marking this as "experimental" sufficient to cover those
issues for now?</pre>

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

richhickey said: <pre>
I agree this still needs work, but would be nice to get it in people's hands
to get some feedback.

I guess don't mark it fixed until we are happy with it? Or, we could create a branch
</pre>

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

richhickey said: We need to finesse this a bit or pull for 1.1. I'm not sure anyone is using it, so we've had no feedback. I don't want to marry the error seq, so how about just simply:

agent + exception
clear-agent-errors is not ok in a handler
mark as experimental - subject to change

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

chouser@n01se.net said: A proposed solution is discussed here:

http://www.assembla.com/wiki/show/clojure/Agent_exception_handlers

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

chouser@n01se.net said: [file:cwEwcA_RSr3RpIeJe5aVNr]: Implementation of :error-handler proposal – still needs docstrings and more testing, but code should be complete.

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

chouser@n01se.net said: (In [[r:b63af1ad6ce38b50552be3c424ea166cb063ee7c]]) Add agent error handlers and error modes :fail and :continue. Fixes #30

Branch: master





[CLJ-22] GC Issue 18: with-open allows multiple bindings but silently closes only the first 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: None

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


 Description   
Reported by Chousuke, Dec 18, 2008
in Clojure rev 1175
------------------------------
(import '(java.io StringReader))
(def stream1 (StringReader. "Test"))
(def stream2 (StringReader. "Test2"))

(with-open [a stream1 b stream2] (println "do-nothing"))

(.ready stream2) ; should throw an exception, but doesn't, since stream2 is
not closed

the reason is simple enough: in with-open, the bindings parameter is passed
to let, but in the finally clause, only a simple (.close ~(first bindings))
is emitted.

I have a patch to make with-open support multiple bindings cleanly, but I
do not have a CA so I can't submit it.

--
Jarkko Oranen




Comment 1 by m...@kotka.de, Dec 18, 2008
Reading the docstring I get the impression, that only one binding was intended at the beginning.
However allowing multiple bindings would a) not be a problem, b) justify the let style binding and
c) have pratical relevance.

I attached a simple patch.
 with-open.diff
887 bytes Download
Comment 2 by Chousuke, Dec 19, 2008
The patch is essentially identical to the solution I came up with, except that I used
let* instead of let for safety because destructuring doesn't make sense for with-open.

I'm going to have to go submit a CA so that next time I have an issue with a solution
I can actually submit the patch myself :)
Comment 3 by richhickey, Dec 19, 2008
That is a good point - destructuring is not supported. I don't think let* is the way
to achieve that - no one should be writing let* directly. The macro could just check
that all bindings are to simple symbols.

Also, the closes should happen in reverse order.

This can be achieved by solving the last, most important problem - you can't just do
this with one let, as each binding could potentially fail:

open a
open b
throw exception opening c

b and a never closed.

i.e., multi-binding with-open must use nested lets/trys, maybe could be defined in
terms of recursive calls to current macro.
Comment 4 by m...@kotka.de, Dec 19, 2008
Argh. I should really think, before writing.

Ok. Here the next idea:
with-open calls itself recursively. It checks that the next binding target (?) is a symbol.
Then it assigns just this one binding to a let and again calls itself wrapped in a try. This
gives in particular the reverse order for closing. And in case something bad happens
during opening ensures that previously opened streams are closed.

I had one problem though: Since we check for the bindings being a vector, one has
to take care, that one passes around the bindings again as a vector. Or one uses an
inner macro, where with-open does the check and then passes on to with-open*,
which also accepts a seq.

I took a different route and simply did a subvec instead of a take or drop. Then
we check for the vector several times, but I think this is the least intrusive version.
I had to move the subvec defn upwards, though.

 with-open.diff
2.3 KB Download
Comment 5 by richhickey, Dec 23, 2008
Patch applied (svn 1182) - thanks!
Status: Fixed


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

Converted from http://www.assembla.com/spaces/clojure/tickets/22
Attachments:
with-open.diff - https://www.assembla.com/spaces/clojure/documents/aq046Aw3er3PSteJe5afGb/download/aq046Aw3er3PSteJe5afGb
with-open-1.diff - https://www.assembla.com/spaces/clojure/documents/aq08wqw3er3PSteJe5afGb/download/aq08wqw3er3PSteJe5afGb

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

cemerick said: [file:aq046Aw3er3PSteJe5afGb]

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

cemerick said: [file:aq08wqw3er3PSteJe5afGb]





[CLJ-37] GC Issue 33: resultset-seq breaks when the result set contains duplicate column names (with 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: None

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


 Description   
Reported by arohner, Jan 05, 2009
What (small set of) steps will reproduce the problem?

Create a java.sql.ResultSet containing two columns with the same name, and
then pass it to resultset-seq. 

What is the expected output? What do you see instead?
The expected output is an exception message that is helpful in diagnosing
the problem. resultset-seq instead throws "java.lang.RuntimeException:
java.lang.IllegalArgumentException: Too many arguments to struct constructor" 

What version are you using?
This was first reproduced in r1060. svn shows the function has not been
touched since 2008-07-29

Was this discussed on the group? If so, please provide a link to the
discussion:
http://groups.google.com/group/clojure/browse_frm/thread/e533e9cdf758f210?q=#43e5775c2d959dc7
http://groups.google.com/group/clojure/browse_thread/thread/58e4921de5c86c3c/7ca1de2daad839da?show_docid=7ca1de2daad839da

The attached patch modifies resultset-seq to throw an exception with the
message "
 resultset-seq.patch
1.5 KB Download
Comment 1 by arohner, Jan 05, 2009
The attached patch modifies resultset-seq to throw an exception with the message
"result set must have unique column names" when the column names are duplicated. It
also moves the definition of the set function above resultset-seq.
Comment 2 by richhickey, Feb 09, 2009
shouldn't this use distinct? instead of set+count
Comment 3 by arohner, Feb 09, 2009
You're right. I was not aware of distinct? Attaching v2 of the patch. This time,
rather than moving the definition of set up, I've moved the definition of
resultset-seq to below the definition of distinct?
 resultset-seq.v2.patch
2.2 KB Download
Comment 4 by richhickey, Apr 12, 2009
Fixed (also moved to using column labels) - r1346 - thanks for the report.
Status: Fixed


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

Converted from http://www.assembla.com/spaces/clojure/tickets/37
Attachments:
resultset-seq.patch - https://www.assembla.com/spaces/clojure/documents/cAajI6w3ir3PSteJe5afGb/download/cAajI6w3ir3PSteJe5afGb
resultset-seq.v2.patch - https://www.assembla.com/spaces/clojure/documents/cAamwsw3ir3PSteJe5afGb/download/cAamwsw3ir3PSteJe5afGb

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

cemerick said: [file:cAajI6w3ir3PSteJe5afGb]

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

cemerick said: [file:cAamwsw3ir3PSteJe5afGb]





[CLJ-36] GC Issue 32: Fix stray CPL comments and docstring for 'delay' 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: None

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


 Description   
Reported by chouser, Jan 05, 2009
What (small set of) steps will reproduce the problem?

N/A

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

N/A

What version are you using?

SVN 1195

Was this discussed on the group? If so, please provide a link to the
discussion:

http://groups.google.com/group/clojure/browse_thread/thread/b2d73537eca894f0/d5a3b1e31f80c49f

Please provide any additional information below.

 comments.patch
5.6 KB Download
Comment 1 by richhickey, Jan 06, 2009
oops - gotta change that comment template in all my editors

patch applied svn 1197 - thanks!
Status: Fixed


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

Converted from http://www.assembla.com/spaces/clojure/tickets/36
Attachments:
comments.patch - https://www.assembla.com/spaces/clojure/documents/b-6ZScw3ir3Qr1eJe5aVNr/download/b-6ZScw3ir3Qr1eJe5aVNr

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

cemerick said: [file:b-6ZScw3ir3Qr1eJe5aVNr]





[CLJ-40] GC Issue 36: Add Counted marker interface 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: None

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


 Description   
Reported by richhickey, Jan 07, 2009
Marker interface with no methods. Would indicate O(1) count for
collections. Could be used to optimize vectr creation and some sequence ops

Comment 1 by chouser, Feb 10, 2009
Besides Java built-in classes, RT.count() works on
IPersistentCollection objects, so these are the ones that need to be
examined to see if they should implement Counted.

(defn getClassesInDir [basedir subdir]
  (let [regex (re-pattern (str basedir #"(.*)\.class"))]
    (map #(Class/forName (.replace (second (re-find regex (str %))) "/" "."))
         (.listFiles (java.io.File. (str basedir subdir))))))

(def clj-classes (getClassesInDir "/home/chouser/build/clojure/classes/" "clojure/lang"))

(defn has-count? [c]
  (try (.getMethod c "count" (into-array Class []))
    (catch NoSuchMethodException e)))

(count (filter has-count? clj-classes))  ==> 62 -- hopefully there are some useful
base classes.

(defn has-own-count? [c]
  (try (.getDeclaredMethod c "count" (into-array Class []))
    (catch NoSuchMethodException e)))

(count (filter has-own-count? clj-classes))  ==> 26 -- better

user=> (dorun (map println (sort (map str (filter has-own-count? clj-classes)))))
class clojure.lang.AMapEntry
class clojure.lang.APersistentSet
class clojure.lang.APersistentVector$RSeq
class clojure.lang.APersistentVector$Seq
class clojure.lang.APersistentVector$SubVector
class clojure.lang.ASeq
class clojure.lang.ArraySeq
class clojure.lang.ArraySeq$ArraySeq_double
class clojure.lang.ArraySeq$ArraySeq_float
class clojure.lang.ArraySeq$ArraySeq_int
class clojure.lang.ArraySeq$ArraySeq_long
class clojure.lang.Cons
class clojure.lang.LazilyPersistentVector
class clojure.lang.PersistentArrayMap
class clojure.lang.PersistentArrayMap$Seq
class clojure.lang.PersistentHashMap
class clojure.lang.PersistentList
class clojure.lang.PersistentList$EmptyList
class clojure.lang.PersistentQueue
class clojure.lang.PersistentQueue$Seq
class clojure.lang.PersistentStructMap
class clojure.lang.PersistentTreeMap
class clojure.lang.PersistentTreeMap$Seq
class clojure.lang.PersistentVector
class clojure.lang.Range
interface clojure.lang.IPersistentCollection

The promise of Counted is non-obvious for some of these.  For example,
APersistentSet and PersistentStructMap both have count() methods that
rely on IPersistentMap, which does not itself promise Counted.
However everything in clojure.lang that currently provides
IPersistentMap also promises Counted, so it seems appropriate for
APersistentSet and PersistentStructMap to promise Counted as well.

Similarly, APersistentVector$Seq uses count() from IPersistentVector
which does not itself promise Counted.  But since PersistentVector and
LazilyPersistentVector are both Counted, APersistentVector$Seq can
promise Counted.

Finally, PersistentQueue and PersistentQueue$Seq use ISeq.count(), but
the only ISeqs they use are PersistentList or seqs on vectors, so both
can also promise Counted.

If any of those conclusions are incorrect, or if the Counted marker
should be moved up to a parent interface in any of those cases, please
let me know.

The first patch attached marks almost all of the 'has-own-count?'
classes listed earlier as Counted.  The four non-Counted classes from
that list are:

(dorun (map println (filter #(and (has-own-count? %)
                                  (not (isa? % clojure.lang.Counted)))
                            clj-classes)))
clojure.lang.ASeq
clojure.lang.PersistentTreeMap$Seq
clojure.lang.Cons
clojure.lang.IPersistentCollection

There are total of 36 Counted classes, and 27 non-Counted
IPersistentCollection classes.

 add-counted.patch
10.2 KB Download
Comment 2 by richhickey, Feb 10, 2009
Thanks for doing the legwork on this, fixed in 1268
Status: Fixed


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

Converted from http://www.assembla.com/spaces/clojure/tickets/40
Attachments:
add-counted.patch - https://www.assembla.com/spaces/clojure/documents/adJv1uw3mr3PSteJe5afGb/download/adJv1uw3mr3PSteJe5afGb

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

cemerick said: [file:adJv1uw3mr3PSteJe5afGb]





[CLJ-35] GC Issue 31: Report more incorrect usages of binding vectors 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: None

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


 Description   
Reported by chouser, Jan 05, 2009
What (small set of) steps will reproduce the problem?

The (< x y) form of the following expression is silently ignored:
(take 100 (for [x  (range 1000) y (range 1000) (< x y)][x y])) 

What version are you using?

SVN 1195

Was this discussed on the group? If so, please provide a link to the
discussion:

http://groups.google.com/group/clojure/browse_thread/thread/56793fb65903cece

Please provide any additional information below.

The attached patch is identical to the one in the discussion thread.
 binding-assertions.patch
8.1 KB Download
Comment 1 by richhickey, Jan 07, 2009
patch applied - svn 1205 - thanks!
Status: Fixed


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

Converted from http://www.assembla.com/spaces/clojure/tickets/35
Attachments:
binding-assertions.patch - https://www.assembla.com/spaces/clojure/documents/bQyrVOw3ir3R14eJe5aVNr/download/bQyrVOw3ir3R14eJe5aVNr

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

cemerick said: [file:bQyrVOw3ir3R14eJe5aVNr]





[CLJ-39] GC Issue 35: Wiki is closed to the public 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: None

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


 Description   
Reported by dresweng...@dreish.org, Jan 07, 2009
Last night on IRC, the GC Wiki was suggested as a way to organize a users'
wish-list so rhickey can conveniently ignore it and focus on real issues in
the issue tracker.  Unfortunately, it appears only rhickey is allowed to
edit, much less add pages to, the wiki.

Comment 1 by richhickey, Jan 07, 2009
No, the suggestion was to use the user wiki:

http://en.wikibooks.org/wiki/Clojure_Programming
Status: WontFix


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

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





[CLJ-38] GC Issue 34: A Lisp reader without access to EvalReader() 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: None

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


 Description   
Reported by dresweng...@dreish.org, Jan 06, 2009
Like any good Lisp, Clojure can compile and run code while reading, read and compile code while 
running, and read and run code while compiling.

Unfortunately that means it isn't safe for an application to use (read) to read something from an 
untrusted source. If the input stream contains, e.g., #=(eval (def core-app-function #(throw 
(Exception.)))), the application would blow up.

Feature request is for a version of the reader that has #= shut off, for reading untrusted data.

(Discussion was on #clojure; rhickey asked me to add this, so there's no Google Group discussion 
that I'm aware of.)
Comment 1 by christophe.grand, Jan 17, 2009
the aforementioned discussion: http://clojure-log.n01se.net/date/2009-01-06.html#18:41c
Comment 2 by the.stuart.sierra, Feb 18, 2009
Common Lisp has *read-eval*:
http://www.lispworks.com/documentation/HyperSpec/Body/v_rd_eva.htm

A similar flag might be an easy way to implement a "safe" reader.
Comment 3 by jhawk28, Mar 17, 2009
adds the *read-eval*
 Issue 34.patch.txt
2.1 KB Download
Comment 4 by richhickey, Apr 12, 2009
Patch applied - r1347 - thanks!
Status: Fixed


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

Converted from http://www.assembla.com/spaces/clojure/tickets/38
Attachments:
Issue34.patch.txt - https://www.assembla.com/spaces/clojure/documents/c3JgXGw3ir3PSteJe5afGb/download/c3JgXGw3ir3PSteJe5afGb

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

cemerick said: [file:c3JgXGw3ir3PSteJe5afGb]





[CLJ-41] GC Issue 37: .hashCode and .equals for Clojure vectors/seqs break Java contract. 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: None

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


 Description   
Reported by wolfe.a.jason, Jan 07, 2009
What (small set of) steps will reproduce the problem?

(list (.equals [1 2] (seq [1 2])) (.hashCode [1 2]) (.hashCode '(1 2)))


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

I see (true 994 -1919631597)
I think I should see (true i i), or perhaps (false i j) for some ints i, j


What version are you using?

svn 1162


Was this discussed on the group? If so, please provide a link to the
discussion:

http://groups.google.com/group/clojure/browse_thread/thread/5d11bc0da25a7ecc/06d6cd888a516119?hl=en&lnk=gst&q=.hashcode#06d6cd888a516119

Nobody asked me to add this here so I hope this isn't out of line ... 


Please provide any additional information below.

The crux is, the Java API says:

"If two objects are equal according to the equals(Object)  method, then
calling the hashCode method on each of the two objects must produce the
same integer result. "

As you can see here:

user> (doseq [s ['(1 2) (seq '(1 2)) [1 2] (seq [1 2]) (ArrayList. [1
2])]]
  (print "\n" (.hashCode s))
  (doseq [t ['(1 2) (seq '(1 2)) [1 2] (seq [1 2]) (ArrayList. [1
2])]]
    (print "\t" (.equals s t))))

 -1919631597     true    true    true    true    false
 -1919631597     true    true    true    true    false
 994             true    true    true    true    true
 -1919631597     true    true    true    true    false
 994             false   false   true    false   true 

this contract is violated by Clojure collections.  In particular, 
(.equals [1 2] (seq [1 2]) but they have different .hashCode()s.  

Some issues this can cause
  - Clojure hash-map and array-map have different behaviors
  - (get (hash-map {(vector &args) true} (list &args)) will return true
    iff there is a hash collision between the vector and list (?) 
  - Unexpected pain in unknown places when using Clojure objects in Java
code that expects the contract to hold

-Jason

Comment 1 by wolfe.a.jason, Jan 07, 2009
P.S. I realized that the reason for the discrepancy might be that java.util.list
hashCodes (used by vectors) are defined in a front-to-back manner.  This makes it
perhaps non-obvious how to efficiently compute them recursively back-to-front, as one
might like to to for seqs (so that each rest-seq can cache its hash value).  This
code shows that this can in fact be done efficiently.

(defn forward-hash "How hashCode() is defined in java.util.List"  [s]
  (loop [s (seq s) h (int 1)]
    (if s 
        (recur (rest s) (int (unchecked-add (unchecked-multiply h 31) (hash (first s)))))
      h)))


(def int-pow 
     (memoize 
      (fn [x n]
 (let [x (int x) n (int n)]
   (cond (zero? n) 1
  (even? n) (let [h (int-pow x (/ n 2))] (unchecked-multiply h h))
  :else     (unchecked-multiply x (int-pow x (dec n))))))))

(defn backward-hash "Compute the same value as forward-hash, but back-to-front."  [s]
  (let [s (seq s) p (int-pow 31 (count (rest s)))]
    (if s 
        (unchecked-add (unchecked-multiply 30 p)
         (unchecked-add (int (backward-hash (rest s)))
          (unchecked-multiply (int (hash (first s))) p)))
 1)))
   

user> (map #(% (vec (range 1000))) [forward-hash backward-hash #(.hashCode %)])
(133786869 133786869 133786869)

HTH, Jason

P.P.S. I'll put my Contributor Agreement in the mail today.   
Comment 2 by wolfe.a.jason, Jan 07, 2009
Note on a small special case: Java null effectively has hash code 0 (I think) whereas
java.util.List hashCode() must be 1 for empty Lists.  Fortunately, the REPL says:

user> (.equals [1] (seq [1]))
true
user> (.equals [] (seq []))
false

so I guess the empty vector is not .equal to the empty seq anyway (as mandated by the
Java API).  So, giving non-empty seqs java.util.List hashCodes would in fact be the
right thing to do, it seems to me.  


Comment 3 by richhickey, Jan 15, 2009
Fixed - svn 1215 - thanks for the report

Status: Fixed


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

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





[CLJ-43] GC Issue 39: Reader metadata fails for empty collection literals 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: None

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


 Description   
Reported by chouser, Jan 09, 2009
What (small set of) steps will reproduce the problem?

Originally reported by Tomasz Skutnik.

user=> (meta #^{:some :metadata} [])
nil
user=> (meta #^{:some :metadata} ())
nil
user=> (meta #^{:some :metadata} {})
nil

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

I expect to see metadata {:some :metadata} as I do in these cases:

user=> (meta #^{:some :metadata} [1])
{:some :metadata}
user=> (meta '#^{:some :metadata} (1))
{:some :metadata}
user=> (meta #^{:some :metadata} {:a 1})
{:some :metadata}
user=> (meta (with-meta [] {:some :metadata}))
{:some :metadata}
user=> (meta (with-meta () {:some :metadata}))
{:some :metadata}
user=> (meta (with-meta {} {:some :metadata}))
{:some :metadata}

What version are you using?

SVN 1205

Was this discussed on the group? If so, please provide a link to the
discussion:

http://groups.google.com/group/clojure/msg/686e161b780565e0

Please provide any additional information below.

Comment 1 by richhickey, Jan 14, 2009
fixed in svn 1213 - thanks for the report
Status: Fixed


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

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





[CLJ-46] GC Issue 42: Classes from :methods argument vectors are not resolved before passing to overload-names (+ 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: None

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


 Description   
Reported by m...@kotka.de, Jan 10, 2009
What (small set of) steps will reproduce the problem?

Try to compile the following namespace definition:

(ns foo.Bar
  (:gen-class
     :methods [[toString [Object] String]]))

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

I expect this to compile normally, but the following exception is thrown:

1:1 user=> (binding [*compile-path* "tmp"] (compile 'foo.Bar))
java.lang.RuntimeException: java.lang.RuntimeException: java.lang.RuntimeException: 
java.lang.RuntimeException: java.lang.RuntimeException: java.lang.RuntimeException: 
java.lang.RuntimeException: java.lang.IllegalArgumentException: No matching field found: 
getSimpleName for class clojure.lang.Symbol (Bar.clj:1)

What version are you using?

SVN rev. 1195

Was this discussed on the group? If so, please provide a link to the discussion:

The issue was brought up by baggins on #clojure:
http://clojure-log.n01se.net/date/2009-01-10.html#07:54

Please provide any additional information below.

Attached is a patch, which fixes the symptom. But I'm not sure, whether it fixes the issue.
 issue-42.diff
851 bytes Download
Comment 1 by richhickey, Jan 14, 2009
Path applied - svn 1210 - thanks!
Status: Fixed


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

Converted from http://www.assembla.com/spaces/clojure/tickets/46
Attachments:
issue-42.diff - https://www.assembla.com/spaces/clojure/documents/cdfd3ww3mr3Qr1eJe5aVNr/download/cdfd3ww3mr3Qr1eJe5aVNr

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

cemerick said: [file:cdfd3ww3mr3Qr1eJe5aVNr]





[CLJ-44] GC Issue 40: Overflow check in Numbers.minus (+ 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: None

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


 Description   
Reported by achim.passen, Jan 10, 2009
There are some corner cases where "-"  overflows but does not throw an "integer overflow" 
exception:

user=> (- Integer/MAX_VALUE Integer/MIN_VALUE) 
-1 
user=> (- Long/MAX_VALUE Long/MIN_VALUE) 
-1 

The problem seems to be that negating MIN_VALUE yields MIN_VALUE   
again, so it slips through the overflow check. The patch adds extra checks for MIN_VALUE.

version: SVN r1205

http://groups.google.com/group/clojure/browse_thread/thread/3db6cb2b71008e73

 overflow.diff
693 bytes Download
Comment 1 by richhickey, Jan 14, 2009
patch applied - svn 1212 - thanks!
Status: Fixed


 Comments   
Comment by Assembla Importer [ 24/Aug/10 2:44 PM ]

Converted from http://www.assembla.com/spaces/clojure/tickets/44
Attachments:
overflow.diff - https://www.assembla.com/spaces/clojure/documents/bz9pX-w3mr3PSteJe5afGb/download/bz9pX-w3mr3PSteJe5afGb

Comment by Assembla Importer [ 24/Aug/10 2:44 PM ]

cemerick said: [file:bz9pX-w3mr3PSteJe5afGb]





[CLJ-45] GC Issue 41: [PATCH] several macros claim to want only 2 binding forms, allow more 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: None

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


 Description   
Reported by Chousuke, Jan 10, 2009
several macros only check for (even? (count bindings)) even though they
should check for exactly 2 bindings. 

Trivial fix attached.

--
Jarkko Oranen
 fix-check.patch
1.5 KB Download
Comment 1 by chouser, Jan 10, 2009
Whoops.  Thanks for catching that, Jarkko.
Comment 2 by richhickey, Jan 14, 2009
patch applied - svn 1211 - thanks!
Status: Fixed


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

Converted from http://www.assembla.com/spaces/clojure/tickets/45
Attachments:
fix-check.patch - https://www.assembla.com/spaces/clojure/documents/bU2G4ow3mr3PSteJe5afGb/download/bU2G4ow3mr3PSteJe5afGb

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

cemerick said: [file:bU2G4ow3mr3PSteJe5afGb]





[CLJ-51] GC Issue 47: format, name and namespace are not hinted {:tag String} 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: None

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


 Description   
Reported by christophe.grand, Jan 15, 2009
format, name and namespace are not hinted {:tag String}

(If you can't apply this patch, I promise to never use svn diff again!)
 name-namespace-format.patch
933 bytes Download
Comment 1 by christophe.grand, Jan 16, 2009
A broader patch that removes many reflection warnings from clojure.core files.
(I don't see how to prevent inlinable fns to raise warnings for their "default case".)
 clojure-core-hints.patch
14.6 KB Download
Comment 2 by christophe.grand, Jan 17, 2009
added hints to to-array and to-array-2d.
 clojure-core-hints2.patch
15.2 KB Download
Comment 3 by richhickey, Jan 24, 2009
This is great!

patch applied - svn 1229 - thanks!
Status: Fixed


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

Converted from http://www.assembla.com/spaces/clojure/tickets/51
Attachments:
clojure-core-hints.patch - https://www.assembla.com/spaces/clojure/documents/a67udew3qr3P8LeJe5afGb/download/a67udew3qr3P8LeJe5afGb
clojure-core-hints2.patch - https://www.assembla.com/spaces/clojure/documents/a67xgIw3qr3P8LeJe5afGb/download/a67xgIw3qr3P8LeJe5afGb
name-namespace-format.patch - https://www.assembla.com/spaces/clojure/documents/a67z28w3qr3P8LeJe5afGb/download/a67z28w3qr3P8LeJe5afGb

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

cemerick said: [file:a67udew3qr3P8LeJe5afGb]

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

cemerick said: [file:a67xgIw3qr3P8LeJe5afGb]

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

cemerick said: [file:a67z28w3qr3P8LeJe5afGb]





[CLJ-48] GC Issue 44: non-Exception throwables stay wrapped in InvocationTargetException 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: None

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


 Description   
Reported by s-google...@localtoast.org, Jan 14, 2009
What (small set of) steps will reproduce the problem?

Invoke a java method which throws an AssertionError (or any other subclass
of Error), through reflection.

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

I'd expect to catch the AssertionError object itself (which is the case for
a type-annotated call). Instead, I end up catching an InvocationTargetException

What version are you using?

r1214

Comment 1 by richhickey, Jan 24, 2009
Could you please provide some Clojure code that demonstrates the problem?
Comment 2 by s-google...@localtoast.org, Jan 29, 2009
; method defined through clojure for brevity, any java method which throws a
non-Exception will suffice
user=> (defn throw-error [] (throw (new Error)))
#'user/throw-error

; expected behavior (type annotation creates a direct call)
user=> (let [#^clojure.lang.IFn o throw-error] (.invoke o))
java.lang.Error (NO_SOURCE_FILE:0)

; unexpected behavior, the reflect code has wrapped our Throwable
user=> (let [o throw-error] (.invoke o))
java.lang.reflect.InvocationTargetException (NO_SOURCE_FILE:0)


Comment 3 by richhickey, Feb 23, 2009
fixed - svn 1303 - thank for the report
Status: Fixed
Comment 4 by berlin.brown, Feb 24, 2009
I am getting this error also, is this fixed in the december release:


(defn simple-mkdirs-handler
  "Simple utility to make directories.  Throws error on invalid directory."
  [dirname]
  ;;;;;;;;;;;;;;;;;
  (if (empty? dirname) (throw (Error. "ERR: <mkdirs> Invalid Directory"))
      (let [file (new File dirname)]
        (if (not (.canWrite file))
          (throw (Error. "ERR: <mkdirs> Invalid Directory. Cannot write."))
          (try (.mkdirs file)
               (catch Exception e
                      (throw (Error. (str "ERR: <mkdirs> Invalid Directory. Cannot
mkdir => " 
                                          (.getMessage e))))))))))


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

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





[CLJ-53] GC Issue 49: Complement ~x => (unquote x) with ~@x => (unquote-splicing x) 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: None

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


 Description   
Reported by m...@kotka.de, Jan 18, 2009
Describe the feature/change.

Currently, ~ outside a syntax-quote is expanded to (clojure.core/unquote ..).
However this is not done for ~@. The attached patch also introduces the
expansion of ~@ to (clojure.core/unquote-splicing ...).

Was this discussed on the group? If so, please provide a link to the discussion:

http://groups.google.com/group/clojure/browse_frm/thread/6d0c5f7e37909055


 issue-49.diff
2.2 KB Download
Comment 1 by richhickey, Feb 09, 2009
patch applied - svn 1263 - thanks!
Status: Fixed


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

Converted from http://www.assembla.com/spaces/clojure/tickets/53
Attachments:
issue-49.diff - https://www.assembla.com/spaces/clojure/documents/b1TQrsw3qr3Qr1eJe5aVNr/download/b1TQrsw3qr3Qr1eJe5aVNr

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

cemerick said: [file:b1TQrsw3qr3Qr1eJe5aVNr]





[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-55] GC Issue 51: defmacro forms return nil when evaled 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: None

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


 Description   
Reported by christophe.grand, Jan 19, 2009
defmacro forms return nil when evaled while defn and def forms return the
defined Var.

 defmacro-returns-var.patch
700 bytes Download
Comment 1 by richhickey, Jan 24, 2009
patch applied - svn 1230 - thanks!
Status: Fixed


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

Converted from http://www.assembla.com/spaces/clojure/tickets/55
Attachments:
defmacro-returns-var.patch - https://www.assembla.com/spaces/clojure/documents/cGmKtuw3qr3P8LeJe5afGb/download/cGmKtuw3qr3P8LeJe5afGb

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

cemerick said: [file:cGmKtuw3qr3P8LeJe5afGb]





[CLJ-52] GC Issue 48: Per defmulti hierarchies 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: None

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


 Description   
Reported by m...@kotka.de, Jan 17, 2009
Describe the feature/change.

This is an issue from the TODO list.

Currently multimethods use the global-hierarchy. However sometimes it is useful, to define
a dedicated hierarchy for a given set of multimethods. The attached patch adds a new
:hierarchy argument to defmulti which specifies the desired hierarchy. The hierarchy may be
any IRef.

The patch depends on the patch of  issue #8 .

Was this discussed on the group? If so, please provide a link to the discussion:

http://groups.google.com/group/clojure/browse_frm/thread/f8b1be403c927b03/438c21a8007
2a105?lnk=gst&q=per+defmulti+hierarchies

 issue-48.diff
3.4 KB Download
Comment 1 by richhickey, Feb 09, 2009
patch applied - svn 1262 - thanks!
Status: Fixed


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

Converted from http://www.assembla.com/spaces/clojure/tickets/52
Attachments:
issue-48.diff - https://www.assembla.com/spaces/clojure/documents/bFLf80w3qr3PSteJe5afGb/download/bFLf80w3qr3PSteJe5afGb

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

cemerick said: [file:bFLf80w3qr3PSteJe5afGb]





[CLJ-33] GC Issue 29: Range sometimes yields wrong sequence (with 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: None

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


 Description   
Reported by olov.lassus, Jan 02, 2009
The clojure.lang.Range type is implemented with integer type start and end
indices. The core.clj range function should detect when an index doesn't
fit inside an int and create an increasing sequence using iterate instead.
The current implementation detects too large positive, but not too large
negative ranges. The overflow occurs silently without throwing an exception.

Before:
user=> (take 1 (range -2147483649 0))
(2147483647)


After applying the patch which apply cleanly against trunk r1195:
user=> (take 1 (range -2147483649 0))
(-2147483649)


I also made the range function slightly less conservative < vs <= wise.
This shouldn't affect correctness but (range 0 2147483647) will now return
a Range (after patch) instead of a LazyCons (before).

 support_large_negative_range.patch
918 bytes Download
Comment 1 by richhickey, Jan 07, 2009
Patch applied - svn 1204 - thanks!
Status: Fixed


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

Converted from http://www.assembla.com/spaces/clojure/tickets/33
Attachments:
support_large_negative_range.patch - https://www.assembla.com/spaces/clojure/documents/a9MAyww3ir3Qr1eJe5aVNr/download/a9MAyww3ir3Qr1eJe5aVNr

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

cemerick said: [file:a9MAyww3ir3Qr1eJe5aVNr]





[CLJ-56] GC Issue 52: Make set/union accept any number of arguments 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: None

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


 Description   
Reported by konrad.h...@laposte.net, Jan 20, 2009
Describe the feature/change.

set/union currently accepts two sets as arguments. The operation is well defined for any number of 
sets and similar operations (+, concat, ...) take any number of arguments, so I think set/union 
should do so as well.

Was this discussed on the group? If so, please provide a link to the discussion:


 set-union.diff
575 bytes Download
Comment 1 by scgilardi, Jan 20, 2009
There are implementations here as well:

http://groups.google.com/group/clojure/msg/5bb548afe2cbbe02

At one point, this was on Rich's public Clojure "to-do" list.

Comment 2 by wolfe.a.jason, Jan 22, 2009
On a somewhat related note, let me plug my own post about efficient set operations:

http://groups.google.com/group/clojure/browse_thread/thread/29609929e94f279c?hl=en#

(I am in favor of multi-arg set functions as well; while my versions don't do this, I
believe this can be done simply by (reduce union #{} sets) or (reduce
intersection/difference (first sets) (rest sets))


Comment 3 by wolfe.a.jason, Feb 02, 2009
This may now be subsumed by this issue:

http://code.google.com/p/clojure/issues/detail?id=64&colspec=ID%20Type%20Status%20Priority%20Reporter%20Owner%20Summary

which includes a patch for multi-arg, more efficient
clojure.set/union/difference/intersection functions.
Comment 4 by richhickey, Feb 22, 2009
(No comment was entered for this change.)
Status: Fixed


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

Converted from http://www.assembla.com/spaces/clojure/tickets/56
Attachments:
set-union.diff - https://www.assembla.com/spaces/clojure/documents/c5rguUw3qr3PSteJe5afGb/download/c5rguUw3qr3PSteJe5afGb

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

cemerick said: [file:c5rguUw3qr3PSteJe5afGb]





[CLJ-49] GC Issue 45: :post-init option for gen-class 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: None

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


 Description   
Reported by chouser, Jan 15, 2009
Describe the feature/change.

It's currently impossible to create a class with gen-class that calls
its own (or its super-classes') methods when it is constructed.  This
is a problem if there is stateful initialization required by the
superclass for which it has only methods, not ctor args.

Was this discussed on the group? If so, please provide a link to the
discussion:

http://groups.google.com/group/clojure/browse_thread/thread/d1fbdb7450b46dee/b5539e4a21c411c6
http://clojure-log.n01se.net/date/2009-01-15.html#10:22-10:37a

Comment 1 by chouser, Mar 07, 2009
(No comment was entered for this change.)
 gen-class-post-init.patch
3.7 KB Download
Comment 2 by cjkent, Mar 24, 2009
I've applied the patch and it works, but only if I define a post-init function with
no args.  I was expecting at least a single "this" arg.  Or is there another way to
get a reference to the newly created object?
Comment 3 by chouser, Mar 24, 2009
The args given to your class's constructor are passed directly to your post-init
function.  But you have a good point -- the 'this' arg should probably be included. 
I've attached a new patch that allows this:

(ns clojure.contrib.test-clojure.gen-class
  (:gen-class
     :extends javax.swing.border.TitledBorder
     :constructors {[int int String] [String]}
     :init my-init
     :post-init after-ctor))

(defn -my-init [x y s]
  (println "Init ignoring" x "and" y ", going with" (str "foo+" s))
  [[(str "foo+" s)] nil])

(defn -after-ctor [this x y s]
  (print "Constructing" this "with ")
  (prn x y s))

user=> (compile 'clojure.contrib.test-clojure.gen-class)
clojure.contrib.test-clojure.gen-class

user=> (clojure.contrib.test_clojure.gen_class. 3 4 "hello")
Init ignoring 3 and 4 , going with foo+hello
Constructing #<gen_class clojure.contrib.test_clojure.gen_class@1ab2b55> with 3 4 "hello"
#<gen_class clojure.contrib.test_clojure.gen_class@1ab2b55>

 post-init.patch
3.8 KB Download
Comment 4 by cjkent, Mar 25, 2009
Great, that works perfectly.  Thanks.
Comment 5 by richhickey, Apr 12, 2009
Patch applied - r1348 - thanks!
Status: Fixed


 Comments   
Comment by Assembla Importer [ 24/Aug/10 2:44 PM ]

Converted from http://www.assembla.com/spaces/clojure/tickets/49
Attachments:
post-init.patch - https://www.assembla.com/spaces/clojure/documents/acQi8-w3qr3PSteJe5afGb/download/acQi8-w3qr3PSteJe5afGb
gen-class-post-init.patch - https://www.assembla.com/spaces/clojure/documents/acQlMww3qr3PSteJe5afGb/download/acQlMww3qr3PSteJe5afGb

Comment by Assembla Importer [ 24/Aug/10 2:44 PM ]

cemerick said: [file:acQi8-w3qr3PSteJe5afGb]

Comment by Assembla Importer [ 24/Aug/10 2:44 PM ]

cemerick said: [file:acQlMww3qr3PSteJe5afGb]





[CLJ-57] GC Issue 53: tree-seq arbitrarily requires its root arg to be a branch 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: None

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


 Description   
Reported by christophe.grand, Jan 24, 2009
r1228:
user=> (tree-seq (constantly false) seq [1 2 3])
([1 2 3] 1 2 3) ; I expected ([1 2 3])

The actual behaviour of tree-seq is undefined when the root isn't a branch
since children is called upon root without any check.

The attached patch fixes this by always checking if a node is a branch
before calling children on it.

http://groups.google.com/group/clojure/browse_thread/thread/335707370295b654



 tree-seq.patch
1.6 KB Download
Comment 1 by richhickey, Jan 24, 2009
patch applied - svn 1231 - thanks!
Status: Fixed


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

Converted from http://www.assembla.com/spaces/clojure/tickets/57
Attachments:
tree-seq.patch - https://www.assembla.com/spaces/clojure/documents/doKXrMw3qr3PSteJe5afGb/download/doKXrMw3qr3PSteJe5afGb

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

cemerick said: [file:doKXrMw3qr3PSteJe5afGb]





[CLJ-62] GC Issue 58: `() gives strange compiler error (i.e. backquote of empty list) 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: None

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


 Description   
Reported by tuomas.lukka, Jan 29, 2009

What (small set of) steps will reproduce the problem?

Run the code `()   

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

I'd expect it to return a quoted empty list. Instead an error results:

Exception in thread "main" java.lang.UnsupportedOperationException: Unknown
Collection type (test.clj:1)
 at clojure.lang.Compiler.load(Compiler.java:4476)
 at clojure.lang.Compiler.loadFile(Compiler.java:4437)
 at clojure.lang.Script.main(Script.java:65)
Caused by: java.lang.UnsupportedOperationException: Unknown Collection type
 at clojure.lang.LispReader$SyntaxQuoteReader.syntaxQuote(LispReader.java:711)
 at clojure.lang.LispReader$SyntaxQuoteReader.invoke(LispReader.java:655)
 at clojure.lang.LispReader.read(LispReader.java:143)
 at clojure.lang.Compiler.load(Compiler.java:4466)
 ... 2 more

What version are you using?

20081217

Was this discussed on the group? If so, please provide a link to the
discussion:

no

Please provide any additional information below.

Comment 1 by richhickey, Feb 09, 2009
fixed in svn 1255 - thanks for the report
Status: Fixed


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

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





[CLJ-63] GC Issue 60: Ratio to floating point conversion miscalculation 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: None

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


 Description   
Reported by jbondeson, Jan 30, 2009
Originally discussed here:
http://groups.google.com/group/clojure/browse_thread/thread/1f8029b8556ce851/9b7538b192490097?lnk=gst&q=ratio#9b7538b192490097

The current implementation of conversion of clojure.lang.Ratio class
to a fixed precision floating point value is not what one would expect. 
For example:

user> (double (/ (expt 2 1024) 3))
Infinity
when in fact it should return: 5.992310449541053E307  

Attached is the fix for the Ratio class to allow for the proper conversion
to a double or float by using a BigDecimal division with a fixed precision.

Additionally, I sent in my CA on Monday, so it should be there anytime now.
 ratio-conv.diff
1.0 KB Download
Comment 1 by richhickey, Feb 09, 2009
patch applied - svn 1256 - thanks!
Status: Fixed


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

Converted from http://www.assembla.com/spaces/clojure/tickets/63
Attachments:
ratio-conv.diff - https://www.assembla.com/spaces/clojure/documents/ckgKFGw3ur3R14eJe5aVNr/download/ckgKFGw3ur3R14eJe5aVNr

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

cemerick said: [file:ckgKFGw3ur3R14eJe5aVNr]

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

oranenj said: Updating tickets (#63, #65, #66, #67, #68, #70, #73, #74, #75, #76, #78, #80, #81, #83, #86, #88, #90, #92, #93, #95, #97, #98)





[CLJ-54] GC Issue 50: Fully qualified/classpath relative filename in a Var's metadata 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: None

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


 Description   
Reported by m...@kotka.de, Jan 19, 2009
Describe the feature/change.

Currently only the basename of the file where a Var is defined is stored in its metadata.
Unfortunately this is ambiguous. So extracting the exact position in the source tree
through use of the metadata is not possible.

Attached is a patch which stores

- the classpath relative filename for files loaded through the classpath or
- an absolute filename for files loaded via load-file

in the metadata of the Var. This removes any ambiguity.

Was this discussed on the group? If so, please provide a link to the discussion:

This was briefly asked on the #clojure channel.
http://clojure-log.n01se.net/date/2009-01-19.html#11:55

 issue-50.diff
921 bytes Download
Comment 1 by richhickey, Apr 12, 2009
Patch applied - r1349 - thanks!
Status: Fixed


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

Converted from http://www.assembla.com/spaces/clojure/tickets/54
Attachments:
issue-50.diff - https://www.assembla.com/spaces/clojure/documents/clMnZGw3qr3PSteJe5afGb/download/clMnZGw3qr3PSteJe5afGb

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

cemerick said: [file:clMnZGw3qr3PSteJe5afGb]





[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-34] GC Issue 30: Add doc string to ns macro 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: None

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


 Description   
Reported by richhickey, Jan 04, 2009
Support
(ns
  "doc string goes here"
 ...)

Comment 1 by m...@kotka.de, Jan 04, 2009
Allow optional docstrings for a namespace as:

(ns foo.bar
  "docstring here"
  ...)

Attached patch uses the namespace symbol to transport the docstring to the namespace.

The Namespace class is modified to call its superclass constructor with the metadata
of the symbol passed in as name. If the first item of the references part of the ns macro
is a string, it is attached to the metadata of the given Symbol. From there it is again
transferred to the meta data of the Namespace.

Modified doc to check for the given symbol being a Namespace. If so its docstring is
retrieved and printed. If the symbol does not name a Namespace, it is interpreted as
a Var.

Added helper print-namespace-doc to complement print-doc.


 issue-30.diff
2.2 KB Download
Comment 2 by richhickey, Jan 22, 2009
Patch applied - svn 1224 - thanks!
Status: Fixed


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

Converted from http://www.assembla.com/spaces/clojure/tickets/34
Attachments:
issue-30.diff - https://www.assembla.com/spaces/clojure/documents/bvKds6w3ir3Qr1eJe5aVNr/download/bvKds6w3ir3Qr1eJe5aVNr

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

cemerick said: [file:bvKds6w3ir3Qr1eJe5aVNr]





[CLJ-58] GC Issue 54: defn with proxy inside with invalid proxy name gives a strange error 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: None

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


 Description   
Reported by tuomas.lukka, Jan 27, 2009
------------------------------

What (small set of) steps will reproduce the problem?

(defn a []
    (proxy [Runnable] []
        (run [] (println "HEI"))))

(defn a []
    (proxy [Foo] []
        (run [] (println "HEI"))))


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

I'd expect a reasonable compiler error. I get an internal
error instead.
java.lang.NullPointerException (test.clj:7)
 at clojure.lang.Compiler.analyzeSeq(Compiler.java:4113)
 at clojure.lang.Compiler.analyze(Compiler.java:3935)
 at clojure.lang.Compiler.analyze(Compiler.java:3908)
 at clojure.lang.Compiler$BodyExpr$Parser.parse(Compiler.java:3613)
 at clojure.lang.Compiler$FnMethod.parse(Compiler.java:3456)
 at clojure.lang.Compiler$FnMethod.access$1100(Compiler.java:3335)
 at clojure.lang.Compiler$FnExpr.parse(Compiler.java:2921)
 at clojure.lang.Compiler.analyzeSeq(Compiler.java:4104)
 at clojure.lang.Compiler.analyze(Compiler.java:3935)
 at clojure.lang.Compiler.analyzeSeq(Compiler.java:4094)
 at clojure.lang.Compiler.analyze(Compiler.java:3935)
 at clojure.lang.Compiler.access$100(Compiler.java:38)
 at clojure.lang.Compiler$DefExpr$Parser.parse(Compiler.java:366)
 at clojure.lang.Compiler.analyzeSeq(Compiler.java:4106)
 at clojure.lang.Compiler.analyze(Compiler.java:3935)
 at clojure.lang.Compiler.analyzeSeq(Compiler.java:4094)
 at clojure.lang.Compiler.analyze(Compiler.java:3935)
 at clojure.lang.Compiler.analyze(Compiler.java:3908)
 at clojure.lang.Compiler.eval(Compiler.java:4146)
 at clojure.lang.Compiler.load(Compiler.java:4470)
 at clojure.lang.Compiler.loadFile(Compiler.java:4437)
 at clojure.main$load_script__5177.invoke(main.clj:117)
 at clojure.main$script_opt__5209.invoke(main.clj:163)
 at clojure.main$_main__5222.doInvoke(main.clj:227)
 at clojure.lang.RestFn.applyTo(RestFn.java:142)
 at clojure.main.main(Unknown Source)
Caused by: java.lang.NullPointerException
 at clojure.lang.Reflector.invokeInstanceMethod(Reflector.java:26)
 at clojure.core$get_super_and_interfaces__4708.invoke(core_proxy.clj:195)
 at clojure.core$proxy__4729.doInvoke(core_proxy.clj:270)
 at clojure.lang.RestFn.invoke(RestFn.java:445)
 at clojure.lang.Var.invoke(Var.java:335)
 at clojure.lang.AFn.applyToHelper(AFn.java:180)
 at clojure.lang.Var.applyTo(Var.java:444)
 at clojure.lang.Compiler.macroexpand1(Compiler.java:4025)
 at clojure.lang.Compiler.analyzeSeq(Compiler.java:4092)
 ... 25 more



What version are you using?

20081217

Was this discussed on the group? If so, please provide a link to the
discussion:

Please provide any additional information below.

Comment 1 by tuomas.lukka, Jan 27, 2009
(and note that the first expression with Runnable works, the second with Foo is the
one that produces the error).
Comment 2 by richhickey, Apr 12, 2009
Fixed by r1342 - thanks for the report
Status: Fixed


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

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





[CLJ-66] GC Issue 63: docstring for refer-clojure is outdated 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: None

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


 Description   
Reported by chouser, Feb 02, 2009

What (small set of) steps will reproduce the problem?

user=> (doc refer-clojure)
-------------------------
clojure.core/refer-clojure
([& filters])
Macro
  Same as (refer 'clojure <filters>)
nil

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

Docstring should be:
Same as (refer 'clojure.core <filters>)

What version are you using?

1241 trunk

Was this discussed on the group? If so, please provide a link to the
discussion:

http://groups.google.com/group/clojure/msg/598502ccfc42a5ce

Please provide any additional information below.

Comment 1 by richhickey, Feb 09, 2009
fixed in svn 1259 - thanks for the report
Status: Fixed


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

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

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

oranenj said: Updating tickets (#63, #65, #66, #67, #68, #70, #73, #74, #75, #76, #78, #80, #81, #83, #86, #88, #90, #92, #93, #95, #97, #98)





[CLJ-60] GC Issue 56: Make printed IRef's more useful 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: None

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


 Description   
Reported by chouser, Jan 28, 2009
Describe the feature/change.

Currently when you print an IRef, the contents are not printed.  With
the attached patch:

user=> (agent 99)
#<Agent@1dee400: 99>

user=> (atom #{:bomb})
#<Atom@e3849c: #{:bomb}>

user=> (ref "erence")
#<Ref@44cbbe: "erence">

Note that they're no more readable in the (read) sense.  Also note
that Vars are unchanged:

user=> #'nil?
#'clojure.core/nil?

Was this discussed on the group? If so, please provide a link to the
discussion:

http://groups.google.com/group/clojure/browse_thread/thread/e63c5e3e1f429f6e

 print-iref.patch
694 bytes Download
Comment 1 by richhickey, Feb 09, 2009
patch applied - svn 1254 - thanks!
Status: Fixed


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

Converted from http://www.assembla.com/spaces/clojure/tickets/60
Attachments:
print-iref.patch - https://www.assembla.com/spaces/clojure/documents/bprrp8w3ur3O2PeJe5afGb/download/bprrp8w3ur3O2PeJe5afGb

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

cemerick said: [file:bprrp8w3ur3O2PeJe5afGb]





[CLJ-59] GC Issue 55: "repeat" with multiple arities and remove "replicate" 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: None

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


 Description   
Reported by timothypratley, Jan 28, 2009
"repeat" with multiple arities and remove "replicate"
http://groups.google.com/group/clojure/browse_thread/thread/bb2bd6ad6986fed
f


 repeat.patch
746 bytes Download
Comment 1 by timothypratley, Jan 28, 2009
opps didn't mean to submit this yet sorry, hang on.
Comment 2 by timothypratley, Jan 28, 2009
Please find attached the 'real' patch! Sorry, first time using this system.
 repeat.patch
3.1 KB Download
 contrib-repeat.patch
740 bytes Download
Comment 3 by richhickey, Feb 09, 2009
I don't have a CA from you, please see:

http://clojure.org/contributing
Comment 4 by richhickey, Apr 12, 2009
Repeat now supports an optional number-of-repetitions arg. Removing replicate is
another issue
Status: Fixed


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

Converted from http://www.assembla.com/spaces/clojure/tickets/59
Attachments:
repeat.patch - https://www.assembla.com/spaces/clojure/documents/a6jRnuw3ur3O2PeJe5afGb/download/a6jRnuw3ur3O2PeJe5afGb
repeat-1.patch - https://www.assembla.com/spaces/clojure/documents/a6jT6sw3ur3O2PeJe5afGb/download/a6jT6sw3ur3O2PeJe5afGb
contrib-repeat.patch - https://www.assembla.com/spaces/clojure/documents/a6jWBIw3ur3O2PeJe5afGb/download/a6jWBIw3ur3O2PeJe5afGb

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

cemerick said: [file:a6jRnuw3ur3O2PeJe5afGb]

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

cemerick said: [file:a6jT6sw3ur3O2PeJe5afGb]

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

cemerick said: [file:a6jWBIw3ur3O2PeJe5afGb]





[CLJ-70] GC Issue 67: clojure.lang.Compile doesn't provide a way to control *warn-on-reflection* 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: None

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


 Description   
Reported by cemer...@snowtide.com, Feb 06, 2009

Attached is a patch to add a warn-on-reflection option to  
clojure.lang.Compile.  In short, if the clojure.compile.warn-on-
reflection system property is set to "true", then *warn-on-reflection*  
is set to true for the duration of the compile process for the libs  
specified as command line args. 

This feature was discussed in #clojure on 2009.02.05:
http://clojure-log.n01se.net/date/2009-02-05.html#08:18

Comment 1  by richhickey, Feb 09, 2009

patch applied - svn 1260 - thanks!

Status: Fixed


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

Converted from http://www.assembla.com/spaces/clojure/tickets/70
Attachments:
0002-added-warn-on-reflection-option-to-c.l.Compile.patch - https://www.assembla.com/spaces/clojure/documents/avzlIQw3Kr3R14eJe5aVNr/download/avzlIQw3Kr3R14eJe5aVNr

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

oranenj said: [file:avzlIQw3Kr3R14eJe5aVNr]

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

oranenj said: Updating tickets (#63, #65, #66, #67, #68, #70, #73, #74, #75, #76, #78, #80, #81, #83, #86, #88, #90, #92, #93, #95, #97, #98)





[CLJ-65] GC Issue 62: Make clojure.main not exit when exception during --init if user requested a repl 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: None

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


 Description   
Reported by arohner, Jan 31, 2009

Describe the feature/change.

clojure.main should not exit if there was an exception in an --init file
and the user requested a repl. i.e.

java -cp clojure.jar clojure.main --init file-with-errors.clj -r 

should not exit. Having a repl is useful to read doc strings and experiment
with fixes for the problem.

Was this discussed on the group? If so, please provide a link to the
discussion:

http://groups.google.com/group/clojure/browse_frm/thread/f96109d71fa47200#

The attached patch adds a try/catch around the init method for the repl in
clojure.main. It does not change the behavior for the case where the user
specifies a file to run rather than a repl.

Comment 1  by richhickey, Feb 09, 2009
patch applied - svn 1258 - thanks!
Status: Fixed


 Comments   
Comment by Assembla Importer [ 24/Aug/10 2:45 PM ]

Converted from http://www.assembla.com/spaces/clojure/tickets/65
Attachments:
main-not-exit.patch - https://www.assembla.com/spaces/clojure/documents/bcXZ2Cw3Cr3Qr1eJe5aVNr/download/bcXZ2Cw3Cr3Qr1eJe5aVNr

Comment by Assembla Importer [ 24/Aug/10 2:45 PM ]

oranenj said: [file:bcXZ2Cw3Cr3Qr1eJe5aVNr]

Comment by Assembla Importer [ 24/Aug/10 2:45 PM ]

oranenj said: Updating tickets (#63, #65, #66, #67, #68, #70, #73, #74, #75, #76, #78, #80, #81, #83, #86, #88, #90, #92, #93, #95, #97, #98)





[CLJ-68] GC Issue 65: zip/remove does not return the correct loc 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: None

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


 Description   
Reported by christophe.grand, Feb 04, 2009

What (small set of) steps will reproduce the problem?
user=> (require '[clojure.zip :as zip])
user=> (-> '((1 2) 3) zip/seq-zip zip/next zip/next zip/next zip/node)
2
user=> (-> '((1 2) 3) zip/seq-zip zip/next zip/next zip/next zip/next 
zip/node)
3
user=> (-> '((1 2) 3) zip/seq-zip zip/next zip/next zip/next zip/next 
zip/remove zip/node)
(1 2)

What is the expected output? 
2

Was this discussed on the group? If so, please provide a link to the
discussion:
http://groups.google.com/group/clojure/browse_thread/thread/794c17dd17d06b2c/8c2056d8310c2b68?lnk=gst&q=zip%2Fremove#8c2056d8310c2b68

Comment 1 by christophe.grand, Feb 04, 2009

This current patch introduce righmost as an helper function for this fix.

It also adds leftmost and prev which are germane but not directly related to this bug
and its fix.

Comment 2  by richhickey, Feb 09, 2009

patch applied - svn 1259 - thanks!

Status: Fixed


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

Converted from http://www.assembla.com/spaces/clojure/tickets/68
Attachments:
zip-remove.patch - https://www.assembla.com/spaces/clojure/documents/b8uiAYw3Gr3O2PeJe5afGb/download/b8uiAYw3Gr3O2PeJe5afGb

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

oranenj said: [file:b8uiAYw3Gr3O2PeJe5afGb]: on comment 1

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

oranenj said: Updating tickets (#63, #65, #66, #67, #68, #70, #73, #74, #75, #76, #78, #80, #81, #83, #86, #88, #90, #92, #93, #95, #97, #98)





[CLJ-71] GC Issue 68: every? returns nil instead of false 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: Release 1.1

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

Approval: Ok

 Description   
Reported by pedro.dhb, Feb 07, 2009


What (small set of) steps will reproduce the problem?

(every? #{\space} "dam") #=> nil


What is the expected output? What do you see instead?
The expected output is false according to the API docs for every?. Currently nil is returned.

What version are you using?
SVN revision 1252

Was this discussed on the group? If so, please provide a link to the discussion:
It was mentioned on the IRC but not in the groups.

Please provide any additional information below.
_END _INFO



Comment 1 by slash2314, Feb 24, 2009

If need needs to return false in this case, I propose the following patch.


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

Converted from http://www.assembla.com/spaces/clojure/tickets/71
Attachments:
every-false.patch - https://www.assembla.com/spaces/clojure/documents/bjODraw3Kr3O2PeJe5afGb/download/bjODraw3Kr3O2PeJe5afGb
0001-core-make-every-return-false-instead-of-nil.patch - https://www.assembla.com/spaces/clojure/documents/bZMX5WxNqr3P5SeJe5afGb/download/bZMX5WxNqr3P5SeJe5afGb

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

oranenj said: [file:bjODraw3Kr3O2PeJe5afGb]: on comment 1

Comment by Assembla Importer [ 24/Aug/10 4: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 4:45 AM ]

richhickey said: No CA from original submitter - fresh patch welcome

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

richhickey said: Updating tickets (#42, #71)

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

oranenj said: [file:drpB3kxNar3PzkeJe5afGb]

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

oranenj said: [file:bZMX5WxNqr3P5SeJe5afGb]

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

oranenj said: Sorry for the "double post".
This new patch compiles fine for me and passes all the tests in contrib, so it doesn't look like anything depends on every? returning nil.

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

oranenj said: (In [[r:b03e19aa341fea01c1279a74f4184f6538d0f72e]]) core: make every? return false instead of nil

Refs #71

Signed-off-by: Chouser <chouser@n01se.net>

Branch: master

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

chouser@n01se.net said: Created ticket #133 to track this fix against Clojure 1.0. That allows this ticket to be closed.

Dup'ing a ticket like this is a bit of work, but if we like the results it can probably be automated pretty easily.





[CLJ-75] CG Issue 72: clojure.main/repl manipulates *in* in the body of the loop rather than in a read hook, can't override that behavior 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: None

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


 Description   
Reported by scgilardi, Feb 09, 2009

What (small set of) steps will reproduce the problem?

    The defect is apparent by inspecting the source for clojure.main/repl.
Defect reported by Eric Thorsen.

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

    N/A

What version are you using?

    svn 1263

Was this discussed on the group? If so, please provide a link to the
discussion:

    http://groups.google.com/group/clojure/browse_frm/thread/237632fbd6b3c01b

Please provide any additional information below.

    A patch is attached. I cleaned up the read manipulations into a new
repl-read hook. clojure.main/repl is more readable now. I also made
functions in clojure.main for repl-prompt and repl-caught, formerly inline
functions. Clarified some hook descriptions in the docs string for repl.
Avoided using a var (even private) for the eof sentinel in eval-opt.

Note: the number of arguments to the read hook has changed. When this patch
is applied, all previous read hooks will need an update. I'll handle the
one in clojure.contrib.repl-ln.

Comment 1  by richhickey, Feb 10, 2009

Thanks! While this patch says it is based on rev 1263, it doesn't seem to reflect the
changes of rev 1258:

http://code.google.com/p/clojure/source/diff?spec=svn1258&r=1258&format=side&path=/trunk/src/clj/clojure/main.clj

added for  issue 62 :

http://code.google.com/p/clojure/issues/detail?id=62

Is this just an oversight or was there a problem with that patch?


Comment 2 by scgilardi, Feb 10, 2009

It was just an oversight. I'm sorry about that. Thanks for catching it. The enclosed
patch: repl-read-2.patch includes the functionality from the fix to  issue 62 .

Comment 3  by richhickey, Feb 10, 2009

patch applied - svn 1269 - thanks!

Status: Fixed


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

Converted from http://www.assembla.com/spaces/clojure/tickets/75
Attachments:
repl-read.patch - https://www.assembla.com/spaces/clojure/documents/aZ0c5yw3Sr3R14eJe5aVNr/download/aZ0c5yw3Sr3R14eJe5aVNr
repl-read-2.patch - https://www.assembla.com/spaces/clojure/documents/aZ0fMmw3Sr3R14eJe5aVNr/download/aZ0fMmw3Sr3R14eJe5aVNr

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

oranenj said: [file:aZ0c5yw3Sr3R14eJe5aVNr]

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

oranenj said: [file:aZ0fMmw3Sr3R14eJe5aVNr]: on comment 1

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

oranenj said: Updating tickets (#63, #65, #66, #67, #68, #70, #73, #74, #75, #76, #78, #80, #81, #83, #86, #88, #90, #92, #93, #95, #97, #98)





[CLJ-72] GC Issue 69: Documentation: repl_and_main page should discuss use of java -jar clojure.jar 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: None

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


 Description   
Reported by hlship, Feb 08, 2009

In many cases, when you have a script with no extra dependencies outside of
Clojure, it is easiest to:

java -jar clojure.jar myscript.clj

This should be mentioned on:

http://clojure.org/repl_and_main

Comment 1 by richhickey, Feb 09, 2009

This was discussed and it was agreed that this causes more problems later on for new
users when try to use other jars and -cp doesn't work

Status: WontFix


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

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

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

oranenj said: Updating tickets (#72, #82)

WontFix on google code





[CLJ-67] GC Issue 64: Efficient, multi-arg clojure.set/union/difference/intersection 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: None

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


 Description   
Reported by wolfe.a.jason, Feb 02, 2009

Describe the feature/change.

Efficient set operations that use information about set sizes to iterate
through smaller sets.

Was this discussed on the group? If so, please provide a link to the
discussion:

http://groups.google.com/group/clojure/browse_thread/thread/29609929e94f279c?hl=en&tvc=2&q=jason+set

http://groups.google.com/group/clojure/browse_thread/thread/b35ca9035762e1a4/67786ac082d5f6f4?hl=en&lnk=gst&q=jason+set#67786ac082d5f6f4

In particular, the second link describes the algorithms implemented in the
patch.

Also, since you didn't respond to my question, I decided to go ahead and
merge with this issue:

http://code.google.com/p/clojure/issues/detail?id=52&colspec=ID%20Type%20Status%20Priority%20Reporter%20Owner%20Summary

and make multi-arg versions.  I can provide a two-arg patch instead if you
prefer.

Right now, there is no calling of "set" or "set?", and so very unexpected
behavior may occur when non-sets are passed:

user=> (union #{1 2} #{4 5} [5 6 7] #{7 8})
[5 6 7 7 8 1 2 4 5]

(Since the vector is largest, it is used as the seed, and calling "into" on
it uses vector rather than set semantics).

user=> (intersection #{0 1} [5 6 7])
#{0 1}

(Since the set is smallest, it is used as the seed.  Then, when we ask the
vector if it "contains?" 0 or 1, it uses vector contains-index semantics
rather than set contains-value semantics).

If calling "set" on the arguments is low-overhead for things that are
already sets, I would be in favor of that rather than allowing the above
behaviors.  But, I got the impression you would not be, so I left this out
for now.  

Please let me know if you have any questions.

Comment 1  by richhickey, Feb 09, 2009

I don't understand the homemade sorts and two-arg-xxx fns

Comment 2 by wolfe.a.jason, Feb 09, 2009

The "homemade sorts" are several times faster than "sort" or the equivalent, because
they only need to extract the largest or smallest set from the arglist.  I couldn't
find a more concise or clear way of writing them that didn't slow the entire
functions down significantly when passed a few small sets.

The two-arg fns are just helpers, to avoid repeating the same code several times.

Take intersection, for instance.  The basic algorithm is:
  - Find and extract the smallest set from the arg-list
  - Successively intersect this with each other set, using two-arg-intersection
    (which iterates through the first set, which will always be smaller).
This means that intersection is O((size of smallest set) * (number of sets)) rather
than O(sum of set sizes) as you would get with a simpler implementation.



Comment 3 by richhickey, Feb 10, 2009

You could probably use min-key + remove if you don't need a full sort:

(let [mv (apply min-key count vs) ovs (remove #(identical? mv %) vs)]...

If the hand bubble still has utility, you could make it its own function. The
duplication in union and intersection is not good.

As far as the external two-arg-fns, all I meant was that there's no reason not to
make these the two-arg arity overloads themselves, i.e. the variable arity
'difference' can reduce with the arity-2 'difference'. Lots of Clojure code does this.


Comment 4 by wolfe.a.jason, Feb 10, 2009

My main goal in writing these was efficiency; in particular, my objective was to
perform as close to the current versions (with reduce) when passed a bunch of small
(e.g., single-element sets).  This meant trying to reduce the amount of per-argument
overhead.

I originally had factored out an extract-min (i.e., hand-bubble) function, but for it
to work for both union and intersection it had to take a compare or key function as
argument, and this seemed to slow things down substantially over inlining (along with
the one or two extra conses needed).

Similarly, the problem with making the two-arg version of intersection an arity
overload is that (the only way I can see how to do it) this would triple-up on calls
to count.  I guess there's no reason not to do it for difference though; that's
probably an artifact of an earlier version.

Anyway, I'll do some more experiments, try to clean these up a bit more, and submit
an updated patch.  In general, what's your feeling about trading off clarity of code
for efficiency?  For instance, if getting rid of the inlined hand-bubble causes a 50%
performance hit on small sets, is this worth it?

Thanks!

Comment 5 by richhickey, Feb 10, 2009

> In general, what's your feeling about trading off clarity of code for efficiency?  

I'm generally against it.

> For instance, if getting rid of the inlined hand-bubble causes a 50% performance
hit on small sets, is this worth it? 

Yes. Really, I don't want micro-optimized code like this in Clojure. Things change
pretty fast in JVM optimization, and the tweaks you make now can become completely
irrelevant or even counterproductive in the future. Best to keep things simple and clear.


Comment 6 by wolfe.a.jason, Feb 11, 2009

OK, a second stab at a patch is attached.  I've tried to clean things up as much as I
could without hurting efficiency too much.

In particular,
 - I extracted a bubble-max-key function.  I must have done something wrong before,
since this didn't actually slow things down by much.
 - I got rid of the "two-arg" functions.  This had no effect for difference, but
slowed down intersection by up to 40% by tripling calls to "count".

Overall, intersection is up to 45% slower than the previous version, union is up to
25% slower, and difference is the same.  If you really don't like bubble-max-key, you
can replace it by

(defn bubble-max-key [k coll]
  (let [max (apply max-key k coll)]
    (cons max (remove #(identical? max %) coll))))

but this will make union and intersection run about twice as slow on inputs like
[#{1} #{2} #{3}].

Thanks!

Comment 7  by richhickey, Feb 11, 2009

patch applied - svn 1276 - thanks!

Your analysis of how much % slower is flawed though, a classic example of improving
the time of something that will be only a small part of the total runtime with
non-trivial sized sets, i.e. the algorithmic differences matter, the constant factors
per set (count calls etc) don't.

Status: Fixed


 Comments   
Comment by Assembla Importer [ 24/Aug/10 2:45 PM ]

Converted from http://www.assembla.com/spaces/clojure/tickets/67
Attachments:
set-patch.patch - https://www.assembla.com/spaces/clojure/documents/aZFbHiw3Gr3Qr1eJe5aVNr/download/aZFbHiw3Gr3Qr1eJe5aVNr
set-patch2.patch - https://www.assembla.com/spaces/clojure/documents/aZKvGcw3Gr3Qr1eJe5aVNr/download/aZKvGcw3Gr3Qr1eJe5aVNr

Comment by Assembla Importer [ 24/Aug/10 2:45 PM ]

oranenj said: [file:aZFbHiw3Gr3Qr1eJe5aVNr]

Comment by Assembla Importer [ 24/Aug/10 2:45 PM ]

oranenj said: [file:aZKvGcw3Gr3Qr1eJe5aVNr]: on comment 6

Comment by Assembla Importer [ 24/Aug/10 2:45 PM ]

oranenj said: Updating tickets (#63, #65, #66, #67, #68, #70, #73, #74, #75, #76, #78, #80, #81, #83, #86, #88, #90, #92, #93, #95, #97, #98)





[CLJ-74] GC Issue 71: IDeref print method can recurse infinitely 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: None

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


 Description   
Reported by chouser, Feb 09, 2009

What (small set of) steps will reproduce the problem?

(binding [*print-level* 4]
  (let [a (atom nil)]
    (prn (reset! a a))))

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

Desired output:
#<Atom@1e67e6a: #<Atom@1e67e6a: #<Atom@1e67e6a: #<Atom@1e67e6a: #>>>>

Actual output:
#<Atom@1a9d1b: #<Atom@1a9d1b: #<Atom@1a9d1b: #<Atom@1a9d1b: #<Atom@1a9d1b:
#<Atom@1a9d1b: #<Atom@1a9d1b: #<Atom@1a9d1b: ...etc...
StackOverflowError (NO_SOURCE_FILE:0)

What version are you using?

SVN trunk 1261

Was this discussed on the group? If so, please provide a link to the
discussion:

http://clojure-log.n01se.net/date/2009-02-09.html#17:53d

Please provide any additional information below.

Quick work-around for anyone seeing this problem:
(remove-method print-method clojure.lang.IDeref)

At the very least, the *print-level* should be honored, and the
attached patch does that.

Comment 1  by richhickey, Feb 10, 2009

patch applied - svn 1266 - thanks!

Status: Fixed


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

Converted from http://www.assembla.com/spaces/clojure/tickets/74
Attachments:
ideref-honors-print-level.patch - https://www.assembla.com/spaces/clojure/documents/dncD-ow3Or3Qr1eJe5aVNr/download/dncD-ow3Or3Qr1eJe5aVNr

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

oranenj said: [file:dncD-ow3Or3Qr1eJe5aVNr]

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

oranenj said: Updating tickets (#63, #65, #66, #67, #68, #70, #73, #74, #75, #76, #78, #80, #81, #83, #86, #88, #90, #92, #93, #95, #97, #98)





[CLJ-73] GC Issue 70: Maven integration 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: None

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


 Description   
Reported by hlship, Feb 08, 2009

It would be nice if Clojure could be deployed into a Maven repository, with
source, even if it does not use Maven to build.

This is just a matter of keeping the maven-ant-tasks JAR handy, and
providing a POM to identify the clojure version number.

Part of this would be to package the Java source for Clojure, to assist in
debugging.

If there is interest in this (I hope there is) I will be happy to provide a
patch.

I'm also interested in hosting a continuous integration build of Clojure at
Tapestry360 (http://tapestry.formos.com).

Comment 1 by hlship, Feb 08, 2009

Attached is a patch; it removes all but the essential content from pom.xml, and
extends build.xml with new targets for deploying.

You will need the copy of maven-ant-tasks-2.0.9.jar in the root directory.

I would recommend changing the groupId from "jvm.clojure" to "org.clojure" to follow
established standards.

Comment 2  by richhickey, Feb 09, 2009

Thanks.

Will they always need maven-ant-tasks-2.0.9.jar (i.e. when they don't care about
Maven)? Currently, building Clojure requires no deps other than Ant itself

Comment 3 by hlship, Feb 09, 2009

I could reformulate the patch so that maven-ant-tasks is only needed when performing
a deploy operation.  However, there is no problem with just checking the JAR into the
SVN repository. That's what I do on a number of projects that need to be otherwise
self-reliant (i.e., they then download their dependencies from Maven using the tasks
inside the maven-ant-tasks JAR).

Comment 4 by hlship, Feb 09, 2009

Is this stalled (.e. are you waiting for updated patch) or going forward with
checking the JAR in?

Comment 5 by richhickey, Feb 10, 2009

My current feeling is to not require any maven support jars for the current ant
process. Would Maven users have maven-ant-tasks anyway?

Would you mind asking on the group how people feel about having a jar that large in
the repository? Personally, I'm against it. Clojure doesn't come with Ant either.

Also, I don't know what the groupId is for, but yes, "org.clojure" seems better.

Comment 6 by hlship, Feb 10, 2009

The new patch fixes the groupId in pom.xml.  It also requires that users who want to
run the nightly-build or stable-build targets have a copy of the Maven ant tasks in
their $ANT_HOME/lib.  Since that's basically the CI server (for nightly builds) and
perhaps you, its not a problem.  Other users, with our without the Maven ant tasks,
can run the build as before.

Comment 7  by richhickey, Feb 10, 2009

Thanks! This seems like a fine plan, however your patch seems to be against a very
old rev, and I'm afraid of messing it up in the merge. Could you produce a patch
against current trunk?

Comment 8 by hlship, Feb 10, 2009

That's odd, I thought I had down a refresh before I started.  Give me a few minutes.

Comment 9 by hlship, Feb 10, 2009

Cleaned it up a lot; it now builds the slim jar and deploys it as an attached
artifact (meaning that Maven users can decide to use it instead of the full JAR by
providing <classifier>slim</classifier>, which is the whole point).

Comment 10  by richhickey, Feb 10, 2009

Hmm..., I'm still unable to apply this, seems to be built on rev 1162, we're up to
1265 now.

Comment 11 by hlship, Feb 10, 2009

Wierd.  I've never had svn give me this kind of trouble before.  I'll do a fresh
checkout and try again. It shouldn't be this difficult.

Comment 12 by hlship, Feb 10, 2009

OK.  Try this one. Freshly redid the changes.

BTW, If you have Maven installed it will look something like:

$ ant nightly-build
Buildfile: build.xml

clean:

init:
    [mkdir] Created dir: /Users/Howard/work/clojure/target/classes

compile-java:
    [javac] Compiling 121 source files to /Users/Howard/work/clojure/target/classes
    [javac] Note: Some input files use unchecked or unsafe operations.
    [javac] Note: Recompile with -Xlint:unchecked for details.

compile-clojure:
     [java] Compiling clojure.core to /Users/Howard/work/clojure/target/classes
     [java] Compiling clojure.main to /Users/Howard/work/clojure/target/classes
     [java] Compiling clojure.set to /Users/Howard/work/clojure/target/classes
     [java] Compiling clojure.xml to /Users/Howard/work/clojure/target/classes
     [java] Compiling clojure.zip to /Users/Howard/work/clojure/target/classes
     [java] Compiling clojure.inspector to /Users/Howard/work/clojure/target/classes

jar:
      [jar] Building jar: /Users/Howard/work/clojure/clojure.jar
      [jar] Building jar: /Users/Howard/work/clojure/clojure-slim.jar
      [jar] Building jar: /Users/Howard/work/clojure/target/clojure-sources.jar

all:

nightly-build:
[mvn:deploy] Deploying to file:/var/www/maven-snapshot-repository
[mvn:deploy] Uploading:
org/clojure/clojure-lang/1.0-SNAPSHOT/clojure-lang-1.0-20090211.005400-2.jar to remote
[mvn:deploy] Uploaded 1405K
[mvn:deploy] Uploading:
org/clojure/clojure-lang/1.0-SNAPSHOT/clojure-lang-1.0-20090211.005400-2-sources.jar
to remote
[mvn:deploy] Uploaded 276K
[mvn:deploy] Uploading:
org/clojure/clojure-lang/1.0-SNAPSHOT/clojure-lang-1.0-20090211.005400-2-slim.jar to
remote
[mvn:deploy] Uploaded 515K

BUILD SUCCESSFUL
Total time: 14 seconds
~/work/clojure
$ 

Comment 13  by richhickey, Feb 10, 2009

patch applied - svn 1270 - thanks!

Status: Fixed
Comment 14 by richhickey, Feb 11, 2009

I had to back out this patch as it broke the build destination directories

Status: Started
Comment 15 by hlship, Feb 11, 2009

Was there something sacrosanct about the classes going in ./build?  I follow the
conventions that all derived files go somewhere under ./target, such that the clean
target just has to delete that one directory.

This coding via patches thing is really annoying; it's like coding underwater!

Comment 16 by richhickey, Feb 11, 2009

Well, people can run Clojure by just putting the ./classes and ./src/clj dirs in the
classpath. I do this when the jar won't build due to broken code in core clj files,
or when making incremental changes on the Java side. ./classes is also the default
dir for AOT compilation, and people expect clean to clear it. So, it is a breaking
change.

Comment 17 by hlship, Feb 11, 2009

OK, then. I'll make a less intrusive patch if that's ok.

Comment 18 by hlship, Feb 11, 2009

Ok, this one puts the compiled classes into ./classes the way it was before.  I'm
checking to see if I can sign you CLA, and maybe I can help out more directly.  I'm
on the opposite side of this a lot, getting patches that are (sometimes) more work to
use than it would be to write the functionality myself from scratch!

Comment 19  by richhickey, Feb 21, 2009

I'm ready to give this another try if you could please make a patch based off of
trunk (there were some recent changes that need to be preserved). Also, these patches
seem to do a substantial reorganization of the file, making them difficult to assess.

Comment 20 by hlship, Feb 21, 2009

I'll have something together in about an hour.

Comment 21 by hlship, Feb 21, 2009

OK, I focused this time on making minimal disruption rather than making the Ant
build.xml more conformant.

Comment 22  by richhickey, Feb 21, 2009

patch applied - svn 1299 - thanks!

Status: Fixed
Comment 23 by dimi...@gashinsky.com, Feb 22, 2009

Cannot do mvn install after this patch
Attaching a fix to do ant install for the same effect.


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

Converted from http://www.assembla.com/spaces/clojure/tickets/73
Attachments:
maven-6.patch - https://www.assembla.com/spaces/clojure/documents/b-ngbUw3Or3R14eJe5aVNr/download/b-ngbUw3Or3R14eJe5aVNr
mvn-local-install.patch - https://www.assembla.com/spaces/clojure/documents/b-niX0w3Or3R14eJe5aVNr/download/b-niX0w3Or3R14eJe5aVNr
maven-deploy.patch - https://www.assembla.com/spaces/clojure/documents/b-nlDyw3Or3R14eJe5aVNr/download/b-nlDyw3Or3R14eJe5aVNr
maven-ant-tasks-2.0.9.jar - https://www.assembla.com/spaces/clojure/documents/b-nod8w3Or3R14eJe5aVNr/download/b-nod8w3Or3R14eJe5aVNr
maven-deploy-2.patch - https://www.assembla.com/spaces/clojure/documents/b-nqLQw3Or3R14eJe5aVNr/download/b-nqLQw3Or3R14eJe5aVNr
maven-3.patch - https://www.assembla.com/spaces/clojure/documents/b-nthew3Or3R14eJe5aVNr/download/b-nthew3Or3R14eJe5aVNr
maven-4.diff - https://www.assembla.com/spaces/clojure/documents/b-nvQ-w3Or3R14eJe5aVNr/download/b-nvQ-w3Or3R14eJe5aVNr
maven-5.patch - https://www.assembla.com/spaces/clojure/documents/b-nyn8w3Or3R14eJe5aVNr/download/b-nyn8w3Or3R14eJe5aVNr

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

oranenj said: [file:b-ngbUw3Or3R14eJe5aVNr]: on comment 21

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

oranenj said: [file:b-niX0w3Or3R14eJe5aVNr]: on comment 23

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

oranenj said: [file:b-nlDyw3Or3R14eJe5aVNr]: on comment 1

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

oranenj said: [file:b-nod8w3Or3R14eJe5aVNr]: on comment 1

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

oranenj said: [file:b-nqLQw3Or3R14eJe5aVNr]: on comment 6

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

oranenj said: [file:b-nthew3Or3R14eJe5aVNr]: on comment 9

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

oranenj said: [file:b-nvQ-w3Or3R14eJe5aVNr]: on comment 12

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

oranenj said: [file:b-nyn8w3Or3R14eJe5aVNr]: on comment 18

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

oranenj said: Updating tickets (#63, #65, #66, #67, #68, #70, #73, #74, #75, #76, #78, #80, #81, #83, #86, #88, #90, #92, #93, #95, #97, #98)





[CLJ-80] GC Issue 77: r1265 causes VerifyError on dalvik 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: None

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


 Description   
Reported by rwvtveer, Feb 12, 2009

The inlining as provided by r1265 produces verifyerrors on dalvik (android):

W/dalvikvm(  214): VFY: unable to resolve virtual method 6650: Ljava/lang/StringBuilder;.append (C)Ljava/lang/AbstractStringBuilder;
W/dalvikvm(  214): VFY:  rejecting opcode 0x6e at 0x0043
W/dalvikvm(  214): VFY:  rejected Lclojure/core$slurp__4218;.invoke(Ljava/lang/Object;)Ljava/lang/Object;
W/dalvikvm(  214): Verifier rejected class Lclojure/core$slurp__4218;
W/dalvikvm(  214): Exception Ljava/lang/VerifyError; thrown during Lclojure/core__init;.<clinit>
W/dalvikvm(  214): Exception Ljava/lang/RuntimeException; thrown during Lclojure/lang/RT;.<clinit>

As discussed on ml: http://groups.google.com/group/clojure/browse_thread/thread/399090b419f72add/395d3b2b32660211

Comment 1 by r.p.levy, Mar 11, 2009

Are you working on getting Clojure to function on the Android phone?  How can I learn
more about the status of that effort? Thanks! Rob

Comment 2 by rwvtveer, Mar 17, 2009

Without this r1265 changeset and the beans function AOT compiled code works on
dalvik.  Checkout http://github.com/remvee/clojure/ and
http://github.com/remvee/clojurehelloandroid/ if you want to play with clojure on
Android.

Comment 3 by richhickey, Apr 12, 2009

Fixed r1344 - thanks for the report!

Status: Fixed


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

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

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

oranenj said: Updating tickets (#63, #65, #66, #67, #68, #70, #73, #74, #75, #76, #78, #80, #81, #83, #86, #88, #90, #92, #93, #95, #97, #98)





[CLJ-76] GC Issue 73: proxy macro allows invalid method declaration 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: None

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


 Description   
Reported by jbondeson, Feb 09, 2009

This patch was originally discussed in IRC on 2009-02-09.

The proxy macro allows you to define methods of the same name within the
same block.  This results in a last-defined-wins scenario.

user> (def p (proxy [java.util.concurrent.Future] [] (get [] 0) (get
[timeout unit] 2)))
#'user/p
user> (.get p 30 java.util.concurrent.TimeUnit/MILLISECONDS)
2
user> (.get p)
java.lang.IllegalArgumentException: Wrong number of args passed to:
user$fn--1271$fn (NO_SOURCE_FILE:0)

If the definitions are reversed the results are reversed:

user> (def q (proxy [java.util.concurrent.Future] [] (get [timeout unit] 2)
(get [] 0)))
#'user/q
user> (.get q)
0
user> (.get q 30 java.util.concurrent.TimeUnit/MILLISECONDS)
java.lang.IllegalArgumentException: Wrong number of args passed to:
user$fn--1416$fn (NO_SOURCE_FILE:0)

The correct way to do multiple files of different -arity is:

user> (def r (proxy [java.util.concurrent.Future] [] (get ([] 0) ([timeout
unit] 2))))
#'user/r
user> (.get r)
0
user> (.get r 30 java.util.concurrent.TimeUnit/MILLISECONDS)
2

The attached patch will catch an incorrect method redefinition and throw an
IllegalArgumentException identifying the method redefined.

Comment 1  by richhickey, Feb 10, 2009

patch applied - svn 1257 - thanks!

Status: Fixed


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

Converted from http://www.assembla.com/spaces/clojure/tickets/76
Attachments:
proxy-method-redefinition-error.patch - https://www.assembla.com/spaces/clojure/documents/co7pRWw3Sr3Qr1eJe5aVNr/download/co7pRWw3Sr3Qr1eJe5aVNr

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

oranenj said: [file:co7pRWw3Sr3Qr1eJe5aVNr]

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

oranenj said: Updating tickets (#63, #65, #66, #67, #68, #70, #73, #74, #75, #76, #78, #80, #81, #83, #86, #88, #90, #92, #93, #95, #97, #98)





[CLJ-78] GC Issue 75: stackoverflow when counting a long cons chain 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: None

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


 Description   
Reported by chouser, Feb 10, 2009

What (small set of) steps will reproduce the problem?

(count (nth (iterate #(cons 1 %) [0]) 10000))

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

Expected: 10001
Actual:   java.lang.StackOverflowError (NO_SOURCE_FILE:0)

What version are you using?

SVN 1263 trunk

Was this discussed on the group? If so, please provide a link to the
discussion:

http://groups.google.com/group/clojure/browse_thread/thread/7bfb8898fb393afc/1a20cba75a95ceca

Please provide any additional information below.

As a result of the conversation linked above, the following issue was
created:

http://code.google.com/p/clojure/issues/detail?id=36

The patch attached here depends on the patch from  issue 36  above,
specifically a Counted marker interface.  With both patches applied:

Using 'count' on a large Cons chain no longer crashes:

(def x (nth (iterate #(cons 1 %) [0]) 10000000))

user=> (time (count x))
"Elapsed time: 337.329691 msecs"
10000001

Using 'count' on a vector of the same size is of course still much
faster:

user=> (def y (into [] x))
user=> (time (count y))
"Elapsed time: 0.092615 msecs"
10000001

Counting a cons of a single item onto a vector seq is still much
faster than walking the whole length of the seq:

user=> (time (count (cons 1 y)))
"Elapsed time: 0.159946 msecs"
10000002

Comment 1  by richhickey, Feb 10, 2009

patch applied - svn 1268 - thanks!

Status: Fixed


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

Converted from http://www.assembla.com/spaces/clojure/tickets/78
Attachments:
fix-count-cons.patch - https://www.assembla.com/spaces/clojure/documents/dLtc0iw3Sr3O2PeJe5afGb/download/dLtc0iw3Sr3O2PeJe5afGb

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

oranenj said: [file:dLtc0iw3Sr3O2PeJe5afGb]

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

oranenj said: Updating tickets (#63, #65, #66, #67, #68, #70, #73, #74, #75, #76, #78, #80, #81, #83, #86, #88, #90, #92, #93, #95, #97, #98)





[CLJ-79] GC Issue 76: adding sorted-set-by Created: 18/Jun/09  Updated: 24/Aug/10  Resolved: 24/Aug/10

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

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

Approval: Ok

 Description   
Reported by timothypratley, Feb 11, 2009

http://groups.google.com/group/clojure/browse_thread/thread/9d280b6229aef38
4/0e5a2e1f80cb3810

user=> (sorted-set-by #(> (:hat %1) (:hat %2)) {:hat 2} {:hat 3} {:hat 1})
#{{:hat 3} {:hat 2} {:hat 1}}

Printed+signed CA is in the snail mail


 Comments   
Comment by Assembla Importer [ 24/Aug/10 2:45 PM ]

Converted from http://www.assembla.com/spaces/clojure/tickets/79
Attachments:
sorted-set-by.patch - https://www.assembla.com/spaces/clojure/documents/bOIR-4w3Wr3Qr1eJe5aVNr/download/bOIR-4w3Wr3Qr1eJe5aVNr
sorted-set-by.diff - https://www.assembla.com/spaces/clojure/documents/alPuT-xbCr3OXTeJe5aVNr/download/alPuT-xbCr3OXTeJe5aVNr
sorted-set-by2.diff - https://www.assembla.com/spaces/clojure/documents/aFa77SVAGr3QYWeJe5afGb/download/aFa77SVAGr3QYWeJe5afGb

Comment by Assembla Importer [ 24/Aug/10 2:45 PM ]

oranenj said: [file:bOIR-4w3Wr3Qr1eJe5aVNr]

Comment by Assembla Importer [ 24/Aug/10 2:45 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:45 PM ]

cemerick said: [file:alPuT-xbCr3OXTeJe5aVNr]: patch rebased to current github master

Comment by Assembla Importer [ 24/Aug/10 2:45 PM ]

chouser@n01se.net said: Chas, would you mind changing sorted-set-by (and I guess sorted-set too, since this touches it) to use the new-style (Foo/static arg) syntax? It's my understanding Rich wants to move core toward that as we go.

Comment by Assembla Importer [ 24/Aug/10 2:45 PM ]

cemerick said: Yeah, that's fine. I'm also going to take a whack at 129 in the process.

Comment by Assembla Importer [ 24/Aug/10 2:45 PM ]

cemerick said: [file:aFa77SVAGr3QYWeJe5afGb]: revised patch with / static method invocations

Comment by Assembla Importer [ 24/Aug/10 2:45 PM ]

cemerick said: Revised patch attached, based off of today's rhickey/master.

Comment by Assembla Importer [ 24/Aug/10 2:45 PM ]

cemerick said: (In [[r:9e810bf17700982eb1a3a5cf21c0fcba6bc0eea5]]) added sorted-set-by, adapted from timothypratley's patch, fixes #79

Signed-off-by: Chouser <chouser@n01se.net>

Branch: master





[CLJ-86] GC Issue 82: read-line bug 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: None

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


 Description   
Reported by DiscipleRayne, Feb 17, 2009

What (small set of) steps will reproduce the problem?

Call read-line

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

Should accept input.

Instead it throws a clojure.lang.LineNumberingPushbackReader cannot be cast
to java.io.BufferedReader


What version are you using?

Rev 1286

Revision

1268

Was this discussed on the group? If so, please provide a link to the
discussion:

No

Please provide any additional information below.

Doesn't do this in the release version, only in the newest revisions. It's
been redefined, don't know why though.

Comment 1 by scgilardi, Mar 02, 2009

Discussion is here:

http://groups.google.com/group/clojure/browse_frm/thread/48f1fb08b3052083/eaff1f7c16ce84e2?tvc=1&q=read-line#eaff1f7c16ce84e2

Comment 2 by slash2314, Mar 02, 2009

A simple fix to this bug would be the following patch.

Comment 3  by chouser, Mar 02, 2009

slash2314: Have you sent in your CA?  If so, which name at
http://clojure.org/contributing is yours?

The bug appears to have been introduced by this change, line 1972:
http://tinyurl.com/ahhqaz

Registered contributor Perry Trolard has a fix here:
http://groups.google.com/group/clojure/msg/85f858df39daca2a

I've attached Perry's fix in patch form.

--Chouser

Comment 4  by richhickey, Mar 03, 2009

fixed in svn 1321 - thanks!

Status: Fixed


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

Converted from http://www.assembla.com/spaces/clojure/tickets/86
Attachments:
issue-82.patch - https://www.assembla.com/spaces/clojure/documents/bnD318w34r3Ou4eJe5aVNr/download/bnD318w34r3Ou4eJe5aVNr
fix-read-line.patch - https://www.assembla.com/spaces/clojure/documents/bnD6JIw34r3Ou4eJe5aVNr/download/bnD6JIw34r3Ou4eJe5aVNr

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

oranenj said: [file:bnD318w34r3Ou4eJe5aVNr]

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

oranenj said: [file:bnD6JIw34r3Ou4eJe5aVNr]: on comment 3

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

oranenj said: Updating tickets (#63, #65, #66, #67, #68, #70, #73, #74, #75, #76, #78, #80, #81, #83, #86, #88, #90, #92, #93, #95, #97, #98)





[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-82] GC Issue 79: Allow read to accept readers other than a PushbackReader 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: None

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


 Description   
Reported by p...@hagelb.org, Feb 12, 2009

"read" should be able to accept different kinds of readers, wrapping them
in a PushbackReader where necessary.

This should be implemented in LispReader.java rather than the read function
in core.clj, since the latter would require turning read into a multimethod.

http://groups.google.com/group/clojure/browse_thread/thread/fedbb2a63af633f0


Comment 1 by p...@hagelb.org, Feb 12, 2009

Attached a small patch that provides this and updates the docstring for read.

Simple test case: (= [1 2 3] (read (java.io.StringReader. "[1 2 3]")))

Comment 2  by p...@hagelb.org, Feb 20, 2009

Feel free to close this out as a wontfix; I can't find any way around the problems
brought up by the mailing list.

Comment 3 by richhickey, Feb 21, 2009

ok - WontFix

Status: WontFix


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

Converted from http://www.assembla.com/spaces/clojure/tickets/82
Attachments:
read-from-reader.patch - https://www.assembla.com/spaces/clojure/documents/at4zcYw30r3R14eJe5aVNr/download/at4zcYw30r3R14eJe5aVNr

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

oranenj said: [file:at4zcYw30r3R14eJe5aVNr]: on comment 1

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

oranenj said: Updating tickets (#72, #82)

WontFix on google code





[CLJ-92] GC Issue 88: Add :let support for 'doseq' and 'for' 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: None

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


 Description   
Reported by chouser, Feb 26, 2009

Describe the feature/change.

Attached patch supports forms like:

(for [x (range 10)
      y (range 10)
      :let [z (+ x y)
            zz (- x y)]
      :when (< z 5)]
  [z zz])
-> ([0 0] [1 -1] [2 -2] [3 -3] [4 -4] [1 1] [2 0] [3 -1]
    [4 -2] [2 2] [3 1] [4 0] [3 3] [4 2] [4 4])

(doseq [x (range 10)
        y (range 10)
        :let [z (+ x y)
              zz (- x y)]
        :when (< z 5)]
  (prn z zz))
0 0
1 -1
2 -2
3 -3
4 -4
1 1
2 0
3 -1
4 -2
2 2
3 1
4 0
3 3
4 2
4 4
-> nil

Was this discussed on the group? If so, please provide a link to the
discussion:

http://clojure-log.n01se.net/date/2009-02-26.html#11:16b

Comment 1  by richhickey, Feb 27, 2009

I don't think there's any way to avoid becoming order-sensitive on these :options :(

Comment 2 by chouser, Feb 27, 2009

Still need to do 'for', but I think this should work for 'doseq':

(defmacro doseq
  "Repeatedly executes body (presumably for side-effects) with
  bindings and filtering as provided by \"for\".  Does not retain
  the head of the sequence. Returns nil."
  [seq-exprs & body]
  (assert-args doseq
     (vector? seq-exprs) "a vector for its binding"
     (even? (count seq-exprs)) "an even number of forms in binding vector")
  (let [step (fn step [recform exprs]
               (if-not exprs
                 [true `(do ~@body)]
                 (let [k (first exprs)
                       v (second exprs)
                       seqsym (when-not (keyword? k) (gensym))
                       recform (if (keyword? k) recform `(recur (next ~seqsym)))
                       steppair (step recform (nnext exprs))
                       needrec (steppair 0)
                       subform (steppair 1)]
                   (cond
                     (= k :let) [needrec `(let ~v ~subform)]
                     (= k :while) [false `(when ~v
                                            ~subform
                                            ~@(when needrec [recform]))]
                     (= k :when) [false `(if ~v
                                           (do
                                             ~subform
                                             ~@(when needrec [recform]))
                                           ~recform)]
                     :else [true
                            `(loop [~seqsym (seq ~v)]
                               (when-let [~k (first ~seqsym)]
                                 ~subform
                                 ~@(when needrec [recform])))]))))]
    (nth (step nil (seq seq-exprs)) 1)))

Comment 3 by chouser, Mar 02, 2009

Attached is a new patch that emits code for :while, :when, and :let in the order they
are given.  This allows :while and :when to guard each other as well as :let.  This
'doseq' is essentially the same as my previous comment, but won't stop when there's a
nil in the seq.  This 'for' is quite different from the 'doseq', and instead is
similar to the old 'for' with some refactoring.

Both 'for' and 'doseq' still pass the regression tests in
clojure.contrib.test-clojure.for.

Comment 4  by richhickey, Mar 03, 2009

patch applied - svn 1320 - thanks!

Status: Fixed


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

Converted from http://www.assembla.com/spaces/clojure/tickets/92
Attachments:
doseq-for-let.patch - https://www.assembla.com/spaces/clojure/documents/a45Fzow38r3Ou4eJe5aVNr/download/a45Fzow38r3Ou4eJe5aVNr
ordered-doseq-for-let.patch - https://www.assembla.com/spaces/clojure/documents/a45IoOw38r3Ou4eJe5aVNr/download/a45IoOw38r3Ou4eJe5aVNr

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

oranenj said: [file:a45Fzow38r3Ou4eJe5aVNr]

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

oranenj said: [file:a45IoOw38r3Ou4eJe5aVNr]: on comment 3

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

oranenj said: Updating tickets (#63, #65, #66, #67, #68, #70, #73, #74, #75, #76, #78, #80, #81, #83, #86, #88, #90, #92, #93, #95, #97, #98)





[CLJ-85] Double post of #84 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: None

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


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

Converted from http://www.assembla.com/spaces/clojure/tickets/85
Attachments:
genclass-allow-unresolved-classname.patch - https://www.assembla.com/spaces/clojure/documents/c9OAUmw30r3RbzeJe5afGb/download/c9OAUmw30r3RbzeJe5afGb

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

oranenj said: [file:c9OAUmw30r3RbzeJe5afGb]: on comment 1





[CLJ-81] GC Issue 78: patch to improve startup time on low end hardware 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: None

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


 Description   
Reported by rwvtveer, Feb 12, 2009

As discussed on ml: http://groups.google.com/group/clojure/browse_thread/thread/c40b2973109db24/f7c51fddaaec0d3b

The attached patch provides custom constant serialization for:

* base types: String, Integer, Double, Character, Class, Symbol, Keyword and Var
* collections: IPersistentMap, IPersistentVector and IPersistentList/ISeq

If meta data is associated with on the emitted object it will be serialized and attached.  If the object is of a different type the previous method, using 
lispreader, is used.  The *print-initialized* hack is still in place because in a theoretical case it is still needed.

Comment 1  by richhickey, Mar 03, 2009

patch applied (w/some changes) - svn 1322 - thanks
I'd like top revisit this as a multimethod at some point

Status: Fixed


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

Converted from http://www.assembla.com/spaces/clojure/tickets/81
Attachments:
constant-emitter.diff - https://www.assembla.com/spaces/clojure/documents/dqfpz2w3Wr3O2PeJe5afGb/download/dqfpz2w3Wr3O2PeJe5afGb

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

oranenj said: [file:dqfpz2w3Wr3O2PeJe5afGb]

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

oranenj said: Updating tickets (#63, #65, #66, #67, #68, #70, #73, #74, #75, #76, #78, #80, #81, #83, #86, #88, #90, #92, #93, #95, #97, #98)





[CLJ-88] GC Issue 84: Wiki pages have wrong copyright year 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: None

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


 Description   

Reported by hlship, Feb 21, 2009

It's listed as 2008, should start seeing 2009 for changed pages.

Comment 1 by richhickey, Feb 24, 2009

(No comment was entered for this change.)

Status: Fixed



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

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

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

oranenj said: Updating tickets (#63, #65, #66, #67, #68, #70, #73, #74, #75, #76, #78, #80, #81, #83, #86, #88, #90, #92, #93, #95, #97, #98)





[CLJ-90] GC Issue 86: dorun implementation tripping lazy sequence assert logic 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: None

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


 Description   
Reported by jbondeson, Feb 23, 2009

What (small set of) steps will reproduce the problem?

(dorun (list (lazy-seq nil)))

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

This should not assert.

What version are you using?

svn r1300


Attached is a patch to have dorun use the do special form rather than force
the evaluation in the if statement.

Comment 1  by richhickey, Feb 23, 2009

fixed in svn 1301

Status: Fixed


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

Converted from http://www.assembla.com/spaces/clojure/tickets/90
Attachments:
dorun.diff - https://www.assembla.com/spaces/clojure/documents/dmSTKKw34r3RbzeJe5afGb/download/dmSTKKw34r3RbzeJe5afGb

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

oranenj said: [file:dmSTKKw34r3RbzeJe5afGb]

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

oranenj said: Updating tickets (#63, #65, #66, #67, #68, #70, #73, #74, #75, #76, #78, #80, #81, #83, #86, #88, #90, #92, #93, #95, #97, #98)





[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-95] GC Issue 91: Documentation for rand inaccurate 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: None

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


 Description   
Reported by joshuatfox, Mar 04, 2009

A minor issue.

The doc says that the number is between 0 and 1, but if the parameter n is 
not 1, then this is not accurate.

Reproduce as below in the REPL.



user=> (doc rand)
-------------------------
clojure.core/rand
([] [n])
  Returns a random floating point number between 0 (inclusive) and
  1 (exclusive).
nil
user=> (rand 100000)
44028.44964067226

Comment 1 by richhickey, Apr 09, 2009

fixd in r1343 - thanks for the report

Status: Fixed


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

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

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

oranenj said: Updating tickets (#63, #65, #66, #67, #68, #70, #73, #74, #75, #76, #78, #80, #81, #83, #86, #88, #90, #92, #93, #95, #97, #98)





[CLJ-96] GC Issue 92: Check for key identity in collections 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: Release 1.2

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

Approval: Ok

 Description   
Reported by chouser, Mar 09, 2009

Describe the feature/change.

Clojure code routes key lookups through
clojure.lang.Util.equiv()/equals(), which do an identity check.

Using the collections from outside Clojure may to more expensive
comparisons even on identical objects, so each collection should also
do an identity check.

Was this discussed on the group? If so, please provide a link to the
discussion:

http://groups.google.com/group/clojure/msg/6a2e491fcf564a68


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

Converted from http://www.assembla.com/spaces/clojure/tickets/96
Attachments:
0001-Check-for-identity-before-equality-in-.equals-for-co.patch - https://www.assembla.com/spaces/clojure/documents/ch_3rOrUir36rbeJe5d-aX/download/ch_3rOrUir36rbeJe5d-aX

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 Assembla Importer [ 24/Aug/10 6:45 AM ]

richhickey said: Updating tickets (#8, #42, #113, #2, #20, #94, #96, #104, #119, #124, #127, #149, #162)

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

richhickey said: Updating tickets (#94, #96, #104, #119, #163)

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

cgrand said: [file:ch_3rOrUir36rbeJe5d-aX]: patch

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

cgrand said: Add identity check to .equals in gvec, ASeq, APersistentVector, APersistentSet and APersistentMap.

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

cgrand said: (In [[r:ee9fc81dd2ef15d7ea3e17e7ec2370c5c09d633e]]) Check for identity before equality in .equals for collections, see #96

Signed-off-by: Stuart Halloway <stu@thinkrelevance.com>

Branch: master





[CLJ-93] GC Issue 89: letrec 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: None

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


 Description   
Reported by richhickey, Feb 27, 2009

add oft-requested letrec


Comment 1 by H.Duerer, Feb 27, 2009

I would find this quite useful.  As discussed on IRC channel the alternatives seem upgly.

In my need I basically want to do something like

(let [result (cons initial-value 
              (map complex-function result other-sequence1 other-sequence2 ...))]
  result)

Comment 2 by richhickey, Feb 28, 2009

added letfn - svn 1315

Status: Fixed


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

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

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

oranenj said: Updating tickets (#63, #65, #66, #67, #68, #70, #73, #74, #75, #76, #78, #80, #81, #83, #86, #88, #90, #92, #93, #95, #97, #98)





[CLJ-91] GC Issue 87: *-seq should return seq/nil 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: Release 1.1

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

Approval: Ok

 Description   
Reported by aaraines, Feb 26, 2009

This patch alters line-seq, resultset-seq, re-seq, and tree-seq to return
nil if the LazySeq is empty, as discussed in #clojure.

http://clojure-log.n01se.net/date/2009-02-26.html#14:05

Comment 1  by aaraines, Feb 26, 2009

Patch against SVN 1309.

Comment 2 by aaraines, Feb 27, 2009

This patch uses (seq s) for its test rather than (first s).


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

Converted from http://www.assembla.com/spaces/clojure/tickets/91
Attachments:
aar-star-seq-nil.patch - https://www.assembla.com/spaces/clojure/documents/acJw44w38r3Ou4eJe5aVNr/download/acJw44w38r3Ou4eJe5aVNr
aar-star-seq-nil-2.patch - https://www.assembla.com/spaces/clojure/documents/acJzTGw38r3Ou4eJe5aVNr/download/acJzTGw38r3Ou4eJe5aVNr
issue-91-star-seq-nil.diff - https://www.assembla.com/spaces/clojure/documents/aXOzTMJNer3QCTeJe5aVNr/download/aXOzTMJNer3QCTeJe5aVNr

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

oranenj said: [file:acJw44w38r3Ou4eJe5aVNr]

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

oranenj said: [file:acJzTGw38r3Ou4eJe5aVNr]: on comment 3

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

richhickey said: As of patch aar-star-seq-nil-2.patch this is still not quite right. The logic should be, do the read/whatever, if something, return (cons something (lazy-seq again)), else return nil. aar-star-seq-nil-2.patch is creating a lazy seq then immediately forcing it.

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

drewr said: [file:aXOzTMJNer3QCTeJe5aVNr]: *-seq returns lazy-seq or nil

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

drewr said: Since tree-seq always returns a seq with at least one element, I did not include it in this ticket. I hope that's correct.

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

technomancy said: +1; this looks good to me.

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

richhickey said: issue-91-star-seq-nil.diff ok





[CLJ-104] GC Issue 100: gen-class creating non-compliant field names 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: Release 1.2

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

Approval: Ok

 Description   
Reported by solkis, Apr 04, 2009

The defect was described in this clojure group post by Michael Reid: 

http://groups.google.com/group/clojure/browse_thread/thread/e64719d716c29ce0

It appears that IBM JVMs have more stringent field name checking than do
the Sun JVMs.

Classes generated by gen-class and executing on IBM JVMs used with the
WebSphere Application Server require the basic fix outlined in the patch on
the thread above or the following error will result:

java.lang.ClassFormatError: JVMCFRE114 field name is invalid;


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

Converted from http://www.assembla.com/spaces/clojure/tickets/104
Attachments:
use-underscore-instead-of-dash-104.patch - https://www.assembla.com/spaces/clojure/documents/cNfYU0r9qr348xeJe5d-aX/download/cNfYU0r9qr348xeJe5d-aX
munge-genclass-field-names-104.patch - https://www.assembla.com/spaces/clojure/documents/akvHectnCr37JQeJe5dVir/download/akvHectnCr37JQeJe5dVir

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

richhickey said: Updating tickets (#8, #42, #113, #2, #20, #94, #96, #104, #119, #124, #127, #149, #162)

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

richhickey said: Updating tickets (#94, #96, #104, #119, #163)

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

stu said: [file:cNfYU0r9qr348xeJe5d-aX]

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

stu said: [file:akvHectnCr37JQeJe5dVir]

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

stu said: Disregard the April 14 patch, and please take a look at the April 20 patch (which includes tests).

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

stu said: (In [[r:084e5604710eb16df43ad529adabf18f40795bf9]]) munge genclass field names to keep Java side happy, see #104

Signed-off-by: Stuart Halloway <stu@thinkrelevance.com>

Branch: master





[CLJ-100] GC Issue 96: In FOR macro the :let clause does not establish a lexical binding 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: None

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


 Description   
Reported by splendidlord, Mar 14, 2009

> What (small set of) steps will reproduce the problem?

In a fresh Clojure:
(for [a (range 5) :let [x (* a a)]] x)
==> java.lang.Exception: Unable to resolve symbol: x in this context

Now:
(def x -1000)
(for [a (range 5) :let [x (* a a)]] x)
==> (-1000 -1000 -1000 -1000 -1000)


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

It should be:
(for [a (range 5) :let [x (* a a)]] x)
==> (0 1 4 9 16)


> What version are you using?

SVN r1327

Comment 1 by splendidlord, Mar 14, 2009

Sorry, I have two clojure.jars on my system and I used an older one.
In r1327 this bug does not longer exist. Please close the issue, thanks.

Comment 2 by richhickey, Mar 16, 2009

(No comment was entered for this change.)

Status: Invalid


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

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





[CLJ-101] GC Issue 97: partition-by does not work correctly when passed a function with side-effects 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: None

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


 Description   
> What (small set of) steps will reproduce the problem?

(def coll '(a a b c nil nil nil d e f))
(partition-by #(or (nil? %) (gensym)) coll)
==> partition-by runs into an endless loop


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

From what the doc string says it seems that
partition-by would return:
((a) (a) (a) (b) (c) (nil nil nil) (d) (e) (f))
The provided function returns for non-nil elements
a new value.


> What version are you using?

r1327


> Please provide any additional information below.

A minimum change would be to update the doc strings,
stating that f must not have side-effects.
But if we would like to keep that door open, then the
current behaviour could be patched.
The problem is this:
In partition-by fv gets assigned (f (first s)), and
only a moment later (f (first s)) is evaluated again,
in the binding for run, in the take-while.
But as f has side effects we have:
(= (f (first s)) (f (first s))) ==> false
Now take-while will return an empty lazy-seq and the
drop will remove zero elements, as run is empty.

Instead fv should always be an element of run, and
take-while should run on the rest of s instead of on
s itself.

Comment 1  by richhickey, Mar 16, 2009

partition-by is not part of Clojure core

Status: Invalid


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

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





[CLJ-97] GC Issue 93: proxy: inheriting a method from more than one iface 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: None

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


 Description   
Reported by christophe.grand, Mar 09, 2009

What (small set of) steps will reproduce the problem?
(do (proxy [clojure.lang.IPersistentVector] []) nil)

What is the expected output? What do you see instead?
Expected:
nil
Observed:
java.lang.ClassFormatError: Duplicate method name&signature in class file
clojure/proxy/java/lang/Object$IPersistentVector

Discussed on the group:
http://groups.google.com/group/clojure/msg/5cfc8d64fcbe2f52

Comment 1 by christophe.grand, Mar 09, 2009

Changed duplicate methods detection to not take the return type into account.
Changed stub generation to always generate a stub for the most specific return type.

Comment 2  by richhickey, Mar 16, 2009

patch applied - svn 1328 - thanks!

Status: Fixed
Comment 3 by christophe.grand, Mar 17, 2009

(No comment was entered for this change.)

Comment 4  by christophe.grand, Mar 17, 2009

with patch93bis.patch proxy emits bridge methods for covariant return types (except
for the method whose return type is the most specific)

Comment 5 by richhickey, Mar 17, 2009

(No comment was entered for this change.)

Status: Started
Comment 6 by richhickey, Mar 17, 2009

patch applied - r1333 - thanks!

Status: Fixed


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

Converted from http://www.assembla.com/spaces/clojure/tickets/97
Attachments:
patch93.patch - https://www.assembla.com/spaces/clojure/documents/dUY4Iow38r3R14eJe5aVNr/download/dUY4Iow38r3R14eJe5aVNr
patch93bis.patch - https://www.assembla.com/spaces/clojure/documents/dUY7Byw38r3R14eJe5aVNr/download/dUY7Byw38r3R14eJe5aVNr

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

oranenj said: [file:dUY4Iow38r3R14eJe5aVNr]

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

oranenj said: [file:dUY7Byw38r3R14eJe5aVNr]: on comment 3

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

oranenj said: Updating tickets (#63, #65, #66, #67, #68, #70, #73, #74, #75, #76, #78, #80, #81, #83, #86, #88, #90, #92, #93, #95, #97, #98)





[CLJ-94] GC Issue 90: Support metadata on fns 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: Release 1.2

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


 Description   
Reported by richhickey, Mar 04, 2009

Requires dealing with the with-meta copying issues for closures


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

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

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

richhickey said: Updating tickets (#8, #42, #113, #2, #20, #94, #96, #104, #119, #124, #127, #149, #162)

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

richhickey said: Updating tickets (#94, #96, #104, #119, #163)

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

richhickey said: Child association with ticket #245 was added

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

richhickey said: Child association with ticket #245 was removed





[CLJ-98] GC Issue 94: (ancestors ClassName) does not include tag ancestors of ClassName's superclasses 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: None

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


 Description   
Reported by cemer...@snowtide.com, Mar 10, 2009

ancestors does not include the tag parents of a class' superclasses.  It
therefore is inconsistent with isa?.  Interaction example:

;;;;;;;;;;;
user=> (ancestors String)
#{java.io.Serializable java.lang.Object java.lang.CharSequence  
java.lang.Comparable}
user=> (ancestors Object)
nil
user=> (derive String ::foo)
nil
user=> (derive Object ::bar)
nil
user=> (isa? String ::foo)
true
user=> (isa? String ::bar)
true
user=> (ancestors Object)
#{:user/bar}
user=> (ancestors String)  ;; should include ::bar!
#{java.io.Serializable java.lang.Object java.lang.CharSequence :user/
foo java.lang.Comparable}
;;;;;;;;;;;

I'd expect that ::bar would be included in the set returned by  
(ancestors String).  A similar interaction involving only keywords shows
that the tag ancestors of a parent are obviously included in the set of
ancestors of a child:

;;;;;;;;;;
user=> (derive ::p ::gp)
nil
user=> (derive ::c ::p)
nil
user=> (ancestors ::c)
#{:user/p :user/gp}
;;;;;;;;;;

The fix appears to be relatively simple, assuming I'm fully understanding
the problem.  Patch attached.

Comment 1  by richhickey, Mar 17, 2009

patch applied - r1334 - thanks!

Status: Fixed


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

Converted from http://www.assembla.com/spaces/clojure/tickets/98
Attachments:
ancestors_of_superclasses.patch - https://www.assembla.com/spaces/clojure/documents/aYFNf8w4ar3O2PeJe5afGb/download/aYFNf8w4ar3O2PeJe5afGb

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

oranenj said: [file:aYFNf8w4ar3O2PeJe5afGb]

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

oranenj said: Updating tickets (#63, #65, #66, #67, #68, #70, #73, #74, #75, #76, #78, #80, #81, #83, #86, #88, #90, #92, #93, #95, #97, #98)





[CLJ-102] GC Issue 98: proxy emits bytecode improperly referring to 21- & 22-arg overloads of IFn.invoke (Regression?) 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: None

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


 Description   
Reported by cemer...@snowtide.com, Mar 15, 2009

Attempting to obfuscate a jar that includes clojure.jar's contents using
proguard results in two errors:

 [proguard] Warning: clojure.proxy.clojure.lang.APersistentMap: can't find
referenced method 'java.lang.Object
invoke(java.lang.Object,java.lang.Object,java.lang.Object,java.lang.Object,java.lang.Object,java.lang.Object,java.lang.Object,java.lang.Object,java.lang.Object,java.lang.Object,java.lang.Object,java.lang.Object,java.lang.Object,java.lang.Object,java.lang.Object,java.lang.Object,java.lang.Object,java.lang.Object,java.lang.Object,java.lang.Object,java.lang.Object,java.lang.Object)'
in class clojure.lang.IFn
 [proguard] Warning: clojure.proxy.clojure.lang.APersistentMap: can't find
referenced method 'java.lang.Object
invoke(java.lang.Object,java.lang.Object,java.lang.Object,java.lang.Object,java.lang.Object,java.lang.Object,java.lang.Object,java.lang.Object,java.lang.Object,java.lang.Object,java.lang.Object,java.lang.Object,java.lang.Object,java.lang.Object,java.lang.Object,java.lang.Object,java.lang.Object,java.lang.Object,java.lang.Object,java.lang.Object,java.lang.Object)'
in class clojure.lang.IFn

This is almost identical to a previously reported (and fixed) problem with
gen-class, where it used to emit 21- and 22-argument overloads of
IFn.invoke that delegated to the gen-class' superclass' implementation
(which obviously doesn't provide IFn.invoke overloads with greater than 20
arguments).  This issue was reported and fixed last August:

http://groups.google.com/group/clojure/browse_thread/thread/b3698314084d8f54

Looks like the problem has cropped up again, only this time in conjunction
with AOT compiled proxies.

Comment 1 by cemer...@snowtide.com, Mar 16, 2009

Fixed in r1330 -- thanks, Rich!

Comment 2 by richhickey, Mar 16, 2009

(No comment was entered for this change.)

Status: Fixed


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

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

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

oranenj said: Updating tickets (#102, #105, #106, #109, #110, #111, #116)





[CLJ-106] GC Issue 102: Possible bug in proxy: NPE for unqualified class 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: None

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


 Description   
Reported by paul.drummond.webmail, Apr 05, 2009

Using latest svn version of clojure (rev 1338)

The following works - note ActionListener is fully qualified:

-----
user=> (.addActionListener (javax.swing.JButton.)
                   (proxy [java.awt.event.ActionListener] []
                     (actionPerformed [evt]
                                      (println "button press"))))
nil
-----
If I remove the package name I get a NullPointerException:

-----
user=> (.addActionListener (javax.swing.JButton.)
                   (proxy [ActionListener] []
                     (actionPerformed [evt]
                                      (println "button press"))))
java.lang.NullPointerException (NO_SOURCE_FILE:161)
user=>
------

Of course, I haven't imported ActionListener so I wouldn't expect it
to evaluate without error - I just wasn't expecting a
NullPointerException.

Comment 1 by richhickey, Apr 09, 2009

fixed in r1342 - thanks for the report

Status: Fixed


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

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

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

oranenj said: Updating tickets (#102, #105, #106, #109, #110, #111, #116)





[CLJ-110] GC Issue 106: clojure.main should exit with non-zero code on unhandled exceptions 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: None

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


 Description   
Reported by duelin.markers, Apr 12, 2009

See discussion in this thread:
http://groups.google.com/group/clojure/browse_thread/thread/8861acaff4db422d

Currently the following exits with a success exit code (zero).
java -jar clojure.jar clojure.main -e "some-garbage"

The attached patch allows unhandled exceptions to bubble up so the JVM can
terminate the way it normally would.

Comment 1  by richhickey, Apr 14, 2009

Fixed - r1351 - thanks for the report

Status: Fixed


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

Converted from http://www.assembla.com/spaces/clojure/tickets/110
Attachments:
dont_swallow_exceptions_in_clojure_main.patch - https://www.assembla.com/spaces/clojure/documents/b-aWy4w4ir3O2PeJe5afGb/download/b-aWy4w4ir3O2PeJe5afGb

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

oranenj said: [file:b-aWy4w4ir3O2PeJe5afGb]

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

oranenj said: Updating tickets (#102, #105, #106, #109, #110, #111, #116)





[CLJ-111] CG Issue 107: Old junk on sourceforge 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: None

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


 Description   
Reported by chrisperkins99, Apr 15, 2009

The first google hit for "clojure download" points directly to an old
(2008-03-29) version on sourceforge.

Perhaps you should remove the download, or remove the whole sourceforge
project, or at least update it to point unsuspecting newbies to the new
google-code location for the project.


Comment 1 by richhickey, Apr 27, 2009

(No comment was entered for this change.)

Status: Fixed


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

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

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

oranenj said: Updating tickets (#102, #105, #106, #109, #110, #111, #116)





[CLJ-108] GC Issue 104: macro call from Java isn't evaluated 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: None

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


 Description   
Reported by csaager, Apr 10, 2009

What (small set of) steps will reproduce the problem?
(defn abb [a [b] [& c]] b)
(defmacro extr [fun] `((meta (var ~fun)) :arglists))

Java 
Var extr,abb ...
Object arglists = extr.invoke(abb) 



What is the expected output? What do you see instead?
Expected ([a [b] [& c]]) (like in REPL)
Got: ((clojure.core/meta (var
#'org.enclojure.ide.nb.editor.ClojureSourceTemplate/abb)) :arglists) (a Cons)

What version are you using?
org-enclojure-ide-nb-editor-20090406.590.1337.nbm

Was this discussed on the group? If so, please provide a link to the
discussion:

Please provide any additional information below.

I tried to call Compiler.eval(arglists) and eval.invoke(arglists), both
threw an exception
Exception in thread "main" java.lang.ClassCastException: clojure.lang.Var
cannot be cast to clojure.lang.Symbol (NO_SOURCE_FILE:0)
        at clojure.lang.Compiler.analyzeSeq(Compiler.java:4493)
        at clojure.lang.Compiler.analyze(Compiler.java:4315)
        at clojure.lang.Compiler.analyze(Compiler.java:4276)
        at clojure.lang.Compiler$InvokeExpr.parse(Compiler.java:2761)
        at clojure.lang.Compiler.analyzeSeq(Compiler.java:4488)
        at clojure.lang.Compiler.analyze(Compiler.java:4315)
        at clojure.lang.Compiler.analyze(Compiler.java:4276)
        at clojure.lang.Compiler$InvokeExpr.parse(Compiler.java:2757)
        at clojure.lang.Compiler.analyzeSeq(Compiler.java:4488)
        at clojure.lang.Compiler.analyze(Compiler.java:4315)
        at clojure.lang.Compiler.analyze(Compiler.java:4276)
        at clojure.lang.Compiler$BodyExpr$Parser.parse(Compiler.java:3852)
        at clojure.lang.Compiler$FnMethod.parse(Compiler.java:3687)
        at clojure.lang.Compiler$FnMethod.access$1100(Compiler.java:3564)
        at clojure.lang.Compiler$FnExpr.parse(Compiler.java:2953)
        at clojure.lang.Compiler.analyzeSeq(Compiler.java:4484)
        at clojure.lang.Compiler.analyze(Compiler.java:4315)
        at clojure.lang.Compiler.eval(Compiler.java:4520)
        at clojure.core$eval__3975.invoke(core.clj:1743)
        at clojure.lang.Var.invoke(Var.java:346)
        at com.yourcompany.NewClass.main(NewClass.java:32)
Caused by: java.lang.ClassCastException: clojure.lang.Var cannot be cast to
clojure.lang.Symbol
        at clojure.lang.Compiler$TheVarExpr$Parser.parse(Compiler.java:485)
        at clojure.lang.Compiler.analyzeSeq(Compiler.java:4486)
        ... 20 more



Comment 1 by durka42, Apr 12, 2009

I am not sure this is a bug.

Macros are just functions with a bit set in the metadata, so when called like
functions they should just return code.
extr.invoke(abb) returns ((clojure.core/meta (var #'clojure.core/abb)) :arglists).
Note that the macro was called with the Var abb. When evaluated, this throws an
exception because var was called with a Var instead of a symbol (it is meant to be
called as (var abb)).
What the REPL does is more like extr.invoke(RT.readString("abb")) or
extr.invoke(Symbol.create("abb")), both of which return ((clojure.core/meta (var
abb)) :arglists) which can be evaluated as you expect.

Comment 2  by richhickey, Apr 12, 2009

Please discuss things like this on the group to clarify the issue and your
understanding before posting an issue here - thanks.

Status: Invalid


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

Converted from http://www.assembla.com/spaces/clojure/tickets/108
Attachments:
test.java - https://www.assembla.com/spaces/clojure/documents/acZHQ2w4ir3Od2eJe5aVNr/download/acZHQ2w4ir3Od2eJe5aVNr

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

oranenj said: [file:acZHQ2w4ir3Od2eJe5aVNr]: on comment 1





[CLJ-116] CG Issue 112: Use platform default encoding for *in*, *out*, and *err* 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: None

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


 Description   
Reported by scgilardi, Apr 29, 2009

What (small set of) steps will reproduce the problem?

    Code inspection, RT.java

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

    *in* *out* and *err* use UTF-8 encoding currently. Using the platform
default encoding (as determined by the JVM environment) is a better choice.

What version are you using?

    SVN 1359

Was this discussed on the group? If so, please provide a link to the
discussion:

    http://groups.google.com/group/clojure/browse_frm/thread/621aa30c78ba1b9e

Please provide any additional information below.

    As requested, a patch is enclosed. Note that this changes only *in*,
*out*, and *err*. Clojure source files are still expected (by the reader
and compiler) to be UTF-8 encoded.

Comment 1  by richhickey, Apr 29, 2009

Patch applied - r1360 - thanks!

Status: Fixed


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

Converted from http://www.assembla.com/spaces/clojure/tickets/116
Attachments:
default-encoding.patch - https://www.assembla.com/spaces/clojure/documents/cuSS9Ww4mr3Ou4eJe5aVNr/download/cuSS9Ww4mr3Ou4eJe5aVNr

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

oranenj said: [file:cuSS9Ww4mr3Ou4eJe5aVNr]

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

oranenj said: Updating tickets (#102, #105, #106, #109, #110, #111, #116)





[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-105] GC Issue 101: Strongly typed minus throws too often (with 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: None

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


 Description   
Reported by olov.lassus, Apr 04, 2009

First issue is for binary minus, long and int types.  Issue 40  touched upon
this but didn't cover all cases.

Actual (r1338):
user=> (- Integer/MAX_VALUE Integer/MIN_VALUE)
java.lang.ArithmeticException: integer overflow (NO_SOURCE_FILE:0)
user=> (- Long/MAX_VALUE Long/MIN_VALUE)      
java.lang.ArithmeticException: integer overflow (NO_SOURCE_FILE:0)
user=> (- (int -1) Integer/MIN_VALUE)         
java.lang.ArithmeticException: integer overflow (NO_SOURCE_FILE:0)
user=> (- (long -1) Long/MIN_VALUE)     
java.lang.ArithmeticException: integer overflow (NO_SOURCE_FILE:0)

Expected (with patch):
user=> (- Integer/MAX_VALUE Integer/MIN_VALUE)
java.lang.ArithmeticException: integer overflow (NO_SOURCE_FILE:0)
user=> (- Long/MAX_VALUE Long/MIN_VALUE)      
java.lang.ArithmeticException: integer overflow (NO_SOURCE_FILE:0)
user=> (- (int -1) Integer/MIN_VALUE)         
2147483647
user=> (- (long -1) Long/MIN_VALUE)   
9223372036854775807


Second issue is for unary minus, long type.

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

Expected (with patch):
user=> (- (long (Integer/MIN_VALUE)))
2147483648

Comment 1  by richhickey, Apr 09, 2009

Patches applied - svn r1341 - thanks!

Status: Fixed


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

Converted from http://www.assembla.com/spaces/clojure/tickets/105
Attachments:
typed_binary_minus.patch - https://www.assembla.com/spaces/clojure/documents/ckxeGOw4er3Ou4eJe5aVNr/download/ckxeGOw4er3Ou4eJe5aVNr
typed_unary_minus.patch - https://www.assembla.com/spaces/clojure/documents/ckxhm0w4er3Ou4eJe5aVNr/download/ckxhm0w4er3Ou4eJe5aVNr

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

oranenj said: [file:ckxeGOw4er3Ou4eJe5aVNr]

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

oranenj said: [file:ckxhm0w4er3Ou4eJe5aVNr]

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

oranenj said: Updating tickets (#102, #105, #106, #109, #110, #111, #116)





[CLJ-109] GC Issue 105: Build patch: install results to local Maven repository 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: None

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


 Description   
Reported by hlship, Apr 10, 2009

This patch creates a ci-build target that builds and installs the results
to the local Maven repository (where those changed JARs will be visible to
the clojure-contrib ci-build).

Comment 1  by dimi...@gashinsky.com, Apr 11, 2009

I've submitted a similar patch to the  Issue 70 .
Hope this one goes in.

Comment 2 by richhickey, Apr 14, 2009

Patch applied - r1352 - thanks!

Status: Fixed


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

Converted from http://www.assembla.com/spaces/clojure/tickets/109
Attachments:
clojure-build-patch.patch - https://www.assembla.com/spaces/clojure/documents/bmVO0yw4ir3O2PeJe5afGb/download/bmVO0yw4ir3O2PeJe5afGb

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

oranenj said: [file:bmVO0yw4ir3O2PeJe5afGb]

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

oranenj said: Updating tickets (#102, #105, #106, #109, #110, #111, #116)





[CLJ-117] GC Issue 113: Incorrect handling of trailing decimal points in numbers 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: Release 1.1

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

Approval: Ok

 Description   
Reported by scgilardi, May 04, 2009

What (small set of) steps will reproduce the problem?

        user=> (class 123.)
        java.lang.Integer

In contrast, Java reads such a number as a double.

        % javac Foo.java
        Foo.java:5: possible loss of precision
        found   : double
        required: int
                    int a = 123.;
                            ^
        1 error

Another place this comes up is with a number formatted as 123.e4.  
Currently that's an invalid number in Clojure:

        user=> (class 123.e4)
        java.lang.NumberFormatException: Invalid number: 123.e4
        java.lang.Exception: Unmatched delimiter: )
        user=>

Java reads it as 1230000.0

What version are you using?

1.0.0

Was this discussed on the group? If so, please provide a link to the
discussion:

http://groups.google.com/group/clojure/browse_thread/thread/c0db774b78171b9b/c57e878f11f2f199?lnk=gst&q=number#c57e878f11f2f199

Please provide any additional information below.

I've enclosed a patch to LispReader.java that fixes the problem. The patch
contains two changes, one necessary, one optional:

necessary: change the regular expressions intPat and floatPat so that "1."
is not considered an "int" and "1.e3" is accepted as a legal float.

optional: change the handling of the "M" suffix in matchNumber to make the
float handling code use matcher groups like the int and bigint handling
code does rather than using string manipulations.

I recommend both changes.

Comment 1  by scgilardi, May 04, 2009

I've attached a patch to clojure-contrib/src/clojure/contrib/test_clojure/reader.clj
to provide additional tests for reading Doubles and BigDecimals that pass with the
fixed Clojure LispReader.


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

Converted from http://www.assembla.com/spaces/clojure/tickets/117
Attachments:
number-trailing-dot.patch - https://www.assembla.com/spaces/clojure/documents/drAVxMw4mr3Ou4eJe5aVNr/download/drAVxMw4mr3Ou4eJe5aVNr
number-trailing-dot-tests.patch - https://www.assembla.com/spaces/clojure/documents/drAYtUw4mr3Ou4eJe5aVNr/download/drAYtUw4mr3Ou4eJe5aVNr

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

oranenj said: [file:drAVxMw4mr3Ou4eJe5aVNr]

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

oranenj said: [file:drAYtUw4mr3Ou4eJe5aVNr]: on comment 1

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

importer said: (In [[r:f1d13b8f1fbda376352caf85857cc0585717bcd9]]) parse "1." and "1.e3" as legal floats. Refs #117

Signed-off-by: Chouser <chouser@n01se.net>

Branch: master

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

chouser@n01se.net said: Leaving this open until the location of clojure-tests are settled so that the attached test patch can be committed as well.

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

importer said: (In [[r:5e34989a7098a55ca014030d7446d2dc20ebc33b]]) Test reading of numbers like "1." and "1.e3". Fixes #117

Signed-off-by: Chouser <chouser@n01se.net>

Branch: master





[CLJ-119] GC Issue 115: Document that #^chars works 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: Release 1.2

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


 Description   
Reported by hlship, May 05, 2009

In the Java Interop documentation, it identifies a number of special tags
that can be used to identify parameters of primitive arrays.

It does not list #^chars (equivalent to char[]) but this appears to (at
least partially) work.

On a related note, for this code:

(def #^StringBuilder *buffer*)

(defn- add-text
  "Adds text to the buffer and manages the *text-location* var."
  [#^chars ch start length]
  (.append *buffer* ch start length)  ;;;; line 98
  (when (nil? *text-location*)
        (set! *text-location* (current-location))))


I still get 

Reflection warning,
com/howardlewisship/cascade/internal/xmltokenizer.clj:98 - call to append
can't be resolved.


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

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

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 ]

troussan said: The reflection warning in the example code is caused by start and length parameters. If you replace the line 98 with:
(.append buffer ch (int start) (int length)) ;;;; line 98
the call to append is resolved.

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

richhickey said: Updating tickets (#8, #42, #113, #2, #20, #94, #96, #104, #119, #124, #127, #149, #162)

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

richhickey said: Updating tickets (#94, #96, #104, #119, #163)

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

stu said: To prevent the reflection warning, use primitive coercions as needed:

(.append *buffer* ch start length)

I have update the docs on clojure.org.

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

stu said: repeating the previous comment, with the coercions this time.

(.append *buffer* ch (int start) (int length))




[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-123] GC Issue 119: require doc out of date 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: Release 1.1

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

Approval: Ok

 Description   
Reported by hlship, May 20, 2009

The following doc for the (require) form seems to be out of date:

  'require loads a lib by loading its root resource. The root resource path
  is derived from the root directory path by repeating its last component
  and appending '.clj'. For example, the lib 'x.y.z has root directory
  <classpath>/x/y/z; root resource <classpath>/x/y/z/z.clj. The root
  resource should contain code to create the lib's namespace and load any
  additional lib resources.

Unless I'm missing something big, the root resource is
<classpath>/x/y/z.clj.  I'm not sure how the root directory feeds into
things now. If I remember back about 6 months, an older version of Clojure
did it this way.


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

Converted from http://www.assembla.com/spaces/clojure/tickets/123
Attachments:
0001-Bring-documentation-for-require-up-to-date.patch - https://www.assembla.com/spaces/clojure/documents/cX-0jCw4Cr3RbzeJe5afGb/download/cX-0jCw4Cr3RbzeJe5afGb

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

oranenj said: [file:cX-0jCw4Cr3RbzeJe5afGb]: Bring 'require doc up to date and add an usage example

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

oranenj said: Added a patch that improves the documentation

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

chouser@n01se.net said: Please include "Refs #123" in your git commit message, so that the ticket will be updated automatically on push, like this:

(In 31825fe1991baa3fc9375556ec6f6c595c175f4e) Bring documentation for 'require up to date

This seems to me to be a bug that should be fixed in 1.0 as well. Since we don't have a process in place for that yet, for now I'll just leave this ticket open.

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

chouser@n01se.net said: Created ticket #141 to track this issue against branch 1.0.

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

chouser@n01se.net said: Child association with ticket #141 was added





[CLJ-125] GC Issue 121: slurp should accept an encoding name 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: Release 1.1

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

Approval: Ok

 Description   
Reported by cemer...@snowtide.com, Jun 09, 2009

clojure.core/slurp currently does not accept an encoding to use when
reading the content from the provided path.  Using the system-default
encoding is a very common failure pattern.

Attached is a patch which adds an encoding argument to slurp (while
retaining the existing behaviour of falling back on the system-default
encoding when one is not specified).


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

Converted from http://www.assembla.com/spaces/clojure/tickets/125
Attachments:
slurp-encoding.patch - https://www.assembla.com/spaces/clojure/documents/byFSiOw4ur3Od2eJe5aVNr/download/byFSiOw4ur3Od2eJe5aVNr

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

oranenj said: [file:byFSiOw4ur3Od2eJe5aVNr]

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

cemerick said: (In [[r:d97dfc8791e87dbd7727eb3b76d3b62f11de9089]]) add an optional encoding argument to slurp. Fixes #125

Signed-off-by: Chouser <chouser@n01se.net>

Branch: master





[CLJ-128] Ensure that PersistentTreeMap.empty() (and therefore PersistentTreeSet.empty()) retain the callee's comparator Created: 18/Jun/09  Updated: 24/Aug/10  Resolved: 24/Aug/10

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

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


 Description   

Currently:

user=> (-> (sorted-set-by (comparator >) 1 2 3) empty (into [1 2 3]))
#{1 2 3}

The above should evaluate to #{3 2 1} (the provided comparator is being dropped by the 'empty' call).



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

Converted from http://www.assembla.com/spaces/clojure/tickets/128
Attachments:
fix-128.diff - https://www.assembla.com/spaces/clojure/documents/aaAsAO7eer3R_eeJe5afGb/download/aaAsAO7eer3R_eeJe5afGb
fix-128-b.diff - https://www.assembla.com/spaces/clojure/documents/bkb7eW7nWr3RUheJe5aVNr/download/bkb7eW7nWr3RUheJe5aVNr
fix-128-c.diff - https://www.assembla.com/spaces/clojure/documents/camOJA7oOr3QIWeJe5aVNr/download/camOJA7oOr3QIWeJe5aVNr

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

richhickey said: Updating tickets (#127, #128, #129, #130)

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

devlinsf said: [file:aaAsAO7eer3R_eeJe5afGb]: This fixes empty to preserve a comparator

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

devlinsf said: I had add a new arity for withMeta to PersistentTreeSet and PersistentTreeMap. This new form takes a comparator when creating a new value.

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

chouser@n01se.net said: Sean, both the map and set already have constructors that include meta and comparator (via impl in the set case). I think you can just use those in the empty() methods.

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

devlinsf said: Rewrote empty per Chouser's suggestion. Removed new arity to withMeta. Added tests to test_clojure/sequences.clj Should be better now.

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

chouser@n01se.net said: Sean, I don't see a new patch attached.

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

chouser@n01se.net said: [file:bkb7eW7nWr3RUheJe5aVNr]: Simplified patch to fix sorted empty() methods

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

chouser@n01se.net said: [file:camOJA7oOr3QIWeJe5aVNr]: patch against 1.1.0-rc1 that includes fix and tests

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

chouser@n01se.net said: (In [[r:89ad4ab4265299327001e2717aa73c8f87f11346]]) empty for sorted-map and sorted-set now maintain comparator. Fixes #128

Signed-off-by: Rich Hickey <richhickey@gmail.com>

Branch: master

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

importer said: (In [[r:a3a1b3aa3523608f0b69e0d8655d519767246c79]]) Added sorted tests to test-empty in test_clojure/sequences.clj Refs #128

Signed-off-by: Rich Hickey <richhickey@gmail.com>

Branch: master

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

importer said: (In [[r:855f394d6895cebfcee307dbccea9bdeffe792f5]]) Added test-empty-sorted to test_clojure/sequences.clj Refs #128

Signed-off-by: Rich Hickey <richhickey@gmail.com>

Branch: master





[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-134] *-zip lose metadata Created: 23/Jun/09  Updated: 24/Aug/10  Resolved: 24/Aug/10

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

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

Approval: Ok

 Description   

vector-zip and seq-zip do not transport metadata on the nodes.

Reported by Justin Balthrop on #clojure.

To reproduce:

1. Create a vector with metadata.
2. Create a vector zipper.
3. Move in the tree.
4. Recreate the root.

Now the metadata is lost.

Proposed fix:

Move the metadata in the make-node function of the vector zipper.

Patch attached.



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

Converted from http://www.assembla.com/spaces/clojure/tickets/134
Attachments:
zip-metadata-bug.diff - https://www.assembla.com/spaces/clojure/documents/c1enmoydyr3RpYeJe5afGb/download/c1enmoydyr3RpYeJe5afGb

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

meikelbrandmeyer said: [file:c1enmoydyr3RpYeJe5afGb]: Patch for metadata bug in zipper

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

meikelbrandmeyer said: (In [[r:dc5b4e60b88b9183e40a2427ef91b64c45c42ac3]]) Move metadata in vector-zip and seq-zip

Fixes #134
Signed-off-by: Chouser <chouser@n01se.net>

Branch: master

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

chouser@n01se.net said: Child association with ticket #161 was added





[CLJ-142] Bug: Compile-time NPE on set! of non-existent field Created: 03/Jul/09  Updated: 24/Aug/10  Resolved: 24/Aug/10

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

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


 Description   

(set! (.foo "fred") 47)



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

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

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

richhickey said: (In [[r:c4a5cd208aef54ae5b292fa41c4880017315e553]]) fix compile-time NPE on set! of non-existent field, fixes #142

Branch: master

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

chouser@n01se.net said: Child association with ticket #147 was added





[CLJ-141] GC Issue 119: require doc out of date Created: 01/Jul/09  Updated: 24/Aug/10  Resolved: 24/Aug/10

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

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

Approval: Ok

 Description   

This ticket is for tracking #123 against branch 1.0



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

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

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

chouser@n01se.net said: Parent association with ticket #123 was added

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

chouser@n01se.net said: Closing this because there seems to be no demand to fix this kind of bug in 1.0, and demand is only likely to decrease over time.





[CLJ-137] Add *math-context* to with-bindings so it's set!-able at REPL Created: 29/Jun/09  Updated: 24/Aug/10  Resolved: 24/Aug/10

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

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

Approval: Ok

 Description   

Add math-context</code> to <code>clojure.main/with-bindings so it's set!-able at REPL.



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

Converted from http://www.assembla.com/spaces/clojure/tickets/137
Attachments:
settable-math-context.patch - https://www.assembla.com/spaces/clojure/documents/bYiaYCznur3QWleJe5aVNr/download/bYiaYCznur3QWleJe5aVNr

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

scgilardi said: [file:bYiaYCznur3QWleJe5aVNr]: patches clojure.main/with-bindings to include math-context

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

richhickey said: Please mark as "ready to test" when you add a patch, thanks

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

richhickey said: Also please submit patches as produced by git format-patch, they retain authorship and other commit information.

See:
http://clojure.org/patches

Thanks

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

scgilardi said: Updated patch using git format-patch, ready to test. Thanks.

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

chouser@n01se.net said: This patch works fine with git for me – attribution and all. It does contain two commits, which threw me for a moment, but I think multi-commit patches are acceptable.

This patch looks fine to me.

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

importer said: (In [[r:ab7947e68a5b435f243790e197cfdb781d47986f]]) Refs #137: make math-context settable, with test + tests of with-precision

Signed-off-by: Chouser <chouser@n01se.net>

Branch: master

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

importer said: (In [[r:12888faab8f5c7bc13da5a8f506c2a594c48500c]]) move with-precision tests to that section of vars.clj Fixes #137

Signed-off-by: Chouser <chouser@n01se.net>

Branch: master

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

scgilardi said: Given Rich's post today about math-context not being part of Clojure's public API, should we add to this ticket implementation of a function like "set-precision!" (a sibling of with-precision) to make this capability usable in Clojure code?

I like math-context not being public. I hadn't thought of it before, but having it be public would be an unnecessary Java-ism--inappropriate for the Clojure-in-Clojure future.

(I'm leaving this ticket as fixed. We can either reopen it, open another ticket for set-precision!, or do nothing based on any futher discussions.)

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

chouser@n01se.net said: I didn't know (or had forgotten) about with-precision.

I'd personally be happy to see a 'set-precision!' and maybe a docstring for math-context that points to 'with-precision' and 'set-precision!'.

I'd also think that should be a new ticket, since the problem described in this ticket is indeed fixed by the patch in this ticket.





[CLJ-143] support overlapping ensures with no retry Created: 03/Jul/09  Updated: 24/Aug/10  Resolved: 24/Aug/10

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

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


 Description   

Currently ref ensures have same retry effects as set/alters. Allow overlapping ensures to succeed without retry

Discussed here:

http://groups.google.com/group/clojure/browse_frm/thread/f7b4365b1c71b665/717e1a18c2f84daf?#717e1a18c2f84daf



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

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

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

richhickey said: (In [[r:961743446562b6fa7be25f96de02aacd626169da]]) support overlapping ensures with no retry, refs #143

Branch: master





[CLJ-133] GC Issue 68: every? returns nil instead of false Created: 21/Jun/09  Updated: 24/Aug/10  Resolved: 24/Aug/10

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

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

Approval: Ok

 Description   

This ticket is for tracking #71 against Clojure 1.0



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

Converted from http://www.assembla.com/spaces/clojure/tickets/133
Attachments:
ticket-133-from-71.diff - https://www.assembla.com/spaces/clojure/documents/cyGJMsxTOr3OaseJe5afGb/download/cyGJMsxTOr3OaseJe5afGb
tc133_everyq.diff - https://www.assembla.com/spaces/clojure/documents/b1BM8WAUer3QimeJe5aVNr/download/b1BM8WAUer3QimeJe5aVNr
tc133_everyq_v2.diff - https://www.assembla.com/spaces/clojure/documents/dFPtUwAVKr3Q07eJe5aVNr/download/dFPtUwAVKr3Q07eJe5aVNr

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

chouser@n01se.net said: [file:cyGJMsxTOr3OaseJe5afGb]: The fix from #71 rebased to Clojure 1.0

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

chouser@n01se.net said: Attached is revision:b03e19aa341fea01c1279a74f4184f6538d0f72e rebased for Clojure 1.0

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

fsodomka said: [file:b1BM8WAUer3QimeJe5aVNr]: added tests for every?

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

fsodomka said: I believe that this issue is fixed and could be closed. I am also adding (uncommenting) tests for every? - see attached patch file tc133_everyq.diff

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

fsodomka said: [file:dFPtUwAVKr3Q07eJe5aVNr]: added tests for every?

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

stu said: fixed long ago





[CLJ-131] Move Clojure tests from contrib into Clojure 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: Release 1.1

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

Approval: Ok

 Description   

See this page in the wiki:

http://www.assembla.com/wiki/show/clojure/Getting_Tests_Into_Clojure



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

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

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

fsodomka said: Child association with ticket #144 was added

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

fsodomka said: Child association with ticket #158 was added





[CLJ-138] min and max history for refs Created: 30/Jun/09  Updated: 24/Aug/10  Resolved: 24/Aug/10

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

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


 Description   

knobs for history control. With positive min-history, will keep history even in absence of detected conflict. max history will limit dynamic history accumulation.



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

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

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

richhickey said: (In [[r:6201f5e2ddd52f1b483d75563b0380deba59777c]]) added ref min/max history control - refs #138

Branch: master





[CLJ-144] test-clojure: change (are _ ...) to (are [x] (true? x) ...) Created: 06/Jul/09  Updated: 24/Aug/10  Resolved: 24/Aug/10

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

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

Approval: Ok

 Description   

Old clojure.contrib.test-is framework used (are _ value1 value2 ...) syntax for testing if all values are logically true. New clojure.test uses (are [x] (true? x) value1 value2 ...) or (are [x] (if x true false) value1 value2 ...) and this change needs to be reflected in test_clojure/numbers.clj.



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

Converted from http://www.assembla.com/spaces/clojure/tickets/144
Attachments:
test_clojure_are.diff - https://www.assembla.com/spaces/clojure/documents/dvCpAkANar3QdBeJe5afGb/download/dvCpAkANar3QdBeJe5afGb
test_clojure_are_v2.diff - https://www.assembla.com/spaces/clojure/documents/damCkoAVKr3PdgeJe5afGb/download/damCkoAVKr3PdgeJe5afGb

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

fsodomka said: [file:dvCpAkANar3QdBeJe5afGb]: fixes test_clojure/numbers.clj

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

fsodomka said: [file:damCkoAVKr3PdgeJe5afGb]: fixes test_clojure/numbers.clj

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

fsodomka said: Parent association with ticket #131 was added

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

richhickey said: I don't understand this.

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

fsodomka said: Old 'are' had syntax (are condition expr1 expr2 ...), but new 'are' has (are params-vector condition expr1 expr2 ...). Tests in numbers.clj were updated with params-vector [x], but no condition were given.

user=> (macroexpand-1 '(are [x] true false nil))
(clojure.template/do-template [x] (clojure.test/is true) false nil)

Clearly, test (are [x] true false nil) will never fail, because first value is logically true and false and nil will never be considered.

See more explanation in:
http://groups.google.com/group/clojure-dev/browse_frm/thread/d0fd9d717db1e1db

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

fsodomka said: (In [[r:6e29153854c799cb46abc23382059d6ee20e755e]]) fixed test-clojure, refs #144

Signed-off-by: Chouser <chouser@n01se.net>

Branch: master





[CLJ-135] zipper: children does not check node type Created: 23/Jun/09  Updated: 24/Aug/10  Resolved: 24/Aug/10

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

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

Approval: Ok

 Description   

children does not check the node type.

Reported by Justin Balthrop on #clojure.

To reproduce:

(-> (clojure.core/vector-zip '[(1 2) (3 4)]) clojure.zip/down clojure.zip/down) descends into the list, where it should not.

Proposed fix:

children should check branch? and throw an exception if the node is actually a leaf.

Patch attached.



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

Converted from http://www.assembla.com/spaces/clojure/tickets/135
Attachments:
zip-children-bug.diff - https://www.assembla.com/spaces/clojure/documents/cqC9AaydWr3PjFeJe5afGb/download/cqC9AaydWr3PjFeJe5afGb

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

meikelbrandmeyer said: [file:cqC9AaydWr3PjFeJe5afGb]: Patch for the children bug in the zipper





[CLJ-139] defmulti should not add {:tag 'clojure.lang.MultiFn} to multimethod metatdata Created: 02/Jul/09  Updated: 11/Oct/10  Resolved: 11/Oct/10

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

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

Approval: Ok

 Description   

defmulti's current behavior of adding a {:tag 'clojure.lang.MultiFn} to the new multimethod's metadata interferes with providing a type hint for the return value of the multimethod. This is easily fixed by deleting this behavior, as in the attached patch.



 Comments   
Comment by Assembla Importer [ 11/Oct/10 3:25 PM ]

Converted from http://www.assembla.com/spaces/clojure/tickets/139
Attachments:
0003-Removed-tag-MultiFn-inserted-by-defmulti.patch - https://www.assembla.com/spaces/clojure/documents/cTOAMyzSmr3QQreJe5aVNr/download/cTOAMyzSmr3QQreJe5aVNr

Comment by Assembla Importer [ 11/Oct/10 3:25 PM ]

davidmiller said: [file:cTOAMyzSmr3QQreJe5aVNr]: Patch to core.clj to fix defmulti behavior

Comment by Assembla Importer [ 11/Oct/10 3:25 PM ]

aaron said: before patch as of 167a73857a746e8dbeeb

user=> (defmulti foo "this is foo" {:author "me" :arglists '([bar])} type)
#'user/foo
user=> (meta (var foo))
{:ns #<Namespace user>, :name foo, :arglists ([bar]), :author "me", :doc "this is foo", :line 1, :file "NO_SOURCE_PATH", :tag clojure.lang.MultiFn}

after patch

user=> (defmulti foo "this is foo" {:author "me" :arglists '([bar])} type)
#'user/foo
user=> (meta (var foo))
{:ns #<Namespace user>, :name foo, :arglists ([bar]), :author "me", :doc "this is foo", :line 1, :file "NO_SOURCE_PATH"}

Comment by Assembla Importer [ 11/Oct/10 3:25 PM ]

stu said: Updating tickets (#139, #278, #285, #368, #443, #430)

Comment by Assembla Importer [ 11/Oct/10 3:25 PM ]

stu said: Updating tickets (#139, #278, #285, #368, #443, #430)





[CLJ-145] clojure.set/rename-keys doesn't do what it says it should Created: 06/Jul/09  Updated: 24/Aug/10  Resolved: 24/Aug/10

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

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

Approval: Ok

 Description   

user=> (doc rename-keys)
-------------------------
clojure.set/rename-keys
([map kmap])
Returns the map with the keys in kmap renamed to the vals in kmap
nil

I expect the return value to be a map of the same size as the first input, with its keys being those in the first input other than those which are substituted according to the second. That is not what occurs:

user=> (rename-keys {:foo 1 :bar 2} {:foo :new-foo :zob :new-zob})
{:new-zob nil, :new-foo 1, :bar 2}

Tested against a1397390d8b3b63f2039359520629d87b152d717 (current at time of filing).



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

Converted from http://www.assembla.com/spaces/clojure/tickets/145
Attachments:
patch-issue145.diff - https://www.assembla.com/spaces/clojure/documents/d8vdtEbFyr36hUeJe5aVNr/download/d8vdtEbFyr36hUeJe5aVNr

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

rnewman said: [file:d8vdtEbFyr36hUeJe5aVNr]: One-line fix.

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

rnewman said: This is still biting me a little, so here's a one-line fix.

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

chouser@n01se.net said: Richard, would you please use git to format your patch as described here: http://clojure.org/patches

Thanks,
--Chouser

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

rnewman said: Done. Sorry about that!

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

richhickey said: Thanks for the patch. FYI, the tests needed patching too.





[CLJ-151] Function to return last n items of a seq Created: 11/Jul/09  Updated: 24/Aug/10  Resolved: 24/Aug/10

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

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

Approval: Ok

 Description   

My fork on github of clojure had a last-n branch that is an unacceptable breaking change by returning a seq even for just a single item. A different solution is needed.



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

Converted from http://www.assembla.com/spaces/clojure/tickets/151
Attachments:
last-n.diff - https://www.assembla.com/spaces/clojure/documents/cgeCSqBO4r3PxueJe5afGb/download/cgeCSqBO4r3PxueJe5afGb
last-n-v2.diff - https://www.assembla.com/spaces/clojure/documents/cqqgugEomr3ONjeJe5aVNr/download/cqqgugEomr3ONjeJe5aVNr
take-last.diff - https://www.assembla.com/spaces/clojure/documents/b9iKQQUMir3OzreJe5aVNr/download/b9iKQQUMir3OzreJe5aVNr

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

chouser@n01se.net said: [file:cgeCSqBO4r3PxueJe5afGb]: last with one arg is unchanged. last with an extra count arg returns a seq

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

chouser@n01se.net said: Attached a patch that defined 'last' with one arg as it has been. 'last' with an extra count arg returns a seq.

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

chouser@n01se.net said: [file:cqqgugEomr3ONjeJe5aVNr]: bail early if end of seq found while setting up lead

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

chouser@n01se.net said: I've attached an improved patch [file:last-n-v2.diff]

Both the old and new patches avoid retaining the head, as demonstrated by the first expr blowing the heap, but second not:

(last 3 (map count (doall (take 1e5 (iterate #(str % 'x) "y")))))
(last 3 (map count (take 1e5 (iterate #(str % 'x) "y"))))t

However, the v2 patch also gives up walking the 'lead' seq forward as soon as it reaches the end of the input seq (this is how 'drop' behaves). You can observe the differnce by seeing that with v2 this returns immediately:

(last 1e10 [1 2 3 4 5])

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

chouser@n01se.net said: For small n's and large collections implementing IPersistentStack, 'last' could be much efficient by using 'pop' and 'reverse', though this would mean it wouldn't always use the seq of the collection.

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

richhickey said: I'm not sure I get the reverse bit - reverse is fast for stacks? Certainly we could do better for colls implementing Indexed or RandomAccess. I guess all that means is that the doc shouldn't dictate linear time, and should instead say maybe in best time complexity supported by the data structure.

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

richhickey said: faster for last 1 I should say. Seems more and more like last 1 and last N shouldn't be combined.

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

chouser@n01se.net said: [file:b9iKQQUMir3OzreJe5aVNr]: implement take-last as its own function

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

chouser@n01se.net said: (In [[r:0ba40a260162330836b97f6d1bf3466404a63b55]]) Implement take-last Fixes #151

Branch: master





[CLJ-146] NPE when creating an empty array of ints, longs, floats or doubles Created: 07/Jul/09  Updated: 24/Aug/10  Resolved: 24/Aug/10

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

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

Approval: Ok

 Description   

(int-array []) should return an empty array - the same as (int-array 0). Also true for long-array, float-array and double-array.

user=> (doc int-array)
-------------------------
clojure.core/int-array
([size-or-seq] [size init-val-or-seq])
Creates an array of ints

OK:
user=> (int-array [1 2])
#<int[] [I@1342ba4>
user=> (vec (int-array [1 2]))
[1 2]

NPE:
user=> (int-array [])
java.lang.NullPointerException (NO_SOURCE_FILE:0)

OK:
user=> (int-array 2)
#<int[] [I@18d9850>
user=> (vec (int-array 2))
[0 0]
user=> (int-array 0)
#<int[] [I@1e97f9f>
user=> (vec (int-array 0))
[]

NPE:
user=> (long-array [])
java.lang.NullPointerException (NO_SOURCE_FILE:0)
user=> (float-array [])
java.lang.NullPointerException (NO_SOURCE_FILE:0)
user=> (double-array [])
java.lang.NullPointerException (NO_SOURCE_FILE:0)

user=> (int-array ())
java.lang.NullPointerException (NO_SOURCE_FILE:0)
user=> (int-array {})
java.lang.NullPointerException (NO_SOURCE_FILE:0)
user=> (int-array #{})
java.lang.NullPointerException (NO_SOURCE_FILE:0)



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

Converted from http://www.assembla.com/spaces/clojure/tickets/146
Attachments:
fix_and_test_146.diff - https://www.assembla.com/spaces/clojure/documents/b0V98YAUWr3Qj6eJe5afGb/download/b0V98YAUWr3Qj6eJe5afGb
fix_and_test_146_v2.diff - https://www.assembla.com/spaces/clojure/documents/aa7RF6AVOr3PFkeJe5afGb/download/aa7RF6AVOr3PFkeJe5afGb
fix_and_test_146_v3.diff - https://www.assembla.com/spaces/clojure/documents/bNDk58GSGr3OJWeJe5aVNr/download/bNDk58GSGr3OJWeJe5aVNr

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

fsodomka said: [file:b0V98YAUWr3Qj6eJe5afGb]: fix errors and add tests

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

fsodomka said: See patch fix_and_test_146.diff. Fixes Java code and adds tests. It is my first patch for the Java code of Clojure, so be careful

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

fsodomka said: [file:aa7RF6AVOr3PFkeJe5afGb]: fix errors and add tests

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

richhickey said: A better fix is to use RT.count(s) rather than s.count(). Then there is no special handling.

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

fsodomka said: [file:bNDk58GSGr3OJWeJe5aVNr]: fix errors and add tests

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

fsodomka said: New version of patch uploaded. See if this works.

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

richhickey said: Patch v3 is ok, thanks

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

chouser@n01se.net said: Child association with ticket #188 was added

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

fsodomka said: (In [[r:270185aba54cef1d8ce59ec347b5623f2e502afe]]) fixed NPE when creating an empty array of ints, longs, floats or doubles, fixes #146

Signed-off-by: Chouser <chouser@n01se.net>

Branch: master





[CLJ-155] Classname/staticThing leaves Classname unresolved at syntaxQuote time Created: 14/Jul/09  Updated: 24/Aug/10  Resolved: 24/Aug/10

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

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

Approval: Ok

 Description   

Class names for static field and method references are resolved differently for modern vs. old syntax:

user=> `(Integer/foo)
(Integer/foo)
user=> `(. Integer foo)
(. java.lang.Integer user/foo)

This means that using an imported class in a defmacro via modern syntax will break if the macro is expanded in a namespace that doesn't have that class imported, or worse could attempt to a same-named class from a different package.

Reported by technomancy in IRC



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

Converted from http://www.assembla.com/spaces/clojure/tickets/155
Attachments:
ticket-155.diff - https://www.assembla.com/spaces/clojure/documents/bvQRQmB_Or3OXZeJe5aVNr/download/bvQRQmB_Or3OXZeJe5aVNr

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

chouser@n01se.net said: [file:bvQRQmB_Or3OXZeJe5aVNr]: Resolve classnames in modern-syntax static calls at syntaxQuote time.

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

chouser@n01se.net said: Attached patch as discussed in IRC.

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

chouser@n01se.net said: Child association with ticket #156 was added

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

chouser@n01se.net said: (In [[r:994f118c56bb3139f87093a6ec44eb8c04acbdaf]]) Resolve classnames in modern-syntax static calls at syntaxQuote time. Fixes #155

Signed-off-by: Chouser <chouser@n01se.net>

Branch: master





[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-156] Classname/staticThing leaves Classname unresolved at syntaxQuote time [for 1.0 from #155] Created: 13/Jul/09  Updated: 22/Sep/10  Resolved: 22/Sep/10

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

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

Approval: Ok

 Description   

This ticket is for tracking #155 against Clojure 1.0



 Comments   
Comment by Assembla Importer [ 22/Sep/10 2:27 PM ]

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

Comment by Assembla Importer [ 22/Sep/10 2:27 PM ]

chouser@n01se.net said: Parent association with ticket #155 was added

Comment by Assembla Importer [ 22/Sep/10 2:27 PM ]

stu said: Updating tickets (#180, #156, #187, #188)

invalidating old 1.0 back-tickets so they don't keep showing up in reports





[CLJ-152] Doc string for "binding" should be explicit about binding in parallel Created: 12/Jul/09  Updated: 24/Aug/10  Resolved: 24/Aug/10

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

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

Approval: Ok

 Description   

As Tom mentions here: http://groups.google.com/group/clojure/browse_frm/thread/81fc236d3436d72b
the parallel nature of the bindings created by "binding" does not appear to be documented either in its doc string or at clojure.org.
The doc string for binding should mention it.

A proposal for discussion/approval:

clojure.core/binding
([bindings & body])
Macro
binding => var-symbol init-expr

Creates new bindings for the (already-existing) vars, with the
supplied initial values, executes the exprs in an implicit do, then
re-establishes the bindings that existed before. The new bindings
are made in parallel: all init-exprs are evaluated before the
vars are bound as a group to their new values.



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

Converted from http://www.assembla.com/spaces/clojure/tickets/152
Attachments:
152-binding-docstring.diff - https://www.assembla.com/spaces/clojure/documents/bGPkGOMkir3OYweJe5aVNr/download/bGPkGOMkir3OYweJe5aVNr

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

stuart.sierra said: [file:bGPkGOMkir3OYweJe5aVNr]: Patch, very similar to Stephen's docstring

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

stuart.sierra said: (In [[r:ff116fb3a986334e77bc0521167fe89c8e27313d]]) core.clj: binding doc string now says it's parallel, fixes #152

Signed-off-by: Chouser <chouser@n01se.net>

Branch: master





[CLJ-154] (keyword "a/b") => ns nil, name a/b; should be ns a, name b Created: 13/Jul/09  Updated: 24/Aug/10  Resolved: 24/Aug/10

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

Type: Defect
Reporter: Anonymous Assignee: Stephen C. Gilardi
Resolution: Completed Votes: 0
Labels: None

Approval: Ok

 Description   

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

for generated keywords, seems dodgy
(keyword "aaaaa/bbbbb") => :aaaaa/bbbbb
(name (keyword "aaaaa/bbbbb")) => "aaaaa/bbbbb"
(namespace (keyword "aaaaa/bbbbb")) => nil

It would seem cleaner if the java Keyword.intern() and Symbol.intern()
methods were symmetrical and used the same way in core.clj.



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

Converted from http://www.assembla.com/spaces/clojure/tickets/154
Attachments:
fix-154.patch - https://www.assembla.com/spaces/clojure/documents/aGf_3wB8Cr3PfNeJe5afGb/download/aGf_3wB8Cr3PfNeJe5afGb

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

scgilardi said: [file:aGf_3wB8Cr3PfNeJe5afGb]

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

scgilardi said: Description of fix-154.patch:

  • added intern(String nsname) to Keyword.java
  • changed clojure.core/keyword to call it
  • updated clojure.core/symbol and clojure.core/keyword to new static call syntax
  • added tests to reader.clj using corrected keyword, duplicating similar tests for symbol, and adding tests of keyword constructed from a symbol
Comment by Assembla Importer [ 24/Aug/10 6:55 AM ]

importer said: (In [[r:a1b4a33bb8ccf739c481754fc563117ed3604c75]]) fixed keyword ctor, added tests, fix #154

Signed-off-by: Chouser <chouser@n01se.net>

Branch: master





[CLJ-136] Enhancement: give meaningful names to inline expanders Created: 26/Jun/09  Updated: 24/Aug/10  Resolved: 24/Aug/10

Status: Closed
Project: