<!--
RSS generated by JIRA (4.4#649-r158309) at Sun May 19 01:58:29 CDT 2013

It is possible to restrict the fields that are returned in this document by specifying the 'field' parameter in your request.
For example, to request only the issue key and summary add field=key&field=summary to the URL of your request.
For example:
http://dev.clojure.org/jira/sr/jira.issueviews:searchrequest-xml/temp/SearchRequest.xml?jqlQuery=project+%3D+CLJ+AND+resolution+%3D+Unresolved+AND+fixVersion+is+EMPTY+ORDER+BY+priority+DESC&tempMax=1000&field=key&field=summary
-->
<!-- If you wish to do custom client-side styling of RSS, uncomment this:
<?xml-stylesheet href="http://dev.clojure.org/jira/styles/jiraxml2html.xsl" type="text/xsl"?>
-->
<rss version="0.92">
    <channel>
        <title>Clojure JIRA</title>
        <link>http://dev.clojure.org/jira/secure/IssueNavigator.jspa?reset=true&amp;jqlQuery=project+%3D+CLJ+AND+resolution+%3D+Unresolved+AND+fixVersion+is+EMPTY+ORDER+BY+priority+DESC</link>
        <description>An XML representation of a search request</description>
                <language>en-us</language>
                        <issue start="0" end="168" total="168"/>
                <build-info>
            <version>4.4</version>
            <build-number>649</build-number>
            <build-date>25-07-2011</build-date>
        </build-info>
<item>
            <title>[CLJ-1001] Proxy cannot call proper super-class method</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1001</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;Attached is a program that reproduces this issue.  We have a proxy, `p&apos;, which sub-classes java.io.InputStream.  There are three methods named `read&apos; in java.io.InputStream: abstract int read(); int read(byte[] b); and int read(byte[] b, int off, int len); see &lt;a href=&quot;http://docs.oracle.com/javase/6/docs/api/java/io/InputStream.html&quot;&gt;http://docs.oracle.com/javase/6/docs/api/java/io/InputStream.html&lt;/a&gt;.  In the definition of proxy `p&apos;, we implement the abstract variant of method `read&apos;, making `p&apos; a concrete instance of java.io.InputStream.&lt;/p&gt;

&lt;p&gt;The first invocation, (. p read), returns -1, which is expected.&lt;/p&gt;

&lt;p&gt;The second invocation, (. p (read b 0 n)), should call int read(byte[] b, int off, int len); in java.io.InputStream.  But these are actual behavior:&lt;/p&gt;


&lt;p&gt;$ clojure1.2 ~/tmp/proxy-bug.clj &lt;br/&gt;
Exception in thread &quot;main&quot; java.lang.IllegalArgumentException: Wrong number of args (4) passed to: user$eval1$fn (proxy-bug.clj:0)&lt;br/&gt;
        at clojure.lang.Compiler.eval(Compiler.java:5441)&lt;br/&gt;
        at clojure.lang.Compiler.load(Compiler.java:5858)&lt;br/&gt;
        at clojure.lang.Compiler.loadFile(Compiler.java:5821)&lt;br/&gt;
        at clojure.main$load_script.invoke(main.clj:221)&lt;br/&gt;
        at clojure.main$script_opt.invoke(main.clj:273)&lt;br/&gt;
        at clojure.main$main.doInvoke(main.clj:354)&lt;br/&gt;
        at clojure.lang.RestFn.invoke(RestFn.java:408)&lt;br/&gt;
        at clojure.lang.Var.invoke(Var.java:365)&lt;br/&gt;
        at clojure.lang.AFn.applyToHelper(AFn.java:161)&lt;br/&gt;
        at clojure.lang.Var.applyTo(Var.java:482)&lt;br/&gt;
        at clojure.main.main(main.java:37)&lt;br/&gt;
Caused by: java.lang.IllegalArgumentException: Wrong number of args (4) passed to: user$eval1$fn&lt;br/&gt;
        at clojure.lang.AFn.throwArity(AFn.java:437)&lt;br/&gt;
        at clojure.lang.AFn.invoke(AFn.java:51)&lt;br/&gt;
        at user.proxy$java.io.InputStream$0.read(Unknown Source)&lt;br/&gt;
        at user$eval1.invoke(proxy-bug.clj:9)&lt;br/&gt;
        at clojure.lang.Compiler.eval(Compiler.java:5425)&lt;br/&gt;
        ... 10 more&lt;/p&gt;


&lt;p&gt;$ clojure1.2 ~/tmp/proxy-bug.clj &lt;br/&gt;
Exception in thread &quot;main&quot; java.lang.IllegalArgumentException: Wrong number of args (4) passed to: user$eval1$fn (proxy-bug.clj:0)&lt;br/&gt;
        at clojure.lang.Compiler.eval(Compiler.java:5441)&lt;br/&gt;
        at clojure.lang.Compiler.load(Compiler.java:5858)&lt;br/&gt;
        at clojure.lang.Compiler.loadFile(Compiler.java:5821)&lt;br/&gt;
        at clojure.main$load_script.invoke(main.clj:221)&lt;br/&gt;
        at clojure.main$script_opt.invoke(main.clj:273)&lt;br/&gt;
        at clojure.main$main.doInvoke(main.clj:354)&lt;br/&gt;
        at clojure.lang.RestFn.invoke(RestFn.java:408)&lt;br/&gt;
        at clojure.lang.Var.invoke(Var.java:365)&lt;br/&gt;
        at clojure.lang.AFn.applyToHelper(AFn.java:161)&lt;br/&gt;
        at clojure.lang.Var.applyTo(Var.java:482)&lt;br/&gt;
        at clojure.main.main(main.java:37)&lt;br/&gt;
Caused by: java.lang.IllegalArgumentException: Wrong number of args (4) passed to: user$eval1$fn&lt;br/&gt;
        at clojure.lang.AFn.throwArity(AFn.java:437)&lt;br/&gt;
        at clojure.lang.AFn.invoke(AFn.java:51)&lt;br/&gt;
        at user.proxy$java.io.InputStream$0.read(Unknown Source)&lt;br/&gt;
        at user$eval1.invoke(proxy-bug.clj:9)&lt;br/&gt;
        at clojure.lang.Compiler.eval(Compiler.java:5425)&lt;br/&gt;
        ... 10 more&lt;/p&gt;</description>
                <environment>Linux herberteuler 3.2.0-2-amd64 #1 SMP Sat May 12 23:08:28 UTC 2012 x86_64 GNU/Linux</environment>
            <key id="15471">CLJ-1001</key>
            <summary>Proxy cannot call proper super-class method</summary>
                <type id="1" iconUrl="http://dev.clojure.org/jira/images/icons/bug.gif">Defect</type>
                                <priority id="3" iconUrl="http://dev.clojure.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="herberteuler@yahoo.com.cn">Guanpeng Xu</reporter>
                        <labels>
                    </labels>
                <created>Wed, 23 May 2012 22:21:33 -0500</created>
                <updated>Wed, 23 May 2012 22:24:43 -0500</updated>
                                    <version>Release 1.2</version>
                <version>Release 1.3</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                        <comments>
                    <comment id="28577" author="herberteuler@yahoo.com.cn" created="Wed, 23 May 2012 22:24:43 -0500"  >&lt;p&gt;The second behavior should be in Clojure 1.3:&lt;/p&gt;

&lt;p&gt;$ clojure1.3 ~/tmp/proxy-bug.clj &lt;br/&gt;
Exception in thread &quot;main&quot; clojure.lang.ArityException: Wrong number of args (4) passed to: user$eval1$fn&lt;br/&gt;
        at clojure.lang.AFn.throwArity(AFn.java:437)&lt;br/&gt;
        at clojure.lang.AFn.invoke(AFn.java:51)&lt;br/&gt;
        at user.proxy$java.io.InputStream$0.read(Unknown Source)&lt;br/&gt;
        at user$eval1.invoke(proxy-bug.clj:9)&lt;br/&gt;
        at clojure.lang.Compiler.eval(Compiler.java:6468)&lt;br/&gt;
        at clojure.lang.Compiler.load(Compiler.java:6905)&lt;br/&gt;
        at clojure.lang.Compiler.loadFile(Compiler.java:6866)&lt;br/&gt;
        at clojure.main$load_script.invoke(main.clj:282)&lt;br/&gt;
        at clojure.main$script_opt.invoke(main.clj:342)&lt;br/&gt;
        at clojure.main$main.doInvoke(main.clj:426)&lt;br/&gt;
        at clojure.lang.RestFn.invoke(RestFn.java:408)&lt;br/&gt;
        at clojure.lang.Var.invoke(Var.java:401)&lt;br/&gt;
        at clojure.lang.AFn.applyToHelper(AFn.java:161)&lt;br/&gt;
        at clojure.lang.Var.applyTo(Var.java:518)&lt;br/&gt;
        at clojure.main.main(main.java:37)&lt;/p&gt;

&lt;p&gt;Sorry for the inconvenience.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="11247" name="proxy-bug.clj" size="274" author="herberteuler@yahoo.com.cn" created="Wed, 23 May 2012 22:21:33 -0500" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                                                                                            </customfields>
    </item>

<item>
            <title>[CLJ-740] Unnecessary boxing of primitives in case form</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-740</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;Found this while profiling some performance-critical code.&lt;/p&gt;

&lt;p&gt;Consider the following Clojure function:&lt;/p&gt;
&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;(defn test-&lt;span class=&quot;code-keyword&quot;&gt;case&lt;/span&gt; ^&lt;span class=&quot;code-object&quot;&gt;double&lt;/span&gt; [^&lt;span class=&quot;code-object&quot;&gt;long&lt;/span&gt; i ^&lt;span class=&quot;code-object&quot;&gt;double&lt;/span&gt; d1 ^&lt;span class=&quot;code-object&quot;&gt;double&lt;/span&gt; d2]
  (&lt;span class=&quot;code-keyword&quot;&gt;case&lt;/span&gt; (&lt;span class=&quot;code-object&quot;&gt;int&lt;/span&gt; i)
    0 d1
    d2))&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;Current Clojure 1.3 snapshot compiles it to:&lt;/p&gt;
&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;&lt;span class=&quot;code-keyword&quot;&gt;public&lt;/span&gt; &lt;span class=&quot;code-keyword&quot;&gt;final&lt;/span&gt; &lt;span class=&quot;code-object&quot;&gt;double&lt;/span&gt; invokePrim(&lt;span class=&quot;code-object&quot;&gt;long&lt;/span&gt;, &lt;span class=&quot;code-object&quot;&gt;double&lt;/span&gt;, &lt;span class=&quot;code-object&quot;&gt;double&lt;/span&gt;)   &lt;span class=&quot;code-keyword&quot;&gt;throws&lt;/span&gt; java.lang.Exception;
  Code:
   0:	lload_1
   1:	invokestatic	#67; &lt;span class=&quot;code-comment&quot;&gt;//Method clojure/lang/RT.intCast:(J)I
&lt;/span&gt;   4:	istore	7
   6:	iload	7
   8:	i2l
   9:	invokestatic	#73; &lt;span class=&quot;code-comment&quot;&gt;//Method clojure/lang/Numbers.num:(J)Ljava/lang/&lt;span class=&quot;code-object&quot;&gt;Number&lt;/span&gt;;
&lt;/span&gt;   12:	invokestatic	#79; &lt;span class=&quot;code-comment&quot;&gt;//Method clojure/lang/Util.hash:(Ljava/lang/&lt;span class=&quot;code-object&quot;&gt;Object&lt;/span&gt;;)I
&lt;/span&gt;   15:	iconst_0
   16:	ishr
   17:	iconst_1
   18:	iand
   19:	tableswitch{ &lt;span class=&quot;code-comment&quot;&gt;//0 to 0
&lt;/span&gt;		0: 36;
		&lt;span class=&quot;code-keyword&quot;&gt;default&lt;/span&gt;: 58 }
   36:	iload	7
   38:	i2l
   39:	invokestatic	#73; &lt;span class=&quot;code-comment&quot;&gt;//Method clojure/lang/Numbers.num:(J)Ljava/lang/&lt;span class=&quot;code-object&quot;&gt;Number&lt;/span&gt;;
&lt;/span&gt;   42:	getstatic	#45; &lt;span class=&quot;code-comment&quot;&gt;//Field const__3:Ljava/lang/&lt;span class=&quot;code-object&quot;&gt;Object&lt;/span&gt;;
&lt;/span&gt;   45:	invokestatic	#83; &lt;span class=&quot;code-comment&quot;&gt;//Method clojure/lang/Util.equals:(Ljava/lang/&lt;span class=&quot;code-object&quot;&gt;Object&lt;/span&gt;;Ljava/lang/&lt;span class=&quot;code-object&quot;&gt;Object&lt;/span&gt;;)Z
&lt;/span&gt;   48:	ifeq	58
   51:	dload_3
   52:	invokestatic	#88; &lt;span class=&quot;code-comment&quot;&gt;//Method java/lang/&lt;span class=&quot;code-object&quot;&gt;Double&lt;/span&gt;.valueOf:(D)Ljava/lang/&lt;span class=&quot;code-object&quot;&gt;Double&lt;/span&gt;;
&lt;/span&gt;   55:	&lt;span class=&quot;code-keyword&quot;&gt;goto&lt;/span&gt;	63
   58:	dload	5
   60:	invokestatic	#88; &lt;span class=&quot;code-comment&quot;&gt;//Method java/lang/&lt;span class=&quot;code-object&quot;&gt;Double&lt;/span&gt;.valueOf:(D)Ljava/lang/&lt;span class=&quot;code-object&quot;&gt;Double&lt;/span&gt;;
&lt;/span&gt;   63:	checkcast	#92; &lt;span class=&quot;code-comment&quot;&gt;//class java/lang/&lt;span class=&quot;code-object&quot;&gt;Number&lt;/span&gt;
&lt;/span&gt;   66:	invokevirtual	#96; &lt;span class=&quot;code-comment&quot;&gt;//Method java/lang/&lt;span class=&quot;code-object&quot;&gt;Number&lt;/span&gt;.doubleValue:()D
&lt;/span&gt;   69:	dreturn
}&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;This bytecode contains boxing of primitives (calls to clojure/lang/Numbers.num and java/lang/Double.valueOf) and calls to clojure/lang/Util.hash and clojure/lang/Util.equals that does not seem necessary.&lt;/p&gt;

&lt;p&gt;At 60-66 primitive double is boxed into Double only to be converted back into primitive.&lt;/p&gt;

&lt;p&gt;The equivalent Java code compiles to much simpler and faster bytecode:&lt;/p&gt;
&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;&lt;span class=&quot;code-keyword&quot;&gt;public&lt;/span&gt; &lt;span class=&quot;code-object&quot;&gt;double&lt;/span&gt; testCase(&lt;span class=&quot;code-object&quot;&gt;long&lt;/span&gt;, &lt;span class=&quot;code-object&quot;&gt;double&lt;/span&gt;, &lt;span class=&quot;code-object&quot;&gt;double&lt;/span&gt;);
  Code:
   0:	lload_1
   1:	l2i
   2:	lookupswitch{ &lt;span class=&quot;code-comment&quot;&gt;//1
&lt;/span&gt;		0: 20;
		&lt;span class=&quot;code-keyword&quot;&gt;default&lt;/span&gt;: 22 }
   20:	dload_3
   21:	dreturn
   22:	dload	5
   24:	dreturn
}&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;</description>
                <environment></environment>
            <key id="14354">CLJ-740</key>
            <summary>Unnecessary boxing of primitives in case form</summary>
                <type id="1" iconUrl="http://dev.clojure.org/jira/images/icons/bug.gif">Defect</type>
                                <priority id="3" iconUrl="http://dev.clojure.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="kryshen">Mikhail Kryshen</reporter>
                        <labels>
                    </labels>
                <created>Thu, 17 Feb 2011 02:49:45 -0600</created>
                <updated>Tue, 1 Mar 2011 02:51:43 -0600</updated>
                                    <version>Release 1.3</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>1</watches>
                        <comments>
                    <comment id="26250" author="ataggart" created="Mon, 28 Feb 2011 14:16:07 -0600"  >&lt;p&gt;Improved via patch on &lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-426&quot; title=&quot;case should handle hash collision&quot;&gt;&lt;del&gt;CLJ-426&lt;/del&gt;&lt;/a&gt;.&lt;/p&gt;

&lt;div class=&quot;preformatted panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;preformattedContent panelContent&quot;&gt;
&lt;pre&gt;(defn test-case ^double [^long i ^double d1 ^double d2]
  (case (int i)
    0 d1
    d2))
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;now emits as&lt;/p&gt;

&lt;div class=&quot;preformatted panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;preformattedContent panelContent&quot;&gt;
&lt;pre&gt; 0  lload_1 [i]
 1  invokestatic clojure.lang.RT.intCast(long) : int [67]
 4  istore 7 [G__7903] // let-bound expression
 6  iload 7 [G__7903]
 8  tableswitch default: 32
      case 0: 28
28  dload_3 [d2]
29  goto 34
32  dload 5 [arg2]
34  dreturn
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;or if the int cast of the expression is omitted:&lt;/p&gt;

&lt;div class=&quot;preformatted panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;preformattedContent panelContent&quot;&gt;
&lt;pre&gt; 0  lload_1 [i]
 1  lstore 7 [G__7903] // let-bound expression
 3  lload 7 [G__7903]
 5  l2i
 6  tableswitch default: 35
      case 0: 24
24  lconst_0           // match, verify long expr wasn&apos;t truncated
25  lload 7 [G__7903]
27  lcmp
28  ifne 35
31  dload_3 [d2]
32  goto 37
35  dload 5 [arg2]
37  dreturn
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                                                                                            </customfields>
    </item>

<item>
            <title>[CLJ-760] ClassNotFound when AOT compiling a self-referring deftype extended to a protocol</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-760</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;If I create a deftype that refers to itself in a protocol extension like below:&lt;/p&gt;
&lt;div class=&quot;preformatted panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;preformattedContent panelContent&quot;&gt;
&lt;pre&gt;(ns type-test)

(defprotocol Foo
  (isa-foo [x]))

(deftype TypeTest []
  Foo
  (isa-foo [x]
           (instance? TypeTest x)))
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;And use that code via another namespace:&lt;/p&gt;

&lt;div class=&quot;preformatted panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;preformattedContent panelContent&quot;&gt;
&lt;pre&gt;(ns test-type-user
  (:use [type-test :only (isa-foo)])
  (:import [type-test TypeTest]))

(isa-foo (TypeTest.))
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;When I try to AOT compile the test-type-user namespace with Clojure 1.2.0, I get &lt;em&gt;java.lang.NoClassDefFoundError: compile&lt;/em&gt;&lt;em&gt;stub/type-test/TypeTest (test_type_user.clj:5)&lt;/em&gt;.  Full stack trace attached.  Running the same code on 1.2.1 and 1.3.0-alpha6 yielded the same exception with a slightly different error message (stacktrace for 1.2.1 is also in the attached file).&lt;/p&gt;

&lt;p&gt;This came up in a test at Revelytix.  We worked around this issue by not using &lt;em&gt;instance?&lt;/em&gt; and instead comparing based on class name.  Another workaround is to define the deftype and the extension separately (using extend-type or something similar).  This problem also doesn&apos;t occur if the usage of the deftype and the definition of it are in the same namespace (i.e. if &lt;em&gt;type-test&lt;/em&gt; and &lt;em&gt;test-type-user&lt;/em&gt; were in the same file).&lt;/p&gt;
</description>
                <environment>Clojure 1.2.0, 1.2.1, 1.3.0-alpha6, JDK 1.6.0_24, Ubuntu 10.10</environment>
            <key id="14376">CLJ-760</key>
            <summary>ClassNotFound when AOT compiling a self-referring deftype extended to a protocol</summary>
                <type id="1" iconUrl="http://dev.clojure.org/jira/images/icons/bug.gif">Defect</type>
                                <priority id="3" iconUrl="http://dev.clojure.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="ryansenior">Ryan Senior</reporter>
                        <labels>
                    </labels>
                <created>Fri, 18 Mar 2011 09:06:37 -0500</created>
                <updated>Fri, 18 Mar 2011 10:27:46 -0500</updated>
                                    <version>Release 1.2</version>
                                                        <due></due>
                    <votes>1</votes>
                        <watches>1</watches>
                        <comments>
                    <comment id="26312" author="alexmiller" created="Fri, 18 Mar 2011 10:27:46 -0500"  >&lt;p&gt;The first case where we saw this was actually in having a deftype implement a Java interface (not a protocol) and in that case you cannot extend the interface outside the deftype (although comparing based on class name of course works).  &lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="10153" name="stacktraces.txt" size="4744" author="ryansenior" created="Fri, 18 Mar 2011 09:06:37 -0500" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                                                                                            </customfields>
    </item>

<item>
            <title>[CLJ-864] defrecord positional arity factory fn should have an inline version that calls the record constructor</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-864</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;defrecord positional arity factory fn should have an inline version that calls the record constructor&lt;/p&gt;</description>
                <environment></environment>
            <key id="14900">CLJ-864</key>
            <summary>defrecord positional arity factory fn should have an inline version that calls the record constructor</summary>
                <type id="4" iconUrl="http://dev.clojure.org/jira/images/icons/improvement.gif">Enhancement</type>
                                <priority id="3" iconUrl="http://dev.clojure.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="hiredman">Kevin Downey</reporter>
                        <labels>
                    </labels>
                <created>Wed, 26 Oct 2011 03:17:55 -0500</created>
                <updated>Wed, 26 Oct 2011 03:17:55 -0500</updated>
                                                                            <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                                                                                            </customfields>
    </item>

<item>
            <title>[CLJ-1046] Drop-while as a reducer</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1046</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;Implement drop-while as a reducer. Follows the same atom-based strategy as drop and take.&lt;/p&gt;

&lt;p&gt;Does not depend on any of my other reducer patches, but there will probably be some minor merge conflicts unless it is merged after &lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-1045&quot; title=&quot;Generalize/refactor implementation of PersistentVector/coll-fold&quot;&gt;CLJ-1045&lt;/a&gt;, and before &lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-992&quot; title=&quot;`iterate` reducer&quot;&gt;CLJ-992&lt;/a&gt; and &lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-993&quot; title=&quot;`range` reducer&quot;&gt;CLJ-993&lt;/a&gt;.&lt;/p&gt;</description>
                <environment></environment>
            <key id="15636">CLJ-1046</key>
            <summary>Drop-while as a reducer</summary>
                <type id="4" iconUrl="http://dev.clojure.org/jira/images/icons/improvement.gif">Enhancement</type>
                                <priority id="3" iconUrl="http://dev.clojure.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="amalloy">Alan Malloy</reporter>
                        <labels>
                    </labels>
                <created>Sat, 18 Aug 2012 19:11:59 -0500</created>
                <updated>Sat, 18 Aug 2012 19:11:59 -0500</updated>
                                                                            <due></due>
                    <votes>0</votes>
                        <watches>3</watches>
                                <attachments>
                    <attachment id="11445" name="drop-while-reducer.patch" size="1997" author="amalloy" created="Sat, 18 Aug 2012 19:11:59 -0500" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10000" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Patch</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10002">Code and Test</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[CLJ-887] Error when calling primitive functions with destructuring in the arg vector</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-887</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;If one defines a primitive-taking function with destructuring, calling that function will result in a ClassCastException, IFF the primitive return-type hint is present.&lt;/p&gt;

&lt;div class=&quot;preformatted panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;preformattedContent panelContent&quot;&gt;
&lt;pre&gt;Clojure 1.4.0-master-SNAPSHOT
user=&amp;gt; (defn foo [[a b] ^long x ^long y] 0)
#&apos;user/foo
user=&amp;gt; (foo [1 2] 3 4)
0
user=&amp;gt; (defn foo ^long [[a b] ^long x ^long y] 0)
#&apos;user/foo
user=&amp;gt; (foo [1 2] 3 4)
ClassCastException user$foo cannot be cast to clojure.lang.IFn$OLLL  user/eval9 (NO_SOURCE_FILE:4)
user=&amp;gt; (pst)
ClassCastException user$foo cannot be cast to clojure.lang.IFn$OLLL
	user/eval9 (NO_SOURCE_FILE:4)
	clojure.lang.Compiler.eval (Compiler.java:6493)
	clojure.lang.Compiler.eval (Compiler.java:6459)
	clojure.core/eval (core.clj:2796)
	clojure.main/repl/read-eval-print--5967 (main.clj:244)
	clojure.main/repl/fn--5972 (main.clj:265)
	clojure.main/repl (main.clj:265)
	clojure.main/repl-opt (main.clj:331)
	clojure.main/main (main.clj:427)
	clojure.lang.Var.invoke (Var.java:397)
	clojure.lang.Var.applyTo (Var.java:518)
	clojure.main.main (main.java:37)
nil
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;</description>
                <environment></environment>
            <key id="15038">CLJ-887</key>
            <summary>Error when calling primitive functions with destructuring in the arg vector</summary>
                <type id="1" iconUrl="http://dev.clojure.org/jira/images/icons/bug.gif">Defect</type>
                                <priority id="3" iconUrl="http://dev.clojure.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="ataggart">Alexander Taggart</reporter>
                        <labels>
                    </labels>
                <created>Tue, 29 Nov 2011 15:46:47 -0600</created>
                <updated>Tue, 29 Nov 2011 15:48:19 -0600</updated>
                                    <version>Release 1.3</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>1</watches>
                                <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                                                                                            </customfields>
    </item>

<item>
            <title>[CLJ-884] Reflector error messages can be improved when no matching method is found.</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-884</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;When accessing a java method with an arity mismatch or a mismatched parameter type, Reflector.java returns the following error on REPL:&lt;br/&gt;
IllegalArgumentException No matching method found: xyz for class com.abc.MyClass&lt;/p&gt;

&lt;p&gt;eventhough method xyz might exist on MyClass, but was being called with the wrong number of arguments.&lt;/p&gt;

&lt;p&gt;Attached is a patch that fixes that problem.&lt;/p&gt;
</description>
                <environment>All</environment>
            <key id="15031">CLJ-884</key>
            <summary>Reflector error messages can be improved when no matching method is found.</summary>
                <type id="4" iconUrl="http://dev.clojure.org/jira/images/icons/improvement.gif">Enhancement</type>
                                <priority id="3" iconUrl="http://dev.clojure.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="rahulpilani">Rahul Pilani</reporter>
                        <labels>
                    </labels>
                <created>Sun, 27 Nov 2011 15:56:51 -0600</created>
                <updated>Fri, 23 Mar 2012 01:14:18 -0500</updated>
                                    <version>Release 1.3</version>
                                                        <due></due>
                    <votes>1</votes>
                        <watches>1</watches>
                        <comments>
                    <comment id="27984" author="jafingerhut" created="Thu, 22 Mar 2012 20:47:21 -0500"  >&lt;p&gt;diff.patch of Nov 27, 2011 does not apply cleanly to latest master version of Clojure code (using &quot;patch -p1 &amp;lt; diff.patch&quot;, at least).  It is preferred by Clojure team that patches are in git format-patch format.  Instructions for producing such a patch are given at &lt;a href=&quot;http://clojure.org/patches&quot;&gt;http://clojure.org/patches&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;Rahul, are you planning to sign a Clojure Contributor Agreement?  Without that, this code cannot be included in Clojure, unless a contributor reimplements it on their own.&lt;/p&gt;</comment>
                    <comment id="27985" author="jafingerhut" created="Fri, 23 Mar 2012 01:14:18 -0500"  >&lt;p&gt;In private communication with the patch author today, he expressed an interest in submitting a signed CA so this patch can be considered for inclusion in Clojure.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="10718" name="diff.patch" size="4785" author="rahulpilani" created="Sun, 27 Nov 2011 15:56:51 -0600" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10000" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Patch</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10001">Code</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[CLJ-1016] Global scope overrides lexical scope for classes (Clojure assumes no classes in default package / Clojure cannot handle yFiles JARs in classpath)</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1016</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;The most visible symptom of this bug is having a class named &apos;w&apos; (default package) in your classpath (such classes are produced by Java obfuscation tools such as yFiles) and then attempting to load Clojure&apos;s core class. For example:&lt;/p&gt;

&lt;p&gt;  java -cp hotspotapi.jar:clojure-1.4.0-slim.jar clojure.main&lt;/p&gt;

&lt;p&gt;(where hotspotapi.jar is a stereotypical example of an obfuscated JAR) results in:&lt;/p&gt;

&lt;p&gt;Exception in thread &quot;main&quot; java.lang.ExceptionInInitializerError&lt;br/&gt;
	at clojure.main.&amp;lt;clinit&amp;gt;(main.java:20)&lt;br/&gt;
Caused by: java.lang.NoSuchFieldException: close, compiling:(clojure/core.clj:6139)&lt;br/&gt;
	at clojure.lang.Compiler.analyzeSeq(Compiler.java:6462)&lt;br/&gt;
	at clojure.lang.Compiler.analyze(Compiler.java:6262)&lt;br/&gt;
	at clojure.lang.Compiler.analyze(Compiler.java:6223)&lt;br/&gt;
	at clojure.lang.Compiler$BodyExpr$Parser.parse(Compiler.java:5618)&lt;br/&gt;
	at clojure.lang.Compiler$TryExpr$Parser.parse(Compiler.java:2178)&lt;br/&gt;
	at clojure.lang.Compiler.analyzeSeq(Compiler.java:6455)&lt;br/&gt;
	at clojure.lang.Compiler.analyze(Compiler.java:6262)&lt;br/&gt;
	at clojure.lang.Compiler.analyze(Compiler.java:6223)&lt;br/&gt;
	at clojure.lang.Compiler$BodyExpr$Parser.parse(Compiler.java:5618)&lt;br/&gt;
	at clojure.lang.Compiler$LetExpr$Parser.parse(Compiler.java:5919)&lt;br/&gt;
	at clojure.lang.Compiler.analyzeSeq(Compiler.java:6455)&lt;br/&gt;
	at clojure.lang.Compiler.analyze(Compiler.java:6262)&lt;br/&gt;
	at clojure.lang.Compiler.analyzeSeq(Compiler.java:6443)&lt;br/&gt;
	at clojure.lang.Compiler.analyze(Compiler.java:6262)&lt;br/&gt;
	at clojure.lang.Compiler.analyzeSeq(Compiler.java:6443)&lt;br/&gt;
	at clojure.lang.Compiler.analyze(Compiler.java:6262)&lt;br/&gt;
	at clojure.lang.Compiler.analyze(Compiler.java:6223)&lt;br/&gt;
	at clojure.lang.Compiler$BodyExpr$Parser.parse(Compiler.java:5618)&lt;br/&gt;
	at clojure.lang.Compiler$FnMethod.parse(Compiler.java:5054)&lt;br/&gt;
	at clojure.lang.Compiler$FnExpr.parse(Compiler.java:3674)&lt;br/&gt;
	at clojure.lang.Compiler.analyzeSeq(Compiler.java:6453)&lt;br/&gt;
	at clojure.lang.Compiler.analyze(Compiler.java:6262)&lt;br/&gt;
	at clojure.lang.Compiler.analyzeSeq(Compiler.java:6443)&lt;br/&gt;
	at clojure.lang.Compiler.analyze(Compiler.java:6262)&lt;br/&gt;
	at clojure.lang.Compiler.access$100(Compiler.java:37)&lt;br/&gt;
	at clojure.lang.Compiler$DefExpr$Parser.parse(Compiler.java:518)&lt;br/&gt;
	at clojure.lang.Compiler.analyzeSeq(Compiler.java:6455)&lt;br/&gt;
	at clojure.lang.Compiler.analyze(Compiler.java:6262)&lt;br/&gt;
	at clojure.lang.Compiler.analyze(Compiler.java:6223)&lt;br/&gt;
	at clojure.lang.Compiler.eval(Compiler.java:6515)&lt;br/&gt;
	at clojure.lang.Compiler.load(Compiler.java:6952)&lt;br/&gt;
	at clojure.lang.RT.loadResourceScript(RT.java:359)&lt;br/&gt;
	at clojure.lang.RT.loadResourceScript(RT.java:350)&lt;br/&gt;
	at clojure.lang.RT.load(RT.java:429)&lt;br/&gt;
	at clojure.lang.RT.load(RT.java:400)&lt;br/&gt;
	at clojure.lang.RT.doInit(RT.java:436)&lt;br/&gt;
	at clojure.lang.RT.&amp;lt;clinit&amp;gt;(RT.java:318)&lt;br/&gt;
	... 1 more&lt;br/&gt;
Caused by: java.lang.NoSuchFieldException: close&lt;br/&gt;
	at java.lang.Class.getField(Class.java:1537)&lt;br/&gt;
	at clojure.lang.Compiler$StaticFieldExpr.&amp;lt;init&amp;gt;(Compiler.java:1180)&lt;br/&gt;
	at clojure.lang.Compiler$HostExpr$Parser.parse(Compiler.java:923)&lt;br/&gt;
	at clojure.lang.Compiler.analyzeSeq(Compiler.java:6455)&lt;br/&gt;
	... 37 more&lt;br/&gt;
Could not find the main class: clojure.main. Program will exit.&lt;/p&gt;

&lt;p&gt;To understand what is going on, consider this simple test:&lt;/p&gt;

&lt;p&gt;import java.io.StringReader;&lt;/p&gt;

&lt;p&gt;import clojure.lang.Compiler;&lt;br/&gt;
import clojure.lang.RT;&lt;/p&gt;

&lt;p&gt;public class Test {&lt;br/&gt;
    public static void main(String[] args) {
        RT.var(&quot;clojure.core&quot;, &quot;require&quot;);
        String s = &quot;(let [mumble (new java.io.StringReader \&quot;\&quot;)] (. mumble close))&quot;;
        Compiler.load(new StringReader(s));
    }&lt;br/&gt;
}&lt;/p&gt;

&lt;p&gt;It should be clear that &apos;mumble&apos; in the dot operator is referencing the locally defined mumble. However, if we define a class named &apos;mumble&apos; in the default package, Clojure picks that one up instead.&lt;/p&gt;

&lt;p&gt;To forestall any objections: yes, we know that placing classes in the default package is extremely poor form. Point of the matter is, the Java ecosystem is extremely diverse and there are a lot of JARs people may not have control over. While one might argue, &quot;Don&apos;t put classes in the default namespace&quot;, point of the matter is, Clojure is wrong here, and these situations arise in practice, through no fault of the implementer.&lt;/p&gt;</description>
                <environment></environment>
            <key id="15547">CLJ-1016</key>
            <summary>Global scope overrides lexical scope for classes (Clojure assumes no classes in default package / Clojure cannot handle yFiles JARs in classpath)</summary>
                <type id="1" iconUrl="http://dev.clojure.org/jira/images/icons/bug.gif">Defect</type>
                                <priority id="3" iconUrl="http://dev.clojure.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="ezyang">Edward Z. Yang</reporter>
                        <labels>
                    </labels>
                <created>Thu, 21 Jun 2012 10:31:20 -0500</created>
                <updated>Mon, 27 Aug 2012 21:24:13 -0500</updated>
                                    <version>Release 1.5</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                        <comments>
                    <comment id="28886" author="ezyang" created="Thu, 21 Jun 2012 11:01:06 -0500"  >&lt;p&gt;Here is a workaround patch which makes this error less likely to occur.&lt;/p&gt;</comment>
                    <comment id="29274" author="jafingerhut" created="Mon, 27 Aug 2012 19:37:34 -0500"  >&lt;p&gt;Edward, it is Rich Hickey&apos;s policy only to consider for inclusion in Clojure patches written by people who have signed a Contributor Agreement: &lt;a href=&quot;http://clojure.org/contributing&quot;&gt;http://clojure.org/contributing&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;Were you interested in becoming a contributor?&lt;/p&gt;</comment>
                    <comment id="29276" author="ezyang" created="Mon, 27 Aug 2012 21:24:13 -0500"  >&lt;p&gt;Sure, although the patch attached is emphatically not the one you want to actually applying, since it only band-aids the problem.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="11340" name="collision-workaround.patch" size="1128" author="ezyang" created="Thu, 21 Jun 2012 11:01:06 -0500" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                                                                                            </customfields>
    </item>

<item>
            <title>[CLJ-959] after call to clojure.java.shell/sh, jvm won&apos;t exit</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-959</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;Create the following four-line file, shell_example.clj:&lt;/p&gt;

&lt;p&gt;;; simple example of call to sh that causes jvm to hang after print&lt;br/&gt;
(require &apos;&lt;span class=&quot;error&quot;&gt;&amp;#91;clojure.java.shell :as shell&amp;#93;&lt;/span&gt;)&lt;br/&gt;
(shell/sh &quot;ls&quot;)&lt;br/&gt;
(println &quot;jvm should exit after this, but it doesn&apos;t&quot;)&lt;/p&gt;

&lt;p&gt;Run:&lt;br/&gt;
java -jar clojure-1.3.0.jar shell_example.clj&lt;/p&gt;

&lt;p&gt;After the message is printed, the jvm doesn&apos;t quit. It just sits there. I have to hit Ctrl-C to force the jvm to quit.&lt;/p&gt;

&lt;p&gt;This happens on 1.3 and the most recent code in github as of 3/26/2012. I imagine the jvm is waiting for a thread that hasn&apos;t terminated, but the code in the sh function doesn&apos;t look like it&apos;s doing anything obviously wrong. I&apos;m too much of a newcomer to Clojure to dig any deeper.&lt;/p&gt;

&lt;p&gt;My workaround right now is to do (System/exit 0) to force the jvm to quit.&lt;/p&gt;

&lt;p&gt;Thank you for your work on Clojure, it&apos;s simply an amazing language.&lt;/p&gt;</description>
                <environment>Reproduced on Ubuntu using Sun Java 1.6, OpenJDK 1.6, and Sun Java 1.7&lt;br/&gt;
</environment>
            <key id="15295">CLJ-959</key>
            <summary>after call to clojure.java.shell/sh, jvm won&apos;t exit</summary>
                <type id="1" iconUrl="http://dev.clojure.org/jira/images/icons/bug.gif">Defect</type>
                                <priority id="3" iconUrl="http://dev.clojure.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="codeforkjeff">Jeff Chiu</reporter>
                        <labels>
                        <label>shell</label>
                    </labels>
                <created>Mon, 26 Mar 2012 21:55:26 -0500</created>
                <updated>Fri, 8 Jun 2012 12:47:07 -0500</updated>
                                    <version>Release 1.3</version>
                <version>Release 1.4</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>1</watches>
                        <comments>
                    <comment id="28023" author="jafingerhut" created="Tue, 27 Mar 2012 00:19:03 -0500"  >&lt;p&gt;Jeff, this occurs in any Clojure program where certain threading mechanisms are invoked.  In your case, clojure.java.shell/sh uses future, which causes threads to be created that then sit around for about 60 seconds after everything else quits, and the main Java process does not exit until that happens.  Another way to get the program to exit quickly is to call (shutdown-agents), but that isn&apos;t any more convenient than (System/exit 0), nor is there any obvious way you can tell as a newcomer that you should be doing this.&lt;/p&gt;

&lt;p&gt;The ticket &lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-124&quot; title=&quot;GC  Issue 120: Determine mechanism for controlling automatic shutdown of Agents, with a default policy and mechanism for changing that policy as needed&quot;&gt;CLJ-124&lt;/a&gt; is marked with status &quot;Approved&quot; at this time, which leads me to believe that perhaps soon there will be a change made to Clojure such that this situation will change.&lt;/p&gt;</comment>
                    <comment id="28750" author="jafingerhut" created="Fri, 8 Jun 2012 12:47:07 -0500"  >&lt;p&gt;This behavior is now documented on clojuredocs.org for future, and both pmap and clojure.java.shell/sh refer to future for details.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                                                                                            </customfields>
    </item>

<item>
            <title>[CLJ-1013] Clojure&apos;s classloader cannot handle out-of-order loading</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1013</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;Here is a minimal test-case:&lt;/p&gt;

&lt;p&gt;import java.io.IOException;&lt;/p&gt;

&lt;p&gt;    import clojure.lang.PersistentTreeMap;&lt;br/&gt;
    import clojure.lang.RT;&lt;/p&gt;


&lt;p&gt;    public class TestClass {&lt;/p&gt;

&lt;p&gt;            static Class y = RT.class;&lt;br/&gt;
            //static PersistentTreeMap x = PersistentTreeMap.EMPTY;&lt;/p&gt;

&lt;p&gt;            /**&lt;/p&gt;
&lt;ul&gt;
	&lt;li&gt;@param args&lt;/li&gt;
	&lt;li&gt;@throws ClassNotFoundException&lt;/li&gt;
	&lt;li&gt;@throws IOException&lt;br/&gt;
             */&lt;br/&gt;
            public static void main(String[] args) throws IOException, ClassNotFoundException {
                    PersistentTreeMap x = PersistentTreeMap.EMPTY;
     
            }&lt;/li&gt;
&lt;/ul&gt;


&lt;p&gt;    }&lt;/p&gt;

&lt;p&gt;This results in the exception:&lt;/p&gt;

&lt;p&gt;Exception in thread &quot;main&quot; java.lang.ExceptionInInitializerError&lt;br/&gt;
            at java.lang.Class.forName0(Native Method)&lt;br/&gt;
            at java.lang.Class.forName(Class.java:247)&lt;br/&gt;
            at clojure.lang.RT.loadClassForName(RT.java:2056)&lt;br/&gt;
            at clojure.lang.RT.load(RT.java:419)&lt;br/&gt;
            at clojure.lang.RT.load(RT.java:400)&lt;br/&gt;
            at clojure.lang.RT.doInit(RT.java:436)&lt;br/&gt;
            at clojure.lang.RT.&amp;lt;clinit&amp;gt;(RT.java:318)&lt;br/&gt;
            at clojure.lang.PersistentTreeMap.&amp;lt;init&amp;gt;(PersistentTreeMap.java:45)&lt;br/&gt;
            at clojure.lang.PersistentTreeMap.&amp;lt;clinit&amp;gt;(PersistentTreeMap.java:32)&lt;br/&gt;
            at TestClass.main(TestClass.java:19)&lt;br/&gt;
    Caused by: java.lang.NullPointerException&lt;br/&gt;
            at clojure.lang.APersistentSet.contains(APersistentSet.java:33)&lt;br/&gt;
            at clojure.lang.RT.contains(RT.java:700)&lt;br/&gt;
            at clojure.core$contains_QMARK_.invoke(core.clj:1386)&lt;br/&gt;
            at clojure.core$load_lib.doInvoke(core.clj:5255)&lt;br/&gt;
            at clojure.lang.RestFn.applyTo(RestFn.java:142)&lt;br/&gt;
            at clojure.core$apply.invoke(core.clj:603)&lt;br/&gt;
            at clojure.core$load_libs.doInvoke(core.clj:5298)&lt;br/&gt;
            at clojure.lang.RestFn.applyTo(RestFn.java:137)&lt;br/&gt;
            at clojure.core$apply.invoke(core.clj:603)&lt;br/&gt;
            at clojure.core$require.doInvoke(core.clj:5381)&lt;br/&gt;
            at clojure.lang.RestFn.invoke(RestFn.java:408)&lt;br/&gt;
            at clojure.core__init.load(Unknown Source)&lt;br/&gt;
            at clojure.core__init.&amp;lt;clinit&amp;gt;(Unknown Source)&lt;br/&gt;
            ... 10 more&lt;/p&gt;

&lt;p&gt;The crux of the issue appears Clojure&apos;s classloader doesn&apos;t understand how to handle out-of-order classloading.&lt;/p&gt;</description>
                <environment></environment>
            <key id="15532">CLJ-1013</key>
            <summary>Clojure&apos;s classloader cannot handle out-of-order loading</summary>
                <type id="1" iconUrl="http://dev.clojure.org/jira/images/icons/bug.gif">Defect</type>
                                <priority id="3" iconUrl="http://dev.clojure.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="ezyang">Edward Z. Yang</reporter>
                        <labels>
                    </labels>
                <created>Wed, 13 Jun 2012 15:21:42 -0500</created>
                <updated>Wed, 13 Jun 2012 15:21:42 -0500</updated>
                                                                            <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                                                                                            </customfields>
    </item>

<item>
            <title>[CLJ-968] ns emitting gen-class before imports results in imported annotations being discarded.</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-968</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;The following discards the imported annotations:&lt;/p&gt;

&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;(ns com.example.BaseXModuleTest
  (:&lt;span class=&quot;code-keyword&quot;&gt;import&lt;/span&gt; (org.basex.query QueryModule QueryModule$Deterministic))
  (:gen-class
     :&lt;span class=&quot;code-keyword&quot;&gt;extends&lt;/span&gt; org.basex.query.QueryModule
     :methods [
       [^{QueryModule$Deterministic {}}
        addOne [&lt;span class=&quot;code-object&quot;&gt;int&lt;/span&gt;] &lt;span class=&quot;code-object&quot;&gt;int&lt;/span&gt;]]))&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;However, when moving the &lt;tt&gt;gen-class&lt;/tt&gt; call out of the &lt;tt&gt;ns&lt;/tt&gt; declaration, the annotation is correctly applied:&lt;/p&gt;

&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;(ns com.example.BaseXModuleTest
  (:&lt;span class=&quot;code-keyword&quot;&gt;import&lt;/span&gt; (org.basex.query QueryModule QueryModule$Deterministic)))

(gen-class
  :&lt;span class=&quot;code-keyword&quot;&gt;extends&lt;/span&gt; org.basex.query.QueryModule
  :name com.example.BaseXModuleTest
  :methods [
    [^{QueryModule$Deterministic {}}
     addOne [&lt;span class=&quot;code-object&quot;&gt;int&lt;/span&gt;] &lt;span class=&quot;code-object&quot;&gt;int&lt;/span&gt;]])&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;It appears that imported names are not yet in-scope when gen-class is run from a &lt;tt&gt;ns&lt;/tt&gt; declaration.&lt;/p&gt;</description>
                <environment></environment>
            <key id="15321">CLJ-968</key>
            <summary>ns emitting gen-class before imports results in imported annotations being discarded.</summary>
                <type id="1" iconUrl="http://dev.clojure.org/jira/images/icons/bug.gif">Defect</type>
                                <priority id="3" iconUrl="http://dev.clojure.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="charles-dyfis-net">Charles Duffy</reporter>
                        <labels>
                    </labels>
                <created>Mon, 9 Apr 2012 15:38:07 -0500</created>
                <updated>Mon, 9 Apr 2012 15:38:07 -0500</updated>
                                    <version>Release 1.3</version>
                <version>Release 1.4</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                                                                                            </customfields>
    </item>

<item>
            <title>[CLJ-969] Symbol/keyword implements IFn for lookup but a non-collection argument produces non-intuitive results</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-969</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;(&apos;+ 1 2) ;; return 2 because it is treated as (get 1 &apos;+ 2)&lt;/p&gt;

&lt;p&gt;Whilst this is &quot;consistent&quot; once you know the lookup behavior, it&apos;s confusing for Clojure newbies and it seems to be a non-useful behavior.&lt;/p&gt;

&lt;p&gt;Proposal: modify Keyword.invoke() and Symbol.invoke() to restrict first Object argument to instanceof ILookup, Map or IPersistentSet (or null) so that the &quot;not found&quot; behavior doesn&apos;t produce non-intuitive behavior.&lt;/p&gt;</description>
                <environment></environment>
            <key id="15323">CLJ-969</key>
            <summary>Symbol/keyword implements IFn for lookup but a non-collection argument produces non-intuitive results</summary>
                <type id="4" iconUrl="http://dev.clojure.org/jira/images/icons/improvement.gif">Enhancement</type>
                                <priority id="3" iconUrl="http://dev.clojure.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="seancorfield">Sean Corfield</reporter>
                        <labels>
                    </labels>
                <created>Mon, 9 Apr 2012 17:29:03 -0500</created>
                <updated>Mon, 9 Apr 2012 17:29:03 -0500</updated>
                                                                            <due></due>
                    <votes>0</votes>
                        <watches>1</watches>
                                <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                                                                                            </customfields>
    </item>

<item>
            <title>[CLJ-971] Jar within a jar throws a runtime error</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-971</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;I&apos;ve created two jar files in my multi-project Maven setup.  The first jar is the &quot;engine&quot;, and it includes the clojure jar in it.  The other jar is the &quot;application&quot;.  It includes the engine and then packages itself into a one-jar jar file.  This means we have a jar within a jar: The &quot;onejar&quot; contains the engine jar, which in turn contains that clojure jar.&lt;/p&gt;

&lt;p&gt;I then get an error in the runtime:&lt;/p&gt;

&lt;p&gt;Exception in thread &quot;main&quot; java.lang.reflect.InvocationTargetException&lt;br/&gt;
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)&lt;br/&gt;
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)&lt;br/&gt;
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)&lt;br/&gt;
    at java.lang.reflect.Method.invoke(Method.java:616)&lt;br/&gt;
    at com.simontuffs.onejar.Boot.run(Boot.java:340)&lt;br/&gt;
    at com.simontuffs.onejar.Boot.main(Boot.java:166)&lt;br/&gt;
Caused by: java.lang.ExceptionInInitializerError&lt;br/&gt;
    at com.ziroby.clojure.App.main(App.java:14)&lt;br/&gt;
    ... 6 more&lt;br/&gt;
Caused by: java.lang.NullPointerException&lt;br/&gt;
    at clojure.lang.RT.lastModified(RT.java:374)&lt;br/&gt;
    at clojure.lang.RT.load(RT.java:408)&lt;br/&gt;
    at clojure.lang.RT.load(RT.java:398)&lt;br/&gt;
    at clojure.lang.RT.doInit(RT.java:434)&lt;br/&gt;
    at clojure.lang.RT.&amp;lt;clinit&amp;gt;(RT.java:316)&lt;br/&gt;
... 7 more&lt;/p&gt;

&lt;p&gt;See also my Stack Overflow question on this at &lt;a href=&quot;http://stackoverflow.com/questions/7763480/making-an-executable-jar-that-evals-clojure-strings&quot;&gt;http://stackoverflow.com/questions/7763480/making-an-executable-jar-that-evals-clojure-strings&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;In researching it, I&apos;ve found the problem lies in RT.lastModified, where it tries to determine last modified time by looking at the modified time on the jar file for Clojure.  But there&apos;s not actually a jar file, since it&apos;s embedded in another.&lt;/p&gt;

&lt;p&gt;I&apos;ve found that adding a null check solves the problem.  My lastModified looks like this now:&lt;/p&gt;

&lt;p&gt;static public long lastModified(URL url, String libfile) throws Exception{&lt;br/&gt;
	if(url.getProtocol().equals(&quot;jar&quot;)) {
		ZipEntry entry = ((JarURLConnection) url.openConnection()).getJarFile().getEntry(libfile);
		if (entry != null)
			return entry.getTime();
	}&lt;/p&gt;

&lt;p&gt;	return url.openConnection().getLastModified();&lt;br/&gt;
}&lt;/p&gt;

&lt;p&gt;This runs successfully.&lt;/p&gt;

&lt;p&gt;If you&apos;d prefer, I can submit a patch, or commit directly.    &lt;/p&gt;
</description>
                <environment>Maven using the one-jar plugin</environment>
            <key id="15326">CLJ-971</key>
            <summary>Jar within a jar throws a runtime error</summary>
                <type id="1" iconUrl="http://dev.clojure.org/jira/images/icons/bug.gif">Defect</type>
                                <priority id="3" iconUrl="http://dev.clojure.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="ziroby">Ron Romero</reporter>
                        <labels>
                        <label>bug</label>
                    </labels>
                <created>Tue, 10 Apr 2012 22:39:36 -0500</created>
                <updated>Tue, 10 Apr 2012 22:39:36 -0500</updated>
                                    <version>Release 1.2</version>
                <version>Release 1.3</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                                                                                            </customfields>
    </item>

<item>
            <title>[CLJ-903] extend-protocol does not allow classnames as a String</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-903</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;In various places Clojure accepts classnames as &lt;tt&gt;String&lt;/tt&gt;, eg. in &lt;tt&gt;gen-class&lt;/tt&gt; or type hints. However it does not in &lt;tt&gt;extend-protocol&lt;/tt&gt;. This does not allow simple specification of array types.&lt;/p&gt;

&lt;p&gt;See also here: &lt;a href=&quot;http://groups.google.com/group/clojure/browse_thread/thread/722a0c09d02bb0ac&quot;&gt;http://groups.google.com/group/clojure/browse_thread/thread/722a0c09d02bb0ac&lt;/a&gt;&lt;/p&gt;</description>
                <environment></environment>
            <key id="15090">CLJ-903</key>
            <summary>extend-protocol does not allow classnames as a String</summary>
                <type id="4" iconUrl="http://dev.clojure.org/jira/images/icons/improvement.gif">Enhancement</type>
                                <priority id="3" iconUrl="http://dev.clojure.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="mbrandmeyer">Meikel Brandmeyer</reporter>
                        <labels>
                    </labels>
                <created>Fri, 30 Dec 2011 17:17:12 -0600</created>
                <updated>Fri, 30 Dec 2011 17:17:12 -0600</updated>
                                    <version>Release 1.2</version>
                <version>Release 1.3</version>
                <version>Release 1.4</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                                                                                            </customfields>
    </item>

<item>
            <title>[CLJ-1022] gen-class destroys method annotations</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1022</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;When extending a class gen-class doesn&apos;t preserve method annotations.&lt;/p&gt;

&lt;p&gt;If class com.bar.Foo has annotated methods  then in MyClass all annotations are gone.&lt;/p&gt;


&lt;p&gt;(gen-class&lt;br/&gt;
   :name com.my.MyClass&lt;br/&gt;
   :extends com.bar.Foo&lt;br/&gt;
   :implements &lt;span class=&quot;error&quot;&gt;&amp;#91;com.google.common.base.Supplier&amp;#93;&lt;/span&gt;&lt;br/&gt;
   :prefix demo-&lt;br/&gt;
   :post-init post-init)&lt;/p&gt;

&lt;p&gt;(defn demo-post-init &lt;span class=&quot;error&quot;&gt;&amp;#91;this&amp;#93;&lt;/span&gt;&lt;br/&gt;
  (info &quot;initialized&quot;)&lt;br/&gt;
  (swank.swank/start-server :port 68478))&lt;/p&gt;

&lt;p&gt;(defn demo-get &lt;span class=&quot;error&quot;&gt;&amp;#91;_&amp;#93;&lt;/span&gt;&lt;br/&gt;
  (get-msg))&lt;/p&gt;



&lt;p&gt;            Class&amp;lt;?&amp;gt; aClass = Class.forName(&quot;com.my.MyClass&quot;);&lt;br/&gt;
            Method[] methods = aClass.getMethods();&lt;/p&gt;

&lt;p&gt;            for (Method m : methods) {&lt;br/&gt;
                Annotation[] annotations = m.getAnnotations();&lt;br/&gt;
                System.out.println(m.getName()+&quot; &quot;+annotations.length);&lt;br/&gt;
                for (Annotation a : annotations) {
                    System.out.println(a.annotationType().getClass().getName());
                }&lt;br/&gt;
            }&lt;/p&gt;</description>
                <environment></environment>
            <key id="15566">CLJ-1022</key>
            <summary>gen-class destroys method annotations</summary>
                <type id="1" iconUrl="http://dev.clojure.org/jira/images/icons/bug.gif">Defect</type>
                                <priority id="3" iconUrl="http://dev.clojure.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="maris">Maris Orbidans</reporter>
                        <labels>
                        <label>bug</label>
                    </labels>
                <created>Tue, 3 Jul 2012 06:19:26 -0500</created>
                <updated>Tue, 3 Jul 2012 06:19:26 -0500</updated>
                                    <version>Release 1.4</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>1</watches>
                                <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                                                                                            </customfields>
    </item>

<item>
            <title>[CLJ-911] &apos;proxy&apos; prevents overriding Object.finalize (and doesn&apos;t document it)</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-911</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;It appears to be impossible to override Object.finalize() using proxy.  If the method is defined using proxy, then it cannot be called straightforwardly (see below), and it is not called as a finalizer during normal program execution (not demonstrated below).&lt;/p&gt;

&lt;p&gt;See extensive discussion at: &lt;a href=&quot;https://groups.google.com/group/clojure/browse_thread/thread/a1e2fca45af6c1af&quot;&gt;https://groups.google.com/group/clojure/browse_thread/thread/a1e2fca45af6c1af&lt;/a&gt;&lt;/p&gt;

&lt;blockquote&gt;
&lt;p&gt;user=&amp;gt; (def m (proxy &lt;span class=&quot;error&quot;&gt;&amp;#91;java.util.HashMap&amp;#93;&lt;/span&gt; []&lt;br/&gt;
        (finalize []&lt;br/&gt;
          ;(proxy-super finalize)&lt;br/&gt;
          (prn &quot;finalizing...&quot;))&lt;br/&gt;
        (hashCode []&lt;br/&gt;
          99)))&lt;br/&gt;
#&apos;user/m&lt;br/&gt;
user=&amp;gt; (.hashCode m)&lt;br/&gt;
99&lt;br/&gt;
user=&amp;gt; (.finalize m)&lt;br/&gt;
IllegalArgumentException No matching field found: finalize for class user.proxy$java.util.HashMap$0 clojure.lang.Reflector.getInstanceField (Reflector.java:289)&lt;/p&gt;&lt;/blockquote&gt;

&lt;p&gt;There is at least one of two bugs here (thanks to Cedric Greevey for summarising this way):&lt;/p&gt;

&lt;ul&gt;
	&lt;li&gt;If the inability to override finalize() is unintentional, that&apos;s a bug.&lt;/li&gt;
	&lt;li&gt;If it&apos;s intentional for some reason, then (a) that&apos;s not documented, and (b) the failure is silent, in the sense that an explicit call produces an apparently completely unrelated error (above), and the failure to call the method during object finalization is completely silent.&lt;/li&gt;
&lt;/ul&gt;
</description>
                <environment>OS X, Java 1.6.0?</environment>
            <key id="15118">CLJ-911</key>
            <summary>&apos;proxy&apos; prevents overriding Object.finalize (and doesn&apos;t document it)</summary>
                <type id="1" iconUrl="http://dev.clojure.org/jira/images/icons/bug.gif">Defect</type>
                                <priority id="3" iconUrl="http://dev.clojure.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="nxg">Norman Gray</reporter>
                        <labels>
                    </labels>
                <created>Mon, 16 Jan 2012 08:36:27 -0600</created>
                <updated>Mon, 16 Jan 2012 08:36:27 -0600</updated>
                                    <version>Release 1.3</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                                                                                            </customfields>
    </item>

<item>
            <title>[CLJ-1037] Allow doc strings for both interfaces and concrete implementations</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1037</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;In this post&lt;br/&gt;
&lt;a href=&quot;http://groups.google.com/group/clojure/browse_thread/thread/84de74740928da76#&quot;&gt;http://groups.google.com/group/clojure/browse_thread/thread/84de74740928da76#&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;I mentioned the rationale (I think) why this is important and needed. Thank you for consideration.&lt;/p&gt;</description>
                <environment></environment>
            <key id="15613">CLJ-1037</key>
            <summary>Allow doc strings for both interfaces and concrete implementations</summary>
                <type id="4" iconUrl="http://dev.clojure.org/jira/images/icons/improvement.gif">Enhancement</type>
                                <priority id="3" iconUrl="http://dev.clojure.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="wrn.lynn">Warren Lynn</reporter>
                        <labels>
                    </labels>
                <created>Sat, 4 Aug 2012 10:30:53 -0500</created>
                <updated>Sat, 4 Aug 2012 10:30:53 -0500</updated>
                                    <version>Release 1.4</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                                                                                            </customfields>
    </item>

<item>
            <title>[CLJ-986] Adds an exit function to exit clojure process</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-986</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;There is no standard function to exit the clojure process.&lt;br/&gt;
In java implementation,we use (System/exit 0),but in other implementations(CLR), i have to use another function.&lt;/p&gt;

&lt;p&gt;Why not add a standard function in clojure.core?&lt;br/&gt;
For example:&lt;/p&gt;

&lt;p&gt;(defn exit&lt;br/&gt;
   ([] (exit 0)&lt;br/&gt;
   (&lt;span class=&quot;error&quot;&gt;&amp;#91;status&amp;#93;&lt;/span&gt; (System/exit status)))&lt;/p&gt;

&lt;p&gt;I think it&apos;s useful for us.&lt;/p&gt;</description>
                <environment></environment>
            <key id="15414">CLJ-986</key>
            <summary>Adds an exit function to exit clojure process</summary>
                <type id="4" iconUrl="http://dev.clojure.org/jira/images/icons/improvement.gif">Enhancement</type>
                                <priority id="3" iconUrl="http://dev.clojure.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="killme2008">dennis zhuang</reporter>
                        <labels>
                        <label>exit</label>
                        <label>function</label>
                        <label>quit</label>
                    </labels>
                <created>Sun, 6 May 2012 21:25:57 -0500</created>
                <updated>Sun, 6 May 2012 21:25:57 -0500</updated>
                                                                            <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                                                                                            </customfields>
    </item>

<item>
            <title>[CLJ-919] cannot create anonymous primitive functions</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-919</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;Primitive functions only work (e.g. return primitive types) when defined with `defn`.  An equivalent function created with `fn` does not behave the same way as when created with `defn`.  For example:&lt;/p&gt;

&lt;p&gt;(definterface IPrimitiveTester&lt;br/&gt;
   (getType &lt;span class=&quot;error&quot;&gt;&amp;#91;^int x&amp;#93;&lt;/span&gt;)&lt;br/&gt;
   (getType &lt;span class=&quot;error&quot;&gt;&amp;#91;^long x&amp;#93;&lt;/span&gt;)&lt;br/&gt;
   (getType &lt;span class=&quot;error&quot;&gt;&amp;#91;^float x&amp;#93;&lt;/span&gt;)&lt;br/&gt;
   (getType &lt;span class=&quot;error&quot;&gt;&amp;#91;^double x&amp;#93;&lt;/span&gt;)&lt;br/&gt;
   (getType &lt;span class=&quot;error&quot;&gt;&amp;#91;^Object x&amp;#93;&lt;/span&gt;))&lt;/p&gt;

&lt;p&gt;(deftype PrimitiveTester []&lt;br/&gt;
   IPrimitiveTester&lt;br/&gt;
   (getType &lt;span class=&quot;error&quot;&gt;&amp;#91;this ^int x&amp;#93;&lt;/span&gt; :int)&lt;br/&gt;
   (getType &lt;span class=&quot;error&quot;&gt;&amp;#91;this ^long x&amp;#93;&lt;/span&gt; :long)&lt;br/&gt;
   (getType &lt;span class=&quot;error&quot;&gt;&amp;#91;this ^float x&amp;#93;&lt;/span&gt; :float)&lt;br/&gt;
   (getType &lt;span class=&quot;error&quot;&gt;&amp;#91;this ^double x&amp;#93;&lt;/span&gt; :double)&lt;br/&gt;
   (getType &lt;span class=&quot;error&quot;&gt;&amp;#91;this ^Object x&amp;#93;&lt;/span&gt; :object))&lt;/p&gt;

&lt;p&gt;(defmacro pt &lt;span class=&quot;error&quot;&gt;&amp;#91;x&amp;#93;&lt;/span&gt;&lt;br/&gt;
   `(.getType (PrimitiveTester.) ~x))&lt;/p&gt;

&lt;p&gt;(defn with-defn ^double &lt;span class=&quot;error&quot;&gt;&amp;#91;^double x&amp;#93;&lt;/span&gt;&lt;br/&gt;
   (+ x 0.5))&lt;/p&gt;

&lt;p&gt;(pt (with-defn 1.0)) ; =&amp;gt; :double&lt;/p&gt;

&lt;p&gt;(let [a (fn ^double &lt;span class=&quot;error&quot;&gt;&amp;#91;^double x&amp;#93;&lt;/span&gt; (+ x 0.5))] &lt;br/&gt;
  (pt (a 0.1))) ; =&amp;gt; :object &lt;/p&gt;


&lt;p&gt;Please see the discussion on the mailing list for more details and thoughts on what is happening:&lt;br/&gt;
&lt;a href=&quot;http://groups.google.com/group/clojure/browse_thread/thread/d83c8643a7c7d595?hl=en&quot;&gt;http://groups.google.com/group/clojure/browse_thread/thread/d83c8643a7c7d595?hl=en&lt;/a&gt;&lt;/p&gt;
</description>
                <environment></environment>
            <key id="15149">CLJ-919</key>
            <summary>cannot create anonymous primitive functions</summary>
                <type id="1" iconUrl="http://dev.clojure.org/jira/images/icons/bug.gif">Defect</type>
                                <priority id="3" iconUrl="http://dev.clojure.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="bmabey">Ben Mabey</reporter>
                        <labels>
                    </labels>
                <created>Fri, 27 Jan 2012 16:48:42 -0600</created>
                <updated>Fri, 27 Jan 2012 16:48:42 -0600</updated>
                                    <version>Release 1.3</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>1</watches>
                                <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                                                                                            </customfields>
    </item>

<item>
            <title>[CLJ-979] map-&gt;R returns different class when invoked from AOT ccode</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-979</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;(defrecord Dontwork &lt;span class=&quot;error&quot;&gt;&amp;#91;a&amp;#93;&lt;/span&gt;)&lt;/p&gt;

&lt;p&gt;(= (type (Dontwork. nil))&lt;br/&gt;
   (type (map-&amp;gt;Dontwork {:a 1})))&lt;/p&gt;

&lt;p&gt;Will return true if the namespace is not AOT compiled and false if it is.&lt;/p&gt;

&lt;p&gt;I have created a small example project with AOT and non-AOT namespaces to demonstrate&lt;br/&gt;
&lt;a href=&quot;https://github.com/ejackson/aotquestion&quot;&gt;https://github.com/ejackson/aotquestion&lt;/a&gt;&lt;/p&gt;

</description>
                <environment>Mac OS X 10.5, lein 1.7 and lein 2.0</environment>
            <key id="15400">CLJ-979</key>
            <summary>map-&gt;R returns different class when invoked from AOT ccode</summary>
                <type id="1" iconUrl="http://dev.clojure.org/jira/images/icons/bug.gif">Defect</type>
                                <priority id="3" iconUrl="http://dev.clojure.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="ejackson">Edmund Jackson</reporter>
                        <labels>
                    </labels>
                <created>Thu, 3 May 2012 03:01:37 -0500</created>
                <updated>Sun, 13 May 2012 22:35:35 -0500</updated>
                                    <version>Release 1.3</version>
                <version>Release 1.4</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>1</watches>
                        <comments>
                    <comment id="28483" author="scottlowe" created="Sat, 12 May 2012 21:05:37 -0500"  >&lt;p&gt;I can&apos;t reproduce this under Clojure 1.3 or 1.4, and Leiningen 1.7.1 on either Java 1.7.0-jdk7u4-b21 OpenJDK 64-Bit or Java 1.6.0_31 Java HotSpot 64-Bit. OS is Mac OS X 10.7.&lt;/p&gt;

&lt;p&gt;Edmund, how are you running this AOT code? I wrapped your code in a main function and built an uberjar from it.&lt;/p&gt;</comment>
                    <comment id="28485" author="ejackson" created="Sun, 13 May 2012 02:20:57 -0500"  >&lt;p&gt;Hi Scott,&lt;/p&gt;

&lt;p&gt;Interesting.  &lt;/p&gt;

&lt;p&gt;I have two use cases&lt;br/&gt;
1. AOT compile and call from repl.&lt;br/&gt;
My steps: git clone, lein compile, lein repl, (use &apos;aots.death), (in-ns &apos;aots.death), (= (class (Dontwork. nil)) (class (map-&amp;gt;Dontwork {:a 1}))) =&amp;gt; false&lt;/p&gt;

&lt;p&gt;2. My original use case, which I&apos;ve minimised here, is an AOT ns, producing a genclass that is called instantiated from other Java (no main).  This produces the same error. I will produce an example of this and post it too.&lt;/p&gt;</comment>
                    <comment id="28486" author="ejackson" created="Sun, 13 May 2012 04:23:46 -0500"  >&lt;p&gt;Hi Scott,&lt;/p&gt;

&lt;p&gt;Here is an example of it failing in the interop case: &lt;a href=&quot;https://github.com/ejackson/aotquestion2&quot;&gt;https://github.com/ejackson/aotquestion2&lt;/a&gt;&lt;br/&gt;
The steps I&apos;m following to compile this all up are&lt;/p&gt;

&lt;p&gt;git clone git@github.com:ejackson/aotquestion2.git&lt;br/&gt;
cd aotquestion2/cljside/&lt;br/&gt;
lein uberjar&lt;br/&gt;
lein install&lt;br/&gt;
cd ../javaside/&lt;br/&gt;
mvn package&lt;br/&gt;
java -jar ./target/aotquestion-1.0-SNAPSHOT.jar&lt;/p&gt;

&lt;p&gt;and it dies with this:&lt;/p&gt;

&lt;p&gt;Exception in thread &quot;main&quot; java.lang.ClassCastException: cljside.core.Dontwork cannot be cast to cljside.core.Dontwork&lt;br/&gt;
	at cljside.MyClass.makeDontwork(Unknown Source)&lt;br/&gt;
	at aotquestion.App.main(App.java:8)&lt;/p&gt;

&lt;p&gt;The error message is really confusing (to me, anyway), but I think its the same root problem as for the REPL case.&lt;/p&gt;

&lt;p&gt;What do you see when you run the above ?&lt;/p&gt;</comment>
                    <comment id="28487" author="scottlowe" created="Sun, 13 May 2012 08:41:21 -0500"  >&lt;p&gt;Ah, yes, looks like my initial attempt to reproduce was too simplistic. I used your second git repo, and can now confirm that it&apos;s failing for me with the same error.&lt;/p&gt;</comment>
                    <comment id="28497" author="scottlowe" created="Sun, 13 May 2012 22:35:35 -0500"  >&lt;p&gt;I looked into this a little further and the AOT generated code looks correct, in the sense that both code paths appear to be returning the same type.&lt;/p&gt;

&lt;p&gt;However, I wonder if this is really a ClassLoader issue, whereby two definitions of the same class are being loaded at different times, because that would cause the x.y.Class cannot be cast to x.y.Class exception that we&apos;re seeing here.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                                                                                            </customfields>
    </item>

<item>
            <title>[CLJ-792] Refactor method resolution code out of Compiler and into Reflector</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-792</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;Issues:&lt;/p&gt;

&lt;ol&gt;
	&lt;li&gt;Code for obtaining method/constructor instances is duplicated across the Compiler&lt;/li&gt;
	&lt;li&gt;Code for resolving a preferred overloaded method lives in the Compiler&lt;/li&gt;
&lt;/ol&gt;



&lt;p&gt;By consolidating the duplicated code, moving the reflection-related parts into Reflector, and providing a straightforward API, it should be easier to read and understand the method resolution process.  Further, improvements to (e.g., &lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-445&quot; title=&quot;Method/Constructor resolution does not factor in widening conversion of primitive args&quot;&gt;CLJ-445&lt;/a&gt;) the mechanism for reflecting on class members can largely be isolated from the Compiler.  And the few points of coordination (e.g., Compiler emitting same arg and return types as Reflector does when invoking) can be clearly identified and documented.&lt;/p&gt;</description>
                <environment></environment>
            <key id="14423">CLJ-792</key>
            <summary>Refactor method resolution code out of Compiler and into Reflector</summary>
                <type id="3" iconUrl="http://dev.clojure.org/jira/images/icons/task.gif">Task</type>
                                <priority id="3" iconUrl="http://dev.clojure.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="ataggart">Alexander Taggart</assignee>
                                <reporter username="ataggart">Alexander Taggart</reporter>
                        <labels>
                    </labels>
                <created>Wed, 11 May 2011 14:14:39 -0500</created>
                <updated>Mon, 20 Feb 2012 13:11:06 -0600</updated>
                                                                            <due></due>
                    <votes>0</votes>
                        <watches>3</watches>
                        <comments>
                    <comment id="27752" author="stuart.sierra" created="Fri, 17 Feb 2012 14:28:49 -0600"  >&lt;p&gt;Patch does not apply as of commit f5bcf64.&lt;/p&gt;</comment>
                    <comment id="27757" author="ataggart" created="Fri, 17 Feb 2012 15:14:47 -0600"  >&lt;p&gt;Yeah, year-old patches tend to do that.&lt;/p&gt;</comment>
                    <comment id="27777" author="jafingerhut" created="Mon, 20 Feb 2012 13:11:06 -0600"  >&lt;p&gt;I don&apos;t know if this is helpful or not, but this updated version of Alexander&apos;s patch applies cleanly to latest Clojure head as of Feb 20, 2012.  It compiles, but does not pass ant test.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="10931" name="clj-792-reorg-reflector-patch2.txt" size="74113" author="jafingerhut" created="Mon, 20 Feb 2012 13:11:06 -0600" />
                    <attachment id="10226" name="reorg-reflector.patch" size="73345" author="ataggart" created="Wed, 11 May 2011 14:14:40 -0500" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[CLJ-994] repeat reducer</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-994</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;i&apos;m working on clojure.core/repeat reducer. &lt;/p&gt;</description>
                <environment></environment>
            <key id="15436">CLJ-994</key>
            <summary>repeat reducer</summary>
                <type id="4" iconUrl="http://dev.clojure.org/jira/images/icons/improvement.gif">Enhancement</type>
                                <priority id="3" iconUrl="http://dev.clojure.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="jasonjckn">Jason Jackson</reporter>
                        <labels>
                    </labels>
                <created>Fri, 11 May 2012 13:46:08 -0500</created>
                <updated>Fri, 14 Sep 2012 14:37:35 -0500</updated>
                                    <version>Release 1.5</version>
                                                        <due></due>
                    <votes>1</votes>
                        <watches>1</watches>
                        <comments>
                    <comment id="28512" author="jafingerhut" created="Thu, 17 May 2012 18:18:00 -0500"  >&lt;p&gt;Jason, have you tried to build this using JDK 1.6.0?  I&apos;ve tried on Mac OS X 10.6.8 + Oracle/Apple JDK 1.6.0 and Ubuntu 11.10 + IBM JDK 1.6.0, and on both it compiles, but during the tests fails with a ClassNotFoundException for class jsr166y.ForkJoinTask.&lt;/p&gt;

&lt;p&gt;It builds and tests cleanly on Ubuntu 11.10 + Oracle JDK 1.7.0 for me.&lt;/p&gt;</comment>
                    <comment id="28513" author="jasonjckn" created="Thu, 17 May 2012 18:41:45 -0500"  >&lt;p&gt;That&apos;s an issue that applies to all of core.reducers. Alan Malloy experienced it as well. I tried fixing it, but eventually just upgraded to JDK 1.7. I don&apos;t understand why it&apos;s happening.&lt;/p&gt;

</comment>
                    <comment id="28540" author="jasonjckn" created="Sat, 19 May 2012 14:55:46 -0500"  >&lt;p&gt;This issue is isolated to mvn test afaik. &lt;/p&gt;

&lt;p&gt;When I include clojure inside a leiningen project, and add jsr166y.jar to lib directory, core.reducers works fine with java 1.6.&lt;/p&gt;</comment>
                    <comment id="28543" author="jafingerhut" created="Sun, 20 May 2012 03:00:58 -0500"  >&lt;p&gt;Jason, you say it applies to all of core.reducers in your May 17, 2012 comment.  I don&apos;t understand.  Without your patch applied, I can run &quot;./antsetup.sh ; ant&quot; in a freshly-pulled Clojure git repo on either of the JDK 1.6.0 versions mentioned in my earlier comment, and do not get any errors during the tests.  Are you saying perhaps that core.reducers currently has no tests that exercise the problem now, but your patch adds such tests that fail, even with no other changes to the code?&lt;/p&gt;</comment>
                    <comment id="28545" author="jasonjckn" created="Sun, 20 May 2012 11:55:09 -0500"  >&lt;p&gt;Yah that&apos;s right. Now that you mention it, my patch is the first unit test to call r/fold (the existing tests do non-parallel reductions). &lt;/p&gt;</comment>
                    <comment id="28759" author="jafingerhut" created="Fri, 8 Jun 2012 19:11:02 -0500"  >&lt;p&gt;With Stuart Halloway&apos;s commit to Clojure master on June 8, 2012 titled &quot;let reducers tests work under ant&quot;, patch 0001-repeat-for-clojure.core.reducers.patch dated May 11, 2012 now runs correctly even the new unit tests requiring class jsr166y.ForkJoinTask with Oracle/Apple JDK 1.6 and Linux IBM JDK 1.6.&lt;/p&gt;</comment>
                    <comment id="29130" author="jasonjckn" created="Tue, 14 Aug 2012 01:17:04 -0500"  >&lt;p&gt;I&apos;m on the contributors list. Is this patch still needed?&lt;br/&gt;
sorry for long long delay.&lt;/p&gt;</comment>
                    <comment id="29441" author="jasonjckn" created="Fri, 14 Sep 2012 14:37:35 -0500"  >&lt;p&gt;This patch should wait until &lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-993&quot;&gt;http://dev.clojure.org/jira/browse/CLJ-993&lt;/a&gt; is committed. I think there&apos;s a some shared code. &lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="11204" name="0001-repeat-for-clojure.core.reducers.patch" size="4530" author="jasonjckn" created="Fri, 11 May 2012 15:07:18 -0500" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10000" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Patch</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10002">Code and Test</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[CLJ-995] sorted-set doesn&apos;t support IEditableCollection</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-995</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;I think sorted-set (PersistentTreeSet) should implement the transient interface. It&apos;s a special-purpose set and should be usable just like every normal set.&lt;/p&gt;</description>
                <environment></environment>
            <key id="15440">CLJ-995</key>
            <summary>sorted-set doesn&apos;t support IEditableCollection</summary>
                <type id="1" iconUrl="http://dev.clojure.org/jira/images/icons/bug.gif">Defect</type>
                                <priority id="3" iconUrl="http://dev.clojure.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="the-kenny">Moritz Ulrich</reporter>
                        <labels>
                    </labels>
                <created>Sun, 13 May 2012 09:38:20 -0500</created>
                <updated>Mon, 4 Jun 2012 02:32:56 -0500</updated>
                                                                            <due></due>
                    <votes>0</votes>
                        <watches>1</watches>
                        <comments>
                    <comment id="28708" author="hircus" created="Mon, 4 Jun 2012 02:32:56 -0500"  >&lt;p&gt;Note that this would require PersistentTreeMap to implement IEditableCollection as well.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                                                                                            </customfields>
    </item>

<item>
            <title>[CLJ-1081] REPL binding not working that works with with-bindings</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1081</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;This works as expected:&lt;/p&gt;

&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;java -jar clojure-1.4.0.jar -e &lt;span class=&quot;code-quote&quot;&gt;&quot;(&lt;span class=&quot;code-keyword&quot;&gt;do&lt;/span&gt; (require &apos;clojure.repl) (.setDynamic #&apos;clojure.repl/print-doc) (with-bindings {#&apos;clojure.repl/print-doc str} (eval &apos;(clojure.repl/doc println))))&quot;&lt;/span&gt;&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;Output:&lt;/p&gt;

&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;&lt;span class=&quot;code-quote&quot;&gt;&quot;{:ns #&amp;lt;Namespace clojure.core&amp;gt;, :name println, :arglists ([&amp;amp; more]), :added \&quot;&lt;/span&gt;1.0\&lt;span class=&quot;code-quote&quot;&gt;&quot;, :&lt;span class=&quot;code-keyword&quot;&gt;static&lt;/span&gt; &lt;span class=&quot;code-keyword&quot;&gt;true&lt;/span&gt;, :doc \&quot;&lt;/span&gt;Same as print followed by (newline)\&lt;span class=&quot;code-quote&quot;&gt;&quot;, :line 3325, :file \&quot;&lt;/span&gt;clojure/core.clj\&lt;span class=&quot;code-quote&quot;&gt;&quot;}&quot;&lt;/span&gt;&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;But the same thing does not work in the REPL:&lt;/p&gt;

&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;java -jar clojure-1.4.0.jar -e &lt;span class=&quot;code-quote&quot;&gt;&quot;(&lt;span class=&quot;code-keyword&quot;&gt;do&lt;/span&gt; (require &apos;clojure.repl) (.setDynamic #&apos;clojure.repl/print-doc) (clojure.main/repl :init (fn [] {#&apos;clojure.repl/print-doc str}))))&quot;&lt;/span&gt;

Output &lt;span class=&quot;code-keyword&quot;&gt;for&lt;/span&gt; Output of {{(doc println)}}:&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;
&lt;p&gt;user=&amp;gt; (doc println)&lt;br/&gt;
-------------------------&lt;br/&gt;
clojure.core/println&lt;br/&gt;
(&lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;amp; more&amp;#93;&lt;/span&gt;)&lt;br/&gt;
  Same as print followed by (newline)&lt;br/&gt;
nil&lt;br/&gt;
user=&amp;gt;&lt;/p&gt;
&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;</description>
                <environment></environment>
            <key id="15730">CLJ-1081</key>
            <summary>REPL binding not working that works with with-bindings</summary>
                <type id="1" iconUrl="http://dev.clojure.org/jira/images/icons/bug.gif">Defect</type>
                                <priority id="3" iconUrl="http://dev.clojure.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="sdevijver">Steven Devijver</reporter>
                        <labels>
                    </labels>
                <created>Sun, 30 Sep 2012 15:21:42 -0500</created>
                <updated>Mon, 1 Oct 2012 05:51:46 -0500</updated>
                                    <version>Release 1.4</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>1</watches>
                        <comments>
                    <comment id="29583" author="sdevijver" created="Mon, 1 Oct 2012 05:51:46 -0500"  >&lt;p&gt;Found a work-around:&lt;/p&gt;

&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;java -jar clojure-1.4.0.jar -e &lt;span class=&quot;code-quote&quot;&gt;&quot;(&lt;span class=&quot;code-keyword&quot;&gt;do&lt;/span&gt; (require &apos;clojure.repl) (.setDynamic #&apos;clojure.repl/print-doc) (with-bindings {#&apos;clojure.repl/print-doc str} (clojure.main/repl)))))&quot;&lt;/span&gt;&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;I&apos;m still not sure whether the method above using :init should or should not work.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                                                                                            </customfields>
    </item>

<item>
            <title>[CLJ-1077] thread-bound? returns true (implying set! should succeed) even for non-binding thread</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1077</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;thread-bound? returns true for a non-binding thread, this result (according to the docstring) implies that set! should succeed.  However, thread-bound? does not check that any binding that might exist was created by the current thread, and calling set! fails with an exception when it is called from a non-binding thread, even though thread-bound? returns true.&lt;/p&gt;

&lt;p&gt;thread-bound? should return false if there is a binding, and that binding was not established by the current thread.&lt;/p&gt;</description>
                <environment></environment>
            <key id="15720">CLJ-1077</key>
            <summary>thread-bound? returns true (implying set! should succeed) even for non-binding thread</summary>
                <type id="1" iconUrl="http://dev.clojure.org/jira/images/icons/bug.gif">Defect</type>
                                <priority id="3" iconUrl="http://dev.clojure.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="pjstadig">Paul Stadig</reporter>
                        <labels>
                    </labels>
                <created>Wed, 26 Sep 2012 13:51:28 -0500</created>
                <updated>Mon, 1 Oct 2012 11:57:10 -0500</updated>
                                                                            <due></due>
                    <votes>1</votes>
                        <watches>0</watches>
                        <comments>
                    <comment id="29584" author="pjstadig" created="Mon, 1 Oct 2012 10:07:00 -0500"  >&lt;p&gt;I have attached a patch that changes clojure.lang.Var and clojure.core/thread-bound? to only return true if a Var is set!-able.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="11535" name="thread-bound.diff" size="1261" author="pjstadig" created="Mon, 1 Oct 2012 10:07:00 -0500" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10000" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Patch</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10001">Code</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[CLJ-790] Primitive type hints on function names should print error message</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-790</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;Functions returning primitives are hinted with metadata on the argument list, not on the function name.  Using a primitive type hint on a function name should print an error message.&lt;/p&gt;

&lt;p&gt;Currently, misplaced primitive hints are read without error.&lt;/p&gt;</description>
                <environment></environment>
            <key id="14421">CLJ-790</key>
            <summary>Primitive type hints on function names should print error message</summary>
                <type id="4" iconUrl="http://dev.clojure.org/jira/images/icons/improvement.gif">Enhancement</type>
                                <priority id="3" iconUrl="http://dev.clojure.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="alan@thinkrelevance.com">Alan Dipert</assignee>
                                <reporter username="alan@thinkrelevance.com">Alan Dipert</reporter>
                        <labels>
                    </labels>
                <created>Tue, 10 May 2011 12:11:37 -0500</created>
                <updated>Tue, 10 May 2011 12:11:37 -0500</updated>
                                                                            <due></due>
                    <votes>0</votes>
                        <watches>2</watches>
                                <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                                                                                            </customfields>
    </item>

<item>
            <title>[CLJ-992] `iterate` reducer</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-992</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;Added a reducer implementation mirroring clojure.core/iterate. &lt;/p&gt;</description>
                <environment></environment>
            <key id="15430">CLJ-992</key>
            <summary>`iterate` reducer</summary>
                <type id="4" iconUrl="http://dev.clojure.org/jira/images/icons/improvement.gif">Enhancement</type>
                                <priority id="3" iconUrl="http://dev.clojure.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="amalloy">Alan Malloy</reporter>
                        <labels>
                    </labels>
                <created>Thu, 10 May 2012 21:40:46 -0500</created>
                <updated>Fri, 12 Oct 2012 08:10:52 -0500</updated>
                                    <version>Release 1.5</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>2</watches>
                        <comments>
                    <comment id="28441" author="amalloy" created="Thu, 10 May 2012 21:50:25 -0500"  >&lt;p&gt;Should I have made this implement Seqable as well? It wasn&apos;t clear to me, because as far as I could see this was the only function in clojure.core.reducers that&apos;s generating a brand-new sequence rather than transforming an existing one.&lt;/p&gt;</comment>
                    <comment id="28442" author="amalloy" created="Thu, 10 May 2012 22:24:14 -0500"  >&lt;p&gt;Previous version neglected to include the seed value of the iteration in the reduce.&lt;/p&gt;</comment>
                    <comment id="28458" author="jasonjckn" created="Fri, 11 May 2012 11:23:05 -0500"  >&lt;p&gt;Currying iterate seems useless, albeit not harmful. &lt;/p&gt;

&lt;p&gt;While implementing repeat, I couldn&apos;t use currying. Because 1-arity is already reserved for infinite repeat (&lt;span class=&quot;error&quot;&gt;&amp;#91;n x&amp;#93;&lt;/span&gt; and &lt;span class=&quot;error&quot;&gt;&amp;#91;x&amp;#93;&lt;/span&gt;, not &lt;span class=&quot;error&quot;&gt;&amp;#91;n x&amp;#93;&lt;/span&gt; and &lt;span class=&quot;error&quot;&gt;&amp;#91;n&amp;#93;&lt;/span&gt; if currying)&lt;/p&gt;

&lt;p&gt;How about we just support currying for functions where last param is reducible?&lt;/p&gt;</comment>
                    <comment id="29226" author="amalloy" created="Sat, 18 Aug 2012 19:16:21 -0500"  >&lt;p&gt;This new patch replaces the previous patch. As requested, I am splitting up the large issue &lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-993&quot; title=&quot;`range` reducer&quot;&gt;CLJ-993&lt;/a&gt; into smaller tickets.&lt;/p&gt;

&lt;p&gt;Does not depend on any of my other reducer patches, but there will probably be some minor merge conflicts unless it is merged after &lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-1045&quot; title=&quot;Generalize/refactor implementation of PersistentVector/coll-fold&quot;&gt;CLJ-1045&lt;/a&gt; and &lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-1046&quot; title=&quot;Drop-while as a reducer&quot;&gt;CLJ-1046&lt;/a&gt;, and before &lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-993&quot; title=&quot;`range` reducer&quot;&gt;CLJ-993&lt;/a&gt;.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="11192" name="0001-Add-reducers-iterate.patch" size="2029" author="amalloy" created="Thu, 10 May 2012 22:24:14 -0500" />
                    <attachment id="11446" name="iterate-reducer.patch" size="2209" author="amalloy" created="Sat, 18 Aug 2012 19:16:21 -0500" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_10002" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Approval</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10003">Vetted</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                    <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10000" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Patch</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10002">Code and Test</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[CLJ-993] `range` reducer</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-993</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;Rich mentioned in IRC today he&apos;d welcome a reducer implementation of clojure.core/range. Now that I&apos;ve figured out how to do iterate, I figure I&apos;ll knock out range as well by the end of the night. Just opening the issue early to announce my intentions to anyone else interested in doing it.&lt;/p&gt;</description>
                <environment></environment>
            <key id="15431">CLJ-993</key>
            <summary>`range` reducer</summary>
                <type id="4" iconUrl="http://dev.clojure.org/jira/images/icons/improvement.gif">Enhancement</type>
                                <priority id="3" iconUrl="http://dev.clojure.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="amalloy">Alan Malloy</reporter>
                        <labels>
                    </labels>
                <created>Thu, 10 May 2012 21:47:40 -0500</created>
                <updated>Sat, 18 Aug 2012 19:18:48 -0500</updated>
                                    <version>Release 1.5</version>
                                                        <due></due>
                    <votes>1</votes>
                        <watches>2</watches>
                        <comments>
                    <comment id="28443" author="amalloy" created="Thu, 10 May 2012 22:45:49 -0500"  >&lt;p&gt;Implemented range. A separate commit is attached, making iterate and range also Seqable, since I&apos;m not sure if that&apos;s desired. Apply it or not, as you prefer.&lt;/p&gt;</comment>
                    <comment id="28457" author="jasonjckn" created="Fri, 11 May 2012 11:20:32 -0500"  >&lt;p&gt;Range should be foldable&lt;/p&gt;</comment>
                    <comment id="28462" author="amalloy" created="Fri, 11 May 2012 12:53:50 -0500"  >&lt;p&gt;Yep, so it should. Time for me to dig into the folding implementations!&lt;/p&gt;</comment>
                    <comment id="28464" author="amalloy" created="Fri, 11 May 2012 14:42:20 -0500"  >&lt;p&gt;Should I fold (har har) all of these commits into one? I don&apos;t know what is preferred on JIRA, and I also don&apos;t know whether range/iterate should be seqable or if I should just drop the second commit.&lt;/p&gt;</comment>
                    <comment id="28465" author="richhickey" created="Fri, 11 May 2012 15:21:42 -0500"  >&lt;p&gt;Yes, please merge these together, it&apos;s hard to see otherwise (I can barely read diffs as is &lt;img class=&quot;emoticon&quot; src=&quot;http://dev.clojure.org/jira/images/icons/emoticons/smile.gif&quot; height=&quot;20&quot; width=&quot;20&quot; align=&quot;absmiddle&quot; alt=&quot;&quot; border=&quot;0&quot;/&gt;. range and iterate shouldn&apos;t be novel in reducers, but just enhanced return values of core fns. The enhancement (e.g. protocol extensions) &lt;em&gt;can&lt;/em&gt; come by requiring reducers since it can&apos;t be leveraged without it. Also, I&apos;m not sure how I feel about an allocating protocol for &apos;splittable&apos; - I&apos;ve avoided it thus far.&lt;/p&gt;</comment>
                    <comment id="28466" author="amalloy" created="Fri, 11 May 2012 15:30:02 -0500"  >&lt;p&gt;So you want clojure.core/range to return some object (a Range), which implements Counted and Seqable (but isn&apos;t just a lazy-seq), and then inside of clojure.core.reducers I extend CollReduce and CollFold to that type? Okay, I can do that.&lt;/p&gt;

&lt;p&gt;I don&apos;t quite follow what you mean by an allocating protocol. I see your point that my fold-by-halves which takes a function in is analogous to a protocol with a single function, but it doesn&apos;t allocate anything more than foldvec already does - I just pulled that logic out so that the fork/join fiddly work doesn&apos;t need to be repeated in everything foldable. Do you have an alternative recommendation, or is it just something that makes you uneasy and you&apos;re still thinking about?&lt;/p&gt;</comment>
                    <comment id="28468" author="richhickey" created="Fri, 11 May 2012 15:52:39 -0500"  >&lt;p&gt;While vector-fold allocs subvecs, the halving-fn must return a new vector, for all implementations. It&apos;s ok, I don&apos;t think it&apos;s likely to dominate (since fj needs new closures anyway). Please proceed, but keep range and iterate in core. They are sources, not transformers, and only transformers (which must be different from their seq-based counterparts) must reside in reducers. Thanks!&lt;/p&gt;</comment>
                    <comment id="28470" author="stuart.sierra" created="Fri, 11 May 2012 17:01:30 -0500"  >&lt;p&gt;One big patch file is preferred, although that file may contain multiple commits if that makes the intent clearer.&lt;/p&gt;

&lt;p&gt;When adding a patch, update the description of the ticket to indicate which file is the most recent. Leave old patch files around for historical reference.&lt;/p&gt;</comment>
                    <comment id="28472" author="amalloy" created="Fri, 11 May 2012 21:00:47 -0500"  >&lt;p&gt;It&apos;s looking harder than I expected to move iterate and range into core.clj. My plan was to just have them implement Seqable, which is easy enough, but currently they are actually instances of ISeq, because they inherit from LazySeq. A bunch of code all over the place (eg, to print them in the repl) depends on them being ISeq, so I can&apos;t just ignore it. To implement all of these methods (around thirty) would take a large amount of code, which can&apos;t easily be shared between Iteration, Range, and any future reducible sources that are added to core.clj.&lt;/p&gt;

&lt;p&gt;I could write a macro like (defseq Range &lt;span class=&quot;error&quot;&gt;&amp;#91;start end step&amp;#93;&lt;/span&gt; Counted (count &lt;span class=&quot;error&quot;&gt;&amp;#91;this&amp;#93;&lt;/span&gt; ...) ...) which takes normal deftype args and also adds in implementations for ISeq, Collection, and so forth in terms of (.seq this), which will be a LazySeq. However, this seems like a somewhat awkward approach that I would be a little embarrassed to clutter up core.clj with. If anyone has a better alternative I will be pleased to hear it. In the mean time, I will go ahead with this macro implementation, in case it turns out to be the best choice.&lt;/p&gt;</comment>
                    <comment id="28473" author="amalloy" created="Fri, 11 May 2012 23:52:28 -0500"  >&lt;p&gt;&amp;#8211; This patch subsumes all previous patches to this issue and to &lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-992&quot; title=&quot;`iterate` reducer&quot;&gt;CLJ-992&lt;/a&gt; &amp;#8211;&lt;/p&gt;

&lt;p&gt;In order to create an object which is both a lazy sequence and a&lt;br/&gt;
reducible source, I needed to add a macro named defseq to core_deftype.&lt;br/&gt;
It is basically a reimplementation of clojure.lang.LazySeq as a clojure&lt;br/&gt;
macro, so that I can &quot;mix in&quot; lazy-sequence functions into a new class&lt;br/&gt;
with whatever methods are needed for reducing and folding.&lt;/p&gt;

&lt;p&gt;If we wanted, we could use this macro to implement lazy-seq in clojure instead of in java, but that&apos;s unrelated so I didn&apos;t do that in this patch.&lt;/p&gt;

&lt;p&gt;As noted in a previous comment, defseq may not be the right approach, but this works until something better is suggested.&lt;/p&gt;</comment>
                    <comment id="28474" author="amalloy" created="Fri, 11 May 2012 23:58:40 -0500"  >&lt;p&gt;I accidentally included an implementation of drop-while in this patch, which I was playing around with to make sure I understood how this all works. I guess I&apos;ll leave it in for the moment, since it works and is useful, but I can remove it, or move it to a new JIRA ticket, if it&apos;s not wanted at this time.&lt;/p&gt;</comment>
                    <comment id="28479" author="richhickey" created="Sat, 12 May 2012 10:52:52 -0500"  >&lt;p&gt;Ok, I think this patch is officially off the rails. There must be a better way. Let&apos;s start with: touching core/deftype and reimplementing lazy-seq as a macro are off the table. The return value of range doesn&apos;t have to &lt;em&gt;be&lt;/em&gt; a LazySeq, it has to be a lazy seq, .e.g. implement ISeq (7 methods, not 30) which it can do by farming out to its existing impl. It can also implement some new interface for use by the reducer logic. There is also still clojure.lang.Range still there, which is another approach. Please take an extremely conservative approach in these things.&lt;/p&gt;</comment>
                    <comment id="28480" author="amalloy" created="Sat, 12 May 2012 17:53:26 -0500"  >&lt;p&gt;Okay, thanks for the feedback - I&apos;m glad I went into that last patch knowing it was probably wrong &lt;img class=&quot;emoticon&quot; src=&quot;http://dev.clojure.org/jira/images/icons/emoticons/smile.gif&quot; height=&quot;20&quot; width=&quot;20&quot; align=&quot;absmiddle&quot; alt=&quot;&quot; border=&quot;0&quot;/&gt;. I thought I would need to implement the java collection interfaces that LazySeq does, eg java.util.List, in order to avoid breaking interop functions like (defn range-list &lt;span class=&quot;error&quot;&gt;&amp;#91;n&amp;#93;&lt;/span&gt; (ArrayList. (range n))). If it&apos;s sufficient to implement ISeq (and thus IPersistentCollection), then that&apos;s pretty manageable. &lt;/p&gt;

&lt;p&gt;It&apos;s still an unpleasant chunk of boilerplate for each new source, though; would you welcome a macro like defseq if I didn&apos;t put it in core_deftype? If so, it seems like it might as well implement the interop interfaces; if not, I can skip them and implement the 7 (isn&apos;t it more like 9?) methods in ISeq, IPersistentCollection, and Seqable for each new source type.&lt;/p&gt;

&lt;p&gt;Thanks for pointing out clojure.lang.Range to me - I didn&apos;t realize we had it there. Of course with implementation inheritance it would be easy to make Range, Iteration, etc inherit from LazySeq and just extend protocols from them. But that means moving functionality out of clojure and into java, which I didn&apos;t think we&apos;d want to do.&lt;/p&gt;

&lt;p&gt;I&apos;ll put together a patch that just implements ISeq by hand for both of these new types, and attach it probably later today.&lt;/p&gt;</comment>
                    <comment id="28481" author="amalloy" created="Sat, 12 May 2012 19:49:45 -0500"  >&lt;p&gt;So I&apos;ve written a patch that implements ISeq, but not the java Collections interfaces, and it mostly works but there are definitely assumptions in some parts of clojure.core and clojure.lang that assume seqs are Collections. The most obvious to me (ie, it shows up when running mvn test) is RT/toArray - it tests for Collection, but never for ISeq, implying that it&apos;s not willing to handle an ISeq that is not also a collection. Functions which rely on toArray (eg to-array and vec) now fail.&lt;/p&gt;

&lt;p&gt;This patch subsumes all previous patches on this issue, but is not suitable for application because it leaves some failing tests behind - it is intended only for intermediate feedback.&lt;/p&gt;</comment>
                    <comment id="28488" author="richhickey" created="Sun, 13 May 2012 08:50:39 -0500"  >&lt;p&gt;It would be a great help if, time permitting, you could please write up the issues, challenges and options you&apos;ve discovered somewhere on the dev wiki (even a simple table would be fantastic). I realize this has been a challenging task, and at this point perhaps we should opt for the more modest reducers/range and reducers/iterate and leave the two worlds separate. I&apos;d like at some point to unify range, as there are many extant ranges it would be nice to be able to fold, as we can extant vectors.&lt;/p&gt;</comment>
                    <comment id="28489" author="jasonjckn" created="Sun, 13 May 2012 09:24:04 -0500"  >&lt;p&gt;Should r/range return something Seqable and Counted?&lt;/p&gt;

&lt;p&gt;If so, I&apos;ll do the same for r/repeat.&lt;/p&gt;</comment>
                    <comment id="28496" author="amalloy" created="Sun, 13 May 2012 13:59:42 -0500"  >&lt;p&gt;I&apos;ve sketched out a description of the issues and options. I&apos;m not very familiar with the dev wiki and couldn&apos;t figure out where was the right place to put this. &quot;release.next&quot; seems to still be about 1.4 issues, and I don&apos;t know if it&apos;s &quot;appropriate&quot; to create a whole new category for this. It&apos;s available &lt;a href=&quot;https://gist.github.com/1586b2460329dde1c374&quot;&gt;as a gist&lt;/a&gt; until a better home can be found for it.&lt;/p&gt;</comment>
                    <comment id="28575" author="amalloy" created="Wed, 23 May 2012 19:54:24 -0500"  >&lt;p&gt;Here&apos;s a single patch summing up the state Rich suggested &quot;rolling back&quot; to: separate r/range and r/iterate functions. I haven&apos;t heard any feedback since doing the writeup Rich asked for, so am not making any further progress at the moment; if something other than this patch is desired just let me know.&lt;/p&gt;</comment>
                    <comment id="29141" author="richhickey" created="Tue, 14 Aug 2012 14:07:11 -0500"  >&lt;p&gt;I prefer not to see the use of extend like this for new types. Perhaps this code is too DRY? Also, it does a lot in one patch which makes it hard to parse and accept. This adds Range, switches impl of vector folds etc. Can it be broken up into separate tickets that do each step that builds on the previous, e.g. one ticket could be: capture vector fold impl for reuse by similar things.&lt;/p&gt;</comment>
                    <comment id="29225" author="amalloy" created="Sat, 18 Aug 2012 18:19:54 -0500"  >&lt;p&gt;Okay, I should be able to split it up over the weekend. I&apos;ll also see about converting fold-by-halves into a function that is used by Range/Vector, rather than a function that gets extended onto them.&lt;/p&gt;</comment>
                    <comment id="29227" author="amalloy" created="Sat, 18 Aug 2012 19:18:48 -0500"  >&lt;p&gt;As requested, I have split up the large patch on this issue into four smaller tickets. The other three are: &lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-1045&quot; title=&quot;Generalize/refactor implementation of PersistentVector/coll-fold&quot;&gt;CLJ-1045&lt;/a&gt;, &lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-1046&quot; title=&quot;Drop-while as a reducer&quot;&gt;CLJ-1046&lt;/a&gt;, and &lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-992&quot; title=&quot;`iterate` reducer&quot;&gt;CLJ-992&lt;/a&gt;.&lt;/p&gt;

&lt;p&gt;&lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-1045&quot; title=&quot;Generalize/refactor implementation of PersistentVector/coll-fold&quot;&gt;CLJ-1045&lt;/a&gt; contains the implementation of fold-by-halves, and as such this patch cannot be applied until &lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-1045&quot; title=&quot;Generalize/refactor implementation of PersistentVector/coll-fold&quot;&gt;CLJ-1045&lt;/a&gt; is accepted. This ticket does not depend on the other two, but there will be minor merge conflicts if this is merged before them.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="11246" name="0001-CLJ-993-implement-range-and-iterate-as-reducers.patch" size="7633" author="amalloy" created="Wed, 23 May 2012 19:54:24 -0500" />
                    <attachment id="11206" name="0001-CLJ-993-implement-range-and-iterate-as-reducers.patch" size="15264" author="amalloy" created="Fri, 11 May 2012 23:52:28 -0500" />
                    <attachment id="11193" name="0001-CLJ-993-implement-range-as-a-reducer.patch" size="2941" author="amalloy" created="Thu, 10 May 2012 22:45:49 -0500" />
                    <attachment id="11194" name="0002-Make-iterate-and-range-Seqable.patch" size="1193" author="amalloy" created="Thu, 10 May 2012 22:45:49 -0500" />
                    <attachment id="11203" name="0003-Implement-fold-for-Range-objects.patch" size="6204" author="amalloy" created="Fri, 11 May 2012 14:40:36 -0500" />
                    <attachment id="11210" name="just-iseq.patch" size="11691" author="amalloy" created="Sat, 12 May 2012 19:49:45 -0500" />
                    <attachment id="11447" name="range-reducer.patch" size="3740" author="amalloy" created="Sat, 18 Aug 2012 19:18:48 -0500" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10000" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Patch</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10002">Code and Test</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[CLJ-1059] PersistentQueue doesn&apos;t implement java.util.List, causing nontransitive equality</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1059</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;PersistentQueue implements Sequential but doesn&apos;t implement java.util.List. Lists form an equality partition, as do Sequentials. This means that you can end up with nontransitive equality:&lt;/p&gt;

&lt;p&gt;(def q (conj clojure.lang.PersistentQueue/EMPTY 1 2 3))&lt;br/&gt;
;=&amp;gt; #user/q&lt;br/&gt;
(def al (doto (java.util.ArrayList.) (.add 1) (.add 2) (.add 3)))&lt;br/&gt;
;=&amp;gt; #user/al&lt;br/&gt;
(def v &lt;span class=&quot;error&quot;&gt;&amp;#91;1 2 3&amp;#93;&lt;/span&gt;)&lt;br/&gt;
;=&amp;gt; #user/v&lt;br/&gt;
(= al v)&lt;br/&gt;
;=&amp;gt; true&lt;br/&gt;
(= v q)&lt;br/&gt;
;=&amp;gt; true&lt;br/&gt;
(not= al q)&lt;br/&gt;
;=&amp;gt; true&lt;/p&gt;

&lt;p&gt;This happens because PersistentQueue is a Sequential but not a List, ArrayList is a List but not a Sequential, and PersistentVector is both.&lt;/p&gt;</description>
                <environment></environment>
            <key id="15669">CLJ-1059</key>
            <summary>PersistentQueue doesn&apos;t implement java.util.List, causing nontransitive equality</summary>
                <type id="1" iconUrl="http://dev.clojure.org/jira/images/icons/bug.gif">Defect</type>
                                <priority id="3" iconUrl="http://dev.clojure.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="ppotter">Philip Potter</assignee>
                                <reporter username="ppotter">Philip Potter</reporter>
                        <labels>
                    </labels>
                <created>Mon, 3 Sep 2012 04:23:59 -0500</created>
                <updated>Tue, 11 Dec 2012 13:58:01 -0600</updated>
                                    <version>Release 1.4</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>2</watches>
                        <comments>
                    <comment id="29446" author="ppotter" created="Sat, 15 Sep 2012 03:41:15 -0500"  >&lt;p&gt;Whoops, according to &lt;a href=&quot;http://dev.clojure.org/display/design/JIRA+workflow&quot;&gt;http://dev.clojure.org/display/design/JIRA+workflow&lt;/a&gt; I should have emailed clojure-dev before filing this ticket. Here is the discussion:&lt;/p&gt;

&lt;p&gt;&lt;a href=&quot;https://groups.google.com/d/topic/clojure-dev/ME3-Ke-RbNk/discussion&quot;&gt;https://groups.google.com/d/topic/clojure-dev/ME3-Ke-RbNk/discussion&lt;/a&gt;&lt;/p&gt;</comment>
                    <comment id="29452" author="ppotter" created="Sat, 15 Sep 2012 14:37:49 -0500"  >&lt;p&gt;Attached 001-make-PersistentQueue-implement-List.diff, 15/Sep/12&lt;/p&gt;

&lt;p&gt;Note that this patch has a minor conflict with the one I added to &lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-1070&quot; title=&quot;PersistentQueue&amp;#39;s hash function does not match its equality&quot;&gt;&lt;del&gt;CLJ-1070&lt;/del&gt;&lt;/a&gt;, because both add an extra interface to PersistentQueue - List in this case, IHashEq in &lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-1070&quot; title=&quot;PersistentQueue&amp;#39;s hash function does not match its equality&quot;&gt;&lt;del&gt;CLJ-1070&lt;/del&gt;&lt;/a&gt;.&lt;/p&gt;</comment>
                    <comment id="29473" author="chouser@n01se.net" created="Tue, 18 Sep 2012 01:04:48 -0500"  >&lt;p&gt;Philip, patch looks pretty good &amp;#8211; thanks for doing this.  A couple notes:&lt;/p&gt;

&lt;p&gt;This is only my opinion, but I prefer imports be listed without wildcards, even if it means an extra couple lines at the top of a .java file.&lt;/p&gt;

&lt;p&gt;I noticed the &quot;List stuff&quot; code is a copy of what&apos;s in ASeq and EmptyList.  I suppose this is copied because EmptyList and PersistentQueue extend Obj and therefore can&apos;t extend ASeq.  Is this the only reason?  It seems a shame to duplicate these method definitions, but I don&apos;t know of a better solution, do you?&lt;/p&gt;

&lt;p&gt;It would also be nice if the test check a couple of the List methods you&apos;ve implemented.&lt;/p&gt;</comment>
                    <comment id="29474" author="chouser@n01se.net" created="Tue, 18 Sep 2012 01:08:26 -0500"  >&lt;p&gt;oh, also &quot;git am&quot; refused to apply the patch, but I&apos;m not sure why.  &quot;patch -p 1&quot; worked perfectly.&lt;/p&gt;</comment>
                    <comment id="29475" author="ppotter" created="Tue, 18 Sep 2012 01:19:11 -0500"  >&lt;p&gt;did you use the --keep-cr option to git am?&lt;/p&gt;

&lt;p&gt;I struggled to know whether I should be adding CRs or not to line endings, because the files I was editing weren&apos;t consistent in their usage. If you open them in emacs, half the lines have ^M at the end.&lt;/p&gt;</comment>
                    <comment id="29476" author="ppotter" created="Tue, 18 Sep 2012 01:21:23 -0500"  >&lt;p&gt;Will submit another patch, with the import changed. I&apos;ll have a think about the list implementation and see what ideas I can come up with.&lt;/p&gt;</comment>
                    <comment id="29487" author="ppotter" created="Tue, 18 Sep 2012 15:17:17 -0500"  >&lt;p&gt;Attached 002-make-PersistentQueue-implement-Asequential.diff&lt;/p&gt;

&lt;p&gt;This patch is an alternative to 001-make-PersistentQueue-implement-List.diff&lt;/p&gt;

&lt;p&gt;So I took on board what you said about ASeq, but it didn&apos;t feel right making PersistentQueue directly implement ISeq, somehow.&lt;/p&gt;

&lt;p&gt;So I split ASeq into two parts &amp;#8211; ASequential, which implements j.u.{Collection,List} and manages List-equality and hashcodes; and ASeq, which... doesn&apos;t seem to be doing much anymore, to be honest.&lt;/p&gt;

&lt;p&gt;As a bonus, this patch fixes &lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-1070&quot; title=&quot;PersistentQueue&amp;#39;s hash function does not match its equality&quot;&gt;&lt;del&gt;CLJ-1070&lt;/del&gt;&lt;/a&gt; too, so I went and added the tests from that ticket in to demonstrate this fact. It also tidies up PersistentQueue by removing all equals/hashcCode stuff and all Collection stuff.&lt;/p&gt;

&lt;p&gt;(It turns out that because ASeq was already implementing Obj, the fact that PersistentQueue was implementing Obj was no barrier to using it.)&lt;/p&gt;

&lt;p&gt;Would appreciate comments on this approach, and how it differs from the previous patch here and the patch on &lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-1070&quot; title=&quot;PersistentQueue&amp;#39;s hash function does not match its equality&quot;&gt;&lt;del&gt;CLJ-1070&lt;/del&gt;&lt;/a&gt;.&lt;/p&gt;</comment>
                    <comment id="29488" author="ppotter" created="Tue, 18 Sep 2012 15:44:45 -0500"  >&lt;p&gt;Looking at EmptyList&apos;s implementation of List, it is a duplicate of the others, but it shouldn&apos;t be. I think its implementation of indexOf is the biggest culprit - it should just be &apos;return -1;&apos; but it has a great big for loop! But this is beyond the scope of this ticket, so I won&apos;t patch that here.&lt;/p&gt;</comment>
                    <comment id="29731" author="jafingerhut" created="Sat, 20 Oct 2012 12:29:16 -0500"  >&lt;p&gt;Philip, now that the patch for &lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-1070&quot; title=&quot;PersistentQueue&amp;#39;s hash function does not match its equality&quot;&gt;&lt;del&gt;CLJ-1070&lt;/del&gt;&lt;/a&gt; has been applied, these patches no longer apply cleanly.  Would you be willing to update them?  If so, please remove the obsolete patches.&lt;/p&gt;</comment>
                    <comment id="29747" author="ppotter" created="Mon, 22 Oct 2012 05:10:16 -0500"  >&lt;p&gt;Andy, thanks so much for your efforts to make people aware of these things. I will indeed submit new patches, hopefully later this week.&lt;/p&gt;</comment>
                    <comment id="29899" author="ppotter" created="Sat, 3 Nov 2012 12:23:20 -0500"  >&lt;p&gt;Replaced existing patches with new ones which apply cleanly to master.&lt;/p&gt;

&lt;p&gt;There are two patches:&lt;/p&gt;

&lt;p&gt;001-clj-1059-make-persistentqueue-implement-list.diff&lt;/p&gt;

&lt;p&gt;This fixes equality by making PersistentQueue implement List directly. I also took the opportunity to remove the wildcard import and to add tests for the List methods, as compared with the previous version of the patch.&lt;/p&gt;

&lt;p&gt;002-clj-1059-asequential.diff&lt;/p&gt;

&lt;p&gt;This fixes equality by creating a new abstract class ASequential, and making PersistentQueue extend this.&lt;/p&gt;

&lt;p&gt;My preferred solution is still the ASequential patch, but I&apos;m leaving both here for comparison.&lt;/p&gt;</comment>
                    <comment id="30123" author="halgari" created="Fri, 30 Nov 2012 15:37:33 -0600"  >&lt;p&gt;Vetting. &lt;/p&gt;</comment>
                    <comment id="30214" author="jafingerhut" created="Tue, 11 Dec 2012 12:50:19 -0600"  >&lt;p&gt;Philip, this time I think it was patches that were committed for &lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-1000&quot; title=&quot;Performance drop in PersistentHashMap.valAt(...) in v.1.4 -- Util.hasheq(...) ?&quot;&gt;&lt;del&gt;CLJ-1000&lt;/del&gt;&lt;/a&gt; that make your patch 002-clj-1059-asequential.diff not apply cleanly.  I often fix up stale patches where the change is straightforward and mechanical, but in this case you are moving some methods that &lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-1000&quot; title=&quot;Performance drop in PersistentHashMap.valAt(...) in v.1.4 -- Util.hasheq(...) ?&quot;&gt;&lt;del&gt;CLJ-1000&lt;/del&gt;&lt;/a&gt;&apos;s patch changed the implementation of, so it would be best if someone figured out a way to update this patch in a way that doesn&apos;t clobber the &lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-1000&quot; title=&quot;Performance drop in PersistentHashMap.valAt(...) in v.1.4 -- Util.hasheq(...) ?&quot;&gt;&lt;del&gt;CLJ-1000&lt;/del&gt;&lt;/a&gt; changes.&lt;/p&gt;</comment>
                    <comment id="30216" author="ppotter" created="Tue, 11 Dec 2012 13:57:21 -0600"  >&lt;p&gt;Thanks Andy. Submitted a new patch, 002-clj-1059-asequential-rebased-to-cached-hasheq.diff, which supersedes 002-clj-1059-asequential.diff.&lt;/p&gt;

&lt;p&gt;The patch 001-clj-1059-make-persistentqueue-implement-list.diff still applies cleanly, and is still an alternative to 002-clj-1059-asequential-rebased-to-cached-hasheq.diff.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="11660" name="001-clj-1059-make-persistentqueue-implement-list.diff" size="4129" author="ppotter" created="Sat, 3 Nov 2012 12:23:20 -0500" />
                    <attachment id="11755" name="002-clj-1059-asequential-rebased-to-cached-hasheq.diff" size="14108" author="ppotter" created="Tue, 11 Dec 2012 13:57:21 -0600" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_10002" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Approval</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10003">Vetted</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                    <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10000" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Patch</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10002">Code and Test</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[CLJ-939] Exceptions thrown in the top level ns form are reported without file or line number</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-939</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;If there is an error in the `ns` form, an exception is thrown, which is not caught in `load`.&lt;/p&gt;

&lt;p&gt;For example, with an invalid :only clause;&lt;/p&gt;

&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;(ns clj14.myns
  (:use
   [clojure.core :only seq]))&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;This generates a &lt;tt&gt;Don&apos;t know how to create ISeq from: clojure.lang.Symbol&lt;/tt&gt; exception, with source file or line number.&lt;/p&gt;</description>
                <environment></environment>
            <key id="15245">CLJ-939</key>
            <summary>Exceptions thrown in the top level ns form are reported without file or line number</summary>
                <type id="1" iconUrl="http://dev.clojure.org/jira/images/icons/bug.gif">Defect</type>
                                <priority id="3" iconUrl="http://dev.clojure.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="hugoduncan">Hugo Duncan</reporter>
                        <labels>
                    </labels>
                <created>Fri, 24 Feb 2012 12:01:03 -0600</created>
                <updated>Sat, 15 Dec 2012 07:50:03 -0600</updated>
                                    <version>Release 1.3</version>
                <version>Release 1.4</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                        <comments>
                    <comment id="27869" author="hugoduncan" created="Sat, 25 Feb 2012 08:26:57 -0600"  >&lt;p&gt;Corrected patch&lt;/p&gt;</comment>
                    <comment id="27923" author="jafingerhut" created="Fri, 9 Mar 2012 09:26:18 -0600"  >&lt;p&gt;Patch 0001-report-load-exception-with-file-and-line.diff fails build.  Patch 0002-report-load-exception-with-file-and-line.diff applies, builds, and tests cleanly as of March 9, 2012.  Hugo has signed a CA.&lt;/p&gt;</comment>
                    <comment id="29603" author="jafingerhut" created="Fri, 5 Oct 2012 08:13:24 -0500"  >&lt;p&gt;clj-939-report-load-exceptions-with-file-and-line-patch-v2.txt dated Oct 5 2012 is intended to be an update to Hugo Duncan&apos;s patch 0002-report-load-exceptions-with-file-and-line.diff dated Feb 25 2012.  Because of Brandon Bloom&apos;s recently commited patch adding column numbers in addition to line numbers, this is not simply updating some lines of context, but I think it is correct.  It would be good if Hugo could take a look at it and confirm.&lt;/p&gt;</comment>
                    <comment id="29924" author="stuart.sierra" created="Fri, 9 Nov 2012 09:38:21 -0600"  >&lt;p&gt;Screened.&lt;/p&gt;

&lt;p&gt;The error messages are better than what we had before. The line/column numbers are not particularly informative, probably because &lt;tt&gt;ns&lt;/tt&gt; is a macro.&lt;/p&gt;</comment>
                    <comment id="29935" author="richhickey" created="Tue, 13 Nov 2012 15:37:13 -0600"  >&lt;p&gt;This patch doesn&apos;t change the reporting on any other (e.g. nested) exceptions? It looks like it might.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="10958" name="0001-report-load-exceptions-with-file-and-line.diff" size="908" author="hugoduncan" created="Fri, 24 Feb 2012 12:01:03 -0600" />
                    <attachment id="10968" name="0002-report-load-exceptions-with-file-and-line.diff" size="907" author="hugoduncan" created="Sat, 25 Feb 2012 08:26:57 -0600" />
                    <attachment id="11538" name="clj-939-report-load-exceptions-with-file-and-line-patch-v2.txt" size="934" author="jafingerhut" created="Fri, 5 Oct 2012 08:13:24 -0500" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_10002" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Approval</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10006">Incomplete</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                    <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10000" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Patch</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10001">Code</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                    <customfield id="customfield_10003" key="com.atlassian.jira.plugin.system.customfieldtypes:userpicker">
                <customfieldname>Waiting On</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>richhickey</customfieldvalue>
                </customfieldvalues>
            </customfield>
                            </customfields>
    </item>

<item>
            <title>[CLJ-899] Accept and ignore colon between key and value in map literals</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-899</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;Original title was &apos;treat colons as whitespace&apos; which isn&apos;t a problem description but a (flawed) implementation approach&lt;/p&gt;

&lt;p&gt;For JSON compatibility&lt;br/&gt;
known problems when no spaces - x:true and y:false&lt;/p&gt;</description>
                <environment></environment>
            <key id="15079">CLJ-899</key>
            <summary>Accept and ignore colon between key and value in map literals</summary>
                <type id="4" iconUrl="http://dev.clojure.org/jira/images/icons/improvement.gif">Enhancement</type>
                                <priority id="3" iconUrl="http://dev.clojure.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="stu">Stuart Halloway</reporter>
                        <labels>
                    </labels>
                <created>Sun, 18 Dec 2011 08:10:10 -0600</created>
                <updated>Wed, 19 Dec 2012 07:55:59 -0600</updated>
                                                                            <due></due>
                    <votes>4</votes>
                        <watches>9</watches>
                        <comments>
                    <comment id="27488" author="tsdh" created="Fri, 23 Dec 2011 03:22:05 -0600"  >&lt;p&gt;Discussed here: &lt;a href=&quot;https://groups.google.com/d/msg/clojure/XvJUzaY1jec/l8xEwlFl8EUJ&quot;&gt;https://groups.google.com/d/msg/clojure/XvJUzaY1jec/l8xEwlFl8EUJ&lt;/a&gt;&lt;/p&gt;</comment>
                    <comment id="27536" author="hiredman" created="Wed, 11 Jan 2012 14:23:12 -0600"  >&lt;p&gt;please no&lt;/p&gt;</comment>
                    <comment id="27576" author="tavisrudd" created="Mon, 16 Jan 2012 12:17:31 -0600"  >&lt;p&gt;Alan Malloy raises a good point in the google group discussion (&lt;a href=&quot;https://groups.google.com/d/msg/clojure/XvJUzaY1jec/aVpWBicwGhsJ&quot;&gt;https://groups.google.com/d/msg/clojure/XvJUzaY1jec/aVpWBicwGhsJ&lt;/a&gt;) about accidental confusion between trailing (or floating) and leading colons:&lt;br/&gt;
&quot;It isn&apos;t even as simple as &quot;letting them&lt;br/&gt;
be whitespace&quot;, because presumably you want (read-string &quot;{a: b}&quot;) to&lt;br/&gt;
result in (hash-map &apos;a &apos;b), but (read-string &quot;{a :b}&quot;) to result in&lt;br/&gt;
(hash-map &apos;a :b).&quot;&lt;/p&gt;

&lt;p&gt;This issue could be avoided by only treating a colon as whitespace when followed by a comma. As easy cut-paste of json seems the be the key motivation here, the commas are going to be there anyway: valid {&quot;v&quot;:, 1234} vs syntax error {a-key: should-be-a-keyword}.&lt;/p&gt;</comment>
                    <comment id="27578" author="alexbaranosky" created="Mon, 16 Jan 2012 17:23:41 -0600"  >&lt;p&gt;This would be visually confusing imo. &lt;/p&gt;</comment>
                    <comment id="27581" author="laurentpetit" created="Tue, 17 Jan 2012 17:01:00 -0600"  >&lt;p&gt;Please, oh please, no.&lt;/p&gt;</comment>
                    <comment id="27587" author="tavisrudd" created="Wed, 18 Jan 2012 14:40:46 -0600"  >&lt;p&gt;Er, brain fart. I was typing faster than I was thinking and put the comma in the wrong place.  In my head I meant the form following the colon would have to have a comma after it. Thus, {&quot;a-json-key&quot;: 1234, ...} would be valid while {&quot;a-json-key&quot;: was-supposed-to-be-a-keyword &quot;another-json-key&quot; foo} would complain about the colon being an Invalid Token.  I don&apos;t see the need for it, however.&lt;/p&gt;
</comment>
                    <comment id="27879" author="solussd" created="Mon, 27 Feb 2012 10:55:26 -0600"  >&lt;p&gt;Clojure already has reader syntax for a map. If we support JSON, do we also support ruby map literals? Seems like this addition would only add confusion, imo, given colons are used in keywords and keywords are frequently used in maps - e.g., when de-serializing from XML, or even JSON. &lt;img class=&quot;emoticon&quot; src=&quot;http://dev.clojure.org/jira/images/icons/emoticons/smile.gif&quot; height=&quot;20&quot; width=&quot;20&quot; align=&quot;absmiddle&quot; alt=&quot;&quot; border=&quot;0&quot;/&gt;&lt;/p&gt;</comment>
                    <comment id="27880" author="dnolen" created="Mon, 27 Feb 2012 11:19:53 -0600"  >&lt;p&gt;Clojure is no longer a language hosted only on the JVM. Clojure is also hosted on the CLR, and JavaScript. In particular ClojureScript can&apos;t currently easily deal with JSON literals - an extremely common (though problematic) data format. By allowing colon whitespace in map literals - Clojure data structures can effectively become an extensible JSON superset - giving the succinctness of JSON and the expressiveness of XML.&lt;/p&gt;

&lt;p&gt;+1 from me.&lt;/p&gt;</comment>
                    <comment id="29937" author="timmc" created="Tue, 13 Nov 2012 19:27:43 -0600"  >&lt;p&gt;Clojure is only hosted on the JVM; ClojureScript is hosted on JS VMs. If this is useful for CLJS, it should just be a CLJS feature.&lt;/p&gt;</comment>
                    <comment id="30209" author="mikera" created="Mon, 10 Dec 2012 23:51:24 -0600"  >&lt;p&gt;-1 for this whole idea: that way madness lies....&lt;/p&gt;

&lt;p&gt;If we keep adding syntactical oddities like this then the language will become unmaintainably complex. It&apos;s the exact opposite of simple to have lots of special cases and ambiguities that you have to remember.&lt;/p&gt;

&lt;p&gt;If people want to use JSON that is fine, but then the best approach use a specific JSON parser/writer, not just paste it into Clojure source and expect it to work. &lt;/p&gt;</comment>
                    <comment id="30213" author="laczoka" created="Tue, 11 Dec 2012 04:54:16 -0600"  >&lt;p&gt;-1 for reasons mentioned by Allan Malloy and Mike Anderson&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                                                                                            </customfields>
    </item>

<item>
            <title>[CLJ-1136] Type hinting for array classes does not work in binding forms</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1136</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;Type hints don&apos;t work as expected in binding forms. &lt;/p&gt;

&lt;p&gt;The following form results in a reflection warning:&lt;/p&gt;

&lt;p&gt;    (let [^{:tag (Class/forName &quot;&lt;span class=&quot;error&quot;&gt;&amp;#91;Ljava.lang.Object;&amp;quot;)} a (make-array Object 2)&amp;#93;&lt;/span&gt;&lt;br/&gt;
      (aget a 0))&lt;/p&gt;

&lt;p&gt;However, hinting does appear to work correctly on vars:&lt;/p&gt;

&lt;p&gt;    (def ^{:tag (Class/forName &quot;[Ljava.lang.Object;&quot;)} a (make-array Object 2))&lt;br/&gt;
    (aget a 0) ;; no reflection warning&lt;/p&gt;</description>
                <environment>replicated on OpenJDK 7u9 on Ubuntu 12.04, and Hotspot 1.6.0_37 on OSX Lion</environment>
            <key id="15911">CLJ-1136</key>
            <summary>Type hinting for array classes does not work in binding forms</summary>
                <type id="1" iconUrl="http://dev.clojure.org/jira/images/icons/bug.gif">Defect</type>
                                <priority id="3" iconUrl="http://dev.clojure.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="lvanderhart">Luke VanderHart</reporter>
                        <labels>
                        <label>Compiler</label>
                        <label>bug</label>
                    </labels>
                <created>Thu, 20 Dec 2012 14:59:58 -0600</created>
                <updated>Fri, 21 Dec 2012 11:09:56 -0600</updated>
                                    <version>Release 1.4</version>
                <version>Release 1.5</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                        <comments>
                    <comment id="30272" author="gshayban" created="Thu, 20 Dec 2012 22:51:22 -0600"  >&lt;p&gt;It&apos;s a little more insidious than type hinting: the compiler doesn&apos;t evaluate metadata in the binding vec.&lt;/p&gt;

&lt;p&gt;This doesn&apos;t throw the necessary exception...&lt;/p&gt;

&lt;p&gt;(let &lt;span class=&quot;error&quot;&gt;&amp;#91;^{:foo (Class/forName &amp;quot;not real&amp;quot;)} bar 42&amp;#93;&lt;/span&gt;&lt;br/&gt;
  bar)&lt;/p&gt;

&lt;p&gt;neither this...&lt;/p&gt;

&lt;p&gt;(let &lt;span class=&quot;error&quot;&gt;&amp;#91;^{gyorgy ligeti} a 42&amp;#93;&lt;/span&gt;&lt;br/&gt;
  a)&lt;/p&gt;

&lt;p&gt;Gyorgy Ligeti never resolves.&lt;/p&gt;

&lt;p&gt;These two equivalent examples don&apos;t reflect: &lt;br/&gt;
(let &lt;span class=&quot;error&quot;&gt;&amp;#91;^objects a (make-array Object 2)&amp;#93;&lt;/span&gt;&lt;br/&gt;
  (aget a 0))&lt;/p&gt;

&lt;p&gt;(let &lt;span class=&quot;error&quot;&gt;&amp;#91;a ^objects (make-array Object 2)&amp;#93;&lt;/span&gt;&lt;br/&gt;
  (aget a 0))&lt;/p&gt;
</comment>
                    <comment id="30275" author="gshayban" created="Fri, 21 Dec 2012 11:09:56 -0600"  >&lt;p&gt;On only the left-hand side of a local binding, metadata on a symbol is not analyzed or evaluated.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                                                                                            </customfields>
    </item>

<item>
            <title>[CLJ-1108] Allow to specify an Executor instance to be used with future-call</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1108</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;This adds an arity to future-call that expects a java.util.concurrent/ExecutorService instance to be used instead of clojure.lang.Agent/soloExecutor. &lt;/p&gt;</description>
                <environment></environment>
            <key id="15830">CLJ-1108</key>
            <summary>Allow to specify an Executor instance to be used with future-call</summary>
                <type id="4" iconUrl="http://dev.clojure.org/jira/images/icons/improvement.gif">Enhancement</type>
                                <priority id="3" iconUrl="http://dev.clojure.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="mpenet">Max Penet</reporter>
                        <labels>
                    </labels>
                <created>Sun, 18 Nov 2012 06:32:18 -0600</created>
                <updated>Thu, 27 Dec 2012 02:25:43 -0600</updated>
                                                                            <due></due>
                    <votes>0</votes>
                        <watches>1</watches>
                        <comments>
                    <comment id="30328" author="jafingerhut" created="Wed, 26 Dec 2012 16:50:58 -0600"  >&lt;p&gt;Rich Hickey committed a change on Dec 21, 2012 to the future-call function that made the patch bac37b91230d8e4ab3a1e6042a6e8c4b7e9cbf53.patch dated Nov 18 2012 no longer apply cleanly.&lt;/p&gt;

&lt;p&gt;clj-1108-enhance-future-call-patch-v2.txt dated Dec 26 2012 is identical to that earlier patch, except it has been updated to apply cleanly to the latest master.&lt;/p&gt;

&lt;p&gt;It would be best if Max Penet, author of the earlier patch, could verify I&apos;ve merged his patch to the latest Clojure master correctly.&lt;/p&gt;</comment>
                    <comment id="30330" author="mpenet" created="Thu, 27 Dec 2012 02:25:43 -0600"  >&lt;p&gt;It&apos;s verified, it applies correctly to the latest master 00978c76edfe4796bd6ebff3a82182e235211ed0 .&lt;/p&gt;

&lt;p&gt;Thanks Andy. &lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="11685" name="bac37b91230d8e4ab3a1e6042a6e8c4b7e9cbf53.patch" size="3316" author="mpenet" created="Sun, 18 Nov 2012 06:32:18 -0600" />
                    <attachment id="11779" name="clj-1108-enhance-future-call-patch-v2.txt" size="2953" author="jafingerhut" created="Wed, 26 Dec 2012 16:50:58 -0600" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10000" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Patch</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10001">Code</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[CLJ-1142] Incorrect divide-by-zero error with floating point numbers</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1142</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;The unary call for clojure.core// treats a dividend of 0.0 differently than the binary call, likely due to inlining.&lt;/p&gt;

&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;(/ 0.0) ;; java.lang.ArithmeticException: Divide by zero
(/ 1 0.0) ;;= Infinity
(/ 1 (identity 0.0)) ;; java.lang.ArithmeticException: Divide by zero&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;</description>
                <environment></environment>
            <key id="15953">CLJ-1142</key>
            <summary>Incorrect divide-by-zero error with floating point numbers</summary>
                <type id="1" iconUrl="http://dev.clojure.org/jira/images/icons/bug.gif">Defect</type>
                                <priority id="3" iconUrl="http://dev.clojure.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="timmc">Tim McCormack</reporter>
                        <labels>
                    </labels>
                <created>Tue, 8 Jan 2013 16:00:00 -0600</created>
                <updated>Tue, 8 Jan 2013 23:22:50 -0600</updated>
                                    <version>Release 1.4</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>1</watches>
                        <comments>
                    <comment id="30413" author="timmc" created="Tue, 8 Jan 2013 23:22:50 -0600"  >&lt;p&gt;The relevant code seems to be this in clojure.lang.Numbers/divide:&lt;/p&gt;

&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;&lt;span class=&quot;code-keyword&quot;&gt;if&lt;/span&gt;(yops.isZero((&lt;span class=&quot;code-object&quot;&gt;Number&lt;/span&gt;)y))
  &lt;span class=&quot;code-keyword&quot;&gt;throw&lt;/span&gt; &lt;span class=&quot;code-keyword&quot;&gt;new&lt;/span&gt; ArithmeticException(&lt;span class=&quot;code-quote&quot;&gt;&quot;Divide by zero&quot;&lt;/span&gt;);&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;Making Numbers/divide be more restrictive than double arithmetic seems like a bug; explicitly throwing an ArithmeticException instead of letting the JVM figure it just seems like more work than necessary.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                                                                                            </customfields>
    </item>

<item>
            <title>[CLJ-840] Add a way to access the current test var in :each fixtures for clojure.test</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-840</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;When looking at (log) output from tests written with clojure.test, I would like to be able to identify the output associated with each test. A mechanism to expose the current test var within an :each fixture would enable this.&lt;/p&gt;

&lt;p&gt;One mechanism might be to bind a &lt;b&gt;test-var&lt;/b&gt; var with the current test var before calling the each-fixture-fn in clojure.test/test-all-vars.&lt;/p&gt;</description>
                <environment></environment>
            <key id="14636">CLJ-840</key>
            <summary>Add a way to access the current test var in :each fixtures for clojure.test</summary>
                <type id="4" iconUrl="http://dev.clojure.org/jira/images/icons/improvement.gif">Enhancement</type>
                                <priority id="3" iconUrl="http://dev.clojure.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="hugoduncan">Hugo Duncan</reporter>
                        <labels>
                    </labels>
                <created>Wed, 21 Sep 2011 11:20:56 -0500</created>
                <updated>Fri, 18 Jan 2013 09:47:53 -0600</updated>
                                                                            <due></due>
                    <votes>0</votes>
                        <watches>2</watches>
                        <comments>
                    <comment id="26912" author="stuart.sierra" created="Fri, 7 Oct 2011 16:33:31 -0500"  >&lt;p&gt;Or just pass the Var directly into the fixture. Vars are invokable.&lt;/p&gt;</comment>
                    <comment id="26913" author="hugoduncan" created="Fri, 7 Oct 2011 16:45:05 -0500"  >&lt;p&gt;I don&apos;t think that works, since the the function passed to the fixture is not the test var, but a function calling &lt;tt&gt;test-var&lt;/tt&gt; on the test var.&lt;/p&gt;</comment>
                    <comment id="27082" author="hugoduncan" created="Fri, 21 Oct 2011 22:34:24 -0500"  >&lt;p&gt;Patch to add &lt;b&gt;test-var&lt;/b&gt;&lt;/p&gt;</comment>
                    <comment id="27090" author="stuart.sierra" created="Tue, 25 Oct 2011 18:04:52 -0500"  >&lt;p&gt;&lt;tt&gt;&amp;#42;testing-vars&amp;#42;&lt;/tt&gt; already has this information, but it&apos;s not visible to the fixture functions because it gets bound inside &lt;tt&gt;test-var&lt;/tt&gt;.&lt;/p&gt;

&lt;p&gt;Perhaps the &lt;tt&gt;:each&lt;/tt&gt; fixture functions should be called in &lt;tt&gt;test-var&lt;/tt&gt; rather than in test-all-vars. (The namespace of a Var is available in its metadata.) But then we have to call &lt;tt&gt;join-fixtures&lt;/tt&gt; inside &lt;tt&gt;test-var&lt;/tt&gt; every time.&lt;/p&gt;</comment>
                    <comment id="27092" author="stuart.sierra" created="Tue, 25 Oct 2011 18:26:51 -0500"  >&lt;p&gt;Try this patch: clj840-2.diff.&lt;/p&gt;

&lt;p&gt;This makes &lt;tt&gt;&amp;#42;testing-vars&amp;#42;&lt;/tt&gt; visible to &lt;tt&gt;:each&lt;/tt&gt; fixture functions, which seems intuitively more correct.&lt;/p&gt;

&lt;p&gt;BUT it slightly changes the behavior of &lt;tt&gt;test-var&lt;/tt&gt;, which I&apos;m less happy about.&lt;/p&gt;</comment>
                    <comment id="27094" author="hugoduncan" created="Tue, 25 Oct 2011 20:07:27 -0500"  >&lt;p&gt;Might it make sense to provide a function on top of &lt;tt&gt;&lt;b&gt;testing-vars&lt;/b&gt;&lt;/tt&gt; to return the current test-var?&lt;/p&gt;</comment>
                    <comment id="27177" author="stuart.sierra" created="Fri, 28 Oct 2011 09:14:58 -0500"  >&lt;p&gt;No, that function is &lt;tt&gt;first&lt;/tt&gt;&lt;/p&gt;</comment>
                    <comment id="27178" author="hugoduncan" created="Fri, 28 Oct 2011 11:31:05 -0500"  >&lt;p&gt;I agree with having the dynamic vars as part of the extension interface, but would have thought that having a function for use when writing tests would have been cleaner. Just my 2c.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="10495" name="add-test-var.diff" size="2970" author="hugoduncan" created="Fri, 21 Oct 2011 22:34:24 -0500" />
                    <attachment id="10497" name="clj840-2.diff" size="2366" author="stuart.sierra" created="Tue, 25 Oct 2011 18:26:51 -0500" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10000" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Patch</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10001">Code</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[CLJ-825] Protocol implementation inconsistencies </title>
                <link>http://dev.clojure.org/jira/browse/CLJ-825</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;There seems to be some inconsistencies when implementing protocols that have multi arity functions depending on how the protocol is implemented. I have attached a clj file illustrating this. The short version is that multi arity must be defined as such w/ defrecord:&lt;/p&gt;

&lt;p&gt;(defrecord Zomg []&lt;br/&gt;
  SomeProto&lt;br/&gt;
  (hello &lt;span class=&quot;error&quot;&gt;&amp;#91;_&amp;#93;&lt;/span&gt; 1)&lt;br/&gt;
  (hello &lt;span class=&quot;error&quot;&gt;&amp;#91;_ _&amp;#93;&lt;/span&gt; 1))&lt;/p&gt;

&lt;p&gt;And as such with extend-type&lt;/p&gt;

&lt;p&gt;(extend-type Object&lt;br/&gt;
  SomeProto&lt;br/&gt;
  (hello&lt;br/&gt;
    (&lt;span class=&quot;error&quot;&gt;&amp;#91;_&amp;#93;&lt;/span&gt; 1)&lt;br/&gt;
    (&lt;span class=&quot;error&quot;&gt;&amp;#91;_ _&amp;#93;&lt;/span&gt; 1)))&lt;/p&gt;

&lt;p&gt;I have only tested defrecord &amp;amp; extend-type. I am unsure how it works with deftype and extend-protocol.&lt;/p&gt;</description>
                <environment>All</environment>
            <key id="14570">CLJ-825</key>
            <summary>Protocol implementation inconsistencies </summary>
                <type id="1" iconUrl="http://dev.clojure.org/jira/images/icons/bug.gif">Defect</type>
                                <priority id="3" iconUrl="http://dev.clojure.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="carllerche">Carl Lerche</reporter>
                        <labels>
                    </labels>
                <created>Mon, 8 Aug 2011 12:35:38 -0500</created>
                <updated>Mon, 8 Aug 2011 12:35:38 -0500</updated>
                                    <version>Release 1.2</version>
                <version>Release 1.3</version>
                                                        <due></due>
                    <votes>3</votes>
                        <watches>3</watches>
                                <attachments>
                    <attachment id="10310" name="scribbles.clj" size="816" author="carllerche" created="Mon, 8 Aug 2011 12:35:38 -0500" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                                                                                            </customfields>
    </item>

<item>
            <title>[CLJ-1045] Generalize/refactor implementation of PersistentVector/coll-fold</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1045</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;Vector currently contains a specialized implementation of the folding algorithm &quot;split the collection in half until the pieces are small enough&quot;. The attached commit lifts out the general strategy so that it can be reused by other collection types amenable to splitting.&lt;/p&gt;

&lt;p&gt;&lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-993&quot; title=&quot;`range` reducer&quot;&gt;CLJ-993&lt;/a&gt; depends on this patch, as it uses the new fold-by-halves function.&lt;/p&gt;</description>
                <environment></environment>
            <key id="15635">CLJ-1045</key>
            <summary>Generalize/refactor implementation of PersistentVector/coll-fold</summary>
                <type id="4" iconUrl="http://dev.clojure.org/jira/images/icons/improvement.gif">Enhancement</type>
                                <priority id="3" iconUrl="http://dev.clojure.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="amalloy">Alan Malloy</reporter>
                        <labels>
                    </labels>
                <created>Sat, 18 Aug 2012 19:06:24 -0500</created>
                <updated>Fri, 25 Jan 2013 14:29:31 -0600</updated>
                                                                            <due></due>
                    <votes>0</votes>
                        <watches>2</watches>
                        <comments>
                    <comment id="30481" author="jafingerhut" created="Fri, 25 Jan 2013 14:29:31 -0600"  >&lt;p&gt;clj-1045-fold-by-halves-patch-v2.txt dated Jan 25 2013 is identical to fold-by-halves.patch dated Aug 18 2012, except it updates one line of context changed by a recent commit to Clojure master.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="11817" name="clj-1045-fold-by-halves-patch-v2.txt" size="2748" author="jafingerhut" created="Fri, 25 Jan 2013 14:29:31 -0600" />
                    <attachment id="11444" name="fold-by-halves.patch" size="2745" author="amalloy" created="Sat, 18 Aug 2012 19:06:24 -0500" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10000" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Patch</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10001">Code</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[CLJ-1096] Make destrucring emit direct keyword lookups</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1096</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;Currently associative destructuring emits calls to get. The attached patch modify desctruture to emit direct keyword lookups when possible. &lt;/p&gt;

&lt;p&gt;Approved here &lt;a href=&quot;https://groups.google.com/d/msg/clojure-dev/MaYcHQck8VA/nauMus4mzPgJ&quot;&gt;https://groups.google.com/d/msg/clojure-dev/MaYcHQck8VA/nauMus4mzPgJ&lt;/a&gt;&lt;/p&gt;</description>
                <environment></environment>
            <key id="15801">CLJ-1096</key>
            <summary>Make destrucring emit direct keyword lookups</summary>
                <type id="4" iconUrl="http://dev.clojure.org/jira/images/icons/improvement.gif">Enhancement</type>
                                <priority id="3" iconUrl="http://dev.clojure.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="cgrand">Christophe Grand</assignee>
                                <reporter username="cgrand">Christophe Grand</reporter>
                        <labels>
                    </labels>
                <created>Mon, 29 Oct 2012 08:05:45 -0500</created>
                <updated>Sat, 26 Jan 2013 08:15:49 -0600</updated>
                                    <version>Release 1.4</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>2</watches>
                                <attachments>
                    <attachment id="11639" name="desctructure-keyword-lookup.diff" size="1586" author="cgrand" created="Mon, 29 Oct 2012 08:05:45 -0500" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10000" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Patch</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10001">Code</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[CLJ-978] bean unable to handle non-public classes</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-978</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;Take the following Java as an example:&lt;/p&gt;

&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;&lt;span class=&quot;code-keyword&quot;&gt;public&lt;/span&gt; &lt;span class=&quot;code-keyword&quot;&gt;interface&lt;/span&gt; IFoo {
  &lt;span class=&quot;code-object&quot;&gt;String&lt;/span&gt; getBar();
}

class FooImpl {
  &lt;span class=&quot;code-object&quot;&gt;String&lt;/span&gt; getBar() { &lt;span class=&quot;code-keyword&quot;&gt;return&lt;/span&gt; &lt;span class=&quot;code-quote&quot;&gt;&quot;bar&quot;&lt;/span&gt;; }
}&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;As presently implemented, &lt;tt&gt;(bean my-foo)&lt;/tt&gt; tries to invoke the following:&lt;/p&gt;

&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;(. #&amp;lt;Method &lt;span class=&quot;code-keyword&quot;&gt;public&lt;/span&gt; java.lang.&lt;span class=&quot;code-object&quot;&gt;String&lt;/span&gt; FooImpl.getBar&amp;gt; (invoke my-foo nil))&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;However, as &lt;tt&gt;FooImpl&lt;/tt&gt; is not public, this fails:&lt;/p&gt;

&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;java.lang.IllegalAccessException: &lt;span class=&quot;code-object&quot;&gt;Class&lt;/span&gt; clojure.core$bean$fn__1827$fn__1828 can not access a member of class FooImpl with modifiers &lt;span class=&quot;code-quote&quot;&gt;&quot;&lt;span class=&quot;code-keyword&quot;&gt;public&lt;/span&gt;&quot;&lt;/span&gt;
 at sun.reflect.Reflection.ensureMemberAccess (Reflection.java:65)
    java.lang.reflect.Method.invoke (Method.java:588)
    clojure.core$bean$fn__1827$fn__1828.invoke (core_proxy.clj:382)
    clojure.core$bean$v__1832.invoke (core_proxy.clj:388)
    clojure.core$bean$fn__1838$thisfn__1839$fn__1840.invoke (core_proxy.clj:406)
    clojure.lang.LazySeq.sval (LazySeq.java:42)
    clojure.lang.LazySeq.seq (LazySeq.java:60)
    clojure.lang.RT.seq (RT.java:473)&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;However, the same thing succeeds if we call &lt;tt&gt;#&amp;lt;Method public java.lang.String Foo.getBar&amp;gt;&lt;/tt&gt; rather than &lt;tt&gt;#&amp;lt;Method public java.lang.String FooImpl.getBar&amp;gt;&lt;/tt&gt;.&lt;/p&gt;</description>
                <environment></environment>
            <key id="15387">CLJ-978</key>
            <summary>bean unable to handle non-public classes</summary>
                <type id="1" iconUrl="http://dev.clojure.org/jira/images/icons/bug.gif">Defect</type>
                                <priority id="3" iconUrl="http://dev.clojure.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="charles-dyfis-net">Charles Duffy</reporter>
                        <labels>
                    </labels>
                <created>Mon, 30 Apr 2012 21:58:06 -0500</created>
                <updated>Thu, 29 Nov 2012 10:01:49 -0600</updated>
                                    <version>Release 1.4</version>
                                                        <due></due>
                    <votes>1</votes>
                        <watches>1</watches>
                        <comments>
                    <comment id="28348" author="charles-dyfis-net" created="Mon, 30 Apr 2012 22:40:26 -0500"  >&lt;p&gt;Fix inaccurate documentation string&lt;/p&gt;</comment>
                    <comment id="28349" author="charles-dyfis-net" created="Tue, 1 May 2012 09:41:06 -0500"  >&lt;p&gt;Apache Commons Beanutils has their own implementation of this, at &lt;a href=&quot;http://www.docjar.com/html/api/org/apache/commons/beanutils/MethodUtils.java.html#771&quot;&gt;http://www.docjar.com/html/api/org/apache/commons/beanutils/MethodUtils.java.html#771&lt;/a&gt; &amp;#8211; notably, it tries to reflect a method with the given signature and catches the exception on failure, rather than iterating through the whole list. This may be a better approach &amp;#8211; I&apos;m unfamiliar with how the cost of exception handling compares with that of reflecting on the full method list of a class.&lt;/p&gt;</comment>
                    <comment id="28350" author="charles-dyfis-net" created="Tue, 1 May 2012 10:11:45 -0500"  >&lt;p&gt;Prior version of patch were missing new test suite files. Corrected.&lt;/p&gt;</comment>
                    <comment id="28383" author="jafingerhut" created="Fri, 4 May 2012 02:48:37 -0500"  >&lt;p&gt;Thanks for the patches, Charles.  Could you please create a patch in the desired format and attach that, and then remove the obsolete patches?  Instructions for creating a patch are under the heading &quot;Development&quot; at this page: &lt;a href=&quot;http://dev.clojure.org/display/design/JIRA+workflow&quot;&gt;http://dev.clojure.org/display/design/JIRA+workflow&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;Instructions for removing patches are under the heading &quot;Removing patches&quot; on that same page.&lt;/p&gt;</comment>
                    <comment id="28400" author="charles-dyfis-net" created="Sun, 6 May 2012 14:59:15 -0500"  >&lt;p&gt;Added a patch created per documented process.&lt;/p&gt;</comment>
                    <comment id="29597" author="gtrak" created="Thu, 4 Oct 2012 18:44:40 -0500"  >&lt;p&gt;I found in my code that it&apos;s possible to get a NPE if there is no read-method, for instance on the &lt;a href=&quot;http://docs.cascading.org/cascading/2.0/javadoc/cascading/flow/hadoop/HadoopFlow.html&quot;&gt;http://docs.cascading.org/cascading/2.0/javadoc/cascading/flow/hadoop/HadoopFlow.html&lt;/a&gt; object which has a setCascade method but no getter.  I fixed this in our code by inlining the is-zero-args check into the public-method definition and and-ing the whole thing with &apos;method&apos; like the original &apos;bean&apos; code, like so:&lt;/p&gt;

&lt;p&gt;public-method (and method (zero? (alength (. method (getParameterTypes))))&lt;br/&gt;
                  (or (and (java.lang.reflect.Modifier/isPublic (. c (getModifiers)))&lt;br/&gt;
                                                           method)&lt;br/&gt;
                                                      (public-version-of-method method)))&lt;/p&gt;</comment>
                    <comment id="30087" author="richhickey" created="Thu, 29 Nov 2012 10:01:49 -0600"  >&lt;p&gt;Charles, I think we should follow Apache BeanUtils on this. Exceptions not thrown are cheap. Ordinarily, exception for control flow are bad, but this is forced by bad design of reflection API.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="11173" name="clojure--bean-support-for-private-implementation-classes-v3.diff" size="4976" author="charles-dyfis-net" created="Sun, 6 May 2012 14:59:15 -0500" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10000" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Patch</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10002">Code and Test</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[CLJ-1079] Don&apos;t squash explicit :line and :column metadata in the MetaReader</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1079</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;I have been experimenting with using &lt;a href=&quot;https://github.com/lynaghk/cljx&quot;&gt;cljx&lt;/a&gt; to produce Clojure and ClojureScript source from a single file.  This has gone well so far, with the exception that, due to the way the source transformation works, all of the linebreaks and other formatting is gone from the output.  There is an option to include the original &lt;tt&gt;:line&lt;/tt&gt; metadata in the output though, like so:&lt;/p&gt;

&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;;;This file autogenerated from 
;;
;;  src/cljx/com/foo/hosty.cljx
;;
^{:line 1} (ns com.foo.hosty)
^{:line 3} (defn ^{:clj &lt;span class=&quot;code-keyword&quot;&gt;true&lt;/span&gt;} system-hash [x] ^{:line 5} (&lt;span class=&quot;code-object&quot;&gt;System&lt;/span&gt;/identityHashCode x))&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;(Hopefully, such hackery won&apos;t be necessary in the future with &lt;a href=&quot;https://github.com/cgrand/sjacket&quot;&gt;sjacket&lt;/a&gt; or something like it...)&lt;/p&gt;

&lt;p&gt;Unfortunately, when read in using a &lt;tt&gt;LineNumberingPushbackReader&lt;/tt&gt;, code like this has its &lt;tt&gt;:line&lt;/tt&gt; metadata squashed by the line numbers coming from that.  A REPL-friendly example would be:&lt;/p&gt;

&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;=&amp;gt; (meta (read (clojure.lang.LineNumberingPushbackReader.
                 (java.io.StringReader. &lt;span class=&quot;code-quote&quot;&gt;&quot;^{:line 66} ()&quot;&lt;/span&gt;))))
{:line 1}
=&amp;gt; (meta (read (java.io.PushbackReader.
                 (java.io.StringReader. &lt;span class=&quot;code-quote&quot;&gt;&quot;^{:line 66} ()&quot;&lt;/span&gt;))))
{:line 66}&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;The latter seems more correct to me (and is equivalent to &lt;tt&gt;read-string&lt;/tt&gt;).&lt;/p&gt;</description>
                <environment></environment>
            <key id="15727">CLJ-1079</key>
            <summary>Don&apos;t squash explicit :line and :column metadata in the MetaReader</summary>
                <type id="1" iconUrl="http://dev.clojure.org/jira/images/icons/bug.gif">Defect</type>
                                <priority id="3" iconUrl="http://dev.clojure.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="cemerick">Chas Emerick</reporter>
                        <labels>
                    </labels>
                <created>Sat, 29 Sep 2012 17:12:45 -0500</created>
                <updated>Thu, 7 Feb 2013 12:35:21 -0600</updated>
                                    <version>Release 1.4</version>
                <version>Release 1.5</version>
                                                        <due></due>
                    <votes>1</votes>
                        <watches>1</watches>
                        <comments>
                    <comment id="29578" author="cemerick" created="Sat, 29 Sep 2012 19:07:42 -0500"  >&lt;p&gt;{{&lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-1097&quot; title=&quot;node-seq for clojure.zip&quot;&gt;CLJ-1097&lt;/a&gt;.diff}} contains a fix for this issue, as well as a separate commit that eliminates a series of casts in order to improve readability in the area.&lt;/p&gt;</comment>
                    <comment id="29604" author="jafingerhut" created="Fri, 5 Oct 2012 08:23:47 -0500"  >&lt;p&gt;Chas, your patch doesn&apos;t apply cleanly to latest Clojure master as of Oct 5 2012.  I&apos;m not sure, but I think some recent commits to Clojure on Oct 4 2012 caused that.  I also take it as evidence of your awesomeness that you can write patches for tickets that haven&apos;t been filed yet &lt;img class=&quot;emoticon&quot; src=&quot;http://dev.clojure.org/jira/images/icons/emoticons/smile.gif&quot; height=&quot;20&quot; width=&quot;20&quot; align=&quot;absmiddle&quot; alt=&quot;&quot; border=&quot;0&quot;/&gt;&lt;/p&gt;</comment>
                    <comment id="29605" author="cemerick" created="Fri, 5 Oct 2012 09:24:05 -0500"  >&lt;p&gt;&quot;patches for tickets that haven&apos;t been filed yet?&quot;&lt;/p&gt;

&lt;p&gt;Anyway, tweaking up this patch is a small price to pay for having column meta.  New {{&lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-1097&quot; title=&quot;node-seq for clojure.zip&quot;&gt;CLJ-1097&lt;/a&gt;.diff}} patch attached, applies clean on master as of now.  Otherwise same contents as in the original patch, except:&lt;/p&gt;

&lt;ul&gt;
	&lt;li&gt;the same dynamic is also applied to &lt;tt&gt;:column&lt;/tt&gt; metadata, now that it&apos;s available&lt;/li&gt;
	&lt;li&gt;the changes have been rebased into a single commit (including the elimination of the casts in &lt;tt&gt;MetaReader&lt;/tt&gt;, which were becoming so numerous that the code was less readable than most&lt;/li&gt;
&lt;/ul&gt;
</comment>
                    <comment id="29606" author="bronsa" created="Fri, 5 Oct 2012 09:39:21 -0500"  >&lt;p&gt;&quot;patches for tickets that haven&apos;t been filed yet?&quot;&lt;/p&gt;

&lt;p&gt;He was referring to the fact that you uploaded &quot;&lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-1097&quot; title=&quot;node-seq for clojure.zip&quot;&gt;CLJ-1097&lt;/a&gt;.diff&quot; while the ticket is #1079 &lt;/p&gt;</comment>
                    <comment id="29607" author="cemerick" created="Fri, 5 Oct 2012 09:42:14 -0500"  >&lt;p&gt;Oh, hah! Twice now, even! One more data point recommending my having slight dyslexia or somesuch. :-P&lt;/p&gt;

&lt;p&gt;I&apos;ve replaced the attached patch with one that is named properly to avoid any later confusion.&lt;/p&gt;</comment>
                    <comment id="29612" author="cemerick" created="Sun, 7 Oct 2012 15:57:29 -0500"  >&lt;p&gt;Refreshed patch to apply cleanly to master after the recent &lt;a href=&quot;https://github.com/clojure/clojure/commit/65b5f73a9be30669116fcddb6ced9e60680532e5&quot;&gt;off by one patch for &lt;tt&gt;:column&lt;/tt&gt; metadata&lt;/a&gt;.&lt;/p&gt;</comment>
                    <comment id="29699" author="stu" created="Fri, 19 Oct 2012 15:12:42 -0500"  >&lt;p&gt;This feels backwards to me. If a special purpose tool wants to convey information via metadata, why does it use names that collide with those used by LispReader?&lt;/p&gt;</comment>
                    <comment id="29716" author="cemerick" created="Fri, 19 Oct 2012 19:36:17 -0500"  >&lt;p&gt;The information being conveyed is the same &lt;tt&gt;:line&lt;/tt&gt; and &lt;tt&gt;:column&lt;/tt&gt; metadata conveyed by &lt;tt&gt;LispReader&lt;/tt&gt; &#8212;&#160;in fact, that&apos;s where it comes from in the first place.&lt;/p&gt;

&lt;p&gt;Kibit (and cljx) is essentially an out-of-band source transformation tool.  Given an input like this:&lt;/p&gt;

&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;(ns com.foo.hosty)

(defn ^:clj system-hash
  [x]
 (&lt;span class=&quot;code-object&quot;&gt;System&lt;/span&gt;/identityHashCode x))

(defn ^:cljs system-hash
  [x]
  (goog/getUid x))&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;&#8230;it produces two files, a &lt;tt&gt;.clj&lt;/tt&gt; for Clojure, and a &lt;tt&gt;.cljs&lt;/tt&gt; for ClojureScript.  (The first code listing in the ticket description is the former.)&lt;/p&gt;

&lt;p&gt;However, because there&apos;s no way to transform Clojure code/data without losing formatting, anything that depends on line/column numbers (stack traces, stepping debuggers) is significantly degraded.  If &lt;tt&gt;LispReader&lt;/tt&gt; were to defer to &lt;tt&gt;:line&lt;/tt&gt; and &lt;tt&gt;:column&lt;/tt&gt; metadata already available on the loaded forms (there when the two generated files are spit out with &lt;tt&gt;&amp;#42;print-meta&amp;#42;&lt;/tt&gt; on), this would not be the case.&lt;/p&gt;</comment>
                    <comment id="30562" author="jafingerhut" created="Thu, 7 Feb 2013 08:47:49 -0600"  >&lt;p&gt;clj-1079-patch-v2.txt dated Feb 7 2013 is identical to Chas&apos;s &lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-1079&quot; title=&quot;Don&amp;#39;t squash explicit :line and :column metadata in the MetaReader&quot;&gt;CLJ-1079&lt;/a&gt;.diff dated Oct 7 2012, except it applies cleanly to latest master.  I believe the only difference is that some white space in the context lines is updated.&lt;/p&gt;</comment>
                    <comment id="30566" author="jafingerhut" created="Thu, 7 Feb 2013 12:35:08 -0600"  >&lt;p&gt;Sorry for the noise.  I&apos;ve removed clj-1079-patch-v2.txt mentioned in the previous comment, because I learned that &lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-1079&quot; title=&quot;Don&amp;#39;t squash explicit :line and :column metadata in the MetaReader&quot;&gt;CLJ-1079&lt;/a&gt;.diff dated Oct 7 2012 applies cleanly to latest master and passes all tests if you use this command to apply it.&lt;/p&gt;

&lt;p&gt;% git am --keep-cr -s --ignore-whitespace &amp;lt; &lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-1079&quot; title=&quot;Don&amp;#39;t squash explicit :line and :column metadata in the MetaReader&quot;&gt;CLJ-1079&lt;/a&gt;.diff&lt;/p&gt;

&lt;p&gt;I will update the JIRA workflow page instructions for applying patches to mention this, too, because there are multiple patches that fail without --ignore-whitespace, but apply cleanly with that option.  That will eliminate the need to update patches merely for whitespace changes.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="11542" name="CLJ-1079.diff" size="4665" author="cemerick" created="Sun, 7 Oct 2012 15:57:29 -0500" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10000" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Patch</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10002">Code and Test</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[CLJ-859] Built in dynamic vars don&apos;t have :dynamic metadata</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-859</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;I&apos;m sure &apos;built in&apos; is probably not the right term here, but I&apos;m not sure what these are called.&lt;/p&gt;

&lt;p&gt;I ran into this issue earlier today while fixing a bug in clojail. Built in vars, particularly ones listed here without a source link: &lt;a href=&quot;http://clojure.github.com/clojure/clojure.core-api.html&quot;&gt;http://clojure.github.com/clojure/clojure.core-api.html&lt;/a&gt;, do not have :dynamic metadata despite being dynamic. This includes &amp;#42;in&amp;#42;, &amp;#42;out&amp;#42;, and &amp;#42;err&amp;#42; among others. Here are some examples:&lt;/p&gt;

&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;user=&amp;gt; (meta #&apos;*err*)
{:ns #&amp;lt;Namespace clojure.core&amp;gt;, :name *err*, :added &lt;span class=&quot;code-quote&quot;&gt;&quot;1.0&quot;&lt;/span&gt;, :doc &lt;span class=&quot;code-quote&quot;&gt;&quot;A java.io.Writer object representing standard error &lt;span class=&quot;code-keyword&quot;&gt;for&lt;/span&gt; print operations.\n\n  Defaults to &lt;span class=&quot;code-object&quot;&gt;System&lt;/span&gt;/err, wrapped in a PrintWriter&quot;&lt;/span&gt;}
user=&amp;gt; (meta #&apos;*in*)
{:ns #&amp;lt;Namespace clojure.core&amp;gt;, :name *in*, :added &lt;span class=&quot;code-quote&quot;&gt;&quot;1.0&quot;&lt;/span&gt;, :doc &lt;span class=&quot;code-quote&quot;&gt;&quot;A java.io.Reader object representing standard input &lt;span class=&quot;code-keyword&quot;&gt;for&lt;/span&gt; read operations.\n\n  Defaults to &lt;span class=&quot;code-object&quot;&gt;System&lt;/span&gt;/in, wrapped in a LineNumberingPushbackReader&quot;&lt;/span&gt;}
user=&amp;gt; (meta #&apos;*out*)
{:ns #&amp;lt;Namespace clojure.core&amp;gt;, :name *out*, :added &lt;span class=&quot;code-quote&quot;&gt;&quot;1.0&quot;&lt;/span&gt;, :doc &lt;span class=&quot;code-quote&quot;&gt;&quot;A java.io.Writer object representing standard output &lt;span class=&quot;code-keyword&quot;&gt;for&lt;/span&gt; print operations.\n\n  Defaults to &lt;span class=&quot;code-object&quot;&gt;System&lt;/span&gt;/out, wrapped in an OutputStreamWriter&quot;&lt;/span&gt;, :tag java.io.Writer}
user=&amp;gt; (meta #&apos;*ns*)
{:ns #&amp;lt;Namespace clojure.core&amp;gt;, :name *ns*, :added &lt;span class=&quot;code-quote&quot;&gt;&quot;1.0&quot;&lt;/span&gt;, :doc &lt;span class=&quot;code-quote&quot;&gt;&quot;A clojure.lang.Namespace object representing the current namespace.&quot;&lt;/span&gt;, :tag clojure.lang.Namespace}&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;</description>
                <environment></environment>
            <key id="14710">CLJ-859</key>
            <summary>Built in dynamic vars don&apos;t have :dynamic metadata</summary>
                <type id="1" iconUrl="http://dev.clojure.org/jira/images/icons/bug.gif">Defect</type>
                                <priority id="3" iconUrl="http://dev.clojure.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="anthonysimpson">Anthony Simpson</reporter>
                        <labels>
                    </labels>
                <created>Wed, 19 Oct 2011 04:39:09 -0500</created>
                <updated>Fri, 24 Feb 2012 12:41:31 -0600</updated>
                                    <version>Release 1.3</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>2</watches>
                        <comments>
                    <comment id="27072" author="bsmith.occs@gmail.com" created="Wed, 19 Oct 2011 12:03:11 -0500"  >&lt;p&gt;This recent discussion on the users list seems relevant: &lt;a href=&quot;http://groups.google.com/group/clojure/browse_thread/thread/d5efd00c699f73a7&quot;&gt;Should intern obey :dynamic?&lt;/a&gt;.&lt;/p&gt;

&lt;p&gt;It seems to boil down to this the information that a Var is dynamic (or not) is duplicated. Once as metadata with the key &lt;tt&gt;:dynamic&lt;/tt&gt;, and once as a boolean field on the Var class which implements Clojure&apos;s variables. This boolean can be obtained by calling the method &lt;tt&gt;isDynamic()&lt;/tt&gt; on the Var.&lt;/p&gt;

&lt;p&gt;The confusion arises because apparently &lt;tt&gt;:dynamic&lt;/tt&gt; and &lt;tt&gt;.isDynamic&lt;/tt&gt; can get out of sync with each other. &lt;tt&gt;.isDynamic&lt;/tt&gt; is the source of truth in this case.&lt;/p&gt;</comment>
                    <comment id="27073" author="bsmith.occs@gmail.com" created="Wed, 19 Oct 2011 12:18:22 -0500"  >&lt;p&gt;&lt;tt&gt;Compiler$Parser.parse(...)&lt;/tt&gt; finds the &lt;tt&gt;:dynamic&lt;/tt&gt; entry left in the metadata of the symbol by &lt;tt&gt;LispReader&lt;/tt&gt; and passes this on when creating a new &lt;tt&gt;DefExpr&lt;/tt&gt;, which in turn, generates the code that will call &lt;tt&gt;setDynamic(...)&lt;/tt&gt; on the var when it is created at runtime.&lt;/p&gt;

&lt;p&gt;As far as I can tell, the &lt;tt&gt;:dynamic&lt;/tt&gt; entry is irrelevant once that has occurred. It seems to be implemented only as a way to communicate (by way of the reader) with the compiler. Once the compiler&apos;s gotten the message, it isn&apos;t needed anymore. Keeping it around seems to just cause confusion.&lt;/p&gt;

&lt;p&gt;Dynamic vars created by the Java layer of Clojure core don&apos;t use the &lt;tt&gt;:dynamic&lt;/tt&gt; mechanism, they just &lt;tt&gt;setDynamic()&lt;/tt&gt; directly. That&apos;s why they don&apos;t have &lt;tt&gt;:dynamic&lt;/tt&gt; in their meta-data map. &lt;/p&gt;

&lt;ul class=&quot;alternate&quot; type=&quot;square&quot;&gt;
	&lt;li&gt;Perhaps the compiler should elide &lt;tt&gt;:dynamic&lt;/tt&gt; from the metadata map available at runtime, since it has served its purpose.&lt;/li&gt;
	&lt;li&gt;Perhaps Clojure should supply the function &lt;tt&gt;dynamic?&lt;/tt&gt;.
&lt;div class=&quot;preformatted panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;preformattedContent panelContent&quot;&gt;
&lt;pre&gt;(defn dynamic? [^clojure.lang.Var v] (.isDynamic v))&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;&lt;/li&gt;
&lt;/ul&gt;


&lt;p&gt;Or, perhaps one might consider, for 1.4, replacing &lt;tt&gt;:dynamic&lt;/tt&gt; altogether and just enforcing the established naming convention: &lt;tt&gt;&amp;#42;earmuffs&amp;#42;&lt;/tt&gt; are dynamic, &lt;tt&gt;everything-else&lt;/tt&gt; isn&apos;t. (The compile warns about violations of this convention in 1.3.)&lt;/p&gt;</comment>
                    <comment id="27839" author="jafingerhut" created="Fri, 24 Feb 2012 11:39:08 -0600"  >&lt;p&gt;I recently noticed several lines like this one in core.clj.  Depending upon how many symbols are like this, perhaps this method could be used to add :dynamic metadata to symbols in core, along with a unit test to verify that all symbols in core have :dynamic if and only if .isDynamic returns true?&lt;/p&gt;</comment>
                    <comment id="27841" author="jafingerhut" created="Fri, 24 Feb 2012 12:41:31 -0600"  >&lt;p&gt;Ugh.  In my previous comment, by &quot;several lines like this one&quot; I meant to paste the following as an example:&lt;/p&gt;

&lt;p&gt;(alter-meta! #&apos;&lt;b&gt;agent&lt;/b&gt; assoc :added &quot;1.0&quot;)&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                                                                                            </customfields>
    </item>

<item>
            <title>[CLJ-1100] Reader literals cannot contain periods</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1100</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;The LispReader tries to read a record instead of a literal if the tag contains periods:&lt;/p&gt;

&lt;p&gt;&lt;a href=&quot;https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/LispReader.java#L1171&quot;&gt;https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/LispReader.java#L1171&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;Which effectively means that reader tags cannot contain periods.&lt;br/&gt;
The EDN spec is unclear on this: &lt;/p&gt;

&lt;blockquote&gt;&lt;p&gt;edn supports extensibility through a simple mechanism. # followed immediately by a symbol starting with an alphabetic character indicates that that symbol is a tag.&lt;/p&gt;&lt;/blockquote&gt;

&lt;p&gt;(issue opened: &lt;a href=&quot;https://github.com/edn-format/edn/issues/39&quot;&gt;https://github.com/edn-format/edn/issues/39&lt;/a&gt;)&lt;/p&gt;

&lt;p&gt;If periods are allowed, then the LispReader should first check to see if the tag is in &lt;tt&gt;&amp;#42;data-readers&amp;#42;&lt;/tt&gt; and only then if not try to initialize a Java class.&lt;/p&gt;

&lt;p&gt;I&apos;m happy to write the patch if this behavior is what is desired.&lt;/p&gt;</description>
                <environment></environment>
            <key id="15812">CLJ-1100</key>
            <summary>Reader literals cannot contain periods</summary>
                <type id="1" iconUrl="http://dev.clojure.org/jira/images/icons/bug.gif">Defect</type>
                                <priority id="3" iconUrl="http://dev.clojure.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="lynaghk">Kevin Lynagh</reporter>
                        <labels>
                        <label>reader</label>
                    </labels>
                <created>Fri, 2 Nov 2012 23:57:22 -0500</created>
                <updated>Thu, 14 Feb 2013 15:04:53 -0600</updated>
                                                                            <due></due>
                    <votes>1</votes>
                        <watches>2</watches>
                        <comments>
                    <comment id="29904" author="steveminer@gmail.com" created="Tue, 6 Nov 2012 09:41:44 -0600"  >&lt;p&gt;The suggested patch (clj-1100-reader-literal-periods.patch) will break reading records when &amp;#42;default-data-reader-fn* is set.  Try adding a test like this:&lt;/p&gt;

&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;(deftest tags-containing-periods-with-&lt;span class=&quot;code-keyword&quot;&gt;default&lt;/span&gt;
      ;; we need a predefined record &lt;span class=&quot;code-keyword&quot;&gt;for&lt;/span&gt; &lt;span class=&quot;code-keyword&quot;&gt;this&lt;/span&gt; test so we (mis)use clojure.reflect.Field &lt;span class=&quot;code-keyword&quot;&gt;for&lt;/span&gt; convenience
      (let [v &lt;span class=&quot;code-quote&quot;&gt;&quot;#clojure.reflect.Field{:name \&quot;&lt;/span&gt;fake\&lt;span class=&quot;code-quote&quot;&gt;&quot; :type :fake :declaring-class \&quot;&lt;/span&gt;Fake\&lt;span class=&quot;code-quote&quot;&gt;&quot; :flags nil}&quot;&lt;/span&gt;]
        (binding [*&lt;span class=&quot;code-keyword&quot;&gt;default&lt;/span&gt;-data-reader-fn* nil]
          (is (= (read-string v) #clojure.reflect.Field{:name &lt;span class=&quot;code-quote&quot;&gt;&quot;fake&quot;&lt;/span&gt; :type :fake :declaring-class &lt;span class=&quot;code-quote&quot;&gt;&quot;Fake&quot;&lt;/span&gt; :flags nil})))
        (binding [*&lt;span class=&quot;code-keyword&quot;&gt;default&lt;/span&gt;-data-reader-fn* (fn [tag val] (assoc val :meaning 42))]
          (is (= (read-string v) #clojure.reflect.Field{:name &lt;span class=&quot;code-quote&quot;&gt;&quot;fake&quot;&lt;/span&gt; :type :fake :declaring-class &lt;span class=&quot;code-quote&quot;&gt;&quot;Fake&quot;&lt;/span&gt; :flags nil})))))&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;</comment>
                    <comment id="30085" author="richhickey" created="Thu, 29 Nov 2012 09:36:46 -0600"  >&lt;p&gt;The problem assessment is ok, but the resolution approach may not be. What happens should be based not upon what is in data-readers but whether or not the name names a class.&lt;/p&gt;

&lt;p&gt;Is the intent here to allow readers to circumvent records? I&apos;m not in favor of that.&lt;/p&gt;</comment>
                    <comment id="30098" author="steveminer@gmail.com" created="Thu, 29 Nov 2012 16:01:00 -0600"  >&lt;p&gt;New patch following Rich&apos;s comments.  The decision to read a record is now based on the symbol containing periods and not having a namespace.  Otherwise, it is considered a data reader tag.  User&lt;br/&gt;
defined tags are required to be qualified but they may now have periods in the name.  Tests added to show that&lt;br/&gt;
data readers cannot override record classes.  Note: Clojure-defined data reader tags may be unqualified, but they should not contain periods in order to avoid confusion with record classes.&lt;/p&gt;</comment>
                    <comment id="30100" author="steveminer@gmail.com" created="Thu, 29 Nov 2012 16:17:32 -0600"  >&lt;p&gt;I deleted my old patch and some comments referring to it to avoid confusion.&lt;/p&gt;

&lt;p&gt;In Clojure 1.5 beta 1, # followed by a qualified symbol with a period in the name is considered a record and causes an exception for the missing record class.  With the patch, only non-qualified symbols containing periods are considered records.  That allows user-defined qualified symbols with periods in their names to be used as data reader tags.&lt;/p&gt;</comment>
                    <comment id="30564" author="jafingerhut" created="Thu, 7 Feb 2013 09:05:09 -0600"  >&lt;p&gt;clj-1100-periods-in-data-reader-tags-patch-v2.txt dated Feb 7 2013 is identical to &lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-1100&quot; title=&quot;Reader literals cannot contain periods&quot;&gt;CLJ-1100&lt;/a&gt;-periods-in-data-reader-tags.patch dated Nov 29 2012, except it applies cleanly to latest master.  The only change appears to be in some white space in the context lines.&lt;/p&gt;</comment>
                    <comment id="30567" author="jafingerhut" created="Thu, 7 Feb 2013 12:53:25 -0600"  >&lt;p&gt;I&apos;ve removed clj-1100-periods-in-data-reader-tags-patch-v2.txt mentioned in the previous comment, because I learned that &lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-1100&quot; title=&quot;Reader literals cannot contain periods&quot;&gt;CLJ-1100&lt;/a&gt;-periods-in-data-reader-tags.patch dated Nov 29 2012 applies cleanly to latest master and passes all tests if you use this command to apply it.&lt;/p&gt;

&lt;p&gt;% git am --keep-cr -s --ignore-whitespace &amp;lt; &lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-1100&quot; title=&quot;Reader literals cannot contain periods&quot;&gt;CLJ-1100&lt;/a&gt;-periods-in-data-reader-tags.patch&lt;/p&gt;

&lt;p&gt;I&apos;ve already updated the JIRA workflow and screening patches wiki pages to mention this --ignore-whitespace option.&lt;/p&gt;</comment>
                    <comment id="30585" author="jafingerhut" created="Wed, 13 Feb 2013 11:31:03 -0600"  >&lt;p&gt;Both of the current patches, &lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-1100&quot; title=&quot;Reader literals cannot contain periods&quot;&gt;CLJ-1100&lt;/a&gt;-periods-in-data-reader-tags.patch dated Nov 29 2012, and clj-1100-reader-literal-periods.patch dated Nov 6 2012, fail to apply cleanly to latest master (1.5.0-RC15) as of today, although they did last week.  Given all of the changes around read / read-string and edn recently, they should probably be evaluated by their authors to see how they should be updated.&lt;/p&gt;</comment>
                    <comment id="30600" author="steveminer@gmail.com" created="Thu, 14 Feb 2013 12:23:26 -0600"  >&lt;p&gt;I deleted my patch: &lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-1100&quot; title=&quot;Reader literals cannot contain periods&quot;&gt;CLJ-1100&lt;/a&gt;-periods-in-data-reader-tags.patch.  clj-1100-reader-literal-periods.patch is clearly wrong, but the original author or an administrator has to delete that.&lt;/p&gt;</comment>
                    <comment id="30602" author="lynaghk" created="Thu, 14 Feb 2013 13:28:04 -0600"  >&lt;p&gt;I cannot figure out how to remove my attachment (clj-1100-reader-literal-periods.patch) in JIRA.&lt;/p&gt;</comment>
                    <comment id="30603" author="steveminer@gmail.com" created="Thu, 14 Feb 2013 13:43:45 -0600"  >&lt;p&gt;Downarrow (popup) menu to the right of the &quot;Attachments&quot; section.  Choose &quot;manager attachments&quot;.&lt;/p&gt;</comment>
                    <comment id="30604" author="lynaghk" created="Thu, 14 Feb 2013 14:02:50 -0600"  >&lt;p&gt;Great, thanks Steve. Are you going to take another pass at this issue, or should I give it a go?&lt;/p&gt;</comment>
                    <comment id="30605" author="steveminer@gmail.com" created="Thu, 14 Feb 2013 15:04:53 -0600"  >&lt;p&gt;Kevin, I&apos;m not planning to work on this right now as 1.5 is pretty much done.  It might be worthwhile discussing the issue a bit on the dev mailing list before working on a patch, but that&apos;s up to you.  I think my approach was correct, although now changes would have to be applied to both LispReader and EdnReader.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_10002" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Approval</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10003">Vetted</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                    <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                                                                                            </customfields>
    </item>

<item>
            <title>[CLJ-705] Make sorted maps and sets implement j.u.SortedMap and SortedSet interfaces</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-705</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description></description>
                <environment></environment>
            <key id="14314">CLJ-705</key>
            <summary>Make sorted maps and sets implement j.u.SortedMap and SortedSet interfaces</summary>
                <type id="4" iconUrl="http://dev.clojure.org/jira/images/icons/improvement.gif">Enhancement</type>
                                <priority id="3" iconUrl="http://dev.clojure.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="richhickey">Rich Hickey</reporter>
                        <labels>
                    </labels>
                <created>Wed, 5 Jan 2011 12:53:42 -0600</created>
                <updated>Sat, 2 Jun 2012 14:29:11 -0500</updated>
                                                                            <due></due>
                    <votes>0</votes>
                        <watches>1</watches>
                        <comments>
                    <comment id="28684" author="jafingerhut" created="Sat, 2 Jun 2012 14:29:11 -0500"  >&lt;p&gt;This might be a duplicate of &lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-248&quot; title=&quot;Add support for subsets and submaps to sorted Sets/Maps&quot;&gt;CLJ-248&lt;/a&gt;.  See that one before working on this one, at least.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                                                                                            </customfields>
    </item>

<item>
            <title>[CLJ-1076] pprint tests fail on Windows, expecting \n</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1076</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;New pprint tests were committed recently, but they fail on Windows because the tests check for \n, while pprint seems to output \r\n.  A log with the test failures is attached.&lt;/p&gt;

&lt;p&gt;The first failing commit is &lt;a href=&quot;https://github.com/clojure/clojure/commit/4ca0f7ea17888ba7ed56d2fde0bc2d6397e8e1c0&quot;&gt;https://github.com/clojure/clojure/commit/4ca0f7ea17888ba7ed56d2fde0bc2d6397e8e1c0&lt;/a&gt;&lt;/p&gt;</description>
                <environment>Windows 7</environment>
            <key id="15719">CLJ-1076</key>
            <summary>pprint tests fail on Windows, expecting \n</summary>
                <type id="1" iconUrl="http://dev.clojure.org/jira/images/icons/bug.gif">Defect</type>
                                <priority id="3" iconUrl="http://dev.clojure.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="ivan">Ivan Kozik</reporter>
                        <labels>
                    </labels>
                <created>Wed, 26 Sep 2012 02:34:19 -0500</created>
                <updated>Sat, 2 Mar 2013 14:51:46 -0600</updated>
                                    <version>Release 1.5</version>
                                                        <due></due>
                    <votes>1</votes>
                        <watches>2</watches>
                        <comments>
                    <comment id="29575" author="jafingerhut" created="Sat, 29 Sep 2012 14:27:55 -0500"  >&lt;p&gt;Patch clj-1076-fix-tests-on-windows-patch-v1.txt dated Sep 29 2012 when applied to the particular commit that Ivan mentions causes the tests to pass when I run &quot;ant&quot; on a Windows 7 machine for me, and it continues to pass all tests on Mac OS X 10.6.8, too.&lt;/p&gt;

&lt;p&gt;I may be doing something wrong, but when I try to run &quot;ant&quot; to build and test on Windows 7 with latest Clojure master, with or without this patch, it fails right at the beginning of the tests because it can&apos;t find clojure.test.generative.  I&apos;m probably doing something wrong somewhere.  Ivan, would you be able to test this patch on Windows with the latest Clojure master to see if all tests pass for you now?&lt;/p&gt;</comment>
                    <comment id="29576" author="ivan" created="Sat, 29 Sep 2012 14:59:02 -0500"  >&lt;p&gt;All tests pass on Windows 7 here with the patch.&lt;/p&gt;

&lt;p&gt;Ant can&apos;t find my test.generative either because it isn&apos;t in my &quot;${maven.test.classpath}&quot;.  I put it in CLASSPATH and modified my build.xml like this:&lt;br/&gt;
&lt;br/&gt;
     &amp;lt;java classname=&quot;clojure.main&quot; failonerror=&quot;false&quot; fork=&quot;true&quot;&amp;gt;&lt;br/&gt;
       &amp;lt;classpath&amp;gt;&lt;br/&gt;
+        &amp;lt;pathelement path=&quot;${java.class.path}&quot;/&amp;gt;&lt;br/&gt;
         &amp;lt;pathelement path=&quot;${maven.test.classpath}&quot;/&amp;gt;&lt;/p&gt;</comment>
                    <comment id="30205" author="jafingerhut" created="Mon, 10 Dec 2012 13:33:33 -0600"  >&lt;p&gt;Just as a rough idea of how often people are hitting this issue, &lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-1123&quot; title=&quot;UNIX/Windows line endings - clojure.pprint tests cause failure in Windows build&quot;&gt;&lt;del&gt;CLJ-1123&lt;/del&gt;&lt;/a&gt; was opened on Dec 9 2012 and then closed when the ticket creator realized it was a duplicate of this one.&lt;/p&gt;</comment>
                    <comment id="30455" author="mikera" created="Fri, 18 Jan 2013 19:44:14 -0600"  >&lt;p&gt;Hi there is this likely to get fixed soon?&lt;/p&gt;

&lt;p&gt;I&apos;d like to help contribute some more patches to Clojure but it&apos;s tricky to do when I can&apos;t get the build to work &lt;img class=&quot;emoticon&quot; src=&quot;http://dev.clojure.org/jira/images/icons/emoticons/smile.gif&quot; height=&quot;20&quot; width=&quot;20&quot; align=&quot;absmiddle&quot; alt=&quot;&quot; border=&quot;0&quot;/&gt;&lt;/p&gt;</comment>
                    <comment id="30456" author="jafingerhut" created="Fri, 18 Jan 2013 20:39:22 -0600"  >&lt;p&gt;I do not know if or when this patch will be committed to Clojure.&lt;/p&gt;

&lt;p&gt;I can tell you that you can apply the patch to your own local copy of the Clojure source code, and then develop new Clojure patches based upon that version.  The patch that fixes this problem only affects one test file, so it is unlikely to conflict with any changes you develop and submit.&lt;/p&gt;</comment>
                    <comment id="30467" author="mikera" created="Mon, 21 Jan 2013 06:36:19 -0600"  >&lt;p&gt;I can confirm this patch works fine for me on Windows with Maven/Eclipse&lt;/p&gt;

&lt;p&gt;Suggest this patch gets pushed through approval and applied ASAP? It&apos;s a pretty obvious fix that is breaking the build....&lt;/p&gt;</comment>
                    <comment id="30680" author="stu" created="Fri, 1 Mar 2013 12:44:25 -0600"  >&lt;p&gt;This patch is sloppy &amp;#8211; it makes unnecessary whitespace changes in several places.&lt;/p&gt;

&lt;p&gt;Would it be better to make the tests trailing whitespace agnostic?  Otherwise this feels like poking and prodding until the build box is happy.&lt;/p&gt;</comment>
                    <comment id="30686" author="jafingerhut" created="Sat, 2 Mar 2013 14:50:31 -0600"  >&lt;p&gt;Patch clj-1076-fix-tests-on-windows-patch-v2.txt dated Mar 2, 2013 fixes pprint tests on Windows in a different way: Removing all occurrences of carriage return (\r) characters in the output of pprint before comparing it to the expected string.&lt;/p&gt;

&lt;p&gt;I tried simply doing str/trim-newline to remove newlines and carriage returns at the end of the string, but that does not make the tests pass.  They still fail due to carriage returns in the middle of the string.&lt;/p&gt;</comment>
                    <comment id="30687" author="jafingerhut" created="Sat, 2 Mar 2013 14:51:46 -0600"  >&lt;p&gt;Presumptuously changing Approval from Incomplete back to None, since there is a new patch attached that should address the reason it was marked Incomplete.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="11531" name="clj-1076-fix-tests-on-windows-patch-v1.txt" size="3039" author="jafingerhut" created="Sat, 29 Sep 2012 14:27:55 -0500" />
                    <attachment id="11886" name="clj-1076-fix-tests-on-windows-patch-v2.txt" size="1711" author="jafingerhut" created="Sat, 2 Mar 2013 14:50:31 -0600" />
                    <attachment id="11523" name="pprint_test_failures_01b4cb7156.txt" size="25618" author="ivan" created="Wed, 26 Sep 2012 02:34:19 -0500" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10000" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Patch</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10002">Code and Test</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[CLJ-1180] defprotocol doesn&apos;t resolve tag classnames</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1180</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;defprotocol doesn&apos;t resolve tag classnames, this results in exceptions being thrown when the declared protocol uses as a tag an imported class that is not imported in the namespace that uses it.&lt;/p&gt;

&lt;p&gt;user=&amp;gt; (import &apos;clojure.lang.ISeq)&lt;br/&gt;
clojure.lang.ISeq&lt;br/&gt;
user=&amp;gt; (defprotocol p (^ISeq f &lt;span class=&quot;error&quot;&gt;&amp;#91;_&amp;#93;&lt;/span&gt;))&lt;br/&gt;
p&lt;br/&gt;
user=&amp;gt; (ns x)&lt;br/&gt;
nil&lt;br/&gt;
x=&amp;gt; (defn x &lt;span class=&quot;error&quot;&gt;&amp;#91;y&amp;#93;&lt;/span&gt; (let &lt;span class=&quot;error&quot;&gt;&amp;#91;z (user/f y)&amp;#93;&lt;/span&gt; (inc z)))&lt;br/&gt;
CompilerException java.lang.IllegalArgumentException: Unable to resolve classname: ISeq, compiling:(NO_SOURCE_PATH:4:33) &lt;/p&gt;</description>
                <environment></environment>
            <key id="16071">CLJ-1180</key>
            <summary>defprotocol doesn&apos;t resolve tag classnames</summary>
                <type id="1" iconUrl="http://dev.clojure.org/jira/images/icons/bug.gif">Defect</type>
                                <priority id="3" iconUrl="http://dev.clojure.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="bronsa">Nicola Mometto</reporter>
                        <labels>
                    </labels>
                <created>Sun, 10 Mar 2013 14:15:31 -0500</created>
                <updated>Sun, 10 Mar 2013 17:56:10 -0500</updated>
                                    <version>Release 1.5</version>
                <version>Release 1.6</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                <attachments>
                    <attachment id="11905" name="001-CLJ-1180.patch" size="3417" author="bronsa" created="Sun, 10 Mar 2013 15:41:44 -0500" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10000" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Patch</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10002">Code and Test</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[CLJ-1181] clojure.pprint/code-dispatch breaks on certain types of anonymous functions</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1181</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;div class=&quot;preformatted panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;preformattedContent panelContent&quot;&gt;
&lt;pre&gt;(with-out-str 
  (with-pprint-dispatch code-dispatch 
                        (pp/pprint (read-string &quot;(fn* [x] x)&quot;))))
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;
&lt;p&gt;breaks because the format string here: &lt;a href=&quot;https://github.com/clojure/clojure/blob/master/src/clj/clojure/pprint/dispatch.clj#L378&quot;&gt;https://github.com/clojure/clojure/blob/master/src/clj/clojure/pprint/dispatch.clj#L378&lt;/a&gt; expects a sequence. In the case of (fn* &lt;span class=&quot;error&quot;&gt;&amp;#91;x&amp;#93;&lt;/span&gt; x) it is passed a symbol.&lt;/p&gt;</description>
                <environment></environment>
            <key id="16074">CLJ-1181</key>
            <summary>clojure.pprint/code-dispatch breaks on certain types of anonymous functions</summary>
                <type id="1" iconUrl="http://dev.clojure.org/jira/images/icons/bug.gif">Defect</type>
                                <priority id="3" iconUrl="http://dev.clojure.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="devn">Devin Walters</reporter>
                        <labels>
                    </labels>
                <created>Sun, 10 Mar 2013 16:40:11 -0500</created>
                <updated>Mon, 18 Mar 2013 17:40:31 -0500</updated>
                                    <version>Release 1.5</version>
                                                        <due></due>
                    <votes>1</votes>
                        <watches>2</watches>
                        <comments>
                    <comment id="30795" author="hypirion" created="Mon, 18 Mar 2013 17:40:31 -0500"  >&lt;p&gt;I think the main &quot;issue&quot; here resides within the undocumented functionality of fn*. (fn* &lt;span class=&quot;error&quot;&gt;&amp;#91;x&amp;#93;&lt;/span&gt; x) is a semantically working function, but (fn &lt;span class=&quot;error&quot;&gt;&amp;#91;x&amp;#93;&lt;/span&gt; x) expands into (fn* (&lt;span class=&quot;error&quot;&gt;&amp;#91;x&amp;#93;&lt;/span&gt; x)). Anonymous function literals expand into (fn* &lt;span class=&quot;error&quot;&gt;&amp;#91;gensyms&amp;#93;&lt;/span&gt; (...)), and as such, it also accepts expressions like (fn* &lt;span class=&quot;error&quot;&gt;&amp;#91;x&amp;#93;&lt;/span&gt; x). Should pprint pretty print expressions which has used fn* directly, or should it &quot;just&quot; ignore it?&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                                                                                            </customfields>
    </item>

<item>
            <title>[CLJ-865] Macroexpansion discards &amp;form metadata</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-865</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;As discussed in &lt;a href=&quot;http://groups.google.com/group/clojure/browse_thread/thread/2690cb6ca0e8beb8&quot;&gt;http://groups.google.com/group/clojure/browse_thread/thread/2690cb6ca0e8beb8&lt;/a&gt; there is a &quot;surprise factor&quot; when type-hinting an expression that represents a macro, such as with (.length ^String (doto (identity &quot;x&quot;) prn)). Here the doto macro discards the metadata on &amp;amp;form, causing a reflective lookup. This has the effect that while expressions representing function calls can be type-hinted, expressions representing macros in general cannot. The doto macro could be rewritten to respect its &amp;amp;form metadata, but doing this for every macro in existence would be tedious and error-prone. Instead, I propose a change to the compiler, to cause macroexpansion to hang onto the metadata automatically.&lt;/p&gt;

&lt;p&gt;The first patch attached adds a test for the behavior I propose: this test fails. After applying the second patch, the test passes.&lt;/p&gt;

&lt;p&gt;There are a couple points that merit further consideration before accepting my patch:&lt;/p&gt;
&lt;ul class=&quot;alternate&quot; type=&quot;square&quot;&gt;
	&lt;li&gt;I&apos;m not sure I actually got the Java code formatted correctly. My editor is not well-configured to get the clojure/core style right automatically.&lt;/li&gt;
	&lt;li&gt;My solution is to take the &amp;amp;form metadata, drop :line/:file keys, and then merge with the returned metadata, with &amp;amp;form taking precedence. I&apos;m not sure whether this is the right approach in all cases, even though it works for :tag metadata.&lt;/li&gt;
	&lt;li&gt;I achieved this with a change to the compiler, which makes it fairly heavy-weight. It should be possible to instead adjust defmacro if changes to the compiler are not desirable. However, I believe this would involve substantially more work and be harder to test (for example, multiple arities complicate things). It seems nicer to treat the macroexpansion as a black box and then make metadata tweaks to the result, rather than modifying their actual defmacro code.&lt;/li&gt;
	&lt;li&gt;If a macro expands to something that is not an IObj, such as an Integer, then my patch silently discards the caller&apos;s metadata. Would it be better to throw an exception?&lt;/li&gt;
&lt;/ul&gt;
</description>
                <environment></environment>
            <key id="14901">CLJ-865</key>
            <summary>Macroexpansion discards &amp;form metadata</summary>
                <type id="4" iconUrl="http://dev.clojure.org/jira/images/icons/improvement.gif">Enhancement</type>
                                <priority id="3" iconUrl="http://dev.clojure.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="amalloy">Alan Malloy</reporter>
                        <labels>
                        <label>Compiler</label>
                    </labels>
                <created>Wed, 26 Oct 2011 15:19:11 -0500</created>
                <updated>Wed, 6 Jun 2012 17:29:38 -0500</updated>
                                                                            <due></due>
                    <votes>7</votes>
                        <watches>5</watches>
                        <comments>
                    <comment id="27176" author="amalloy" created="Fri, 28 Oct 2011 01:12:50 -0500"  >&lt;p&gt;So I went ahead and did the work of making this change in clojure.core/defmacro instead of clojure.lang.Compiler/macroexpand1. It was even worse than I expected: I didn&apos;t realize we don&apos;t yet have syntax-quote or apply at this stage in bootstrapping, so writing a non-trivial macroexpansion requires a huge amount of (list `foo (list `bar &apos;local-name)) and so forth.&lt;/p&gt;

&lt;p&gt;I&apos;m sure the version I wrote is not optimal, but it seemed simpler to piggyback on defn, and then use alter-var-root to shim the metadata management in, than it would have been to expand to the correct thing in the first place.&lt;/p&gt;

&lt;p&gt;Anyway, attached patch #3 could be applied instead of #2 to resolve the issue in clojure.core instead of clojure.lang. The tests added in patch #1 pass either way.&lt;/p&gt;</comment>
                    <comment id="27286" author="amalloy" created="Sun, 13 Nov 2011 20:29:06 -0600"  >&lt;p&gt;I realized I can do this with a named private function instead of an anonymous function, reducing the amount of mess defmacro itself has to generate. Patch 4 is, I think, strictly better than Patch 3, if a Clojure implementation is preferred to one in Java.&lt;/p&gt;</comment>
                    <comment id="27331" author="chouser@n01se.net" created="Sun, 20 Nov 2011 22:43:45 -0600"  >&lt;p&gt;I prefer patch 0002 in Java over either 0003 or 0004. Patch 0002 keeps the knowledge of how to invoke macro fns (specifically the extra &amp;amp;form and &amp;amp;env args) in one place, macroexpand1 rather than duplicating that knowledge in core.clj as well. Note patch 0001 is just tests.&lt;/p&gt;

&lt;p&gt;The proposed default macroexpansion behavior is more useful than what we currently have, but there are two details I&apos;d like to think about a bit more:&lt;/p&gt;

&lt;p&gt;1) In exchange for a more useful default, macro writers lose the ability to consume their &amp;amp;form metadata and have control over the resulting form metadata without the &amp;amp;form metadata overridding it. That is, macros are no longer in complete control of their output form.&lt;/p&gt;

&lt;p&gt;2) Rule (1) above has hardcoded exceptions for :line and :file, where &amp;amp;form metadata is unable to override the results returned by the macro.&lt;/p&gt;</comment>
                    <comment id="28676" author="amalloy" created="Fri, 1 Jun 2012 14:04:02 -0500"  >&lt;p&gt;This patch incorporates all previous patches to this issue.&lt;/p&gt;

&lt;p&gt;On the clj-dev mailing list, Andy Fingerhut suggested a new metadata key for allowing the macro author to specify &quot;I&apos;ve looked at their &amp;amp;form metadata, and this form is exactly what I want to expand to, please don&apos;t change the metadata any further.&quot; I&apos;ve implemented this, and I think it addresses Chouser&apos;s concern about needing a way to &quot;break out&quot; of the improved-default behavior.&lt;/p&gt;

&lt;p&gt;One open question is, is :explicit-meta the right key to use? I spent some time tracking down a bug caused by my forgetting the keyword and using :explicit-metadata in my test; perhaps something more difficult to get confused by is available.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="10590" name="0001-Add-test-for-macroexpansion-metadata-preservation.patch" size="1258" author="amalloy" created="Wed, 26 Oct 2011 15:19:11 -0500" />
                    <attachment id="10591" name="0002-Preserve-form-metadata-on-macroexpanded-forms.patch" size="1571" author="amalloy" created="Wed, 26 Oct 2011 15:19:11 -0500" />
                    <attachment id="10592" name="0003-Make-defmacro-preserve-form-metadata.patch" size="3898" author="amalloy" created="Fri, 28 Oct 2011 01:12:50 -0500" />
                    <attachment id="10703" name="0004-Another-stab-at-implementing-this.patch" size="3397" author="amalloy" created="Sun, 13 Nov 2011 20:29:06 -0600" />
                    <attachment id="11281" name="updated.patch" size="3824" author="amalloy" created="Fri, 1 Jun 2012 14:04:02 -0500" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10000" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Patch</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10002">Code and Test</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[CLJ-1165] Forbid varargs defprotocol/definterface method declarations because those cannot be defined anyway</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1165</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;Protocol, interface method declarations don&apos;t allow for varags.  Currently, for example&lt;/p&gt;

&lt;div class=&quot;preformatted panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;preformattedContent panelContent&quot;&gt;
&lt;pre&gt;  (defprotocol FooBar
    (foo [this &amp;amp; more]))
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;compiles just fine, and &lt;tt&gt;&amp;amp;&lt;/tt&gt; is interpreted as a usual argument that happens to be&lt;br/&gt;
named &lt;tt&gt;&amp;amp;&lt;/tt&gt; without special meaning.  But clearly, the user wanted to specify a&lt;br/&gt;
varags parameter here.  The same applies to &lt;tt&gt;definterface&lt;/tt&gt;.&lt;/p&gt;

&lt;p&gt;Similarly, providing method implementations via &lt;tt&gt;defrecord&lt;/tt&gt;, &lt;tt&gt;deftype&lt;/tt&gt;, and &lt;tt&gt;reify&lt;/tt&gt;&lt;br/&gt;
don&apos;t allow for varags (but dynamic extensions via &lt;tt&gt;extend&lt;/tt&gt; do).&lt;/p&gt;

&lt;p&gt;So this patch makes &lt;tt&gt;defprotocol&lt;/tt&gt; and &lt;tt&gt;definterface&lt;/tt&gt; throw an&lt;br/&gt;
&lt;tt&gt;IllegalArgumentException&lt;/tt&gt; if a user tries to use varargs in method signatures.&lt;/p&gt;

&lt;p&gt;Similarly, &lt;tt&gt;defrecord&lt;/tt&gt;, &lt;tt&gt;deftype&lt;/tt&gt;, and &lt;tt&gt;reify&lt;/tt&gt; throw an &lt;tt&gt;IllegalArgumentException&lt;/tt&gt; if&lt;br/&gt;
any method implementation arglist contains a varargs argument.&lt;/p&gt;

&lt;p&gt;This patch is a cut-down variant of my patch to &lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-1024&quot;&gt;http://dev.clojure.org/jira/browse/CLJ-1024&lt;/a&gt;&lt;br/&gt;
which has been reverted shortly before Clojure 1.5 was released.  The &lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-1024&quot; title=&quot;Varargs protococol impls can be defined but not called&quot;&gt;&lt;del&gt;CLJ-1024&lt;/del&gt;&lt;/a&gt; patch&lt;br/&gt;
was the same as this one, but it has also forbidden destructuring in &lt;tt&gt;defprotocol&lt;/tt&gt; and&lt;br/&gt;
&lt;tt&gt;definterface&lt;/tt&gt;.  This was a bit too much, because although destructuring has no&lt;br/&gt;
semantic meaning with method declarations, it still can serve a documentation purpose.&lt;/p&gt;

&lt;p&gt;This has been discussed on the list: &lt;a href=&quot;https://groups.google.com/d/topic/clojure-dev/qjkW-cv8nog/discussion&quot;&gt;https://groups.google.com/d/topic/clojure-dev/qjkW-cv8nog/discussion&lt;/a&gt;&lt;/p&gt;</description>
                <environment></environment>
            <key id="16015">CLJ-1165</key>
            <summary>Forbid varargs defprotocol/definterface method declarations because those cannot be defined anyway</summary>
                <type id="4" iconUrl="http://dev.clojure.org/jira/images/icons/improvement.gif">Enhancement</type>
                                <priority id="3" iconUrl="http://dev.clojure.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="stu">Stuart Halloway</assignee>
                                <reporter username="tsdh">Tassilo Horn</reporter>
                        <labels>
                        <label>enhancement</label>
                        <label>patch</label>
                    </labels>
                <created>Fri, 15 Feb 2013 02:13:32 -0600</created>
                <updated>Thu, 4 Apr 2013 19:24:27 -0500</updated>
                                                                            <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                        <comments>
                    <comment id="30834" author="stu" created="Fri, 29 Mar 2013 05:27:06 -0500"  >&lt;p&gt;I think that this patch would be much more helpful to users if it reported the problem form (both name and params). &lt;/p&gt;

&lt;p&gt;(And I wonder if we should be using ex-info for all errors going forward.)&lt;/p&gt;</comment>
                    <comment id="30853" author="tsdh" created="Sun, 31 Mar 2013 05:17:34 -0500"  >&lt;p&gt;New version of the patch that mentions both method name and argument vector, and uses ex-info as Stu suggested.&lt;/p&gt;</comment>
                    <comment id="30874" author="jafingerhut" created="Thu, 4 Apr 2013 19:24:27 -0500"  >&lt;p&gt;Presumuptuously changing Approval from Incomplete back to None, since the reason for marking it Incomplete seems to have been addressed with a new patch.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="11933" name="0001-Protocol-interface-method-declarations-don-t-allow-f.patch" size="3236" author="tsdh" created="Sun, 31 Mar 2013 05:17:34 -0500" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10000" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Patch</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10001">Code</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[CLJ-1093] Empty record literals gets incorrectly evaluated to array-maps</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1093</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;before patch:&lt;br/&gt;
user=&amp;gt; (defrecord a &lt;span class=&quot;error&quot;&gt;&amp;#91;b&amp;#93;&lt;/span&gt;)&lt;br/&gt;
user.a&lt;br/&gt;
user=&amp;gt; #user.a{}&lt;br/&gt;
{}&lt;/p&gt;

&lt;p&gt;after patch:&lt;br/&gt;
user=&amp;gt; (defrecord a &lt;span class=&quot;error&quot;&gt;&amp;#91;b&amp;#93;&lt;/span&gt;)&lt;br/&gt;
user.a&lt;br/&gt;
user=&amp;gt; #user.a{}&lt;br/&gt;
#user.a{:b nil}&lt;/p&gt;</description>
                <environment></environment>
            <key id="15776">CLJ-1093</key>
            <summary>Empty record literals gets incorrectly evaluated to array-maps</summary>
                <type id="1" iconUrl="http://dev.clojure.org/jira/images/icons/bug.gif">Defect</type>
                                <priority id="3" iconUrl="http://dev.clojure.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="4" iconUrl="http://dev.clojure.org/jira/images/icons/status_reopened.gif">Reopened</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="halgari">Timothy Baldridge</assignee>
                                <reporter username="bronsa">Nicola Mometto</reporter>
                        <labels>
                    </labels>
                <created>Wed, 24 Oct 2012 09:13:56 -0500</created>
                <updated>Wed, 13 Mar 2013 14:04:29 -0500</updated>
                                    <version>Release 1.4</version>
                <version>Release 1.5</version>
                                                        <due></due>
                    <votes>2</votes>
                        <watches>1</watches>
                        <comments>
                    <comment id="30052" author="halgari" created="Tue, 27 Nov 2012 11:41:24 -0600"  >&lt;p&gt;Unable to reproduce this bug on latest version of master. Most likely fixed by some of the recent changes to data literal readers. &lt;/p&gt;

&lt;p&gt;Marking Not-Approved. &lt;/p&gt;</comment>
                    <comment id="30053" author="halgari" created="Tue, 27 Nov 2012 11:41:53 -0600"  >&lt;p&gt;Could not reproduce in master. &lt;/p&gt;</comment>
                    <comment id="30681" author="bronsa" created="Fri, 1 Mar 2013 13:23:09 -0600"  >&lt;p&gt;I just checked, and the problem still exists for records with no arguments:&lt;/p&gt;

&lt;p&gt;Clojure 1.6.0-master-SNAPSHOT&lt;br/&gt;
user=&amp;gt; (defrecord a [])&lt;br/&gt;
user.a&lt;br/&gt;
user=&amp;gt; #user.a[]&lt;br/&gt;
{}&lt;/p&gt;

&lt;p&gt;Admittedly it&apos;s an edge case and I see little usage for no-arguments records, but I think it should be addressed aswell since the current behaviour is not what one would expect&lt;/p&gt;</comment>
                    <comment id="30685" author="bendlas" created="Sat, 2 Mar 2013 08:14:28 -0600"  >&lt;p&gt;Got the following REPL interaction:&lt;/p&gt;

&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;% java -jar ~/.m2/repository/org/clojure/clojure/1.5.0/clojure-1.5.0.jar
user=&amp;gt; (defrecord a [])
user.a
user=&amp;gt; (a.)
#user.a{}
user=&amp;gt; #user.a{}
{}
#user.a[]
{}&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;This should be reopened or declined for another reason than reproducability.&lt;/p&gt;</comment>
                    <comment id="30721" author="bronsa" created="Sun, 10 Mar 2013 14:18:03 -0500"  >&lt;p&gt;I&apos;m reopening this since the bug is still there.&lt;/p&gt;
</comment>
                    <comment id="30759" author="jafingerhut" created="Wed, 13 Mar 2013 14:04:29 -0500"  >&lt;p&gt;Patch clj-1093-fix-empty-record-literal-patch-v2.txt dated Mar 13, 2013 is identical to Bronsa&apos;s patch 001-fix-empty-record-literal.patch dated Oct 24, 2012, except that it applies cleanly to latest master.  I&apos;m not sure why the older patch doesn&apos;t but git doesn&apos;t like something about it.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="11609" name="001-fix-empty-record-literal.patch" size="2007" author="bronsa" created="Wed, 24 Oct 2012 09:19:36 -0500" />
                    <attachment id="11914" name="clj-1093-fix-empty-record-literal-patch-v2.txt" size="1771" author="jafingerhut" created="Wed, 13 Mar 2013 14:04:29 -0500" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10000" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Patch</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10002">Code and Test</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[CLJ-1197] Allow fold to parallelize over lazy sequences</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1197</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;This patch implements &lt;tt&gt;foldable-seq&lt;/tt&gt;, which allows fold to parallelize over a lazy sequence. See this conversation on the Clojure mailing list:&lt;/p&gt;

&lt;p&gt;&lt;a href=&quot;https://groups.google.com/forum/#!msg/clojure/8RKCjF00ukQ/b5mmmOB5Uh4J&quot;&gt;https://groups.google.com/forum/#!msg/clojure/8RKCjF00ukQ/b5mmmOB5Uh4J&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;The patch is code only, sadly. No tests because I&apos;ve not been able to find any existing tests for &lt;tt&gt;fold&lt;/tt&gt;:&lt;/p&gt;

&lt;p&gt;&lt;a href=&quot;https://groups.google.com/d/msg/clojure-dev/plQ16L1_FC0/CIyMVIgSZkkJ&quot;&gt;https://groups.google.com/d/msg/clojure-dev/plQ16L1_FC0/CIyMVIgSZkkJ&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;However, I have tested it in a separate project successfully.&lt;/p&gt;</description>
                <environment></environment>
            <key id="16137">CLJ-1197</key>
            <summary>Allow fold to parallelize over lazy sequences</summary>
                <type id="4" iconUrl="http://dev.clojure.org/jira/images/icons/improvement.gif">Enhancement</type>
                                <priority id="3" iconUrl="http://dev.clojure.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="paulbutcher">Paul Butcher</reporter>
                        <labels>
                    </labels>
                <created>Wed, 10 Apr 2013 10:34:09 -0500</created>
                <updated>Wed, 10 Apr 2013 10:34:09 -0500</updated>
                                                                            <due></due>
                    <votes>0</votes>
                        <watches>1</watches>
                                <attachments>
                    <attachment id="11951" name="foldable-seq.diff" size="1774" author="paulbutcher" created="Wed, 10 Apr 2013 10:34:09 -0500" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10000" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Patch</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10001">Code</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[CLJ-1036] Util/hasheq should be hashing a BigInteger to the same values as Long, and BigInt</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1036</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;The doc string for &lt;tt&gt;hash&lt;/tt&gt; states that it defines a hash code function that is consistent with &lt;tt&gt;=&lt;/tt&gt;, but for java.math.BigInteger &lt;tt&gt;hash&lt;/tt&gt; is not consistent with &lt;tt&gt;=&lt;/tt&gt;.&lt;/p&gt;

&lt;div class=&quot;preformatted panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;preformattedContent panelContent&quot;&gt;
&lt;pre&gt;user=&amp;gt; (apply = [(Long. -1) -1N (biginteger -1)])
true
user=&amp;gt; (map hash [(Long. -1) -1N (biginteger -1)])
(0 0 -1)
user=&amp;gt;
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;It is possible to have a PHM with two key/value pairs where the keys are equal, and the hash codes are different:&lt;/p&gt;

&lt;div class=&quot;preformatted panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;preformattedContent panelContent&quot;&gt;
&lt;pre&gt;user=&amp;gt; (assoc clojure.lang.PersistentHashMap/EMPTY (biginteger -1) :oops! -1N :one)
{-1N :one, -1 :oops!}
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;The expected behavior is the same as PersistentArrayMap, which does not have this issue, because it does not hash its keys:&lt;/p&gt;

&lt;div class=&quot;preformatted panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;preformattedContent panelContent&quot;&gt;
&lt;pre&gt;user=&amp;gt; (assoc clojure.lang.PersistentArrayMap/EMPTY (biginteger -1) :oops! -1N :one)
{-1 :one}
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;This same misbehavior also occurs for Doubles and Floats:&lt;/p&gt;

&lt;div class=&quot;preformatted panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;preformattedContent panelContent&quot;&gt;
&lt;pre&gt;thalia.core=&amp;gt; (apply = [(Float. 1e9) (Double. 1e9)])
true
thalia.core=&amp;gt; (map hash [(Float. 1e9) (Double. 1e9)])
(1315859240 1104006501)
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;That leads to the same difference in array-map and hash-map behavior as above for BigInteger and BigInt.&lt;/p&gt;</description>
                <environment></environment>
            <key id="15610">CLJ-1036</key>
            <summary>Util/hasheq should be hashing a BigInteger to the same values as Long, and BigInt</summary>
                <type id="1" iconUrl="http://dev.clojure.org/jira/images/icons/bug.gif">Defect</type>
                                <priority id="3" iconUrl="http://dev.clojure.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="pjstadig">Paul Stadig</reporter>
                        <labels>
                    </labels>
                <created>Thu, 2 Aug 2012 08:41:17 -0500</created>
                <updated>Fri, 12 Apr 2013 08:48:23 -0500</updated>
                                    <version>Release 1.4</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>1</watches>
                        <comments>
                    <comment id="29076" author="pjstadig" created="Thu, 2 Aug 2012 09:55:54 -0500"  >&lt;p&gt;Also, the biginteger function has metadata saying that it has been added since 1.0, but it was actually added in 1.3.  The bigint function has metadata saying that it has been added since 1.3, but it has been added since 1.0.&lt;/p&gt;

&lt;p&gt;I think during the work to implement BigInt someone renamed the existing bigint function (which used to return a BigInteger) to biginteger, and the metadata got carried with it, then a new bigint function was added with :since 1.3 metadata even though that function name has existed since 1.0.&lt;/p&gt;</comment>
                    <comment id="29533" author="jafingerhut" created="Wed, 26 Sep 2012 11:59:08 -0500"  >&lt;p&gt;clj-1036-hasheq-for-biginteger-patch-v1.txt dated Sep 26 2012 makes BigInteger&apos;s return equal hash values for values considered equal by =.&lt;/p&gt;

&lt;p&gt;It does the same for Float and Double types, which before returned different hash values for values considered equal by =&lt;/p&gt;

&lt;p&gt;I went ahead and changed the :added metadata on bigint and biginteger, although I can see that without my change, the person who did that may have meant for the :added to go with the behavior of the function, not with the name.  Paul&apos;s suggested change that I have in the patch is for the :added metadata to go with the name, not the function behavior.  It is easy to remove that part of the patch if that change is not desired.&lt;/p&gt;</comment>
                    <comment id="29934" author="richhickey" created="Tue, 13 Nov 2012 15:29:12 -0600"  >&lt;p&gt;You can&apos;t just consider only the lower long of bigints. Also, what&apos;s the rationale for the float stuff?&lt;/p&gt;</comment>
                    <comment id="29938" author="jafingerhut" created="Tue, 13 Nov 2012 21:44:14 -0600"  >&lt;p&gt;clj-1036-hasheq-for-biginteger-patch-v2.txt dated Nov 13 2012 is identical to clj-1036-hasheq-for-biginteger-patch-v1.txt except that it addresses Rich&apos;s comment that for BigInt&apos;s and BigInteger values that don&apos;t fit in a long, their entire value must be hashed.&lt;/p&gt;

&lt;p&gt;The rationale for the changes to hasheq for Float and Double types is the same as the rationale for the change for BigInteger: without that change, Float and Double types that are = can have different hasheq values.&lt;/p&gt;</comment>
                    <comment id="29939" author="pjstadig" created="Wed, 14 Nov 2012 05:18:58 -0600"  >&lt;p&gt;Although you are correct that Double and Float are &lt;tt&gt;=&lt;/tt&gt;, but have different hashes:&lt;/p&gt;

&lt;div class=&quot;preformatted panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;preformattedContent panelContent&quot;&gt;
&lt;pre&gt;user=&amp;gt; (apply = [(Double. -1.0) (Float. -1.0)])
true
user=&amp;gt; (map hash [(Double. -1.0) (Float. -1.0)])
(-1074790400 -1082130432)
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;I could not get the same errant behavior out of PHM:&lt;/p&gt;

&lt;div class=&quot;preformatted panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;preformattedContent panelContent&quot;&gt;
&lt;pre&gt;user=&amp;gt; (assoc clojure.lang.PersistentHashMap/EMPTY (Float. -1.0) :oops! (Double. -1.0) :one)
{-1.0 :one}
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;I haven&apos;t taken the time to investigate exactly what is happening here, but either way I think this ticket is very specifically about BigInteger and the Float/Double issue could be explored in another ticket.&lt;/p&gt;</comment>
                    <comment id="29943" author="jafingerhut" created="Wed, 14 Nov 2012 10:08:59 -0600"  >&lt;p&gt;I can open another ticket for the Float/Double issue if that is what people would prefer.&lt;/p&gt;

&lt;p&gt;I think what is happening in the test case you give, Paul, is that the hash values for (Float. -1.0) and (Double. -1.0) happen to be the same in their least significant 20 bits, and PHM isn&apos;t using the upper bits where the hash values differ.&lt;/p&gt;

&lt;p&gt;Clojure 1.5.0-beta without patch:&lt;br/&gt;
user=&amp;gt; (map #(format &quot;%x&quot; %) (map hash &lt;span class=&quot;error&quot;&gt;&amp;#91;(Float. -1.0) (Double. -1.0)&amp;#93;&lt;/span&gt;))&lt;br/&gt;
(&quot;bf800000&quot; &quot;bff00000&quot;)&lt;/p&gt;

&lt;p&gt;There are other Float/Double values where this lucky accident doesn&apos;t happen, e.g.&lt;/p&gt;

&lt;p&gt;Clojure 1.5.0-beta1 without patch:&lt;/p&gt;

&lt;p&gt;user=&amp;gt; (= (Float. 1e9) (Double. 1e9))&lt;br/&gt;
true&lt;br/&gt;
user=&amp;gt; (map hash &lt;span class=&quot;error&quot;&gt;&amp;#91;(Float. 1e9) (Double. 1e9)&amp;#93;&lt;/span&gt;)&lt;br/&gt;
(1315859240 1104006501)&lt;br/&gt;
user=&amp;gt; (assoc clojure.lang.PersistentHashMap/EMPTY (Float. 1e9) :oops! (Double. 1e9) :one)&lt;/p&gt;
{1.0E9 :one, 1.0E9 :oops!}

&lt;p&gt;With 1.5.0-beta1 plus patch clj-1036-hasheq-for-biginteger-patch-v2.txt:&lt;/p&gt;

&lt;p&gt;user=&amp;gt; (= (Float. 1e9) (Double. 1e9))&lt;br/&gt;
true&lt;br/&gt;
user=&amp;gt; (map hash &lt;span class=&quot;error&quot;&gt;&amp;#91;(Float. 1e9) (Double. 1e9)&amp;#93;&lt;/span&gt;)&lt;br/&gt;
(1315859240 1315859240)&lt;br/&gt;
user=&amp;gt; (assoc clojure.lang.PersistentHashMap/EMPTY (Float. 1e9) :oops! (Double. 1e9) :one)&lt;/p&gt;
{1.0E9 :one}</comment>
                    <comment id="30341" author="jafingerhut" created="Tue, 1 Jan 2013 11:30:41 -0600"  >&lt;p&gt;Presumptuously changing status from Not Approved to Vetted, since patch clj-1036-hasheq-for-biginteger-patch-v2.txt should address the reasons that Rich marked the previous patch as Not Approved.  Changing it to Vetted on the assumption that if Stuart Halloway marked the previous patch as Screened, the ticket itself is good enough to be Vetted.&lt;/p&gt;</comment>
                    <comment id="30939" author="richhickey" created="Fri, 12 Apr 2013 08:48:23 -0500"  >&lt;p&gt;Patches and tickets need to be better than this. Talks about BigInteger, changes hash for doubles. Lists problem but not approach, need to trawl through comments and code to see what&apos;s going on, etc.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="11674" name="clj-1036-hasheq-for-biginteger-patch-v2.txt" size="3639" author="jafingerhut" created="Tue, 13 Nov 2012 21:44:14 -0600" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_10002" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Approval</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10008">Not Approved</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                    <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10000" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Patch</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10002">Code and Test</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[CLJ-1157] Classes generated by gen-class aren&apos;t loadable from remote codebase for mis-implementation of static-initializer</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1157</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;When a client program uses a remote service which uses RMI, and the service returns a object which created with gen-class with clojure as the return value, the return value is not loadable at client side.&lt;/p&gt;

&lt;p&gt;At client side, a following exeption will be thrown.&lt;/p&gt;

&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;Exception in thread &lt;span class=&quot;code-quote&quot;&gt;&quot;main&quot;&lt;/span&gt; java.lang.ExceptionInInitializerError
        at java.io.ObjectStreamClass.hasStaticInitializer(Native Method)
        at java.io.ObjectStreamClass.computeDefaultSUID(ObjectStreamClass.java:1723)
        at java.io.ObjectStreamClass.access$100(ObjectStreamClass.java:69)
        at java.io.ObjectStreamClass$1.run(ObjectStreamClass.java:247)
        at java.io.ObjectStreamClass$1.run(ObjectStreamClass.java:245)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.io.ObjectStreamClass.getSerialVersionUID(ObjectStreamClass.java:244)
        at java.io.ObjectStreamClass.initNonProxy(ObjectStreamClass.java:600)
        at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1601)
        at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1514)
        at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1750)
        at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1347)
        at java.io.ObjectInputStream.readObject(ObjectInputStream.java:369)
        at sun.rmi.server.UnicastRef.unmarshalValue(UnicastRef.java:324)
        at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:173)
        at java.rmi.server.RemoteObjectInvocationHandler.invokeRemoteMethod(RemoteObjectInvocationHandler.java:194)
        at java.rmi.server.RemoteObjectInvocationHandler.invoke(RemoteObjectInvocationHandler.java:148)
        at $Proxy0.getResult(Unknown Source)
        at client.SampleClient$_main.doInvoke(SampleClient.clj:12)
        at clojure.lang.RestFn.invoke(RestFn.java:397)
        at clojure.lang.AFn.applyToHelper(AFn.java:159)
        at clojure.lang.RestFn.applyTo(RestFn.java:132)
        at client.SampleClient.main(Unknown Source)
 Caused by: java.io.FileNotFoundException: Could not locate remoteserver/SampleInterfaceImpl__init.class or remoteserver/SampleInterfaceImpl.clj on classpath: 
        at clojure.lang.RT.load(RT.java:434)
        at clojure.lang.RT.load(RT.java:402)
        at clojure.core$load$fn__5039.invoke(core.clj:5520)
        at clojure.core$load.doInvoke(core.clj:5519)
        at clojure.lang.RestFn.invoke(RestFn.java:408)
        at clojure.lang.Var.invoke(Var.java:415)
        at remoteserver.SampleInterfaceImpl.&amp;lt;clinit&amp;gt;(Unknown Source)
        ... 23 more&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;h2&gt;&lt;a name=&quot;HOWTOREPRODUCTTHISISSUE&quot;&gt;&lt;/a&gt;HOW TO REPRODUCT THIS ISSUE&lt;/h2&gt;

&lt;p&gt;If you want to see this issue at your computer, clone my example project from my github.&lt;/p&gt;

&lt;p&gt;git clone git://github.com/tyano/clojure_genclass_fix.git&lt;/p&gt;

&lt;p&gt;and build them (You must have installed Leiningen 2):&lt;/p&gt;

&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-none&quot;&gt;cd clojure_genclass_fix
sh build.sh&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;start rmiregistry:&lt;/p&gt;

&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-none&quot;&gt;rmiregistry &amp;amp;&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;start remoteserver:&lt;/p&gt;

&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-none&quot;&gt;cd remoteserver
sh start.sh&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;You will see a message &quot;Server ready. &quot; or &quot;Server ready. (rebind)&quot;.&lt;/p&gt;

&lt;p&gt;At last, start client program:&lt;/p&gt;

&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-none&quot;&gt;cd ../client
sh start.sh&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;Without my patch, you will see a same Exception described above. But with clojure with my patch, you will see a right response message: &quot;response = this is sample.&quot;&lt;/p&gt;


&lt;h2&gt;&lt;a name=&quot;THEREASON&quot;&gt;&lt;/a&gt;THE REASON        &lt;/h2&gt;

&lt;p&gt;The reason of this problem is in bytecodes generated by gen-class. A gen-classed class (in this case, SampleInterfaceImpl.class) uses a static-initializer for loading SampleInterfaceImpl__init.class (which load other classes which implements functions in the class). The static-initializer is like bellow: (the following code is decompiled with JD - &lt;a href=&quot;http://java.decompiler.free.fr/?q=jdgui&quot;&gt;http://java.decompiler.free.fr/?q=jdgui&lt;/a&gt; )&lt;/p&gt;

&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;&lt;span class=&quot;code-keyword&quot;&gt;static&lt;/span&gt;
  {
    RT.&lt;span class=&quot;code-keyword&quot;&gt;var&lt;/span&gt;(&lt;span class=&quot;code-quote&quot;&gt;&quot;clojure.core&quot;&lt;/span&gt;, &lt;span class=&quot;code-quote&quot;&gt;&quot;load&quot;&lt;/span&gt;).invoke(&lt;span class=&quot;code-quote&quot;&gt;&quot;/remoteserver/SampleInterfaceImpl&quot;&lt;/span&gt;);
  }&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;Very simple code. it seems non-problematic. But RT.load changes the classloader for loading __init.class in the processing! RT.load in default uses a context-classloader for loading classes. But all classes depending on a gen-classed class must be loaded a same classloader with a main gen-classed class. In this case, RT.load must use a remote URLClassLoader which load a main class.&lt;/p&gt;

&lt;p&gt;So, gen-class must be create bytecodes that is same with the following java code.&lt;/p&gt;

&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;&lt;span class=&quot;code-keyword&quot;&gt;static&lt;/span&gt;
  {
    Var.pushThreadBindings(RT.map(&lt;span class=&quot;code-keyword&quot;&gt;new&lt;/span&gt; &lt;span class=&quot;code-object&quot;&gt;Object&lt;/span&gt;[] { &lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;.LOADER, SampleInterfaceImpl.class.getClassLoader() }));
    &lt;span class=&quot;code-keyword&quot;&gt;try&lt;/span&gt; {
        RT.&lt;span class=&quot;code-keyword&quot;&gt;var&lt;/span&gt;(&lt;span class=&quot;code-quote&quot;&gt;&quot;clojure.core&quot;&lt;/span&gt;, &lt;span class=&quot;code-quote&quot;&gt;&quot;load&quot;&lt;/span&gt;).invoke(&lt;span class=&quot;code-quote&quot;&gt;&quot;/remoteserver/SampleInterfaceImpl&quot;&lt;/span&gt;);
    }
    &lt;span class=&quot;code-keyword&quot;&gt;finally&lt;/span&gt; 
    {
        Var.popThreadBindings();
    }
  }&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;With this code, RT.load will uses a same classloader which load SampleInterfaceImpl.class.&lt;br/&gt;
My patch for gen-class will create bytecodes equal to the above example.&lt;/p&gt;

&lt;p&gt;You can use an attached patch &apos;20130204_fix_classloader.diff&apos;, or pull &apos;fix_classloader&apos; branch from my github repositry ( git@github.com:tyano/clojure.git ).&lt;/p&gt;</description>
                <environment>Tested on Mac OS X 10.8 and Oracle JVM 1.7.0 update 13.</environment>
            <key id="15988">CLJ-1157</key>
            <summary>Classes generated by gen-class aren&apos;t loadable from remote codebase for mis-implementation of static-initializer</summary>
                <type id="1" iconUrl="http://dev.clojure.org/jira/images/icons/bug.gif">Defect</type>
                                <priority id="3" iconUrl="http://dev.clojure.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="tyano">Tsutomu Yano</reporter>
                        <labels>
                    </labels>
                <created>Mon, 4 Feb 2013 01:06:21 -0600</created>
                <updated>Fri, 12 Apr 2013 09:19:05 -0500</updated>
                                    <version>Release 1.4</version>
                <version>Release 1.5</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>1</watches>
                        <comments>
                    <comment id="30675" author="stu" created="Fri, 1 Mar 2013 10:20:27 -0600"  >&lt;p&gt;This sounds reasonable, but anything touching classloaders must be considered very carefully.&lt;/p&gt;</comment>
                    <comment id="30679" author="stu" created="Fri, 1 Mar 2013 12:12:09 -0600"  >&lt;p&gt;It seems overly complex to have the patch do so much code generation.  Why not implement a method that does this job, and have the generated code call that?&lt;/p&gt;
</comment>
                </comments>
                    <attachments>
                    <attachment id="11832" name="20130204_fix_classloader.diff" size="4563" author="tyano" created="Mon, 4 Feb 2013 01:06:21 -0600" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_10002" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Approval</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10003">Vetted</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                    <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10000" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Patch</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10001">Code</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[CLJ-1205] Update Maven build for Nexus 2.4</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1205</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;These additions to the build configuration are necessary to support changes to the Sonatype Nexus server at oss.sonatype.org, which we use to promote our build artifacts into the Maven Central Repository.&lt;/p&gt;

&lt;p&gt;See Sonatype&apos;s announcement at &lt;a href=&quot;https://groups.google.com/d/msg/clojure-dev/lBpfII2u6vM/LQvr_rO5UGgJ&quot;&gt;https://groups.google.com/d/msg/clojure-dev/lBpfII2u6vM/LQvr_rO5UGgJ&lt;/a&gt;&lt;/p&gt;</description>
                <environment></environment>
            <key id="16155">CLJ-1205</key>
            <summary>Update Maven build for Nexus 2.4</summary>
                <type id="3" iconUrl="http://dev.clojure.org/jira/images/icons/task.gif">Task</type>
                                <priority id="3" iconUrl="http://dev.clojure.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="stuart.sierra">Stuart Sierra</assignee>
                                <reporter username="stuart.sierra">Stuart Sierra</reporter>
                        <labels>
                    </labels>
                <created>Mon, 22 Apr 2013 20:29:15 -0500</created>
                <updated>Mon, 22 Apr 2013 20:29:15 -0500</updated>
                                                                            <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                <attachments>
                    <attachment id="11967" name="0001-nexus-2.4-releases.patch" size="2692" author="stuart.sierra" created="Mon, 22 Apr 2013 20:29:15 -0500" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[CLJ-1118] inconsistent numeric comparison semantics between BigDecimal and other Numerics</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1118</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;user&amp;gt; &lt;b&gt;clojure-version&lt;/b&gt;&lt;br/&gt;
{:major 1, :minor 5, :incremental 0, :qualifier &quot;beta1&quot;}&lt;br/&gt;
user&amp;gt; (== 2.0 2.0M)&lt;br/&gt;
true&lt;br/&gt;
user&amp;gt; (== 2 2.0M)&lt;br/&gt;
false                  &amp;lt;-- this one is not like the others&lt;br/&gt;
user&amp;gt; (== 2 2.0)&lt;br/&gt;
true&lt;br/&gt;
user&amp;gt; (== 2N 2.0)&lt;br/&gt;
true&lt;br/&gt;
user&amp;gt; (== 2 (double 2.0M))&lt;br/&gt;
true&lt;/p&gt;


&lt;p&gt;It&apos;s not clear if this is a bug or an enhancement request, Should BigDecimal&apos;s be special in comparason to their smaller equivalents?&lt;/p&gt;</description>
                <environment></environment>
            <key id="15867">CLJ-1118</key>
            <summary>inconsistent numeric comparison semantics between BigDecimal and other Numerics</summary>
                <type id="1" iconUrl="http://dev.clojure.org/jira/images/icons/bug.gif">Defect</type>
                                <priority id="3" iconUrl="http://dev.clojure.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="arthurulfeldt">Arthur Ulfeldt</reporter>
                        <labels>
                    </labels>
                <created>Fri, 30 Nov 2012 13:36:57 -0600</created>
                <updated>Thu, 25 Apr 2013 19:58:50 -0500</updated>
                                    <version>Release 1.4</version>
                <version>Release 1.5</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                        <comments>
                    <comment id="30113" author="arthurulfeldt" created="Fri, 30 Nov 2012 13:51:10 -0600"  >&lt;p&gt;I understand that the definition of equality between bigDecimals is dependent on both value and scale as in this case:&lt;/p&gt;

&lt;p&gt;user&amp;gt; (== 0.000000M 0.0M)&lt;br/&gt;
false&lt;/p&gt;

&lt;p&gt;I just want to make sure the decission to propagate that semantic across types is intentional. If this is on purpose than this is not a bug.&lt;/p&gt;</comment>
                    <comment id="30114" author="arthurulfeldt" created="Fri, 30 Nov 2012 14:03:16 -0600"  >&lt;p&gt;this could be fixed by calling stripTrailingZeros on bigDecimals before comparing them to Longs or BigInts.  &lt;/p&gt;

&lt;p&gt;(== 2 (double (. 2.0M stripTrailingZeros)))&lt;br/&gt;
true&lt;/p&gt;

&lt;p&gt;Edited by Andy Fingerhut: Unfortunately that fails for BigDecimal values equal to 0, unless they happen to have a scale that matches what you are comparing it to.&lt;/p&gt;

&lt;p&gt;I think a more complete solution is to use BigDecimal&apos;s compareTo method, e.g.:&lt;/p&gt;

&lt;p&gt;(zero? (.compareTo 2.0M (bigdec 2)))&lt;br/&gt;
true&lt;/p&gt;</comment>
                    <comment id="30166" author="halgari" created="Mon, 3 Dec 2012 11:31:33 -0600"  >&lt;p&gt;It seems we need some more eyes on this issue, can you bring this up on clojure-dev and see what they think?&lt;/p&gt;</comment>
                    <comment id="30959" author="jafingerhut" created="Sun, 14 Apr 2013 04:03:23 -0500"  >&lt;p&gt;Patch clj-1118-make-double-equals-true-for-more-bigdecimals-patch-v1.txt dated Apr 14 2013 changes equiv for BigDecimals so that instead of using BigDecimal.equals(), it uses BigDecimal.compareTo() and checks the return value is equal to 0.&lt;/p&gt;

&lt;p&gt;The Java docs for these methods explicitly state that BigDecimal.equals() will treat values that are otherwise equal numerically, but differ in scale, as not equal.&lt;/p&gt;

&lt;p&gt;They also say that BigDecimal.compareTo() will return 0 for such BigDecimals.&lt;/p&gt;

&lt;p&gt;I&apos;m not sure if this is the preferred behavior for Clojure, but if it is, this patch should do it.&lt;/p&gt;</comment>
                    <comment id="30961" author="jafingerhut" created="Mon, 15 Apr 2013 00:18:55 -0500"  >&lt;p&gt;clj-1118-make-double-equals-true-for-more-bigdecimals-patch-v2.txt dated Apr 14 2013 is same as clj-1118-make-double-equals-true-for-more-bigdecimals-patch-v1.txt described in previous comment, except it also has some new tests included.&lt;/p&gt;</comment>
                    <comment id="30963" author="jafingerhut" created="Mon, 15 Apr 2013 21:07:44 -0500"  >&lt;p&gt;clj-1118-make-double-equals-true-for-more-bigdecimals-patch-v3.txt dated Apr 15 2013 is the same as the the previous patch clj-1118-make-double-equals-true-for-more-bigdecimals-patch-v2.txt, except for the following:&lt;/p&gt;

&lt;p&gt;By changing == behavior for BigDecimal by modifying the BigDecimalOps.equiv() method, that also changes the behavior of = when comparing BigDecimal values to other numbers.  hash should be consistent with =, so now hash should return same value for all numerically equal BigDecimal values.  This patch should achieve that.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="11960" name="clj-1118-make-double-equals-true-for-more-bigdecimals-patch-v3.txt" size="4136" author="jafingerhut" created="Mon, 15 Apr 2013 21:07:44 -0500" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10000" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Patch</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10002">Code and Test</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[CLJ-1208] Namespace is not loaded on defrecord class init</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1208</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;As a user of Clojure interop from Java, I want defrecords (and deftypes?) to load their namespaces upon class initialization so that I can simply construct and use AOT&apos;d record classes without manually requiring their namespaces first.&lt;/p&gt;

&lt;p&gt;Calling the defrecord&apos;s constructor may or may not result in &quot;Attempting to call unbound fn&quot; exceptions, depending on what code has already been run.&lt;/p&gt;

&lt;p&gt;This issue has been raised several times over the years, but I could not find an existing ticket for it:&lt;/p&gt;

&lt;ul&gt;
	&lt;li&gt;&lt;a href=&quot;https://groups.google.com/d/msg/clojure-dev/4CtSVWcD15A/shpMuyjMpxsJ&quot;&gt;https://groups.google.com/d/msg/clojure-dev/4CtSVWcD15A/shpMuyjMpxsJ&lt;/a&gt;&lt;/li&gt;
	&lt;li&gt;&lt;a href=&quot;https://groups.google.com/d/msg/clojure/3DekTQZfDTk/wlssZL7EQWEJ&quot;&gt;https://groups.google.com/d/msg/clojure/3DekTQZfDTk/wlssZL7EQWEJ&lt;/a&gt;&lt;/li&gt;
	&lt;li&gt;&lt;a href=&quot;https://groups.google.com/d/msg/clojure/K4gfjrLe8GA/OnB5g4SU0l8J&quot;&gt;https://groups.google.com/d/msg/clojure/K4gfjrLe8GA/OnB5g4SU0l8J&lt;/a&gt;&lt;/li&gt;
&lt;/ul&gt;
</description>
                <environment></environment>
            <key id="16176">CLJ-1208</key>
            <summary>Namespace is not loaded on defrecord class init</summary>
                <type id="1" iconUrl="http://dev.clojure.org/jira/images/icons/bug.gif">Defect</type>
                                <priority id="3" iconUrl="http://dev.clojure.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="timmc">Tim McCormack</reporter>
                        <labels>
                    </labels>
                <created>Fri, 3 May 2013 17:21:54 -0500</created>
                <updated>Fri, 3 May 2013 17:21:54 -0500</updated>
                                                                            <due></due>
                    <votes>0</votes>
                        <watches>1</watches>
                                <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                                                                                            </customfields>
    </item>

<item>
            <title>[CLJ-1207] Importing a class that does not exist fails to report the name of the class that did not exist</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1207</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;Pop quiz: What Java class is missing from the classpath?&lt;/p&gt;

&lt;div class=&quot;preformatted panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;preformattedContent panelContent&quot;&gt;
&lt;pre&gt;java.lang.NoClassDefFoundError: Could not initialize class com.annadaletech.nexus.util.logging__init
 at java.lang.Class.forName0 (Class.java:-2)
    java.lang.Class.forName (Class.java:264)
    clojure.lang.RT.loadClassForName (RT.java:2098)
    clojure.lang.RT.load (RT.java:430)
    clojure.lang.RT.load (RT.java:411)
    clojure.core$load$fn__5018.invoke (core.clj:5530)
    clojure.core$load.doInvoke (core.clj:5529)
    clojure.lang.RestFn.invoke (RestFn.java:408)
    clojure.core$load_one.invoke (core.clj:5336)
    clojure.core$load_lib$fn__4967.invoke (core.clj:5375)
    clojure.core$load_lib.doInvoke (core.clj:5374)
    clojure.lang.RestFn.applyTo (RestFn.java:142)
    clojure.core$apply.invoke (core.clj:619)
    clojure.core$load_libs.doInvoke (core.clj:5413)
    clojure.lang.RestFn.applyTo (RestFn.java:137)
    clojure.core$apply.invoke (core.clj:619)
    clojure.core$require.doInvoke (core.clj:5496)
    clojure.lang.RestFn.invoke (RestFn.java:512)
    novate.console.app$eval1736$loading__4910__auto____1737.invoke (app.clj:1)
    novate.console.app$eval1736.invoke (app.clj:1)
    clojure.lang.Compiler.eval (Compiler.java:6619)
    clojure.lang.Compiler.eval (Compiler.java:6608)
    clojure.lang.Compiler.load (Compiler.java:7064)
    user$eval1732.invoke (NO_SOURCE_FILE:1)
    clojure.lang.Compiler.eval (Compiler.java:6619)
    clojure.lang.Compiler.eval (Compiler.java:6582)
    clojure.core$eval.invoke (core.clj:2852)
    clojure.main$repl$read_eval_print__6588$fn__6591.invoke (main.clj:259)
    clojure.main$repl$read_eval_print__6588.invoke (main.clj:259)
    clojure.main$repl$fn__6597.invoke (main.clj:277)
    clojure.main$repl.doInvoke (main.clj:277)
    clojure.lang.RestFn.invoke (RestFn.java:1096)
    clojure.tools.nrepl.middleware.interruptible_eval$evaluate$fn__584.invoke (interruptible_eval.clj:56)
    clojure.lang.AFn.applyToHelper (AFn.java:159)
    clojure.lang.AFn.applyTo (AFn.java:151)
    clojure.core$apply.invoke (core.clj:617)
    clojure.core$with_bindings_STAR_.doInvoke (core.clj:1788)
    clojure.lang.RestFn.invoke (RestFn.java:425)
    clojure.tools.nrepl.middleware.interruptible_eval$evaluate.invoke (interruptible_eval.clj:41)
    clojure.tools.nrepl.middleware.interruptible_eval$interruptible_eval$fn__625$fn__628.invoke (interruptible_eval.clj:171)
    clojure.core$comp$fn__4154.invoke (core.clj:2330)
    clojure.tools.nrepl.middleware.interruptible_eval$run_next$fn__618.invoke (interruptible_eval.clj:138)
    clojure.lang.AFn.run (AFn.java:24)
    java.util.concurrent.ThreadPoolExecutor.runWorker (ThreadPoolExecutor.java:1110)
    java.util.concurrent.ThreadPoolExecutor$Worker.run (ThreadPoolExecutor.java:603)
    java.lang.Thread.run (Thread.java:722)
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;If you guess &quot;com.annadaletech.nexus.util.logging__init&quot; you are wrong!&lt;/p&gt;

&lt;p&gt;Wait, I&apos;ll give you a hint:&lt;/p&gt;

&lt;div class=&quot;preformatted panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;preformattedContent panelContent&quot;&gt;
&lt;pre&gt;(ns com.annadaletech.nexus.util.logging
  (:use [clojure.string :only [trim-newline]]
        [clojure.pprint :only [code-dispatch pprint with-pprint-dispatch *print-right-margin*]])
  (:import [java.io StringWriter]
           [org.slf4j MDC MarkerFactory Marker LoggerFactory]
           [java.util.concurrent.locks ReentrantLock]))

&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;Oh, sorry, did that not help?&lt;/p&gt;

&lt;p&gt;The correct answer is &quot;org.slf4j.MDC&quot;.  &lt;/p&gt;

&lt;p&gt;Having that information in the stack trace would have saved me nearly an hour. I think it is worth the effort to get that reported correctly.&lt;/p&gt;</description>
                <environment>1.5.1, OS X</environment>
            <key id="16172">CLJ-1207</key>
            <summary>Importing a class that does not exist fails to report the name of the class that did not exist</summary>
                <type id="1" iconUrl="http://dev.clojure.org/jira/images/icons/bug.gif">Defect</type>
                                <priority id="3" iconUrl="http://dev.clojure.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="hlewisship">Howard Lewis Ship</reporter>
                        <labels>
                        <label>feedback</label>
                    </labels>
                <created>Mon, 29 Apr 2013 17:36:32 -0500</created>
                <updated>Fri, 10 May 2013 16:51:24 -0500</updated>
                                    <version>Release 1.5</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                        <comments>
                    <comment id="31079" author="cldwalker" created="Fri, 10 May 2013 13:56:45 -0500"  >&lt;p&gt;When I try this on a fresh project, I get this error:&lt;br/&gt;
&quot;ClassNotFoundException org.slf4j.MDC&lt;br/&gt;
        java.net.URLClassLoader$1.run (URLClassLoader.java:202)&lt;br/&gt;
        java.security.AccessController.doPrivileged (AccessController.java:-2)&quot;&lt;/p&gt;

&lt;p&gt;Howard, could you give us a project.clj or better yet a github repository that recreates this issue?&lt;/p&gt;</comment>
                    <comment id="31082" author="hlewisship" created="Fri, 10 May 2013 16:51:24 -0500"  >&lt;p&gt;I&apos;ll see what I can do. Probably be next week. Thanks for looking at this.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                                                                                        <customfield id="customfield_10003" key="com.atlassian.jira.plugin.system.customfieldtypes:userpicker">
                <customfieldname>Waiting On</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>hlewisship</customfieldvalue>
                </customfieldvalues>
            </customfield>
                            </customfields>
    </item>

<item>
            <title>[CLJ-1183] java interop - cannot call a final method on non-public superclass </title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1183</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;when trying to call a method on a concrete class that is defined as final on its super class that is not public, the runtime throws:&lt;/p&gt;

&lt;p&gt;&quot;java.lang.IllegalArgumentException: Can&apos;t call public method of non-public class&quot;&lt;/p&gt;

&lt;p&gt;even when fully annotated, Reflection is still used and the call fails.&lt;/p&gt;

&lt;p&gt;you can read the full description here &lt;a href=&quot;https://groups.google.com/d/msg/clojure/p2tBMT-BIYc/mDQB8cSponMJ&quot;&gt;https://groups.google.com/d/msg/clojure/p2tBMT-BIYc/mDQB8cSponMJ&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;I included a sample project that demonstrate the problem&lt;/p&gt;</description>
                <environment></environment>
            <key id="16085">CLJ-1183</key>
            <summary>java interop - cannot call a final method on non-public superclass </summary>
                <type id="1" iconUrl="http://dev.clojure.org/jira/images/icons/bug.gif">Defect</type>
                                <priority id="3" iconUrl="http://dev.clojure.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="shlomi">Shlomi</reporter>
                        <labels>
                    </labels>
                <created>Wed, 13 Mar 2013 06:14:49 -0500</created>
                <updated>Sat, 18 May 2013 19:22:33 -0500</updated>
                                    <version>Release 1.4</version>
                <version>Release 1.5</version>
                                                        <due></due>
                    <votes>1</votes>
                        <watches>4</watches>
                        <comments>
                    <comment id="30755" author="shlomi" created="Wed, 13 Mar 2013 06:51:24 -0500"  >&lt;p&gt;in my sample project, i used a nested class, but i didnt have to (as pointed by Marko Topolnik). changing the java code to:&lt;/p&gt;

&lt;p&gt;  abstract class AbstractParent{&lt;br/&gt;
      final public int x() {return 6;}&lt;br/&gt;
  }&lt;/p&gt;

&lt;p&gt;  public class test  extends AbstractParent {}&lt;/p&gt;

&lt;p&gt;and the clojure to:&lt;/p&gt;

&lt;p&gt;  (ns call-test.core (:gen-class))&lt;br/&gt;
  (defn -main &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;amp; args&amp;#93;&lt;/span&gt;(.x ^AbstractParent (test.)))&lt;/p&gt;


&lt;p&gt;would produce the same error,&lt;/p&gt;

&lt;p&gt;java.lang.IllegalArgumentException: Can&apos;t call public method of non-public class: public final int AbstractParent.x()&lt;br/&gt;
at clojure.lang.Reflector.invokeMatchingMethod(Reflector.java:88)&lt;/p&gt;</comment>
                    <comment id="31094" author="zoowar" created="Thu, 16 May 2013 12:05:36 -0500"  >&lt;p&gt;This issue affects the upcoming netty-4.0 release in which the public modifier of AbstractBootstrap was removed.&lt;/p&gt;</comment>
                    <comment id="31106" author="m@mattp.name" created="Sat, 18 May 2013 03:48:49 -0500"  >&lt;p&gt;To get Netty 4 working with Clojure I had to create a set of public static Java methods for the various inaccessible Netty calls, which I then call from Clojure. A PITA, but works fine. Happy to post code if anyone would find it useful.&lt;/p&gt;</comment>
                    <comment id="31107" author="shlomi" created="Sat, 18 May 2013 04:31:36 -0500"  >&lt;p&gt;Matthew, i kinda left that project after running to these and other troubles (focused on previous Netty until version 4 will become ready and be properly documented), but i&apos;d still like to see your code. you have a github account or a gist with it?&lt;/p&gt;

&lt;p&gt;Clojure devs - are there any plans of checking this problem out? it came up from Netty, but the problem is pretty generic&lt;/p&gt;</comment>
                    <comment id="31113" author="m@mattp.name" created="Sat, 18 May 2013 19:22:33 -0500"  >&lt;p&gt;Shlomi: here&apos;s a gist with the code I&apos;m using in it. It&apos;s not comprehensive, just the bits I needed. &lt;/p&gt;

&lt;p&gt;&lt;a href=&quot;https://gist.github.com/scramjet/5606195&quot;&gt;https://gist.github.com/scramjet/5606195&lt;/a&gt;&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="11912" name="call-test.tar.gz" size="1234" author="shlomi" created="Wed, 13 Mar 2013 06:14:49 -0500" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                                                                                            </customfields>
    </item>

<item>
            <title>[CLJ-1002] chunk-* functions not documented</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1002</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;None of the chunk related functions defined in core.clj have documentation.  While their implementations are straightforward, it means the functions do not show up in &lt;a href=&quot;http://clojure.org/api&quot;&gt;http://clojure.org/api&lt;/a&gt;.  Are these not considered part of the API?  If so, should they be private?  Otherwise, I think they should have public documentation.&lt;/p&gt;

&lt;p&gt;For searchability, the function are:&lt;/p&gt;

&lt;p&gt;chunk-append, chunk, chunk-first, chunk-rest, chunk-next, chunk-cons, chunked-seq?&lt;/p&gt;</description>
                <environment></environment>
            <key id="15481">CLJ-1002</key>
            <summary>chunk-* functions not documented</summary>
                <type id="4" iconUrl="http://dev.clojure.org/jira/images/icons/improvement.gif">Enhancement</type>
                                <priority id="4" iconUrl="http://dev.clojure.org/jira/images/icons/priority_minor.gif">Minor</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="jim.blomo">Jim Blomo</reporter>
                        <labels>
                    </labels>
                <created>Sun, 27 May 2012 01:17:18 -0500</created>
                <updated>Sun, 27 May 2012 01:17:18 -0500</updated>
                                    <version>Release 1.5</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                                                                                            </customfields>
    </item>

<item>
            <title>[CLJ-941] NullPointerException possible with seq-zip</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-941</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;For example:&lt;/p&gt;

&lt;p&gt;Clojure 1.3.0&lt;br/&gt;
user=&amp;gt; (require &apos;&lt;span class=&quot;error&quot;&gt;&amp;#91;clojure.zip :as z&amp;#93;&lt;/span&gt;)&lt;br/&gt;
nil&lt;br/&gt;
user=&amp;gt; (-&amp;gt; (z/seq-zip (list 1)) z/down z/remove)&lt;br/&gt;
NullPointerException   clojure.core/with-meta (core.clj:211)&lt;/p&gt;

&lt;p&gt;Possibly the make-node function for seq-zip should be:&lt;/p&gt;

&lt;p&gt;(fn &lt;span class=&quot;error&quot;&gt;&amp;#91;node children&amp;#93;&lt;/span&gt; (with-meta (or children ()) (meta node)))&lt;/p&gt;</description>
                <environment></environment>
            <key id="15249">CLJ-941</key>
            <summary>NullPointerException possible with seq-zip</summary>
                <type id="1" iconUrl="http://dev.clojure.org/jira/images/icons/bug.gif">Defect</type>
                                <priority id="4" iconUrl="http://dev.clojure.org/jira/images/icons/priority_minor.gif">Minor</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="glchapman">Greg Chapman</reporter>
                        <labels>
                    </labels>
                <created>Sun, 26 Feb 2012 17:19:20 -0600</created>
                <updated>Sun, 26 Feb 2012 17:54:13 -0600</updated>
                                    <version>Release 1.3</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                        <comments>
                    <comment id="27878" author="glchapman" created="Sun, 26 Feb 2012 17:54:13 -0600"  >&lt;p&gt;Also the docstring for zipper should probably be updated to indicate that the children parameter can be nil.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                                                                                            </customfields>
    </item>

<item>
            <title>[CLJ-750] clojure.lang.MapEntry violates .equals and .hashCode contracts of HashMap.Entry; leads to non-reflexive .equals, etc.</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-750</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;user&amp;gt; (let &lt;span class=&quot;error&quot;&gt;&amp;#91;h (HashMap.)&amp;#93;&lt;/span&gt; &lt;br/&gt;
       (.put h 1 2) &lt;br/&gt;
       (let [p1 (first h) &lt;br/&gt;
             p2 (first {1 2})] &lt;br/&gt;
        (println (.hashCode p1) (.hashCode p2) &lt;br/&gt;
                 (= p1 p2) (= p2 p1) &lt;br/&gt;
                 (.equals p1 p2) (.equals p2 p1))))&lt;/p&gt;

&lt;p&gt;3 994 false false true false&lt;/p&gt;

&lt;p&gt;clojure.lang.MapEntry does not follow the contracts of hashCode or equals for java.util.Map$Entry.  This, among other things, leads to the above non-reflexive behavior of .equals.  &lt;/p&gt;

&lt;p&gt;I realize this isn&apos;t a simple bug; it&apos;s a fundamental issue, in that it&apos;s impossible to consistently implement both java.util.List and java.util.Map$Entry, which clojure.lang.MapEntry claims to do.  On balance I do find it very useful that Clojure map entries are equivalent to vectors, and probably wouldn&apos;t want to give that up.  But, I think that at minimum this wart should be documented somewhere, since it could lead to some very strange and hard to catch bugs.  &lt;/p&gt;</description>
                <environment></environment>
            <key id="14365">CLJ-750</key>
            <summary>clojure.lang.MapEntry violates .equals and .hashCode contracts of HashMap.Entry; leads to non-reflexive .equals, etc.</summary>
                <type id="1" iconUrl="http://dev.clojure.org/jira/images/icons/bug.gif">Defect</type>
                                <priority id="4" iconUrl="http://dev.clojure.org/jira/images/icons/priority_minor.gif">Minor</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="jawolfe">Jason Wolfe</reporter>
                        <labels>
                    </labels>
                <created>Wed, 2 Mar 2011 22:04:41 -0600</created>
                <updated>Fri, 29 Jul 2011 07:45:40 -0500</updated>
                                    <version>Release 1.2</version>
                <version>Release 1.3</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>2</watches>
                        <comments>
                    <comment id="26259" author="jawolfe" created="Wed, 2 Mar 2011 22:13:33 -0600"  >&lt;p&gt;This might be fixable by changing seq to promise a sequence of pairs rather than MapEntries.  I don&apos;t know enough about Clojure internals to know if this would entail too large a performance hit, but perhaps it&apos;s worth considering.&lt;/p&gt;</comment>
                    <comment id="26273" author="stu" created="Fri, 4 Mar 2011 21:11:41 -0600"  >&lt;p&gt;Rich: is there a doc patch you would want for this?&lt;/p&gt;</comment>
                    <comment id="26670" author="richhickey" created="Fri, 29 Jul 2011 07:45:39 -0500"  >&lt;p&gt;doc patch ok&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                                                                                            </customfields>
    </item>

<item>
            <title>[CLJ-878] DispatchReader always calls CtorReader when no dispatch macro found</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-878</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;At the REPL, I accidentally typed:&lt;/p&gt;

&lt;p&gt;user=&amp;gt; # &quot;\w+&quot;&lt;br/&gt;
RuntimeException Unsupported escape character: \w  clojure.lang.Util.runtimeExce&lt;br/&gt;
ption (Util.java:156)&lt;br/&gt;
#&amp;lt;core$&lt;em&gt;PLUS&lt;/em&gt; clojure.core$&lt;em&gt;PLUS&lt;/em&gt;@6b7dc78&amp;gt;&lt;/p&gt;

&lt;p&gt;You can see the confusing result (the REPL is also left in an unclosed string). After looking at LispReader.java, it seems to me DispatchReader ought to at least check for whitespace before calling CtorReader (perhaps better would be to check for a valid symbol character). Another example:&lt;/p&gt;

&lt;p&gt;user=&amp;gt; (defrecord X &lt;span class=&quot;error&quot;&gt;&amp;#91;x&amp;#93;&lt;/span&gt;)&lt;br/&gt;
user.X&lt;br/&gt;
user=&amp;gt; # &quot;user.X&quot;&lt;span class=&quot;error&quot;&gt;&amp;#91;5&amp;#93;&lt;/span&gt;&lt;br/&gt;
#user.X{:x 5}&lt;/p&gt;

&lt;p&gt;I&apos;m assuming the fact that the above successfully creates an X is accidental.&lt;/p&gt;</description>
                <environment>Windows 7, Java 1.7</environment>
            <key id="15010">CLJ-878</key>
            <summary>DispatchReader always calls CtorReader when no dispatch macro found</summary>
                <type id="1" iconUrl="http://dev.clojure.org/jira/images/icons/bug.gif">Defect</type>
                                <priority id="4" iconUrl="http://dev.clojure.org/jira/images/icons/priority_minor.gif">Minor</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="glchapman">Greg Chapman</reporter>
                        <labels>
                    </labels>
                <created>Tue, 15 Nov 2011 17:28:46 -0600</created>
                <updated>Tue, 15 Nov 2011 17:28:46 -0600</updated>
                                    <version>Release 1.3</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                                                                                            </customfields>
    </item>

<item>
            <title>[CLJ-880] syntax-quote should be a macro instead of implemented inside the reader</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-880</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;syntax-quote is currently a somewhat gnarly bit of java code in LispReader.java, would be great to replace it with a (hopefully less gnarly) clojure macro.&lt;/p&gt;

&lt;p&gt;LispReader.java would be required to do something similar to &apos;x =&amp;gt; (quote x). `x =&amp;gt; (syntax-quote x) , ~x =&amp;gt; (unquote x), ~@x =&amp;gt; (unquote-splicing x)&lt;/p&gt;</description>
                <environment></environment>
            <key id="15017">CLJ-880</key>
            <summary>syntax-quote should be a macro instead of implemented inside the reader</summary>
                <type id="4" iconUrl="http://dev.clojure.org/jira/images/icons/improvement.gif">Enhancement</type>
                                <priority id="4" iconUrl="http://dev.clojure.org/jira/images/icons/priority_minor.gif">Minor</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="hiredman">Kevin Downey</reporter>
                        <labels>
                    </labels>
                <created>Thu, 17 Nov 2011 17:02:48 -0600</created>
                <updated>Thu, 17 Nov 2011 17:02:48 -0600</updated>
                                                                            <due></due>
                    <votes>0</votes>
                        <watches>3</watches>
                                <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                                                                                            </customfields>
    </item>

<item>
            <title>[CLJ-946] eval reader fail to recognize  function object </title>
                <link>http://dev.clojure.org/jira/browse/CLJ-946</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;(defmacro stubbing &lt;span class=&quot;error&quot;&gt;&amp;#91;stub-forms &amp;amp; body&amp;#93;&lt;/span&gt;&lt;br/&gt;
  (let [stub-pairs (partition 2 stub-forms)&lt;br/&gt;
        returns (map last stub-pairs)&lt;br/&gt;
        stub-fns (map constantly returns)  ;;(map #(list &apos;constantly %) returns)&lt;br/&gt;
        real-fns (map first stub-pairs)]&lt;br/&gt;
    `(binding &lt;span class=&quot;error&quot;&gt;&amp;#91;~@(interleave real-fns stub-fns)&amp;#93;&lt;/span&gt;&lt;br/&gt;
       ~@body)))&lt;/p&gt;

&lt;p&gt;This macro is from  Clojure In Action , whith the commented line rewrited (I know that original is better)&lt;br/&gt;
I assumed that this macro would work as supposed , if the stub forms use compile time literal, for e.g&lt;/p&gt;

&lt;p&gt;(def ^:dynamic $ (fn &lt;span class=&quot;error&quot;&gt;&amp;#91;x&amp;#93;&lt;/span&gt; (* x 10))&lt;/p&gt;


&lt;p&gt;(stubbing &lt;span class=&quot;error&quot;&gt;&amp;#91;$ 1&amp;#93;&lt;/span&gt;&lt;br/&gt;
        ($ 1 1))&lt;br/&gt;
;; =&amp;gt;&lt;br/&gt;
IllegalArgumentException No matching ctor found for class clojure.core$constantly$fn__3656&lt;br/&gt;
	clojure.lang.Reflector.invokeConstructor (Reflector.java:166)&lt;br/&gt;
	clojure.lang.LispReader$EvalReader.invoke (LispReader.java:1031)&lt;br/&gt;
	clojure.lang.LispReader$DispatchReader.invoke (LispReader.java:618)&lt;/p&gt;

&lt;p&gt;;;macro can expanded  &lt;br/&gt;
(macroexpand-all &apos;(stubbing &lt;span class=&quot;error&quot;&gt;&amp;#91;$ 1&amp;#93;&lt;/span&gt;&lt;br/&gt;
                ($ 1 1)))&lt;br/&gt;
;; =&amp;gt;&lt;br/&gt;
(let* [] (clojure.core/push-thread-bindings (clojure.core/hash-map (var $) #&amp;lt;core$constantly$fn_&lt;em&gt;3656 clojure.core$constantly$fn&lt;/em&gt;_3656@161f888&amp;gt;)) (try ($ 1 1) (finally (clojure.core/pop-thread-bindings))))&lt;/p&gt;

&lt;p&gt;I thought there is something wrong with eval reader, but i can&apos;t figure it out&lt;/p&gt;

&lt;p&gt;btw the above code can run on clojure-clr&lt;/p&gt;
</description>
                <environment></environment>
            <key id="15263">CLJ-946</key>
            <summary>eval reader fail to recognize  function object </summary>
                <type id="1" iconUrl="http://dev.clojure.org/jira/images/icons/bug.gif">Defect</type>
                                <priority id="4" iconUrl="http://dev.clojure.org/jira/images/icons/priority_minor.gif">Minor</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="xiaonaitong">Naitong Xiao</reporter>
                        <labels>
                    </labels>
                <created>Tue, 6 Mar 2012 02:54:06 -0600</created>
                <updated>Wed, 7 Mar 2012 01:24:47 -0600</updated>
                                    <version>Release 1.3</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                        <comments>
                    <comment id="27905" author="michaelklishin" created="Tue, 6 Mar 2012 23:24:35 -0600"  >&lt;p&gt;As far as I know, Clojure in Action examples are written for Clojure 1.2. What version are you using?&lt;/p&gt;</comment>
                    <comment id="27907" author="xiaonaitong" created="Wed, 7 Mar 2012 01:24:47 -0600"  >&lt;p&gt;I use clojure 1.3&lt;/p&gt;

&lt;p&gt;The example in Clojure In Action is Ok on clojure 1.3&lt;br/&gt;
I just found this peculiar thing when trying to answer a question from another one in a mail list.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                                                                                            </customfields>
    </item>

<item>
            <title>[CLJ-1008] Make sorted maps and sets implement j.u.NavigableMap and NavigableSet interfaces </title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1008</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;Since Clojure 1.5 will probably no longer target JVM 5, add support for the (Concurrent)?Navigable(Map|Set) interfaces.  This should involve adding functions to PersistentTreeMap that descend the red-black tree to select the closest items.&lt;/p&gt;</description>
                <environment></environment>
            <key id="15505">CLJ-1008</key>
            <summary>Make sorted maps and sets implement j.u.NavigableMap and NavigableSet interfaces </summary>
                <type id="4" iconUrl="http://dev.clojure.org/jira/images/icons/improvement.gif">Enhancement</type>
                                <priority id="4" iconUrl="http://dev.clojure.org/jira/images/icons/priority_minor.gif">Minor</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="jim.blomo">Jim Blomo</reporter>
                        <labels>
                    </labels>
                <created>Sat, 2 Jun 2012 19:07:09 -0500</created>
                <updated>Sat, 2 Jun 2012 19:07:31 -0500</updated>
                                    <version>Release 1.5</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                                                                                            </customfields>
    </item>

<item>
            <title>[CLJ-938] Output of clojure.reflect is not suitable for type hints</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-938</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;I&apos;m trying to write a macro which generate reify forms using some reflection.&lt;/p&gt;

&lt;p&gt;clojure.reflect produces type symbols similar to &apos;java.util.Iterator&amp;lt;&amp;gt;&lt;/p&gt;

&lt;p&gt;Unfortunately, the compiler doesn&apos;t accept the &amp;lt;&amp;gt; syntax in type hints:&lt;/p&gt;

&lt;p&gt;(reify Iterable (^{:tag java.util.Iterator} iterator &lt;span class=&quot;error&quot;&gt;&amp;#91;this&amp;#93;&lt;/span&gt; nil)) ; works&lt;/p&gt;

&lt;p&gt;(reify Iterable (^{:tag java.util.Iterator&amp;lt;&amp;gt;} iterator &lt;span class=&quot;error&quot;&gt;&amp;#91;this&amp;#93;&lt;/span&gt; nil)) ;; fails&lt;br/&gt;
CompilerException java.lang.RuntimeException: java.lang.ClassNotFoundException: java.util.Iterator&amp;lt;&amp;gt;, compiling:(NO_SOURCE_PATH:1325)&lt;/p&gt;

&lt;p&gt;It seems like the compiler should understand the &amp;lt;&amp;gt; just enough to strip it, rather than reject it. This would make it much easier to write correct macros involving type hinting and reflection.&lt;/p&gt;

&lt;p&gt;The workaround I have been using is:&lt;/p&gt;

&lt;p&gt;(defn hint&lt;br/&gt;
  &quot;clojure.reflect demarks generics with angle brackets, but&lt;br/&gt;
   the compiler does not support generics in type hints&quot;&lt;br/&gt;
  &lt;span class=&quot;error&quot;&gt;&amp;#91;obj tag&amp;#93;&lt;/span&gt;&lt;br/&gt;
  (let &lt;span class=&quot;error&quot;&gt;&amp;#91;tag (-&amp;gt; tag .toString (.replace &amp;quot;&amp;lt;&amp;gt;&amp;quot; &amp;quot;&amp;quot;) symbol)&amp;#93;&lt;/span&gt;&lt;br/&gt;
    (with-meta obj {:tag tag}))&lt;img class=&quot;emoticon&quot; src=&quot;http://dev.clojure.org/jira/images/icons/emoticons/wink.gif&quot; height=&quot;20&quot; width=&quot;20&quot; align=&quot;absmiddle&quot; alt=&quot;&quot; border=&quot;0&quot;/&gt;&lt;/p&gt;</description>
                <environment></environment>
            <key id="15244">CLJ-938</key>
            <summary>Output of clojure.reflect is not suitable for type hints</summary>
                <type id="1" iconUrl="http://dev.clojure.org/jira/images/icons/bug.gif">Defect</type>
                                <priority id="4" iconUrl="http://dev.clojure.org/jira/images/icons/priority_minor.gif">Minor</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="bbloom">Brandon Bloom</reporter>
                        <labels>
                    </labels>
                <created>Thu, 23 Feb 2012 23:31:12 -0600</created>
                <updated>Fri, 24 Feb 2012 01:37:33 -0600</updated>
                                    <version>Release 1.3</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>1</watches>
                        <comments>
                    <comment id="27832" author="bbloom" created="Fri, 24 Feb 2012 01:37:33 -0600"  >&lt;p&gt;I&apos;m sorry, I got this wrong earlier. The problem is real, but it&apos;s &lt;em&gt;arrays&lt;/em&gt;, not &lt;em&gt;generics&lt;/em&gt;.&lt;/p&gt;

&lt;p&gt;My workaround is useless... :-/&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                                                                                            </customfields>
    </item>

<item>
            <title>[CLJ-1047] Simplify the process of requiring fj in clojure.core.reducers</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1047</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;this patch removes compile-if in favor of import-if, removing code duplication&lt;/p&gt;</description>
                <environment></environment>
            <key id="15638">CLJ-1047</key>
            <summary>Simplify the process of requiring fj in clojure.core.reducers</summary>
                <type id="4" iconUrl="http://dev.clojure.org/jira/images/icons/improvement.gif">Enhancement</type>
                                <priority id="4" iconUrl="http://dev.clojure.org/jira/images/icons/priority_minor.gif">Minor</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="bronsa">Nicola Mometto</reporter>
                        <labels>
                    </labels>
                <created>Tue, 21 Aug 2012 18:27:01 -0500</created>
                <updated>Tue, 21 Aug 2012 18:27:01 -0500</updated>
                                                                            <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                <attachments>
                    <attachment id="11451" name="001-simplify-fj-importing.patch" size="2641" author="bronsa" created="Tue, 21 Aug 2012 18:27:01 -0500" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10000" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Patch</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10001">Code</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[CLJ-955] java object reader constructor doesn&apos;t work</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-955</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;Here is a transcript:&lt;/p&gt;

&lt;p&gt;;user=&amp;gt; &lt;b&gt;clojure-version&lt;/b&gt;&lt;br/&gt;
{:major 1, :minor 4, :incremental 0, :qualifier &quot;beta5&quot;}&lt;br/&gt;
;user=&amp;gt; (.getProtocol #java.net.URL&lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;quot;file:/home/hara/dj/usr/src/clojurescript/src/cljs/cljs/core.cljs&amp;quot;&amp;#93;&lt;/span&gt;)&lt;br/&gt;
java.lang.RuntimeException: Can&apos;t embed object in code, maybe print-dup not defined: &lt;a href=&quot;file:/home/hara/dj/usr/src/clojurescript/src/cljs/cljs/core.cljs&quot;&gt;file:/home/hara/dj/usr/src/clojurescript/src/cljs/cljs/core.cljs&lt;/a&gt;, compiling:(null:2)&lt;br/&gt;
;user=&amp;gt; (.getProtocol (java.net.URL. &quot;file:/home/hara/dj/usr/src/clojurescript/src/cljs/cljs/core.cljs&quot;))&lt;br/&gt;
&quot;file&quot;&lt;/p&gt;

&lt;p&gt;Another transcript from google groups &lt;a href=&quot;https://groups.google.com/forum/?fromgroups&amp;amp;hl=en#!topic/clojure/vlsFgVaKcSQ&quot;&gt;https://groups.google.com/forum/?fromgroups&amp;amp;hl=en#!topic/clojure/vlsFgVaKcSQ&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;user=&amp;gt; (def x #java.net.URL&lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;quot;file:/home/hara/dj/usr/src/clojurescript/src/cljs/cljs/core.cljs&amp;quot;&amp;#93;&lt;/span&gt;)&lt;br/&gt;
#&apos;user/x&lt;br/&gt;
user=&amp;gt; x&lt;br/&gt;
#&amp;lt;URL &lt;a href=&quot;file:/home/hara/dj/usr/src/clojurescript/src/cljs/cljs/core.cljs&quot;&gt;file:/home/hara/dj/usr/src/clojurescript/src/cljs/cljs/core.cljs&lt;/a&gt;&amp;gt;&lt;br/&gt;
user=&amp;gt; (.getProtocol x)&lt;br/&gt;
&quot;file&quot;&lt;/p&gt;


&lt;p&gt;user=&amp;gt; (.getProtocol #java.net.URL&lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;quot;file:/home/hara/dj/usr/src/clojurescript/src/cljs/cljs/core.cljs&amp;quot;&amp;#93;&lt;/span&gt;)&lt;br/&gt;
CompilerException java.lang.RuntimeException: Can&apos;t embed object in code, maybe print-dup not defined: &lt;a href=&quot;file:/home/hara/dj/usr/src/clojurescript/src/cljs/cljs/core.cljs&quot;&gt;file:/home/hara/dj/usr/src/clojurescript/src/cljs/cljs/core.cljs&lt;/a&gt;, compiling:(NO_SOURCE_PATH:5) &lt;br/&gt;
user=&amp;gt; (defmethod print-dup java.net.URL &lt;span class=&quot;error&quot;&gt;&amp;#91;o, ^java.io.Writer w&amp;#93;&lt;/span&gt; (.write w (str o)))&lt;br/&gt;
#&amp;lt;MultiFn clojure.lang.MultiFn@2e694f12&amp;gt;&lt;/p&gt;

&lt;p&gt;user=&amp;gt; (.getProtocol #java.net.URL&lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;quot;file:/home/hara/dj/usr/src/clojurescript/src/cljs/cljs/core.cljs&amp;quot;&amp;#93;&lt;/span&gt;)&lt;br/&gt;
ClassCastException clojure.lang.Symbol cannot be cast to java.net.URL  user/eval11 (NO_SOURCE_FILE:7)&lt;br/&gt;
user=&amp;gt;&lt;/p&gt;

&lt;p&gt;user=&amp;gt; (def x #java.net.URL&lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;quot;file:///home/hara/dj/usr/src/clojurescript/src/cljs/cljs/core.cljs&amp;quot;&amp;#93;&lt;/span&gt;)&lt;br/&gt;
#&apos;user/x&lt;br/&gt;
user=&amp;gt; (printf &quot;(class x)=%s x=&apos;%s&apos;\n&quot; (class x) x)&lt;br/&gt;
(class x)=class java.net.URL x=&apos;file:/home/hara/dj/usr/src/clojurescript/src/cljs/cljs/core.cljs&apos;&lt;br/&gt;
nil&lt;br/&gt;
user=&amp;gt; (let [x #java.net.URL&lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;quot;file:///home/hara/dj/usr/src/clojurescript/src/cljs/cljs/core.cljs&amp;quot;&amp;#93;&lt;/span&gt;]&lt;br/&gt;
(printf &quot;(class x)=%s x=&apos;%s&apos;\n&quot; (class x) x))&lt;br/&gt;
CompilerException java.lang.RuntimeException: Can&apos;t embed object in code, maybe print-dup not defined: &lt;a href=&quot;file:/home/hara/dj/usr/src/clojurescript/src/cljs/cljs/core.cljs&quot;&gt;file:/home/hara/dj/usr/src/clojurescript/src/cljs/cljs/core.cljs&lt;/a&gt;, compiling:(NO_SOURCE_PATH:4) &lt;/p&gt;

&lt;p&gt;user=&amp;gt; (defmethod print-dup java.net.URL &lt;span class=&quot;error&quot;&gt;&amp;#91;o, ^java.io.Writer w&amp;#93;&lt;/span&gt; (.write w (str o)))&lt;br/&gt;
#&amp;lt;MultiFn clojure.lang.MultiFn@3362a63&amp;gt;&lt;br/&gt;
user=&amp;gt; (let [x #java.net.URL&lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;quot;file:///home/hara/dj/usr/src/clojurescript/src/cljs/cljs/core.cljs&amp;quot;&amp;#93;&lt;/span&gt;]&lt;br/&gt;
(printf &quot;(class x)=%s x=&apos;%s&apos;\n&quot; (class x) x))&lt;br/&gt;
(class x)=class clojure.lang.Symbol x=&apos;file:/home/hara/dj/usr/src/clojurescript/src/cljs/cljs/core.cljs&apos;&lt;br/&gt;
nil&lt;/p&gt;</description>
                <environment></environment>
            <key id="15285">CLJ-955</key>
            <summary>java object reader constructor doesn&apos;t work</summary>
                <type id="1" iconUrl="http://dev.clojure.org/jira/images/icons/bug.gif">Defect</type>
                                <priority id="4" iconUrl="http://dev.clojure.org/jira/images/icons/priority_minor.gif">Minor</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="bmillare">Brent Millare</reporter>
                        <labels>
                    </labels>
                <created>Sun, 18 Mar 2012 19:37:26 -0500</created>
                <updated>Mon, 19 Mar 2012 10:26:00 -0500</updated>
                                    <version>Release 1.4</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>1</watches>
                        <comments>
                    <comment id="27963" author="jafingerhut" created="Mon, 19 Mar 2012 02:58:18 -0500"  >&lt;p&gt;I&apos;ve confirmed this behavior with 1.4.0 beta5.  I&apos;ve only tracked it down as far as finding the &quot;Can&apos;t embed object in code&quot; message, which is easy to find in Compiler.java in method emitValue.  That exception is thrown because printString in RT.java throws an exception.&lt;/p&gt;

&lt;p&gt;It isn&apos;t clear to me what should be done instead, though.&lt;/p&gt;</comment>
                    <comment id="27964" author="fogus" created="Mon, 19 Mar 2012 09:03:08 -0500"  >&lt;p&gt;What would it mean to construct an arbitrary Java object for the purpose of embedding it in code in a generic way? You could say that it&apos;s just a matter of calling its constructor with the right args but very often in Java that is &lt;b&gt;not&lt;/b&gt; enough to make an object considered &quot;initialize&quot;.  Sometimes there are init methods or putters or whatever that are required for object construction.  So right there I hope it&apos;s clear that even though #some.Klass&lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;quot;foo&amp;quot;&amp;#93;&lt;/span&gt; provides a way to call an arbitrary constructor, it&apos;s in no way a guarantee that an instance is properly constructed.  The reason that (for example) defrecords are embeddable anywhere is because we know for certain that the constructor creates a fully initialized instance. If you need to embed specific instances in your own code then you have two options:&lt;/p&gt;

&lt;ul&gt;
	&lt;li&gt;Implement a print-dup for the class that guarantees a fully initialized object is built.&lt;/li&gt;
&lt;/ul&gt;


&lt;ul&gt;
	&lt;li&gt;Use Clojure 1.4&apos;s tagged literal feature to do the same.&lt;/li&gt;
&lt;/ul&gt;


&lt;p&gt;Quick point of note:&lt;/p&gt;

&lt;p&gt;Your code &lt;div class=&quot;preformatted panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;preformattedContent panelContent&quot;&gt;
&lt;pre&gt;(defmethod print-dup java.net.URL [o, ^java.io.Writer w] (.write w (str o)))
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;&lt;/p&gt;

&lt;p&gt;Doesn&apos;t do what you think it does.  It spits out exactly &lt;tt&gt;&lt;a href=&quot;file:///home/hara/dj/usr/src/clojurescript/src/cljs/cljs/core.cljs&quot;&gt;file:///home/hara/dj/usr/src/clojurescript/src/cljs/cljs/core.cljs&lt;/a&gt;&lt;/tt&gt; that Clojure reads in as a symbol.  Something like the following might be more appropriate:&lt;/p&gt;

&lt;div class=&quot;preformatted panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;preformattedContent panelContent&quot;&gt;
&lt;pre&gt;(defmethod print-dup java.net.URL [o, ^java.io.Writer w] (.write w &quot;#java.net.URL&quot;) (.write w (str [ (str o) ])))

(let [x #java.net.URL[&quot;file:///home/hara/dj/usr/src/clojurescript/src/cljs/cljs/core.cljs&quot;]]                             
  (printf &quot;(class x)=%s x=&apos;%s&apos;\n&quot; (class x) x) x)                                                                          

; (class x)=class java.net.URL x=&apos;file:/home/hara/dj/usr/src/clojurescript/src/cljs/cljs/core.cljs&apos;

;=&amp;gt; #&amp;lt;URL file:/home/hara/dj/usr/src/clojurescript/src/cljs/cljs/core.cljs&amp;gt;

(.getProtocol *1)                        
;=&amp;gt; &quot;file&quot;
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;</comment>
                    <comment id="27965" author="bmillare" created="Mon, 19 Mar 2012 10:09:10 -0500"  >&lt;p&gt;Fogus, can you please elaborate on using clojure 1.4&apos;s tagged literal features. While I understand that you can define data-reader functions, for example&lt;/p&gt;
&lt;div class=&quot;preformatted panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;preformattedContent panelContent&quot;&gt;
&lt;pre&gt;(binding [*data-readers* {&apos;user/f (fn [x] (java.io.File. (first x)))}] (read-string &quot;#user/f [\&quot;hello\&quot;]&quot;)) ;=&amp;gt; #&amp;lt;File hello&amp;gt;
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;however, I feel this is only half a fix, compared with the first mentioned solution (involving print-dup), since clojure&apos;s tagged literals only are important for reading, not for printing. Does using tagged literals, so that (read-string (pr-str (read-string ...) works, imply that you must also define print methods per class? If this is true, it seems problematic since if different code wants to define different print methods, this will conflict since defining print-dup methods is global. Is there a good solution for printing objects depending on the context? As an alternative solution, I propose making the default print-method of all objects that didn&apos;t already have a printed representation to be a tagged literal, this way, users can customize what it means to read it. (See &lt;a href=&quot;https://groups.google.com/forum/?fromgroups&amp;amp;hl=en#!topic/clojure/GdT5cO6JoSQ&quot;&gt;https://groups.google.com/forum/?fromgroups&amp;amp;hl=en#!topic/clojure/GdT5cO6JoSQ&lt;/a&gt; )&lt;/p&gt;</comment>
                    <comment id="27966" author="fogus" created="Mon, 19 Mar 2012 10:18:29 -0500"  >&lt;p&gt;&quot;Fogus, can you please elaborate on using clojure 1.4&apos;s tagged literal features.&quot;&lt;/p&gt;

&lt;p&gt;I can, but it falls outside of the scope of this particular ticket.  It might be better to take the broader conversation to the design page at &lt;a href=&quot;http://dev.clojure.org/display/design/Tagged+Literals&quot;&gt;http://dev.clojure.org/display/design/Tagged+Literals&lt;/a&gt; and the clojure-dev list.&lt;/p&gt;

&lt;p&gt;Has the original motivation for this ticket been addressed?&lt;/p&gt;</comment>
                    <comment id="27967" author="bmillare" created="Mon, 19 Mar 2012 10:26:00 -0500"  >&lt;p&gt;I think you&apos;ve explained the underlying problem, so yes. One possible caveat might be that it may be a concern that the current error message is not telling that the underlying problem lies in an improperly initialized object. (or maybe it is, and that&apos;s the error message I should expect).&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                                                                                            </customfields>
    </item>

<item>
            <title>[CLJ-1015] Standalone Clojure library for Java users</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1015</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;Many of Clojure&apos;s data structures (e.g. PersistentHashMap) may be of interest to the wider Java community, and would benefit from being packaged in a way that makes them easy to include in projects.  While they are public (and thus can be accessed by way of clojure.lang), Clojure&apos;s classloader is implemented in a way such that Clojure files such as core.clj end up being loaded, even when an end-user is not interested in the Clojure environment itself.  The Java classes could also use some documentation!&lt;/p&gt;

&lt;p&gt;I&apos;d be happy to work on a patch but this change may require some restructuring of the build process, so it&apos;d be good to get community sign-off first.&lt;/p&gt;</description>
                <environment></environment>
            <key id="15536">CLJ-1015</key>
            <summary>Standalone Clojure library for Java users</summary>
                <type id="4" iconUrl="http://dev.clojure.org/jira/images/icons/improvement.gif">Enhancement</type>
                                <priority id="4" iconUrl="http://dev.clojure.org/jira/images/icons/priority_minor.gif">Minor</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="ezyang">Edward Z. Yang</reporter>
                        <labels>
                    </labels>
                <created>Thu, 14 Jun 2012 14:19:00 -0500</created>
                <updated>Thu, 14 Jun 2012 17:39:23 -0500</updated>
                                    <version>Release 1.5</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                        <comments>
                    <comment id="28808" author="jafingerhut" created="Thu, 14 Jun 2012 17:39:23 -0500"  >&lt;p&gt;I am assuming this ticket is a request that the original Clojure distribution be modified to easily build such a library of data structures, and be maintained as a separate build target, going forward.&lt;/p&gt;

&lt;p&gt;Reference to related info: Below is a copy of most of a message from someone with userid Krukow posted to the Clojure Google group on June 3, 2012: &lt;a href=&quot;https://groups.google.com/forum/?fromgroups#!topic/clojure/UyjmafY_ZE8&quot;&gt;https://groups.google.com/forum/?fromgroups#!topic/clojure/UyjmafY_ZE8&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;I created a project containing only the persistent data structures for use with Java et al. &lt;/p&gt;

&lt;p&gt;&lt;a href=&quot;https://github.com/krukow/clj-ds&quot;&gt;https://github.com/krukow/clj-ds&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;It is the data structures only so no bootstrap penalty. There are also Java&apos;ish &quot;improvements&quot; like basic Generics and improved performance on the iterator pattern.&lt;/p&gt;

&lt;p&gt;It&apos;s still on Clojure 1.3 (As far as I recall), but I am planning on taking another iteration.&lt;/p&gt;

&lt;p&gt;TODO:&lt;/p&gt;

&lt;ul class=&quot;alternate&quot; type=&quot;square&quot;&gt;
	&lt;li&gt;better Generics support&lt;/li&gt;
	&lt;li&gt;more data structures  (tries, RRB-trees)&lt;/li&gt;
	&lt;li&gt;include the reducers library support for parallelism&lt;/li&gt;
&lt;/ul&gt;
</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                                                                                            </customfields>
    </item>

<item>
            <title>[CLJ-900] Document defonce-like behavior of defmulti</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-900</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;Since Clojure 1.2 defmulti behaves similarly to defonce. This fact, and how one deals with it when doing interactive development, does not seem to be documented anywhere. This issue pops up fairly regularly in the #clojure channel.&lt;/p&gt;

&lt;p&gt;Commit that introduced the change: &lt;a href=&quot;https://github.com/clojure/clojure/commit/1b8d5001ba094053b24c55829994785be422cfbf&quot;&gt;https://github.com/clojure/clojure/commit/1b8d5001ba094053b24c55829994785be422cfbf&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;I can volunteer to update the docstrings and (if I get access to it) the clojure.org page.&lt;/p&gt;</description>
                <environment></environment>
            <key id="15082">CLJ-900</key>
            <summary>Document defonce-like behavior of defmulti</summary>
                <type id="3" iconUrl="http://dev.clojure.org/jira/images/icons/task.gif">Task</type>
                                <priority id="4" iconUrl="http://dev.clojure.org/jira/images/icons/priority_minor.gif">Minor</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="raek">Rasmus Svensson</reporter>
                        <labels>
                        <label>documentation</label>
                    </labels>
                <created>Mon, 19 Dec 2011 16:40:59 -0600</created>
                <updated>Mon, 19 Dec 2011 16:40:59 -0600</updated>
                                    <version>Release 1.2</version>
                <version>Release 1.3</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>1</watches>
                                <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[CLJ-1029] ns defmacro allows arbitrary execution of clojure.core fns</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1029</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;The form:&lt;/p&gt;

&lt;p&gt;    (ns foo (:print &quot;I AM A ROBOT&quot;))&lt;/p&gt;

&lt;p&gt;will print &quot;I AM A ROBOT&quot;&lt;/p&gt;

&lt;p&gt;This is because the defmacro takes the name of the first element of the reference, looks it up in the clojure.core namespace and invokes it on the rest of the args.&lt;/p&gt;

&lt;p&gt;This is minor, but it does mean that an otherwise declarative form is not executing code.&lt;/p&gt;</description>
                <environment>all</environment>
            <key id="15588">CLJ-1029</key>
            <summary>ns defmacro allows arbitrary execution of clojure.core fns</summary>
                <type id="1" iconUrl="http://dev.clojure.org/jira/images/icons/bug.gif">Defect</type>
                                <priority id="4" iconUrl="http://dev.clojure.org/jira/images/icons/priority_minor.gif">Minor</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="craigbrozefsky">Craig Brozefsky</reporter>
                        <labels>
                    </labels>
                <created>Mon, 23 Jul 2012 21:00:38 -0500</created>
                <updated>Sun, 5 Aug 2012 10:00:07 -0500</updated>
                                    <version>Release 1.2</version>
                <version>Release 1.3</version>
                <version>Release 1.4</version>
                                                        <due></due>
                    <votes>1</votes>
                        <watches>1</watches>
                        <comments>
                    <comment id="29043" author="amalloy" created="Wed, 25 Jul 2012 16:37:07 -0500"  >&lt;p&gt;One apparent problem with this patch is that you throw an exception for :refer. You should add that, and make sure there aren&apos;t any others missing. Also, #{x y z} is better than (set &lt;span class=&quot;error&quot;&gt;&amp;#91;x y z&amp;#93;&lt;/span&gt;), and you should probably use pr-str rather than str, although I can&apos;t think of a case where it matters for the objects in question.&lt;/p&gt;</comment>
                    <comment id="29051" author="jafingerhut" created="Thu, 26 Jul 2012 18:31:58 -0500"  >&lt;p&gt;A more minor detail of patch formatting &amp;#8211; please attach your patch in git format.  See the instructions under the section heading &quot;Development&quot; on this web page: &lt;a href=&quot;http://dev.clojure.org/display/design/JIRA+workflow&quot;&gt;http://dev.clojure.org/display/design/JIRA+workflow&lt;/a&gt;&lt;/p&gt;</comment>
                    <comment id="29085" author="craigbrozefsky" created="Sun, 5 Aug 2012 09:53:15 -0500"  >&lt;p&gt;git format-patch version of the diff, with the edits suggested by other maintainers.&lt;/p&gt;</comment>
                    <comment id="29086" author="craigbrozefsky" created="Sun, 5 Aug 2012 10:00:07 -0500"  >&lt;p&gt;Alan: please note that :refer was not mentioned in the docstring for ns, or used in any of the unit tests for clojure.&lt;/p&gt;

&lt;p&gt;Are you sure that it is an expected argument, or just an arrangement that happens to work under the current ns macro?  The docstring for &apos;refer itself says to use :use in ns macros instead of calling refer.&lt;/p&gt;

&lt;p&gt;I added &quot;refer&quot; to the set of accepted references all the same.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="11412" name="ns-patch.diff" size="1076" author="craigbrozefsky" created="Sun, 5 Aug 2012 09:53:15 -0500" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10000" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Patch</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10001">Code</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[CLJ-776] seque broken for some BlockingQueues</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-776</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;clojure.core/seque takes an optional argument that can be the initial capacity for a LinkedBlockingQueue or an instance of the BlockingQueue interface.&lt;/p&gt;

&lt;p&gt;PriorityBlockingQueue is such a class, but fails to work because seque makes a few assumptions about BlockingQueues that are not true for all BlockingQueues.&lt;/p&gt;

&lt;p&gt;user=&amp;gt; (def s (seque (java.util.concurrent.PriorityBlockingQueue. 100) (shuffle (range 100))))&lt;br/&gt;
#&apos;user/s&lt;br/&gt;
user=&amp;gt; s&lt;br/&gt;
java.lang.NullPointerException&lt;/p&gt;

&lt;p&gt;user=&amp;gt; (seque (java.util.concurrent.SynchronousQueue.) (shuffle (range 100)))&lt;br/&gt;
&amp;lt;never finishes&amp;gt;&lt;/p&gt;

&lt;p&gt;user=&amp;gt; (seque (java.util.concurrent.ArrayBlockingQueue. 10) (shuffle (range 100)))&lt;br/&gt;
(39 41 27 76 1 24 92 34 72 37 67 99 38 21 5 64 9 26 59 43 82 65 3 11 31 93 50 63 15 90 13 75 40 97 57 88 86 53 19 83 2 12 54 49 71 28 68 73 96 44 8 98 61 6 22 25 78 66 32 84 60 94 70 7 89 4 33 55 74 81 51 56 62 87 69 80 77 20 30 91 52 10 48 18 36 58 47 14 16 42 35 17 95 0 45 85 29 23 46 79)&lt;/p&gt;</description>
                <environment></environment>
            <key id="14402">CLJ-776</key>
            <summary>seque broken for some BlockingQueues</summary>
                <type id="1" iconUrl="http://dev.clojure.org/jira/images/icons/bug.gif">Defect</type>
                                <priority id="4" iconUrl="http://dev.clojure.org/jira/images/icons/priority_minor.gif">Minor</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="pepijndevos">Pepijn de Vos</reporter>
                        <labels>
                    </labels>
                <created>Thu, 21 Apr 2011 08:33:48 -0500</created>
                <updated>Fri, 22 Apr 2011 09:27:55 -0500</updated>
                                                                            <due></due>
                    <votes>0</votes>
                        <watches>1</watches>
                        <comments>
                    <comment id="26378" author="pepijndevos" created="Thu, 21 Apr 2011 11:32:12 -0500"  >&lt;p&gt;A working implementation with some tests.&lt;/p&gt;</comment>
                    <comment id="26381" author="pepijndevos" created="Fri, 22 Apr 2011 09:27:55 -0500"  >&lt;p&gt;Attachement removed, I&apos;m working on it here: &lt;a href=&quot;https://gist.github.com/934781&quot;&gt;https://gist.github.com/934781&lt;/a&gt;&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                                                                                            </customfields>
    </item>

<item>
            <title>[CLJ-809] fn&apos;s created using defn should not lexical shadow the var that holds them</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-809</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;currently (defn foo &lt;span class=&quot;error&quot;&gt;&amp;#91;x&amp;#93;&lt;/span&gt; (foo x)) expands to something like (def foo&lt;br/&gt;
(fn foo &lt;span class=&quot;error&quot;&gt;&amp;#91;x&amp;#93;&lt;/span&gt; (foo x))) so the fn is bound to foo lexically in the scope&lt;br/&gt;
of the fn body.&lt;/p&gt;

&lt;p&gt;because of this lexical shadowing self calls to fns defined with defn&lt;br/&gt;
do not incur the overhead of var dereferencing, I assume this is the&lt;br/&gt;
reason it was added.&lt;/p&gt;

&lt;p&gt;the lexical shadowing also breaks memoization if you create the&lt;br/&gt;
memoized functions via (alter-var-root #&apos;foo memoize) and several&lt;br/&gt;
macros here and there emit code in this style, since reusing defn is&lt;br/&gt;
the easiest way to get all the good juicy metadata bits like arglists,&lt;br/&gt;
etc.&lt;/p&gt;

&lt;p&gt;1.3 has changes to eliminate some of the cost of going through the var.&lt;/p&gt;

&lt;p&gt;since going through the var is much cheaper now it would be nice to &lt;br/&gt;
eliminate the lexical shadowing.&lt;/p&gt;

&lt;p&gt;&lt;a href=&quot;http://groups.google.com/group/clojure-dev/browse_thread/thread/33b52b24616967f?hl=en&quot;&gt;http://groups.google.com/group/clojure-dev/browse_thread/thread/33b52b24616967f?hl=en&lt;/a&gt;&lt;/p&gt;</description>
                <environment></environment>
            <key id="14461">CLJ-809</key>
            <summary>fn&apos;s created using defn should not lexical shadow the var that holds them</summary>
                <type id="4" iconUrl="http://dev.clojure.org/jira/images/icons/improvement.gif">Enhancement</type>
                                <priority id="4" iconUrl="http://dev.clojure.org/jira/images/icons/priority_minor.gif">Minor</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="hiredman">Kevin Downey</reporter>
                        <labels>
                    </labels>
                <created>Sat, 11 Jun 2011 14:37:22 -0500</created>
                <updated>Fri, 29 Jul 2011 07:39:50 -0500</updated>
                                    <version>Release 1.2</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>2</watches>
                        <comments>
                    <comment id="26505" author="hiredman" created="Sat, 11 Jun 2011 14:40:23 -0500"  >&lt;p&gt;tests indicate that accessing the fn through the var vs. accessing through the lexical binding have very similar access times&lt;/p&gt;

&lt;p&gt;&lt;a href=&quot;https://gist.github.com/1013008&quot;&gt;https://gist.github.com/1013008&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;results in&lt;/p&gt;

&lt;p&gt;$ java -jar clojure.jar ~/src/lexicaltest.clj&lt;br/&gt;
lexical binding run 0&lt;br/&gt;
&quot;Elapsed time: 86.739 msecs&quot;&lt;br/&gt;
lexical binding run 1&lt;br/&gt;
&quot;Elapsed time: 8.062 msecs&quot;&lt;br/&gt;
lexical binding run 2&lt;br/&gt;
&quot;Elapsed time: 16.182 msecs&quot;&lt;br/&gt;
var binding run 0&lt;br/&gt;
&quot;Elapsed time: 61.136 msecs&quot;&lt;br/&gt;
var binding run 1&lt;br/&gt;
&quot;Elapsed time: 40.317 msecs&quot;&lt;br/&gt;
var binding run 2&lt;br/&gt;
&quot;Elapsed time: 11.641 msecs&quot;&lt;br/&gt;
$&lt;/p&gt;</comment>
                    <comment id="26510" author="jawolfe" created="Mon, 13 Jun 2011 17:05:00 -0500"  >&lt;p&gt;Here&apos;s another test that makes sure no JIT funny business (e.g. dead code elimination) is going on, and also looks at primitive hinted versions.&lt;/p&gt;

&lt;p&gt;&lt;a href=&quot;https://gist.github.com/1023816&quot;&gt;https://gist.github.com/1023816&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;var-obj result, time: 14930352 ,&quot;Elapsed time: 965.577 msecs&quot;&lt;br/&gt;
lex-obj result, time: 14930352 ,&quot;Elapsed time: 957.741 msecs&quot;&lt;br/&gt;
var-prim result, time: 14930352 ,&quot;Elapsed time: 770.411 msecs&quot;&lt;br/&gt;
lex-prim result, time: 14930352 ,&quot;Elapsed time: 113.412 msecs&quot;&lt;br/&gt;
nil&lt;/p&gt;

&lt;p&gt;I&apos;m not sure how to properly hint the var in the var-prim version to get truly comparable results.  In any case, this use case should definitely be kept in mind. &lt;/p&gt;</comment>
                    <comment id="26511" author="hiredman" created="Mon, 13 Jun 2011 17:35:15 -0500"  >&lt;p&gt;I think the point is we want to make sure the jvm can optimize both just as well, so making the code purposefully unoptimizable is kind of silly, yes? &lt;/p&gt;</comment>
                    <comment id="26526" author="jawolfe" created="Tue, 21 Jun 2011 16:41:55 -0500"  >&lt;p&gt;@Kevin In your gist, the return value of foo is not used, and foo has no side effects.  A sufficiently smart compiler could optimize the calls out entirely, which would not tell us much about the runtime of foo.  &lt;/p&gt;</comment>
                    <comment id="26541" author="aaron" created="Tue, 28 Jun 2011 18:49:28 -0500"  >&lt;p&gt;Rich: Given the performance testing (in the email thread) what is the next step here?&lt;/p&gt;

&lt;ul&gt;
	&lt;li&gt;more thorough testing&lt;/li&gt;
	&lt;li&gt;patch?&lt;/li&gt;
&lt;/ul&gt;


&lt;p&gt;Are there things that this might break that we need to consider?&lt;/p&gt;</comment>
                    <comment id="26667" author="richhickey" created="Fri, 29 Jul 2011 07:39:33 -0500"  >&lt;p&gt;Someone needs to make a patch, and then test perf with and without the patch. These simulated tests aren&apos;t necessarily indicative. Naive fib is an ok test once you have a patch. And yes, more things might break - needs careful assessment.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                                                                                            </customfields>
    </item>

<item>
            <title>[CLJ-983] proxy-super does not restore original binding if call throws exception</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-983</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;The code for proxy-call-with-super internally used by proxy-super does not handle exceptions from the call method:&lt;/p&gt;

&lt;p&gt;(defn proxy-call-with-super &lt;span class=&quot;error&quot;&gt;&amp;#91;call this meth&amp;#93;&lt;/span&gt;&lt;br/&gt;
 (let &lt;span class=&quot;error&quot;&gt;&amp;#91;m (proxy-mappings this)&amp;#93;&lt;/span&gt;&lt;br/&gt;
    (update-proxy this (assoc m meth nil))&lt;br/&gt;
    (let &lt;span class=&quot;error&quot;&gt;&amp;#91;ret (call)&amp;#93;&lt;/span&gt;&lt;br/&gt;
      (update-proxy this m)&lt;br/&gt;
      ret)))&lt;/p&gt;

&lt;p&gt;As a result the following sequence behaves unexpectedly:&lt;br/&gt;
(def obj (proxy &lt;span class=&quot;error&quot;&gt;&amp;#91;java.lang.ClassLoader&amp;#93;&lt;/span&gt; []&lt;br/&gt;
		      (loadClass &lt;span class=&quot;error&quot;&gt;&amp;#91;cl&amp;#93;&lt;/span&gt; (println &quot;enter&quot;)&lt;br/&gt;
				 (proxy-super loadClass cl))))&lt;br/&gt;
(.loadClass obj &quot;nonexistent&quot;)&lt;br/&gt;
;; prints enter, then throws ClassNotFoundException&lt;br/&gt;
(.loadClass obj &quot;nonexistent&quot;)&lt;br/&gt;
;; does not print anything before throwing cnfe&lt;/p&gt;


&lt;p&gt;A try-finally block around the invocation would solve this particular issue.&lt;/p&gt;</description>
                <environment></environment>
            <key id="15409">CLJ-983</key>
            <summary>proxy-super does not restore original binding if call throws exception</summary>
                <type id="1" iconUrl="http://dev.clojure.org/jira/images/icons/bug.gif">Defect</type>
                                <priority id="4" iconUrl="http://dev.clojure.org/jira/images/icons/priority_minor.gif">Minor</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="tuor713">Valentin Mahrwald</reporter>
                        <labels>
                        <label>bug</label>
                    </labels>
                <created>Sat, 5 May 2012 03:36:15 -0500</created>
                <updated>Sat, 5 May 2012 09:04:26 -0500</updated>
                                    <version>Release 1.1</version>
                <version>Release 1.2</version>
                <version>Release 1.3</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                        <comments>
                    <comment id="28392" author="tuor713" created="Sat, 5 May 2012 09:04:26 -0500"  >&lt;p&gt;Test &amp;amp; fix patch on latest Clojure github branch.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="11171" name="proxy_super.patch" size="1867" author="tuor713" created="Sat, 5 May 2012 09:04:26 -0500" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                                                                                            </customfields>
    </item>

<item>
            <title>[CLJ-888] defprotocol should throw error when signatures include variable number of parameters</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-888</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;I tried to use &amp;amp; in the signature for a method in defprotocol. Apparently (see below), this is compiled so that &amp;amp; becomes a simple parameter name, and there is no special handling for variable number of parameters. I think the use of &amp;amp; in a protocol signature ought to be detected and immediately cause an exception (I also think this restriction on the signatures ought to be documented; I couldn&apos;t find it specified in the current documentation, though of course it is implied (as I later realized) by the fact that defprotocol creates a Java interface).&lt;/p&gt;

&lt;p&gt;user=&amp;gt; (defprotocol Applier (app &lt;span class=&quot;error&quot;&gt;&amp;#91;this f &amp;amp; args&amp;#93;&lt;/span&gt;))&lt;br/&gt;
Applier&lt;br/&gt;
user=&amp;gt; (deftype A [] Applier (app &lt;span class=&quot;error&quot;&gt;&amp;#91;_ f &amp;amp; args&amp;#93;&lt;/span&gt; (prn f &amp;amp; args) (apply f args)))&lt;br/&gt;
user.A&lt;br/&gt;
user=&amp;gt; (app (A.) + 1 2)&lt;br/&gt;
#&amp;lt;core$&lt;em&gt;PLUS&lt;/em&gt; clojure.core$&lt;em&gt;PLUS&lt;/em&gt;@5d9d0d20&amp;gt; 1 2&lt;br/&gt;
IllegalArgumentException Don&apos;t know how to create ISeq from: java.lang.Long  &lt;br/&gt;
clojure.lang.RT.seqFrom (RT.java:487)&lt;/p&gt;
</description>
                <environment></environment>
            <key id="15039">CLJ-888</key>
            <summary>defprotocol should throw error when signatures include variable number of parameters</summary>
                <type id="4" iconUrl="http://dev.clojure.org/jira/images/icons/improvement.gif">Enhancement</type>
                                <priority id="4" iconUrl="http://dev.clojure.org/jira/images/icons/priority_minor.gif">Minor</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="glchapman">Greg Chapman</reporter>
                        <labels>
                    </labels>
                <created>Tue, 29 Nov 2011 16:38:02 -0600</created>
                <updated>Tue, 29 Nov 2011 16:38:02 -0600</updated>
                                    <version>Release 1.3</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>1</watches>
                                <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                                                                                            </customfields>
    </item>

<item>
            <title>[CLJ-1039] Using &apos;def with metadata {:type :anything} throws ClassCastException</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1039</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;In lein 1.7.1 (and CCW) the form (def ^{:type :anything} mydef 1) throws &quot;ClassCastException clojure.lang.Var cannot be cast to clojure.lang.IObj  clojure.core/with-meta (core.clj:211)&quot;.&lt;br/&gt;
This seems to be due to setting the :type metadata. With other metadata keys it works well.&lt;/p&gt;

&lt;p&gt;If it is intended to forbid setting the :type metadata, then there should be an appropriate error message instead of the ClassCastException&lt;/p&gt;


&lt;p&gt;In lein2 repl which is using &quot;REPL-y 0.1.0-beta8&quot; the exception does not occur.&lt;/p&gt;

&lt;p&gt;Full stacktrace:&lt;br/&gt;
java.lang.ClassCastException: clojure.lang.Var cannot be cast to clojure.lang.IObj&lt;br/&gt;
 at clojure.core$with_meta.invoke (core.clj:211)&lt;br/&gt;
    clojure.core$vary_meta.doInvoke (core.clj:617)&lt;br/&gt;
    clojure.lang.RestFn.invoke (RestFn.java:425)&lt;br/&gt;
    clojure.core/fn (core_print.clj:76)&lt;br/&gt;
    clojure.lang.MultiFn.invoke (MultiFn.java:167)&lt;br/&gt;
    clojure.core$pr_on.invoke (core.clj:3266)&lt;br/&gt;
    clojure.core$pr.invoke (core.clj:3278)&lt;br/&gt;
    clojure.lang.AFn.applyToHelper (AFn.java:161)&lt;br/&gt;
    clojure.lang.RestFn.applyTo (RestFn.java:132)&lt;br/&gt;
    clojure.core$apply.invoke (core.clj:601)&lt;br/&gt;
    clojure.core$prn.doInvoke (core.clj:3311)&lt;br/&gt;
    clojure.lang.RestFn.invoke (RestFn.java:408)&lt;br/&gt;
    clojure.main$repl$read_eval_print__6405.invoke (main.clj:246)&lt;br/&gt;
    clojure.main$repl$fn__6410.invoke (main.clj:266)&lt;br/&gt;
    clojure.main$repl.doInvoke (main.clj:266)&lt;br/&gt;
    clojure.lang.RestFn.invoke (RestFn.java:512)&lt;br/&gt;
    user$eval27$acc_&lt;em&gt;3261&lt;/em&gt;&lt;em&gt;auto&lt;/em&gt;__&lt;em&gt;30$fn&lt;/em&gt;_32.invoke (NO_SOURCE_FILE:1)&lt;br/&gt;
    clojure.lang.AFn.run (AFn.java:24)&lt;br/&gt;
    java.lang.Thread.run (Thread.java:662)&lt;/p&gt;</description>
                <environment>Ubuntu, lein 1.7.1 - lein repl</environment>
            <key id="15618">CLJ-1039</key>
            <summary>Using &apos;def with metadata {:type :anything} throws ClassCastException</summary>
                <type id="1" iconUrl="http://dev.clojure.org/jira/images/icons/bug.gif">Defect</type>
                                <priority id="4" iconUrl="http://dev.clojure.org/jira/images/icons/priority_minor.gif">Minor</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="gv">Gunnar V&#246;lkel</reporter>
                        <labels>
                    </labels>
                <created>Thu, 9 Aug 2012 06:05:34 -0500</created>
                <updated>Fri, 10 Aug 2012 13:40:31 -0500</updated>
                                    <version>Release 1.4</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                        <comments>
                    <comment id="29106" author="stu" created="Fri, 10 Aug 2012 13:40:31 -0500"  >&lt;p&gt;This is caused by the printer dispatch function&lt;/p&gt;

&lt;div class=&quot;preformatted panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;preformattedContent panelContent&quot;&gt;
&lt;pre&gt;(defmulti print-method (fn [x writer]
                         (let [t (get (meta x) :type)]
                           (if (keyword? t) t (class x)))))
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;which ends up calling the default dispatch, which tries to vary-meta.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_10002" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Approval</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10003">Vetted</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                    <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                                                                                            </customfields>
    </item>

<item>
            <title>[CLJ-929] Accessing Java property starting with _ has issues in 1.4</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-929</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;When attempting to use interop syntax with symbols which aren&apos;t legal Java names (such as deleted?), the names are mangled a bit. That&apos;s necessary, of course, and the method of munging can be internal to the compiler. However, the behavior when munging changed a little between 1.3 and 1.4 beta1. Obviously the specifics of munging are something I should avoid relying on, but the way it changed looks like an accident or a bug even so.&lt;/p&gt;

&lt;p&gt;The use-case I ran into is that defrecords contain a field named __meta for tracking their metadata. In both 1.3 and 1.4 you can get at that field with (. record __meta), which avoids munging. But on 1.3 (. record --meta) also accesses it (translating each - to a _), while on 1.4 (. record -meta) works and (. record --meta) doesn&apos;t.&lt;/p&gt;

&lt;p&gt;Actually, looking at line 883 of Compiler.java, it looks like this may be related to the (. foo -property) syntax ported from CLJS, and indeed (. record ---meta) works, I guess by reducing to an &quot;old style&quot; (. record --meta). So that clears up why --meta fails: it&apos;s looking for __meta. I&apos;m still not clear on why (. record -meta) works, though.&lt;/p&gt;

&lt;p&gt;So it looks like the - prefix for properties is not 100% backwards-compatible like it seemed to be. Is this an issue we need to fix, or is the recommendation simply to never have fields that start with - or _?&lt;/p&gt;</description>
                <environment></environment>
            <key id="15208">CLJ-929</key>
            <summary>Accessing Java property starting with _ has issues in 1.4</summary>
                <type id="1" iconUrl="http://dev.clojure.org/jira/images/icons/bug.gif">Defect</type>
                                <priority id="4" iconUrl="http://dev.clojure.org/jira/images/icons/priority_minor.gif">Minor</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="amalloy">Alan Malloy</reporter>
                        <labels>
                    </labels>
                <created>Tue, 7 Feb 2012 17:50:05 -0600</created>
                <updated>Thu, 9 Feb 2012 15:01:53 -0600</updated>
                                    <version>Release 1.4</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>2</watches>
                        <comments>
                    <comment id="27701" author="fogus" created="Thu, 9 Feb 2012 14:33:39 -0600"  >&lt;p&gt;Is this a general problem with fields starting with _ or just fields named __meta as in (defrecord &lt;span class=&quot;error&quot;&gt;&amp;#91;__meta&amp;#93;&lt;/span&gt; ...)&lt;/p&gt;
</comment>
                    <comment id="27702" author="amalloy" created="Thu, 9 Feb 2012 15:01:53 -0600"  >&lt;p&gt;It&apos;s a general issue. (defrecord &lt;span class=&quot;error&quot;&gt;&amp;#91;__meta&amp;#93;&lt;/span&gt;) actually breaks immediately, because the record mechanism itself generates a field named __meta, but any field named with a - or _ prefix has this issue.&lt;/p&gt;

&lt;p&gt;user=&amp;gt; (defrecord Foo &lt;span class=&quot;error&quot;&gt;&amp;#91;-blah&amp;#93;&lt;/span&gt;)&lt;br/&gt;
user.Foo&lt;br/&gt;
user=&amp;gt; (.-blah (Foo. 1))&lt;br/&gt;
IllegalArgumentException No matching field found: blah for class user.Foo  clojure.lang.Reflector.getInstanceField (Reflector.java:289)&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                                                                                            </customfields>
    </item>

<item>
            <title>[CLJ-958] Make APersistentVector.iterator slightly more efficient</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-958</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;The attached patch uses a sequence to create an iterator for persistent vectors.  It should be slightly more efficient for PersistentVector objects than repeatedly calling nth (for reasons that I outline in the commit message).  &lt;/p&gt;</description>
                <environment></environment>
            <key id="15290">CLJ-958</key>
            <summary>Make APersistentVector.iterator slightly more efficient</summary>
                <type id="4" iconUrl="http://dev.clojure.org/jira/images/icons/improvement.gif">Enhancement</type>
                                <priority id="4" iconUrl="http://dev.clojure.org/jira/images/icons/priority_minor.gif">Minor</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="chrismgray">Chris Gray</reporter>
                        <labels>
                    </labels>
                <created>Fri, 23 Mar 2012 13:28:07 -0500</created>
                <updated>Tue, 14 Aug 2012 13:43:53 -0500</updated>
                                                                            <due></due>
                    <votes>0</votes>
                        <watches>1</watches>
                                <attachments>
                    <attachment id="11003" name="0001-Make-APersistentVector.iterator-slightly-more-effici.patch" size="1394" author="chrismgray" created="Fri, 23 Mar 2012 13:28:07 -0500" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_10002" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Approval</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10008">Not Approved</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                    <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10000" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Patch</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10001">Code</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[CLJ-957] Typehints for variadic methods in deftype fail to compile</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-957</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;When a method defined by a protocol has multiple typehinted signatures, it is impossible to implement them using deftype because deftype throws away the typehints.  The compiler then looks for the proper signatures (i.e. with typehints) and throws an exception when it can&apos;t find them.&lt;/p&gt;</description>
                <environment></environment>
            <key id="15289">CLJ-957</key>
            <summary>Typehints for variadic methods in deftype fail to compile</summary>
                <type id="1" iconUrl="http://dev.clojure.org/jira/images/icons/bug.gif">Defect</type>
                                <priority id="4" iconUrl="http://dev.clojure.org/jira/images/icons/priority_minor.gif">Minor</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="chrismgray">Chris Gray</reporter>
                        <labels>
                    </labels>
                <created>Thu, 22 Mar 2012 17:24:31 -0500</created>
                <updated>Sun, 19 Aug 2012 04:31:33 -0500</updated>
                                    <version>Release 1.3</version>
                <version>Release 1.4</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                        <comments>
                    <comment id="27982" author="chrismgray" created="Thu, 22 Mar 2012 17:41:46 -0500"  >&lt;p&gt;Clojure-dev discussion started here: &lt;a href=&quot;http://groups.google.com/group/clojure-dev/browse_thread/thread/1f106a21ec1ce3de&quot;&gt;http://groups.google.com/group/clojure-dev/browse_thread/thread/1f106a21ec1ce3de&lt;/a&gt;&lt;/p&gt;</comment>
                    <comment id="29228" author="jafingerhut" created="Sun, 19 Aug 2012 04:31:33 -0500"  >&lt;p&gt;Patch clj-957-allow-typehinting-of-method-signatures-in-deftype-patch2.txt dated Aug 19 2012 is identical to Chris Gray&apos;s patch 0001-Allow-for-typehinting-of-method-signatures-in-deftyp.patch dated Mar 22, 2012, except it has some updated context lines so that it applies cleanly to latest master.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="11002" name="0001-Allow-for-typehinting-of-method-signatures-in-deftyp.patch" size="3242" author="chrismgray" created="Thu, 22 Mar 2012 17:24:31 -0500" />
                    <attachment id="11448" name="clj-957-allow-typehinting-of-method-signatures-in-deftype-patch2.txt" size="3247" author="jafingerhut" created="Sun, 19 Aug 2012 04:31:32 -0500" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_10002" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Approval</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10008">Not Approved</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                    <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10000" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Patch</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10002">Code and Test</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[CLJ-668] Improve slurp performance by using native Java StringWriter and jio/copy</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-668</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;Instead of copying each character from InputReader to StringBuffer.&lt;/p&gt;

&lt;p&gt;Performance improvement:&lt;/p&gt;
&lt;div class=&quot;preformatted panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;preformattedContent panelContent&quot;&gt;
&lt;pre&gt;From:
user&amp;gt; (time (count (slurp &quot;/home/juergen/test.dat&quot;)))
&quot;Elapsed time: 4269.980863 msecs&quot;
104857600
To:
user&amp;gt; (time (count (slurp &quot;/home/juergen/test.dat&quot;)))
&quot;Elapsed time: 1140.854023 msecs&quot;
104857600
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;Patch: &lt;a href=&quot;http://github.com/juergenhoetzel/clojure/commit/af1a5713cd485ba5f1db25c37906ebaf7d474b47&quot;&gt;http://github.com/juergenhoetzel/clojure/commit/af1a5713cd485ba5f1db25c37906ebaf7d474b47&lt;/a&gt;&lt;/p&gt;</description>
                <environment></environment>
            <key id="14270">CLJ-668</key>
            <summary>Improve slurp performance by using native Java StringWriter and jio/copy</summary>
                <type id="4" iconUrl="http://dev.clojure.org/jira/images/icons/improvement.gif">Enhancement</type>
                                <priority id="4" iconUrl="http://dev.clojure.org/jira/images/icons/priority_minor.gif">Minor</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="juergenhoetzel">J&#252;rgen H&#246;tzel</reporter>
                        <labels>
                    </labels>
                <created>Mon, 1 Nov 2010 15:58:31 -0500</created>
                <updated>Mon, 1 Nov 2010 15:58:31 -0500</updated>
                                    <version>Release 1.3</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>1</watches>
                                <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                                                                                            </customfields>
    </item>

<item>
            <title>[CLJ-997] max-key and min-key to return the first entry in case of several candidates</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-997</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;Consider the following code:&lt;/p&gt;

&lt;p&gt;(def values [&lt;span class=&quot;error&quot;&gt;&amp;#91;1 2&amp;#93;&lt;/span&gt; &lt;span class=&quot;error&quot;&gt;&amp;#91;3 4&amp;#93;&lt;/span&gt; &lt;span class=&quot;error&quot;&gt;&amp;#91;5&amp;#93;&lt;/span&gt; &lt;span class=&quot;error&quot;&gt;&amp;#91;6 7&amp;#93;&lt;/span&gt; &lt;span class=&quot;error&quot;&gt;&amp;#91;8&amp;#93;&lt;/span&gt;])&lt;br/&gt;
(apply max-key count values)&lt;br/&gt;
; =&amp;gt; &lt;span class=&quot;error&quot;&gt;&amp;#91;6 7&amp;#93;&lt;/span&gt;&lt;/p&gt;

&lt;p&gt;Which returns the &lt;b&gt;last&lt;/b&gt; max entry &lt;span class=&quot;error&quot;&gt;&amp;#91;6 7&amp;#93;&lt;/span&gt;. Why its not the first max entry &lt;span class=&quot;error&quot;&gt;&amp;#91;1 2&amp;#93;&lt;/span&gt;?&lt;br/&gt;
Well, truth is &quot;max-key&quot; gives no warranty on which max value will be returned.&lt;/p&gt;

&lt;p&gt;Consider the following example in Scala:&lt;/p&gt;

&lt;p&gt;println(List(List(0, 1, 2), List(2, 3, 4), List(1), List(1, 2, 3)).maxBy(_.length))&lt;br/&gt;
&amp;gt; List(0, 1, 2)&lt;/p&gt;

&lt;p&gt;The very same function in Scala returns the &lt;b&gt;first&lt;/b&gt; max entry (by default).&lt;/p&gt;



&lt;p&gt;The code from relase 1.4 file &quot;clojure/core.clj#4419-4426&quot; looks is:&lt;br/&gt;
=======================&lt;br/&gt;
4419: (defn max-key&lt;br/&gt;
4420:  &quot;Returns the x for which (k x), a number, is greatest.&quot;&lt;br/&gt;
4421:  {:added &quot;1.0&quot;&lt;br/&gt;
4422:   :static true}&lt;br/&gt;
4423:  (&lt;span class=&quot;error&quot;&gt;&amp;#91;k x&amp;#93;&lt;/span&gt; x)&lt;br/&gt;
4424:  (&lt;span class=&quot;error&quot;&gt;&amp;#91;k x y&amp;#93;&lt;/span&gt; (if (&amp;gt; (k x) (k y)) x y))&lt;br/&gt;
4425:  (&lt;span class=&quot;error&quot;&gt;&amp;#91;k x y &amp;amp; more&amp;#93;&lt;/span&gt;&lt;br/&gt;
4426:   (reduce1 #(max-key k %1 %2) (max-key k x y) more)))&lt;br/&gt;
=======================&lt;/p&gt;

&lt;p&gt;I am unsure what is the motivation in returning the last candidate, but&lt;/p&gt;

&lt;p&gt;I suggest two following things:&lt;/p&gt;

&lt;p&gt;1. Make &quot;max-key&quot; and &quot;min-key&quot; return the &lt;b&gt;first&lt;/b&gt; max/min entry if there are several candidates.&lt;/p&gt;

&lt;p&gt;  This behavior seems more natural/convenient (to me), because in most cases you want to get first &quot;winner&quot;.&lt;br/&gt;
  (e.g. find the first biggest vector in a sequence) and less often you need to get the last entry &amp;#8211; in those cases&lt;br/&gt;
   you can do &quot;reverse&quot; before feeding a sequence to &quot;max-key&quot;, thus it seems having &quot;return first max&quot; behavior more useful.&lt;/p&gt;

&lt;p&gt;  Line #4424 should have &quot;&amp;gt;=&quot; instead of &quot;&amp;gt;&quot;.&lt;/p&gt;

&lt;p&gt;2. Make &quot;max-key&quot; and &quot;min-key&quot; make warranty on order, which max/min entry will be returned (either first or last).&lt;/p&gt;

&lt;p&gt;  Line #4420 should say &quot;Returns the x for which (k x), a number, is greatest. In case of several matches, the first max entry will be returned&quot; or the same doc, but saying &quot;the last max entry will returned&quot;.&lt;/p&gt;</description>
                <environment></environment>
            <key id="15453">CLJ-997</key>
            <summary>max-key and min-key to return the first entry in case of several candidates</summary>
                <type id="1" iconUrl="http://dev.clojure.org/jira/images/icons/bug.gif">Defect</type>
                                <priority id="4" iconUrl="http://dev.clojure.org/jira/images/icons/priority_minor.gif">Minor</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="oshyshko">Oleksandr Shyshko</reporter>
                        <labels>
                    </labels>
                <created>Fri, 18 May 2012 06:03:15 -0500</created>
                <updated>Fri, 18 May 2012 16:03:44 -0500</updated>
                                    <version>Release 1.3</version>
                <version>Release 1.4</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>1</watches>
                        <comments>
                    <comment id="28526" author="steveminer@gmail.com" created="Fri, 18 May 2012 16:03:44 -0500"  >&lt;p&gt;The current behavior matches the documentation so I wouldn&apos;t consider it a &quot;defect&quot;.  There doesn&apos;t seem to be a compelling reason to impose a tie-breaker rule on the implementation.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                                                                                            </customfields>
    </item>

<item>
            <title>[CLJ-373] update-in with empty key paths</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-373</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;To the topic of get-in and update-in. While I realize this is not a bug it is odd and in my eyes unexpected and unwanted behavior.&lt;/p&gt;

&lt;p&gt;get-in called with an empty path returns the hashmap it was given to walk through - this is as I expect and makes a lot of sense when dynamically (with generated pathes ) walking a hash map.&lt;/p&gt;

&lt;p&gt;update-in behaves differently and while from the implementation side, it&apos;s behavior too makes sense, it does not work as expected (at least not for me) update-in with an empty map creates a new key &apos;nil&apos; so:&lt;/p&gt;

&lt;p&gt;(update-in {...} [] f) ist he same as (update-in {...} &lt;span class=&quot;error&quot;&gt;&amp;#91;nil&amp;#93;&lt;/span&gt; f) while (get-in {...} []) is not the same as (get-in {...} &lt;span class=&quot;error&quot;&gt;&amp;#91;nil&amp;#93;&lt;/span&gt;) and of cause differs from what update-in does.&lt;/p&gt;

&lt;p&gt;For automatically walking trees the behavior of get-in makes a lot more sense since the current behavior of update-in forces you to check for empty paths and if they are empty fall back to plain assoc and get (or get-in since this works):&lt;/p&gt;
&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;(&lt;span class=&quot;code-keyword&quot;&gt;if&lt;/span&gt;-let [r (butlast @path)]
(&lt;span class=&quot;code-keyword&quot;&gt;do&lt;/span&gt;
  (alter m update-in r dissoc (last @path))
  (alter m update-in r assoc {:name @sr} c))
(&lt;span class=&quot;code-keyword&quot;&gt;do&lt;/span&gt;
  (alter m dissoc (last @path))
  (alter m assoc {:name @sr} c)))&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;Next argument is that update-in with an empty map working on nil isn&apos;t easy to gasp, one needs to know the implementation details to realize that it works, I think 90% of the people reading update-in with [] will not instinctively know that it works on the key nil, so changing this would most likely not break any current code, and if it would the code would be bad anyway &lt;img class=&quot;emoticon&quot; src=&quot;http://dev.clojure.org/jira/images/icons/emoticons/tongue.gif&quot; height=&quot;20&quot; width=&quot;20&quot; align=&quot;absmiddle&quot; alt=&quot;&quot; border=&quot;0&quot;/&gt;.&lt;/p&gt;

&lt;p&gt;Chouser has, a very nice solution on the mailing list that would fix the problem I&apos;m not sure if I&apos;m entitled to post it here since I did not wrote it but it can be found in this thread: &lt;a href=&quot;http://groups.google.com/group/clojure/browse_thread/thread/de5b20b8c3fe498b?hl=en&quot;&gt;http://groups.google.com/group/clojure/browse_thread/thread/de5b20b8c3fe498b?hl=en&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;Regards,&lt;br/&gt;
Heinz&lt;/p&gt;</description>
                <environment></environment>
            <key id="13770">CLJ-373</key>
            <summary>update-in with empty key paths</summary>
                <type id="4" iconUrl="http://dev.clojure.org/jira/images/icons/improvement.gif">Enhancement</type>
                                <priority id="4" iconUrl="http://dev.clojure.org/jira/images/icons/priority_minor.gif">Minor</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="importer">Assembla Importer</reporter>
                        <labels>
                    </labels>
                <created>Fri, 4 Jun 2010 10:31:00 -0500</created>
                <updated>Sat, 8 Sep 2012 06:13:29 -0500</updated>
                                                                            <due></due>
                    <votes>1</votes>
                        <watches>4</watches>
                        <comments>
                    <comment id="23998" author="importer" created="Fri, 8 Oct 2010 10:33:00 -0500"  >&lt;p&gt;Converted from &lt;a href=&quot;http://www.assembla.com/spaces/clojure/tickets/373&quot;&gt;http://www.assembla.com/spaces/clojure/tickets/373&lt;/a&gt;&lt;/p&gt;</comment>
                    <comment id="25938" author="chouser@n01se.net" created="Sat, 13 Nov 2010 18:37:53 -0600"  >&lt;p&gt;I&apos;ve attached my code from the g.group thread in the form of a patch, in case it&apos;s sufficient.  (Thanks to abedra for the gentle kick in the pants.)&lt;/p&gt;</comment>
                    <comment id="25974" author="stu" created="Mon, 29 Nov 2010 08:20:59 -0600"  >&lt;p&gt;Looks to me like the patch is misusing if-let, e.g.&lt;/p&gt;

&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;(when-let [[k &amp;amp; mk] []] &lt;span class=&quot;code-quote&quot;&gt;&quot;Doh!&quot;&lt;/span&gt;) 
=&amp;gt; Doh!&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;Please correct, and add tests for &lt;tt&gt;nil&lt;/tt&gt; and &lt;tt&gt;[]&lt;/tt&gt; keys (at least).&lt;/p&gt;</comment>
                    <comment id="28412" author="scottlowe" created="Tue, 8 May 2012 12:20:53 -0500"  >&lt;p&gt;I will write some tests and correct this.&lt;/p&gt;</comment>
                    <comment id="28419" author="scottlowe" created="Wed, 9 May 2012 20:39:11 -0500"  >&lt;p&gt;I&apos;m sorry to report that my good intentions of wanting to help clear some of the project backlog has created more work by way of further questions. I&apos;d also like to clarify the desired new behaviours for the test cases.&lt;/p&gt;

&lt;p&gt;Heinz proposed that an empty key sequence will not create a new nil key in the returned map.&lt;br/&gt;
He also suggested that the following behaviour changes be made (compare old and new* behaviours):&lt;/p&gt;

&lt;div class=&quot;preformatted panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;preformattedContent panelContent&quot;&gt;
&lt;pre&gt; 
(update-in {1 2} [] (constantly {2 3}))
{nil {2 3}, 1 2}

(update-in* {1 2} [] (constantly {2 3}))
{2 3}

(update-in {1 2} [] assoc  1 3)
{nil {1 3}, 1 2}

(update-in* {1 2} [] assoc  1 3)
{1 3}
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt; 

&lt;p&gt;Chouser also added that nil keys should be honoured, as before:&lt;/p&gt;
&lt;div class=&quot;preformatted panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;preformattedContent panelContent&quot;&gt;
&lt;pre&gt; 
(update-in* {nil 2} [nil] (constantly 3))
{nil 3}
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt; 
&lt;p&gt;I&apos;ve added a variety of tests to cover the existing behaviour and would like to confirm that the above is all that&apos;s required for new behaviour.&lt;/p&gt;

&lt;p&gt;The patch from November 2010 didn&apos;t work, but I tweaked it with a &lt;em&gt;when-let&lt;/em&gt; as Stuart suggested and placed a check for an empty sequence of keys before the &lt;em&gt;when-let&lt;/em&gt; block; because essentially, the primary behaviour change boils down to simply handling an empty sequence of keys, in addition to the existing behaviours.&lt;/p&gt;

&lt;p&gt;I&apos;m not entirely convinced that these changes are a good thing, but at least there&apos;s now something concrete for discussion. Please have a look at what is there. The good news is that at least there are some tests covering &lt;em&gt;update-in&lt;/em&gt; now.&lt;/p&gt;</comment>
                    <comment id="28596" author="jafingerhut" created="Thu, 24 May 2012 22:35:24 -0500"  >&lt;p&gt;clj-373-alter-behavior-of-update-in-with-empty-key-patch2.txt dated May 24, 2012 supersedes patch 0001-&lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-373&quot; title=&quot;update-in with empty key paths&quot;&gt;CLJ-373&lt;/a&gt;&lt;del&gt;Alter-behaviour-of-update-in-with-empty-key&lt;/del&gt;.patch dated May 9, 2012.  It makes no changes to the contents of the patch except in the lines of context that have changed since the earlier patch was created.  It applies cleanly to the latest master whereas the earlier patch no longer does.  Builds and passes tests with Oracle/Apple JDK 1.6 on Mac OS X 10.6.8.&lt;/p&gt;</comment>
                    <comment id="29176" author="fogus" created="Wed, 15 Aug 2012 11:21:49 -0500"  >&lt;p&gt;This patch creates a new error mode highlighted by the following:&lt;/p&gt;

&lt;div class=&quot;preformatted panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;preformattedContent panelContent&quot;&gt;
&lt;pre&gt;(update-in {:a 1} [] inc)

; ClassCastException clojure.lang.PersistentArrayMap cannot be cast to java.lang.Number
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;The reason is that the code that executes in the event that the keys are empty (or nil) blindly assumes that the function given can be applied to the map itself. This is no problem in the case of &lt;tt&gt;assoc&lt;/tt&gt; and the like, but clearly not for &lt;tt&gt;inc&lt;/tt&gt; and many other useful functions.&lt;/p&gt;

&lt;p&gt;The old behavior was to throw an NPE and if any code relies on that fact is now broken. Maybe this is not a problem, but I&apos;m kicking it back to get a little more discussion &lt;b&gt;and&lt;/b&gt; to request that whatever the ultimate fix happens to be, its behavioral changes and error modes are noted in the docstring for &lt;tt&gt;update-in&lt;/tt&gt;.&lt;/p&gt;</comment>
                    <comment id="29407" author="gv" created="Sat, 8 Sep 2012 06:11:44 -0500"  >&lt;p&gt;I vote for changing `update-in` to support empty key vectors.&lt;/p&gt;

&lt;p&gt;Because I think &quot;(apply f m args)&quot; in case of an empty vector is the natural continuation of the usual behavior of update-in:&lt;/p&gt;
&lt;ul class=&quot;alternate&quot; type=&quot;square&quot;&gt;
	&lt;li&gt;update-in with 2 keys the second level map is updated&lt;/li&gt;
	&lt;li&gt;update-in with 1 key the first level map (child of given map) is updated&lt;/li&gt;
	&lt;li&gt;update-in with no key the given map (zero level) is updated.&lt;/li&gt;
&lt;/ul&gt;


&lt;p&gt;Otherwise, you will always have to wrap update-in in something like the following when the keys vector is computed:&lt;/p&gt;
&lt;blockquote&gt;
&lt;p&gt;    (if (seq keys) (apply update-in m keys f args) (apply f m args))&lt;/p&gt;&lt;/blockquote&gt;

&lt;p&gt;To Fogus&apos; last post: (update-in {:a {:b 1}} &lt;span class=&quot;error&quot;&gt;&amp;#91;:a&amp;#93;&lt;/span&gt; inc) fails similar and is not handled with a special exception.&lt;/p&gt;



</comment>
                </comments>
                    <attachments>
                    <attachment id="11182" name="0001-CLJ-373-Alter-behaviour-of-update-in-with-empty-key-.patch" size="2922" author="scottlowe" created="Wed, 9 May 2012 20:39:11 -0500" />
                    <attachment id="10019" name="0001-Support-empty-path-in-update-in.-CLJ-373.patch" size="949" author="chouser@n01se.net" created="Sat, 13 Nov 2010 18:37:53 -0600" />
                    <attachment id="11256" name="clj-373-alter-behavior-of-update-in-with-empty-key-patch2.txt" size="2901" author="jafingerhut" created="Thu, 24 May 2012 22:35:24 -0500" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_10002" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Approval</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10006">Incomplete</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                    <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10000" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Patch</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10002">Code and Test</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                    <customfield id="customfield_10003" key="com.atlassian.jira.plugin.system.customfieldtypes:userpicker">
                <customfieldname>Waiting On</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>chouser@n01se.net</customfieldvalue>
                </customfieldvalues>
            </customfield>
                            </customfields>
    </item>

<item>
            <title>[CLJ-1021] (let [i 5] (defmacro m [v] v) m) interprets m as a function, not a macro</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1021</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;(let &lt;span class=&quot;error&quot;&gt;&amp;#91;i 5&amp;#93;&lt;/span&gt; (defmacro m &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;amp; args&amp;#93;&lt;/span&gt; args) (def x (m (inc 5) (inc 6) (inc 7))) &lt;a href=&quot;#&amp;#39;m)&quot;&gt;x m (meta #&apos;m)&lt;/a&gt;)&lt;br/&gt;
is&lt;br/&gt;
[(8) #&amp;lt;user$eval522$m_&lt;em&gt;523 user$eval522$m&lt;/em&gt;_523@11a74355&amp;gt; {:macro true, :ns #&amp;lt;Namespace user&amp;gt;, :name m, :arglists (&lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;amp; args&amp;#93;&lt;/span&gt;), :line 1, :file &quot;NO_SOURCE_PATH&quot;}]&lt;/p&gt;

&lt;p&gt;It appears to be interpreting m as a function despite the metadata. This behavior only shows up inside the (let ...).&lt;/p&gt;</description>
                <environment></environment>
            <key id="15565">CLJ-1021</key>
            <summary>(let [i 5] (defmacro m [v] v) m) interprets m as a function, not a macro</summary>
                <type id="1" iconUrl="http://dev.clojure.org/jira/images/icons/bug.gif">Defect</type>
                                <priority id="4" iconUrl="http://dev.clojure.org/jira/images/icons/priority_minor.gif">Minor</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="zii-prime">Zii Prime</reporter>
                        <labels>
                        <label>bug</label>
                    </labels>
                <created>Mon, 2 Jul 2012 23:32:22 -0500</created>
                <updated>Thu, 13 Sep 2012 14:29:20 -0500</updated>
                                    <version>Release 1.4</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                        <comments>
                    <comment id="29222" author="bronsa" created="Sat, 18 Aug 2012 11:43:42 -0500"  >&lt;p&gt;The problem is the same as the one for &lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-918&quot;&gt;http://dev.clojure.org/jira/browse/CLJ-918&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;The patch linked there was mine but i had no CA signed at that time, and no account on jira.&lt;/p&gt;

&lt;p&gt;Here is the same patch in the correct format.&lt;/p&gt;

&lt;p&gt;Bug #918 should be closed as this is a duplicate&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="11443" name="001-propagate-on-macro-meta.diff" size="1018" author="bronsa" created="Sat, 18 Aug 2012 11:43:42 -0500" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10000" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Patch</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10001">Code</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[CLJ-1003] :100 is a valid Clojure keyword. Is that intentional?</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1003</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;In the latest clojure (eccde24c7),&lt;/p&gt;

&lt;p&gt;These parse as keywords:&lt;/p&gt;

&lt;p&gt;:100&lt;br/&gt;
:100/a &lt;/p&gt;

&lt;p&gt;This is an error:&lt;/p&gt;

&lt;p&gt;:a/100&lt;/p&gt;

&lt;p&gt;Is this behavior intentional?&lt;/p&gt;

&lt;p&gt;In LispReader.java, the pattern for a symbol (and keyword) is &quot;&lt;span class=&quot;error&quot;&gt;&amp;#91;:&amp;#93;&lt;/span&gt;?([\\D&amp;amp;&amp;amp;&lt;span class=&quot;error&quot;&gt;&amp;#91;^/&amp;#93;&lt;/span&gt;].*/)?([&lt;br clear=&quot;all&quot; /&gt;D&amp;amp;&amp;amp;&lt;span class=&quot;error&quot;&gt;&amp;#91;^/&amp;#93;&lt;/span&gt;]&lt;span class=&quot;error&quot;&gt;&amp;#91;^/&amp;#93;&lt;/span&gt;*)&quot;. If I&apos;m mentally parsing that correctly, it seems like none of my examples should be valid keywords. I don&apos;t know why the first two cases parse.&lt;/p&gt;

&lt;p&gt;&lt;a href=&quot;http://clojure.org/reader&quot;&gt;http://clojure.org/reader&lt;/a&gt; says that none of my examples should parse.&lt;/p&gt;

&lt;p&gt;Clojurescript does not accept any of my examples, see &lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJS-142&quot; title=&quot;ClojureScript reader throws TypeError when map keys start with colon then number&quot;&gt;&lt;del&gt;CLJS-142&lt;/del&gt;&lt;/a&gt;&lt;/p&gt;</description>
                <environment></environment>
            <key id="15482">CLJ-1003</key>
            <summary>:100 is a valid Clojure keyword. Is that intentional?</summary>
                <type id="1" iconUrl="http://dev.clojure.org/jira/images/icons/bug.gif">Defect</type>
                                <priority id="4" iconUrl="http://dev.clojure.org/jira/images/icons/priority_minor.gif">Minor</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="netguy204">Brian Taylor</reporter>
                        <labels>
                    </labels>
                <created>Sun, 27 May 2012 23:39:17 -0500</created>
                <updated>Thu, 13 Sep 2012 18:34:52 -0500</updated>
                                                                            <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                        <comments>
                    <comment id="29438" author="jafingerhut" created="Thu, 13 Sep 2012 18:34:52 -0500"  >&lt;p&gt;The reason that :100 parses as a keyword is that [&lt;br clear=&quot;all&quot; /&gt;D&amp;amp;&lt;span class=&quot;error&quot;&gt;&amp;#91;^/&amp;#93;&lt;/span&gt;] matches a colon character, too.  So the first : of :100 is not matching the &lt;span class=&quot;error&quot;&gt;&amp;#91;:&amp;#93;&lt;/span&gt;? at the beginning of the regular expression, but by a later part of it.  Regexps can be tricky.&lt;/p&gt;

&lt;p&gt;Whether this is intentional or not, my guess is probably not.  Given that the docs at &lt;a href=&quot;http://clojure.org/reader&quot;&gt;http://clojure.org/reader&lt;/a&gt; also say &quot;A symbol can contain one or more non-repeating &apos;:&apos;s&quot;, writing a regexp that matches only what is documented there looks fairly complex.&lt;/p&gt;

&lt;p&gt;Clojure has a history of allowing things, without throwing exceptions or giving any other errors, even if they are documented as not legal.  This may be one of those cases.  Do not consider this last paragraph as any kind of authoritative answer.  It is only my observation.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                                                                                            </customfields>
    </item>

<item>
            <title>[CLJ-1063] Missing dissoc-in</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1063</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;There is no clojure.core/dissoc-in although there is an assoc-in.&lt;br/&gt;
It is correct that dissoc-in can be build with update-in and dissoc but this is an argument against assoc-in as well.&lt;br/&gt;
When a shortcut for assoc-in is provided, there should also be one for dissoc-in for consistency reasons.&lt;br/&gt;
Implementation is analogical to assoc-in.&lt;/p&gt;</description>
                <environment></environment>
            <key id="15682">CLJ-1063</key>
            <summary>Missing dissoc-in</summary>
                <type id="4" iconUrl="http://dev.clojure.org/jira/images/icons/improvement.gif">Enhancement</type>
                                <priority id="4" iconUrl="http://dev.clojure.org/jira/images/icons/priority_minor.gif">Minor</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="gv">Gunnar V&#246;lkel</reporter>
                        <labels>
                    </labels>
                <created>Fri, 7 Sep 2012 05:20:59 -0500</created>
                <updated>Mon, 17 Sep 2012 07:04:54 -0500</updated>
                                    <version>Release 1.4</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>1</watches>
                        <comments>
                    <comment id="29434" author="jafingerhut" created="Thu, 13 Sep 2012 14:17:36 -0500"  >&lt;p&gt;Patch clj-1063-add-dissoc-in-patch-v2.txt dated Sep 13 2012 supersedes 001-dissoc-in.diff dated Sep 7 2012.  It fixes a typo (missing final &quot; in doc string), and adds a test case for the new function.&lt;/p&gt;</comment>
                    <comment id="29436" author="bronsa" created="Thu, 13 Sep 2012 14:27:24 -0500"  >&lt;p&gt;Thanks for the fix Andy&lt;/p&gt;</comment>
                    <comment id="29444" author="jafingerhut" created="Fri, 14 Sep 2012 20:24:31 -0500"  >&lt;p&gt;This proposed dissoc-in should be compared with the one in clojure.core.incubator which I just happened across.  I see they look different, but haven&apos;t examined to see if there are any behavior differences.&lt;/p&gt;

&lt;p&gt;&lt;a href=&quot;https://github.com/clojure/core.incubator/blob/master/src/main/clojure/clojure/core/incubator.clj&quot;&gt;https://github.com/clojure/core.incubator/blob/master/src/main/clojure/clojure/core/incubator.clj&lt;/a&gt;&lt;/p&gt;</comment>
                    <comment id="29447" author="bronsa" created="Sat, 15 Sep 2012 06:43:55 -0500"  >&lt;p&gt;dissoc-in in clojure.core.incubator recursively removes empty maps&lt;/p&gt;

&lt;p&gt;user=&amp;gt; (clojure.core.incubator/dissoc-in {:a {:b {:c 1}}} &lt;span class=&quot;error&quot;&gt;&amp;#91;:a :b :c&amp;#93;&lt;/span&gt;)&lt;br/&gt;
{}&lt;/p&gt;

&lt;p&gt;while the one in this patch doesn&apos;t (as I would expect)&lt;/p&gt;

&lt;p&gt;user=&amp;gt; (dissoc-in {:a {:b {:c 1}}} &lt;span class=&quot;error&quot;&gt;&amp;#91;:a :b :c&amp;#93;&lt;/span&gt;)&lt;br/&gt;
{:a {:b {}}}&lt;/p&gt;</comment>
                    <comment id="29459" author="stu" created="Mon, 17 Sep 2012 07:04:54 -0500"  >&lt;p&gt;Please do this work in the incubator.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="11483" name="001-dissoc-in.diff" size="949" author="bronsa" created="Fri, 7 Sep 2012 06:30:47 -0500" />
                    <attachment id="11495" name="clj-1063-add-dissoc-in-patch-v2.txt" size="1650" author="jafingerhut" created="Thu, 13 Sep 2012 14:17:36 -0500" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_10002" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Approval</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10008">Not Approved</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                    <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10000" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Patch</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10002">Code and Test</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[CLJ-1043] Unordered literals does not preserve left-to-right evaluation of arguments</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1043</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;Given: (defn f &lt;span class=&quot;error&quot;&gt;&amp;#91;x&amp;#93;&lt;/span&gt; (println x) x)&lt;/p&gt;

&lt;p&gt;#{(f 2) (f 1)}&lt;/p&gt;

&lt;p&gt;Prints:&lt;/p&gt;

&lt;p&gt;1&lt;br/&gt;
2&lt;/p&gt;

&lt;p&gt;But expected would be:&lt;/p&gt;

&lt;p&gt;2&lt;br/&gt;
1&lt;/p&gt;

&lt;p&gt;This issue is related to &lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJS-288&quot; title=&quot;Compilation of unordered collections &quot;&gt;CLJS-288&lt;/a&gt;&lt;/p&gt;</description>
                <environment></environment>
            <key id="15632">CLJ-1043</key>
            <summary>Unordered literals does not preserve left-to-right evaluation of arguments</summary>
                <type id="1" iconUrl="http://dev.clojure.org/jira/images/icons/bug.gif">Defect</type>
                                <priority id="4" iconUrl="http://dev.clojure.org/jira/images/icons/priority_minor.gif">Minor</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="bbloom">Brandon Bloom</reporter>
                        <labels>
                    </labels>
                <created>Thu, 16 Aug 2012 21:25:31 -0500</created>
                <updated>Sun, 23 Sep 2012 19:38:35 -0500</updated>
                                    <version>Release 1.4</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>1</watches>
                        <comments>
                    <comment id="29525" author="jafingerhut" created="Sun, 23 Sep 2012 18:01:17 -0500"  >&lt;p&gt;I have the same question as David Nolen for &lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJS-288&quot; title=&quot;Compilation of unordered collections &quot;&gt;CLJS-288&lt;/a&gt;: Is this a bug, or just behavior you didn&apos;t expect?&lt;/p&gt;

&lt;p&gt;It seems that vectors preserve the order of evaluation, so if you really want to control evaluation order you could use something like (set &lt;span class=&quot;error&quot;&gt;&amp;#91;(f 2) (f 1)&amp;#93;&lt;/span&gt;) or (set (map f &lt;span class=&quot;error&quot;&gt;&amp;#91;2 1&amp;#93;&lt;/span&gt;)).&lt;/p&gt;</comment>
                    <comment id="29526" author="bbloom" created="Sun, 23 Sep 2012 19:38:35 -0500"  >&lt;p&gt;I&apos;d consider the expected default behavior of any syntax or macro to evaluate each sub-form once each, from left to right. Conditional, repeated, or out-of-order evaluation should be documented as deviations from that norm. If you buy that, then this is either a code or a documentation bug. My vote is for code bug.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                                                                                            </customfields>
    </item>

<item>
            <title>[CLJ-703] Improve writeClassFile performance</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-703</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;This &lt;a href=&quot;http://groups.google.com/group/clojure/browse_thread/thread/be0c45b3a4f3d46/36337ac7260d7d0a?lnk=gst&amp;amp;q=writeclassfile#36337ac7260d7d0a&quot;&gt;Discussion&lt;/a&gt; about timing issues when writing class files led to the the current implementation of synchronous writes to disk. This leads to bad performance/system-load when compiling Clojure code.&lt;/p&gt;

&lt;p&gt;This &lt;a href=&quot;http://groups.google.com/group/clojure-dev/browse_thread/thread/23213b787d3ec60f#&quot;&gt;Discussion&lt;/a&gt; questioned the current implentation.&lt;/p&gt;

&lt;p&gt;Synchronous writes are not necessary and also do not ensure (crash while calling write) valid classfiles.&lt;/p&gt;

&lt;p&gt;These Patches (0001 is just a code cleanup for creating the directory structure) ensures atomic creation of classfiles by using File.renameTo()&lt;/p&gt;




</description>
                <environment></environment>
            <key id="14312">CLJ-703</key>
            <summary>Improve writeClassFile performance</summary>
                <type id="4" iconUrl="http://dev.clojure.org/jira/images/icons/improvement.gif">Enhancement</type>
                                <priority id="4" iconUrl="http://dev.clojure.org/jira/images/icons/priority_minor.gif">Minor</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="juergenhoetzel">J&#252;rgen H&#246;tzel</reporter>
                        <labels>
                    </labels>
                <created>Tue, 4 Jan 2011 12:58:38 -0600</created>
                <updated>Fri, 5 Oct 2012 19:08:06 -0500</updated>
                                    <version>Release 1.3</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>4</watches>
                        <comments>
                    <comment id="26140" author="djpowell" created="Mon, 17 Jan 2011 14:16:19 -0600"  >
&lt;p&gt;Removing sync makes clojure build much faster.  I wonder why it was added in the first place?  I guess only Rich knows?  I assume that it is not necessary.&lt;/p&gt;

&lt;p&gt;If we are removing sync though, I wouldn&apos;t bother with the atomic rename stuff.  Doing that sort of thing can cause problems on some platforms, eg with search indexers and virus checkers momentarily locking files after they are created.  &lt;/p&gt;

&lt;p&gt;The patch seems to be assuming that sync is there for some reason, but my initial assumption would be that sync isn&apos;t necessary - perhaps it was working around some issue that no longer exists?&lt;/p&gt;
</comment>
                    <comment id="26142" author="juergenhoetzel" created="Wed, 19 Jan 2011 14:05:21 -0600"  >&lt;p&gt;Although its unlikely: there is a possible race condition &quot;loading a paritally written classfile&quot;?:&lt;/p&gt;

&lt;p&gt;&lt;a href=&quot;https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/RT.java#L393&quot;&gt;https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/RT.java#L393&lt;/a&gt;&lt;/p&gt;</comment>
                    <comment id="28600" author="jszakmeister" created="Fri, 25 May 2012 04:22:12 -0500"  >&lt;p&gt;The new improve-writeclassfile-perf version of the patch combines the two previous patches into a single patch file and brings them up-to-date with master.  I can split the two changes back out into separate patch files if desired, but I figured out current tooling is more geared towards a single patch being applied.&lt;/p&gt;</comment>
                    <comment id="28601" author="jszakmeister" created="Fri, 25 May 2012 04:36:10 -0500"  >&lt;p&gt;FWIW, both fixes look sane.  The first one is a nice cleanup.  The second one is a little more interesting in that uses a rename operation to put the final file into place.  It removes the sync call, which does make things faster.  In general, if we&apos;re concerned about on-disk consistency, we should really have a combination of the two: write the full contents to a tmp file, sync it, and atomically rename to the destination file name.&lt;/p&gt;

&lt;p&gt;Neither the current master, nor the current patch will guarantee on-disk consistency across a machine wide crash.  The current master could crash before the sync() occurs, leaving the file in an inconsistent state.  With the patch, the OS may not get the file from file cache to disk before an OS level crash occurs, and leave the file in an inconsistent state as well.  The benefit of the patch version is that the whole file does atomically come into view at once.  It does have a nasty side effect of leaving around a temp file if the compiler crashes just before the rename though.&lt;/p&gt;

&lt;p&gt;Perhaps a little more work to catch an exception and clean up is in order?  In general, I like the patched version better.&lt;/p&gt;</comment>
                    <comment id="29611" author="ivan" created="Fri, 5 Oct 2012 19:07:32 -0500"  >&lt;p&gt;File.renameTo returns false on (most?) errors, but the patch doesn&apos;t check for failure.  Docs say &quot;The return value should always be checked to make sure that the rename operation was successful.&quot;  Failure might be especially likely on Windows, where files are opened by others without FILE_SHARE_DELETE.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="10066" name="0001-use-File.mkdirs-instead-of-mkdir-every-single-direct.patch" size="1224" author="juergenhoetzel" created="Tue, 4 Jan 2011 12:58:38 -0600" />
                    <attachment id="10067" name="0002-Ensure-atomic-creation-of-class-files-by-renaming-a-.patch" size="1442" author="juergenhoetzel" created="Tue, 4 Jan 2011 12:58:38 -0600" />
                    <attachment id="11258" name="improve-writeclassfile-perf.patch" size="2684" author="jszakmeister" created="Fri, 25 May 2012 04:22:12 -0500" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10000" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Patch</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10001">Code</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[CLJ-1087] clojure.data/diff uses set union on key seqs</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1087</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;&lt;tt&gt;clojure.data/diff&lt;/tt&gt;, on line 118, defines:&lt;/p&gt;

&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;java.util.Map
(diff-similar [a b]
  (diff-associative a b (set/union (keys a) (keys b))))&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;Since &lt;tt&gt;keys&lt;/tt&gt; returns a key seq, this seems like an error. &lt;tt&gt;clojure.set/union&lt;/tt&gt; has strange and inconsistent behavior with regard to non-sets, and in this case the two key seqs are concatenated. Based on a cursory benchmark, it seems that this bug &lt;img class=&quot;emoticon&quot; src=&quot;http://dev.clojure.org/jira/images/icons/emoticons/help_16.gif&quot; height=&quot;16&quot; width=&quot;16&quot; align=&quot;absmiddle&quot; alt=&quot;&quot; border=&quot;0&quot;/&gt; is a slight performance gain when the maps have no common keys, and a significant performance loss when the maps have the same keys. The results are still correct because of the merging reduce in &lt;tt&gt;diff-associative&lt;/tt&gt;.&lt;/p&gt;

&lt;p&gt;The patch is easy (just call set on each key seq).&lt;/p&gt;</description>
                <environment></environment>
            <key id="15753">CLJ-1087</key>
            <summary>clojure.data/diff uses set union on key seqs</summary>
                <type id="4" iconUrl="http://dev.clojure.org/jira/images/icons/improvement.gif">Enhancement</type>
                                <priority id="4" iconUrl="http://dev.clojure.org/jira/images/icons/priority_minor.gif">Minor</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="tomoj">Tom Jack</reporter>
                        <labels>
                        <label>bug</label>
                        <label>performance</label>
                    </labels>
                <created>Mon, 15 Oct 2012 03:59:52 -0500</created>
                <updated>Mon, 15 Oct 2012 14:52:42 -0500</updated>
                                                                            <due></due>
                    <votes>0</votes>
                        <watches>1</watches>
                        <comments>
                    <comment id="29650" author="jafingerhut" created="Mon, 15 Oct 2012 14:52:04 -0500"  >&lt;p&gt;clj-1087-diff-perf-enhance-patch-v1.txt dated Oct 15 2012 implements Tom&apos;s suggested performance enhancement, although not exactly in the way he suggested.  It does calculate the union of the two key sequences.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="11562" name="clj-1087-diff-perf-enhance-patch-v1.txt" size="760" author="jafingerhut" created="Mon, 15 Oct 2012 14:52:04 -0500" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10000" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Patch</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10001">Code</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[CLJ-1097] node-seq for clojure.zip</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1097</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;Many times it&apos;s easier to get to a zipper node via (first (filter pred ...)) instead of manually walking the tree via next/up/down. Other times it&apos;s easier to process certain nodes via filter &amp;amp; map instead of again, walking the tree. This patch provides a single function called node-seq that uses zip/next to generate a lazy-seq of nodes. Tests provide two examples.&lt;/p&gt;
</description>
                <environment></environment>
            <key id="15803">CLJ-1097</key>
            <summary>node-seq for clojure.zip</summary>
                <type id="4" iconUrl="http://dev.clojure.org/jira/images/icons/improvement.gif">Enhancement</type>
                                <priority id="4" iconUrl="http://dev.clojure.org/jira/images/icons/priority_minor.gif">Minor</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="halgari">Timothy Baldridge</reporter>
                        <labels>
                        <label>clojure.zip</label>
                    </labels>
                <created>Mon, 29 Oct 2012 21:37:18 -0500</created>
                <updated>Mon, 29 Oct 2012 21:37:18 -0500</updated>
                                    <version>Release 1.5</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                <attachments>
                    <attachment id="11641" name="node-seq.diff" size="1571" author="halgari" created="Mon, 29 Oct 2012 21:37:18 -0500" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10000" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Patch</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10002">Code and Test</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[CLJ-1107] &apos;get&apos; should throw exception on non-Associative argument</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1107</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;The implementation of clojure.core/get returns null if its argument is not a valid associative collection. However, calling &apos;get&apos; on something which is neither nil nor an Associative collection is almost certainly a bug, and should be indicated by an exception.&lt;/p&gt;

&lt;p&gt;This behavior can obscure common programmer errors such as:&lt;/p&gt;

&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;(def a (atom {:a 1 :b 2})

(:foo a)   ; forgot to deref a
;;=&amp;gt; nil&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;&lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-932&quot; title=&quot;contains? should throw exception on non-keyed collections&quot;&gt;&lt;del&gt;CLJ-932&lt;/del&gt;&lt;/a&gt; was accepted as a similar enhancement to &apos;clojure.core/contains?&apos;&lt;/p&gt;

&lt;p&gt;Attached patch 0001 throws an IllegalArgumentException as the fall-through case of RT.getFrom.&lt;/p&gt;</description>
                <environment></environment>
            <key id="15823">CLJ-1107</key>
            <summary>&apos;get&apos; should throw exception on non-Associative argument</summary>
                <type id="4" iconUrl="http://dev.clojure.org/jira/images/icons/improvement.gif">Enhancement</type>
                                <priority id="4" iconUrl="http://dev.clojure.org/jira/images/icons/priority_minor.gif">Minor</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="stuart.sierra">Stuart Sierra</assignee>
                                <reporter username="stuart.sierra">Stuart Sierra</reporter>
                        <labels>
                    </labels>
                <created>Tue, 13 Nov 2012 13:20:33 -0600</created>
                <updated>Tue, 13 Nov 2012 13:57:31 -0600</updated>
                                                                            <due></due>
                    <votes>1</votes>
                        <watches>0</watches>
                                <attachments>
                    <attachment id="11672" name="0001-CLJ-1107-Throw-exception-for-get-called-on-unsupport.patch" size="3204" author="stuart.sierra" created="Tue, 13 Nov 2012 13:57:31 -0600" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10000" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Patch</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10002">Code and Test</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[CLJ-842] clojure.pprint uses the old-style metadata.</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-842</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;I was looking through the implementation of clojure.pprint.* and found that it still uses the old-style metadata to mark vars as private - ^{:private true} instead of ^:private.&lt;/p&gt;

&lt;p&gt;I have migrated the metadata to the new style in the attached trivial patch, which can be used in case this is deemed to be an issue.&lt;/p&gt;

&lt;p&gt;FWIW, there are some other namespaces which use the old-style metadata as well; I am willing to fix those as well.&lt;/p&gt;</description>
                <environment></environment>
            <key id="14646">CLJ-842</key>
            <summary>clojure.pprint uses the old-style metadata.</summary>
                <type id="1" iconUrl="http://dev.clojure.org/jira/images/icons/bug.gif">Defect</type>
                                <priority id="4" iconUrl="http://dev.clojure.org/jira/images/icons/priority_minor.gif">Minor</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="ghoseb">Baishampayan Ghose</reporter>
                        <labels>
                    </labels>
                <created>Mon, 26 Sep 2011 02:35:36 -0500</created>
                <updated>Wed, 14 Nov 2012 13:19:38 -0600</updated>
                                    <version>Release 1.3</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>1</watches>
                        <comments>
                    <comment id="29944" author="jafingerhut" created="Wed, 14 Nov 2012 13:19:38 -0600"  >&lt;p&gt;clj-842-update-clojure.pprint-metadata-v2.txt dated Nov 14 2012 is identical to Baishampayan Ghose&apos;s 0001-Migrate-the-metadata-in-clojure.pprint.-to-the-new-s.patch dated Sep 26, 2011, except it applies cleanly to latest master.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="10372" name="0001-Migrate-the-metadata-in-clojure.pprint.-to-the-new-s.patch" size="16175" author="ghoseb" created="Mon, 26 Sep 2011 02:35:36 -0500" />
                    <attachment id="11676" name="clj-842-update-clojure.pprint-metadata-v2.txt" size="16179" author="jafingerhut" created="Wed, 14 Nov 2012 13:19:38 -0600" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10000" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Patch</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10001">Code</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[CLJ-849] Add a pseudo-variable containing the current line number</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-849</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;Add a pseudo-variable (similar to &amp;#42;file*), containing the current line number. This should be available during AOT compilation. The name &quot;&amp;#42;line-number*&quot; might be good.&lt;/p&gt;

&lt;p&gt;It will be useful for diagnostic log messages. Using exception stack traces has poor runtime performance and the line number should be available to the compiler at minimal cost.&lt;/p&gt;</description>
                <environment>Any</environment>
            <key id="14672">CLJ-849</key>
            <summary>Add a pseudo-variable containing the current line number</summary>
                <type id="4" iconUrl="http://dev.clojure.org/jira/images/icons/improvement.gif">Enhancement</type>
                                <priority id="4" iconUrl="http://dev.clojure.org/jira/images/icons/priority_minor.gif">Minor</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="grkuntzmd">G. Ralph Kuntz, MD</reporter>
                        <labels>
                    </labels>
                <created>Fri, 7 Oct 2011 07:59:03 -0500</created>
                <updated>Wed, 14 Nov 2012 15:44:21 -0600</updated>
                                    <version>Release 1.3</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>3</watches>
                        <comments>
                    <comment id="29947" author="cninja" created="Wed, 14 Nov 2012 15:41:34 -0600"  >&lt;p&gt;Adding initial patch. A symbol&apos;s position is now stored in its metadata, just like a seq when it is read with the LispReader. &lt;/p&gt;

&lt;p&gt;The Compiler.LINE and Compiler.COLUMN values are now updated as each symbol is analyzed. This provides more exact line and column numbers for Compiler errors which will resolve ticket &lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-420&quot; title=&quot;Some compiler exceptions erroneously using REPL line numbers.&quot;&gt;CLJ-420&lt;/a&gt;.&lt;/p&gt;

&lt;p&gt;The Compiler.LINE variable has been interned as clojure.core/&lt;b&gt;line-number&lt;/b&gt;&lt;/p&gt;

&lt;p&gt;Adding extra metadata to symbols resulted in some tests failing due to the extra values. The failing tests have been updated to ignore the new metadata keys.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="11678" name="CLJ-849-line-number-pesudo-variable.diff" size="9179" author="cninja" created="Wed, 14 Nov 2012 15:41:34 -0600" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10000" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Patch</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10002">Code and Test</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[CLJ-1113] `reductions` reducer</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1113</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;It would be nice to have a reducers implementation of the core `reductions` function.&lt;/p&gt;

&lt;p&gt;Initial implementation attempt included.  This version requires an initial reduction value parameter (vs using (f)) and includes that initial value in the final reduction.  I&apos;m not certain either of these decisions is optimal, but results in a function which most closely mimics `clojure.core/reductions`.&lt;/p&gt;</description>
                <environment></environment>
            <key id="15848">CLJ-1113</key>
            <summary>`reductions` reducer</summary>
                <type id="4" iconUrl="http://dev.clojure.org/jira/images/icons/improvement.gif">Enhancement</type>
                                <priority id="4" iconUrl="http://dev.clojure.org/jira/images/icons/priority_minor.gif">Minor</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="llasram">Marshall T. Vandegrift</reporter>
                        <labels>
                    </labels>
                <created>Fri, 23 Nov 2012 08:22:37 -0600</created>
                <updated>Fri, 23 Nov 2012 08:22:37 -0600</updated>
                                    <version>Release 1.5</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                <attachments>
                    <attachment id="11703" name="reductions-reducer.diff" size="2172" author="llasram" created="Fri, 23 Nov 2012 08:22:37 -0600" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10000" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Patch</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10002">Code and Test</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[CLJ-1049] Make reducer/folder support reduce-kv</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1049</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;Currently, although rfn makes an effort to support reduce-kv, it is wasted effort since the return values of reducer and folder don&apos;t satisfy IKVReduce.&lt;/p&gt;

&lt;p&gt;I have a working patch for this, it&apos;s quite small. I have printed a CA but not sent it, so I won&apos;t reveal the patch yet...&lt;/p&gt;

&lt;p&gt;This also applies to ClojureScript.&lt;/p&gt;</description>
                <environment></environment>
            <key id="15641">CLJ-1049</key>
            <summary>Make reducer/folder support reduce-kv</summary>
                <type id="4" iconUrl="http://dev.clojure.org/jira/images/icons/improvement.gif">Enhancement</type>
                                <priority id="4" iconUrl="http://dev.clojure.org/jira/images/icons/priority_minor.gif">Minor</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="tomoj">Tom Jack</reporter>
                        <labels>
                    </labels>
                <created>Wed, 22 Aug 2012 02:22:23 -0500</created>
                <updated>Sun, 23 Sep 2012 20:34:21 -0500</updated>
                                    <version>Release 1.5</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>2</watches>
                        <comments>
                    <comment id="29445" author="tomoj" created="Sat, 15 Sep 2012 00:47:17 -0500"  >&lt;p&gt;Hmm.. it&apos;s not quite as simple as I thought. My first patch simply had reducer/folder implement IKVReduce with `(clojure.core.protocols/kv-reduce coll (xf f1) init)`, but for map and mapcat, this results in strange behavior (reduce-kv reducefs being called with only 2 args).&lt;/p&gt;

&lt;p&gt;Patch 0001 includes modifications to map and mapcat so that the reduce-kv reducef will always be called with 3 args. The previous implementation of mapcat also had the converse problem: during non-kv reduce, if the mapcat fn returned a map, the reducef would be called with 3 args since maps reduce with reduce-kv.&lt;/p&gt;

&lt;p&gt;The patch gives behavior like:&lt;/p&gt;
&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;user&amp;gt; (-&amp;gt;&amp;gt; {1 {2 3 4 5} 6 {7 8 9 10}}
        (r/mapcat #(r/map + %2))
        (reduce-kv #(conj %1 [%2 %3]) []))
[[2 5] [4 9] [7 15] [9 19]]
user&amp;gt; (-&amp;gt;&amp;gt; [{2 3 4 5} {7 8 9 10}]
        (r/mapcat identity)
        (r/reduce conj []))
[[2 3] [4 5] [7 8] [9 10]]&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;</comment>
                    <comment id="29528" author="tomoj" created="Sun, 23 Sep 2012 20:34:21 -0500"  >&lt;p&gt;Would like to discuss these changes (and auto-kv for maps) on clojure-dev, but my membership is still pending. My CA has been received. Anyone know who to contact to get my membership approved?&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="11497" name="0001-reduce-kv-transformations.diff" size="2180" author="tomoj" created="Sat, 15 Sep 2012 00:45:14 -0500" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10000" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Patch</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10001">Code</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[CLJ-1056] defprotocol: invalid method overload syntax getting accepted </title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1056</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;The compiler accepts both of these erroneous forms which while silly, are not imposible to come up with.&lt;/p&gt;

&lt;p&gt;(defprotocol Foo (f (&lt;span class=&quot;error&quot;&gt;&amp;#91;this&amp;#93;&lt;/span&gt;) (&lt;span class=&quot;error&quot;&gt;&amp;#91;this arg&amp;#93;&lt;/span&gt;)))&lt;br/&gt;
(defprotocol Bar (m &lt;span class=&quot;error&quot;&gt;&amp;#91;this&amp;#93;&lt;/span&gt;) (m &lt;span class=&quot;error&quot;&gt;&amp;#91;this arg&amp;#93;&lt;/span&gt;))&lt;/p&gt;</description>
                <environment></environment>
            <key id="15665">CLJ-1056</key>
            <summary>defprotocol: invalid method overload syntax getting accepted </summary>
                <type id="1" iconUrl="http://dev.clojure.org/jira/images/icons/bug.gif">Defect</type>
                                <priority id="4" iconUrl="http://dev.clojure.org/jira/images/icons/priority_minor.gif">Minor</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="vemv">V&#237;ctor M. Valenzuela</reporter>
                        <labels>
                    </labels>
                <created>Sat, 1 Sep 2012 19:19:17 -0500</created>
                <updated>Thu, 29 Nov 2012 16:03:11 -0600</updated>
                                    <version>Release 1.5</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                        <comments>
                    <comment id="30099" author="halgari" created="Thu, 29 Nov 2012 16:02:50 -0600"  >&lt;p&gt;Can not reproduce the fist error:&lt;/p&gt;

&lt;p&gt;user=&amp;gt; (defprotocol Foo (f (&lt;span class=&quot;error&quot;&gt;&amp;#91;this&amp;#93;&lt;/span&gt;) (&lt;span class=&quot;error&quot;&gt;&amp;#91;this arg&amp;#93;&lt;/span&gt;)))    &lt;br/&gt;
CompilerException java.lang.IllegalArgumentException: Parameter declaration missing, compiling:(NO_SOURCE_PATH:5:1) &lt;/p&gt;

&lt;p&gt;But the 2nd one I can reproduce:&lt;/p&gt;

&lt;p&gt;user=&amp;gt; (defprotocol Bar (m &lt;span class=&quot;error&quot;&gt;&amp;#91;this&amp;#93;&lt;/span&gt;) (m &lt;span class=&quot;error&quot;&gt;&amp;#91;this arg&amp;#93;&lt;/span&gt;))    &lt;br/&gt;
Bar&lt;br/&gt;
user=&amp;gt; Bar&lt;br/&gt;
{:on-interface user.Bar, :on user.Bar, :sigs {:m {:doc nil, :arglists (&lt;span class=&quot;error&quot;&gt;&amp;#91;this arg&amp;#93;&lt;/span&gt;), :name m}}, :var #&apos;user/Bar, :method-map {:m :m}, :method-builders {#&apos;user/m #&amp;lt;user$eval71$fn_&lt;em&gt;72 user$eval71$fn&lt;/em&gt;_72@1a2b53fb&amp;gt;}}&lt;br/&gt;
user=&amp;gt; &lt;/p&gt;

&lt;p&gt;Notice that :arglists only has one entry&lt;/p&gt;

&lt;p&gt;Vetting&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_10002" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Approval</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10003">Vetted</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                    <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                                                                                            </customfields>
    </item>

<item>
            <title>[CLJ-1090] Indirect function calls through Var instances fail to clear locals</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1090</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;If you make a function call indirectly by invoking a Var object (which derefs itself and invokes the result), the invocation parameters remain in the thread&apos;s local stack for the duration of the function call, even though they are needed only long enough to be passed into the deref&apos;d function. As a result, passing a lazy seq into a function invoked in its Var form may run out of memory if the seq is forced inside that function. For example:&lt;/p&gt;

&lt;p&gt;(defn total &lt;span class=&quot;error&quot;&gt;&amp;#91;xs&amp;#93;&lt;/span&gt; (reduce + 0 xs))&lt;br/&gt;
(total (range 1000000000))   ; this works, though takes a while&lt;br/&gt;
(#&apos;total (range 1000000000)) ; this dies with out of memory error&lt;/p&gt;

&lt;p&gt;I can provide a patch if it would be useful. The fix should be trivial, something along the lines of wrapping each argN in clojure/lang/Var.java inside a Util.ret1(argN, argN = null) as is done in RestFn.java.&lt;/p&gt;</description>
                <environment>Probably all, but observed on Ubuntu 12.04, OpenJDK 6</environment>
            <key id="15768">CLJ-1090</key>
            <summary>Indirect function calls through Var instances fail to clear locals</summary>
                <type id="1" iconUrl="http://dev.clojure.org/jira/images/icons/bug.gif">Defect</type>
                                <priority id="4" iconUrl="http://dev.clojure.org/jira/images/icons/priority_minor.gif">Minor</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="stfactual">Spencer Tipping</reporter>
                        <labels>
                        <label>performance</label>
                    </labels>
                <created>Mon, 22 Oct 2012 18:43:19 -0500</created>
                <updated>Fri, 30 Nov 2012 14:26:45 -0600</updated>
                                    <version>Release 1.4</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>2</watches>
                        <comments>
                    <comment id="29776" author="stfactual" created="Tue, 23 Oct 2012 13:37:16 -0500"  >&lt;p&gt;Sorry, I typo&apos;d the example. (defn total ...) should be (defn sum ...).&lt;/p&gt;</comment>
                    <comment id="30054" author="halgari" created="Tue, 27 Nov 2012 11:45:43 -0600"  >&lt;p&gt;fixed typeo in example&lt;/p&gt;</comment>
                    <comment id="30055" author="halgari" created="Tue, 27 Nov 2012 11:47:35 -0600"  >&lt;p&gt;Couldn&apos;t reproduce the exception, but the 2nd example did chew through about 4x the amount of memory. Vetting. &lt;/p&gt;</comment>
                    <comment id="30095" author="halgari" created="Thu, 29 Nov 2012 14:57:28 -0600"  >&lt;p&gt;adding a patch. Since most of Clojure ends up running this code in one way or another, I&apos;d assert that tests are included as part of the normal Clojure test process. &lt;/p&gt;

&lt;p&gt;Patch simply calls Util.ret1(argx, argx=null) on all invoke calls. &lt;/p&gt;</comment>
                    <comment id="30097" author="halgari" created="Thu, 29 Nov 2012 15:17:52 -0600"  >&lt;p&gt;And as a note, both examples in the original report now have extremely similar memory usages. &lt;/p&gt;</comment>
                    <comment id="30118" author="stfactual" created="Fri, 30 Nov 2012 14:22:14 -0600"  >&lt;p&gt;Sounds great, and the patch looks good too. Let me know if I need to do anything else.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="11729" name="var-clear-locals.diff" size="19020" author="halgari" created="Thu, 29 Nov 2012 14:57:28 -0600" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_10002" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Approval</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10003">Vetted</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                    <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10000" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Patch</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10001">Code</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[CLJ-1102] Better handling of exceptions with empty stack traces</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1102</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;I don&apos;t know what I did to cause some exceptions to be thrown while running Clojure tests that return a length 0 array from (.getStackTrace throwable), but according to the Java docs this is legal.  I searched all places in the Clojure code that call .getStackTrace and found two that don&apos;t handle this correctly, one of which causes an ArrayOutOfBoundsException (that is the one I found during my testing).&lt;/p&gt;</description>
                <environment></environment>
            <key id="15814">CLJ-1102</key>
            <summary>Better handling of exceptions with empty stack traces</summary>
                <type id="1" iconUrl="http://dev.clojure.org/jira/images/icons/bug.gif">Defect</type>
                                <priority id="4" iconUrl="http://dev.clojure.org/jira/images/icons/priority_minor.gif">Minor</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="jafingerhut">Andy Fingerhut</reporter>
                        <labels>
                    </labels>
                <created>Sun, 4 Nov 2012 17:03:47 -0600</created>
                <updated>Fri, 30 Nov 2012 14:57:46 -0600</updated>
                                    <version>Release 1.5</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>1</watches>
                        <comments>
                    <comment id="29900" author="jafingerhut" created="Sun, 4 Nov 2012 17:07:36 -0600"  >&lt;p&gt;clj-1102-improve-empty-stack-trace-handling-v1.txt dated Nov 4 2012 improves the handling of .getStackTrace returning a length 0 array in two places.  I checked all other places .getStackTrace was called and they seem to already handle this case gracefully.&lt;/p&gt;</comment>
                    <comment id="30120" author="halgari" created="Fri, 30 Nov 2012 14:57:37 -0600"  >&lt;p&gt;Vetting.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="11662" name="clj-1102-improve-empty-stack-trace-handling-v1.txt" size="1791" author="jafingerhut" created="Sun, 4 Nov 2012 17:07:36 -0600" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_10002" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Approval</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10003">Vetted</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                    <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10000" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Patch</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10001">Code</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[CLJ-1103] Make conj assoc dissoc and transient versions handle args similarly</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1103</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;A discussion came up in the Clojure Google group about conj giving an error when taking only a coll as an argument, as opposed to disj which works for this case:&lt;/p&gt;

&lt;p&gt;&lt;a href=&quot;https://groups.google.com/forum/?fromgroups=#!topic/clojure/Z9mFxsTYTqQ&quot;&gt;https://groups.google.com/forum/?fromgroups=#!topic/clojure/Z9mFxsTYTqQ&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;I looked through the rest of the code for similar cases, and found that conj! assoc assoc! and disj! also had the same property, and there were some other differences between them in how different numbers of arguments were handled, such as:&lt;/p&gt;

&lt;p&gt;conj handles an arbitrary number of arguments, but conj! does not.&lt;br/&gt;
assoc checks for a final key with no value specified (&lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-1052&quot; title=&quot;assoc should throw exception if missing val for last key&quot;&gt;&lt;del&gt;CLJ-1052&lt;/del&gt;&lt;/a&gt;), but assoc! did not.&lt;/p&gt;</description>
                <environment></environment>
            <key id="15815">CLJ-1103</key>
            <summary>Make conj assoc dissoc and transient versions handle args similarly</summary>
                <type id="4" iconUrl="http://dev.clojure.org/jira/images/icons/improvement.gif">Enhancement</type>
                                <priority id="4" iconUrl="http://dev.clojure.org/jira/images/icons/priority_minor.gif">Minor</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="jafingerhut">Andy Fingerhut</reporter>
                        <labels>
                    </labels>
                <created>Sun, 4 Nov 2012 18:00:32 -0600</created>
                <updated>Sun, 9 Dec 2012 17:30:00 -0600</updated>
                                    <version>Release 1.4</version>
                <version>Release 1.5</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>2</watches>
                        <comments>
                    <comment id="29901" author="jafingerhut" created="Sun, 4 Nov 2012 18:04:54 -0600"  >&lt;p&gt;clj-1103-make-conj-assoc-dissoc-handle-args-similarly-v1.txt dated Nov 4 2012 makes conj conj! assoc assoc! dissoc dissoc! handle args similarly to each other.&lt;/p&gt;</comment>
                    <comment id="30197" author="bbloom" created="Sun, 9 Dec 2012 17:30:00 -0600"  >&lt;p&gt;I too ran into this and started an additional discussion here: &lt;a href=&quot;https://groups.google.com/d/topic/clojure-dev/wL5hllfhw4M/discussion&quot;&gt;https://groups.google.com/d/topic/clojure-dev/wL5hllfhw4M/discussion&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;In particular, I don&apos;t buy the argument that (into coll xs) is sufficient, since into implies conj and there isn&apos;t an terse and idiomatic way to write (into map (parition 2 keyvals))&lt;/p&gt;

&lt;p&gt;So +1 from me&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="11663" name="clj-1103-make-conj-assoc-dissoc-handle-args-similarly-v1.txt" size="8667" author="jafingerhut" created="Sun, 4 Nov 2012 18:04:54 -0600" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10000" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Patch</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10002">Code and Test</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[CLJ-1124] for-as</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1124</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;A common pattern in programming is building up some data structure step by step:&lt;/p&gt;

&lt;p&gt;In Python:&lt;/p&gt;

&lt;p&gt;&lt;span class=&quot;error&quot;&gt;&amp;#91;code&amp;#93;&lt;/span&gt;&lt;br/&gt;
x = {0: 1}&lt;br/&gt;
for item in stuff:&lt;br/&gt;
    x&lt;span class=&quot;error&quot;&gt;&amp;#91;item&amp;#93;&lt;/span&gt; = item * x.get(item - 1, 0)&lt;br/&gt;
&lt;span class=&quot;error&quot;&gt;&amp;#91;/code&amp;#93;&lt;/span&gt;&lt;br/&gt;
etc.&lt;/p&gt;

&lt;p&gt;In an imperative for loop this is easy since we have easy access to the &quot;current&quot; data structure being built up.&lt;/p&gt;

&lt;p&gt;I propose the addition of a function for-as similar to as-&amp;gt; except the value of the last loop iteration is bound to the name.&lt;/p&gt;

&lt;p&gt;So we can write the above as:&lt;/p&gt;

&lt;p&gt;&lt;span class=&quot;error&quot;&gt;&amp;#91;code&amp;#93;&lt;/span&gt;&lt;br/&gt;
(last (for-as &lt;span class=&quot;error&quot;&gt;&amp;#91;x {0 1}&amp;#93;&lt;/span&gt;&lt;br/&gt;
        &lt;span class=&quot;error&quot;&gt;&amp;#91;item stuff&amp;#93;&lt;/span&gt;&lt;br/&gt;
  (assoc x item (* item (get x (- item 1) 0)))))&lt;br/&gt;
&lt;span class=&quot;error&quot;&gt;&amp;#91;/code&amp;#93;&lt;/span&gt;&lt;/p&gt;

&lt;p&gt;An (un-optimized) implementation might be something like:&lt;/p&gt;

&lt;p&gt;&lt;span class=&quot;error&quot;&gt;&amp;#91;code&amp;#93;&lt;/span&gt;&lt;br/&gt;
(defmacro reduce-for [&lt;span class=&quot;error&quot;&gt;&amp;#91;res init&amp;#93;&lt;/span&gt; for-seq-exprs body-expr]&lt;br/&gt;
  `(reduce #(%2 %1) ~init&lt;br/&gt;
    (for ~for-seq-exprs&lt;br/&gt;
      (fn &lt;span class=&quot;error&quot;&gt;&amp;#91;~res&amp;#93;&lt;/span&gt;&lt;br/&gt;
        ~body-expr))))&lt;br/&gt;
&lt;span class=&quot;error&quot;&gt;&amp;#91;/code&amp;#93;&lt;/span&gt;&lt;/p&gt;

&lt;p&gt;Note: reduce-for does not return a seq, instead it returns the result of the last loop body iteration.&lt;/p&gt;</description>
                <environment></environment>
            <key id="15880">CLJ-1124</key>
            <summary>for-as</summary>
                <type id="4" iconUrl="http://dev.clojure.org/jira/images/icons/improvement.gif">Enhancement</type>
                                <priority id="4" iconUrl="http://dev.clojure.org/jira/images/icons/priority_minor.gif">Minor</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="yongqli">Yongqian Li</reporter>
                        <labels>
                    </labels>
                <created>Mon, 10 Dec 2012 23:27:10 -0600</created>
                <updated>Mon, 10 Dec 2012 23:33:43 -0600</updated>
                                    <version>Release 1.5</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>1</watches>
                        <comments>
                    <comment id="30208" author="yongqli" created="Mon, 10 Dec 2012 23:31:11 -0600"  >&lt;p&gt;(Fixed formatting)&lt;/p&gt;

&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;x = {0: 1}
&lt;span class=&quot;code-keyword&quot;&gt;for&lt;/span&gt; item in stuff:
    x[item] = item * x.get(item - 1, 0)&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;(last (&lt;span class=&quot;code-keyword&quot;&gt;for&lt;/span&gt;-as [x {0 1}]
        [item stuff]
  (assoc x item (* item (get x (- item 1) 0)))))&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;(defmacro reduce-&lt;span class=&quot;code-keyword&quot;&gt;for&lt;/span&gt; [[res init] &lt;span class=&quot;code-keyword&quot;&gt;for&lt;/span&gt;-seq-exprs body-expr]
  `(reduce #(%2 %1) ~init
    (&lt;span class=&quot;code-keyword&quot;&gt;for&lt;/span&gt; ~&lt;span class=&quot;code-keyword&quot;&gt;for&lt;/span&gt;-seq-exprs
      (fn [~res]
        ~body-expr))))&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;(Someone please fix the formatting in above and delete this comment.)&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                                                                                            </customfields>
    </item>

<item>
            <title>[CLJ-1128] Improve merge-with</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1128</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;Set a first map as an initial value for reduce to&lt;br/&gt;
avoid merge-entry (series of contains? calls and etc) call on the first map.&lt;/p&gt;</description>
                <environment></environment>
            <key id="15888">CLJ-1128</key>
            <summary>Improve merge-with</summary>
                <type id="4" iconUrl="http://dev.clojure.org/jira/images/icons/improvement.gif">Enhancement</type>
                                <priority id="4" iconUrl="http://dev.clojure.org/jira/images/icons/priority_minor.gif">Minor</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="edtsech">Edward Tsech</reporter>
                        <labels>
                    </labels>
                <created>Thu, 13 Dec 2012 13:29:35 -0600</created>
                <updated>Thu, 13 Dec 2012 17:41:39 -0600</updated>
                                                                            <due></due>
                    <votes>0</votes>
                        <watches>2</watches>
                        <comments>
                    <comment id="30225" author="edtsech" created="Thu, 13 Dec 2012 13:36:23 -0600"  >&lt;p&gt;Tests pass.&lt;/p&gt;</comment>
                    <comment id="30226" author="jafingerhut" created="Thu, 13 Dec 2012 14:32:13 -0600"  >&lt;p&gt;Edward, your patch replaces the expression (or m1 {}) with m1.  It was changed from m1 to (or m1 {}) in a commit on Oct 16, 2008 with descriptive text &quot;improved nil handling in merge, merge-with&quot;, so I am pretty sure it would be best to leave it as (or m1 {}).  I believe the intent is to allow all but one of the map arguments to merge-with be nil, and everything will still work.&lt;/p&gt;

&lt;p&gt;The rest of the patch for avoiding one merge call seems sound to me.&lt;/p&gt;

&lt;p&gt;Your change would be even better at preserving any metadata on the first non-nil map in the list, if instead of calling with the first map, it called it with the first non-nil item of the list, and then the rest of the list after that.&lt;/p&gt;</comment>
                    <comment id="30228" author="edtsech" created="Thu, 13 Dec 2012 17:41:39 -0600"  >&lt;p&gt;I figured out that `reduce1` did pass a head of the list for me. &lt;img class=&quot;emoticon&quot; src=&quot;http://dev.clojure.org/jira/images/icons/emoticons/smile.gif&quot; height=&quot;20&quot; width=&quot;20&quot; align=&quot;absmiddle&quot; alt=&quot;&quot; border=&quot;0&quot;/&gt; (&lt;a href=&quot;https://github.com/clojure/clojure/blob/master/src/clj/clojure/core.clj#L887&quot;&gt;https://github.com/clojure/clojure/blob/master/src/clj/clojure/core.clj#L887&lt;/a&gt;)&lt;br/&gt;
But case with first nil argument is still valid. Correct me, please, if i&apos;m wrong.&lt;/p&gt;

&lt;p&gt;I&apos;m not sure about `(or m1 {})`. I don&apos;t see any problems which can happen. Probably behaviour of functions which are used internally was changed since 2008.&lt;/p&gt;

&lt;p&gt;(contains? nil :a) ;=&amp;gt; false&lt;br/&gt;
(assoc nil :a 1) ;=&amp;gt; {:a 1}&lt;br/&gt;
(get nil :a) ;=&amp;gt; nil&lt;/p&gt;

&lt;p&gt;I could write some tests for that.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="11761" name="0001-Improve-merge-with.patch" size="851" author="edtsech" created="Thu, 13 Dec 2012 13:29:35 -0600" />
                    <attachment id="11762" name="0002-Improve-merge-with.patch" size="1077" author="edtsech" created="Thu, 13 Dec 2012 17:41:39 -0600" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10000" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Patch</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10001">Code</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[CLJ-1119] inconsistent behavior of lazy-seq w/ macro &amp; closure on excptions</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1119</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;lazy-seq seems to evaluate inconsistently when body includes a macro and throws and exception. 1st evalutation throws the exceptions, subsequent ones return empty sequence.&lt;/p&gt;

&lt;p&gt;demo code:&lt;/p&gt;

&lt;p&gt;(defn gen-lazy []&lt;br/&gt;
  (let [coll &lt;span class=&quot;error&quot;&gt;&amp;#91;1 2 3&amp;#93;&lt;/span&gt;]&lt;br/&gt;
    (lazy-seq&lt;br/&gt;
      (when-let &lt;span class=&quot;error&quot;&gt;&amp;#91;s (seq coll)&amp;#93;&lt;/span&gt;&lt;br/&gt;
        (throw (Exception.))))))&lt;/p&gt;

&lt;p&gt;(def lazy (gen-lazy))&lt;/p&gt;

&lt;p&gt;(try&lt;br/&gt;
  (println &quot;lazy:&quot; lazy)&lt;br/&gt;
  (catch Exception ex&lt;br/&gt;
    (println ex)))&lt;/p&gt;

&lt;p&gt;(try&lt;br/&gt;
  (println &quot;lazy, again:&quot; lazy)&lt;br/&gt;
  (catch Exception ex&lt;br/&gt;
    (println ex)))&lt;/p&gt;

&lt;p&gt;It should throw an exception both times but only does on 1st. Generally speaking an expression shouldn&apos;t evaluate to different things depending on whether it&apos;s been evaluated before.&lt;/p&gt;

&lt;p&gt;When removing the closure ...&lt;/p&gt;

&lt;p&gt;(defn gen-lazy []&lt;br/&gt;
  (lazy-seq&lt;br/&gt;
    (when-let [s (seq &lt;span class=&quot;error&quot;&gt;&amp;#91;1 2 3&amp;#93;&lt;/span&gt;)]&lt;br/&gt;
      (throw (Exception.)))))&lt;/p&gt;

&lt;p&gt;... or removing the when-let macro ...&lt;/p&gt;

&lt;p&gt;(defn gen-lazy []&lt;br/&gt;
  (let [coll &lt;span class=&quot;error&quot;&gt;&amp;#91;1 2 3&amp;#93;&lt;/span&gt;]&lt;br/&gt;
    (lazy-seq&lt;br/&gt;
      (seq coll)&lt;br/&gt;
      (throw (Exception.)))))&lt;/p&gt;

&lt;p&gt;It works i.e. consistently throws the exception, so seems to be some interaction between the closure and the macro at work here. This particular combination is used in the &apos;map&apos; function.&lt;/p&gt;

&lt;p&gt;See also: &lt;a href=&quot;https://groups.google.com/forum/?fromgroups=#!topic/clojure/Z3EiBUQ7Inc&quot;&gt;https://groups.google.com/forum/?fromgroups=#!topic/clojure/Z3EiBUQ7Inc&lt;/a&gt;&lt;/p&gt;</description>
                <environment></environment>
            <key id="15869">CLJ-1119</key>
            <summary>inconsistent behavior of lazy-seq w/ macro &amp; closure on excptions</summary>
                <type id="1" iconUrl="http://dev.clojure.org/jira/images/icons/bug.gif">Defect</type>
                                <priority id="4" iconUrl="http://dev.clojure.org/jira/images/icons/priority_minor.gif">Minor</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="hank">Hank</reporter>
                        <labels>
                    </labels>
                <created>Mon, 3 Dec 2012 03:00:15 -0600</created>
                <updated>Sun, 16 Dec 2012 04:06:49 -0600</updated>
                                    <version>Release 1.4</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>2</watches>
                        <comments>
                    <comment id="30147" author="hank" created="Mon, 3 Dec 2012 04:26:02 -0600"  >&lt;p&gt;N.B. The primary use case I have for this, in case it matters, is interrupting the evaluation of a &apos;map&apos; expression in which the mapped fn is slow to evaluate (throwing an InterruptedException), because I am not interested in its result any more. Then later I re-evaluate it because I am interested in the result after all, however with above bug the lazy sequence terminates instead of recommencing where it left off.&lt;/p&gt;

&lt;p&gt;(UPDATE: This use case is similar to the kind of ersatz continuations that Jetty does (RetryRequest runtime exception) or even Clojure itself when barging STM transactions with the RetryEx exception.)&lt;/p&gt;</comment>
                    <comment id="30149" author="hank" created="Mon, 3 Dec 2012 08:45:27 -0600"  >&lt;p&gt;Related to &lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-457&quot; title=&quot;lazy recursive definition giving incorrect results&quot;&gt;CLJ-457&lt;/a&gt; according to Christophe. His patch fixes this,too.&lt;/p&gt;</comment>
                    <comment id="30172" author="hank" created="Tue, 4 Dec 2012 05:02:32 -0600"  >&lt;p&gt;Sorry Christophe&apos;s patch doesn&apos;t work for me here. It avoids evaluating the LazySeq a second time by prematurely throwing an exception. However a LazySeq might evaluate properly the second time around b/c the situation causing the exception was transient. As per comment above an evaluation might get interrupted, throwing InterruptedException the first time around but not the second time.&lt;/p&gt;

&lt;p&gt;Also the observation with the closure and macro need explanation IMHO.&lt;/p&gt;</comment>
                    <comment id="30189" author="hank" created="Sat, 8 Dec 2012 03:51:04 -0600"  >&lt;p&gt;further insight: &apos;delay&apos; exhibits the same behavior and is a more simple case to examine. the macro suspicion is a red herring: as demoed below it is actually the closed over variable magically turns to nil, the when-let macro simply turned that into a nil for the whole expression.&lt;/p&gt;

&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;(def delayed
  (let [a &lt;span class=&quot;code-keyword&quot;&gt;true&lt;/span&gt;]
    (delay
      (print &lt;span class=&quot;code-quote&quot;&gt;&quot;a=&quot;&lt;/span&gt; a)
      (&lt;span class=&quot;code-keyword&quot;&gt;throw&lt;/span&gt; (Exception.)))))

(&lt;span class=&quot;code-keyword&quot;&gt;try&lt;/span&gt;
  (print &lt;span class=&quot;code-quote&quot;&gt;&quot;delayed 1:&quot;&lt;/span&gt;)
  (force delayed)
  (&lt;span class=&quot;code-keyword&quot;&gt;catch&lt;/span&gt; Exception ex (println ex)))

(&lt;span class=&quot;code-keyword&quot;&gt;try&lt;/span&gt;
  (print &lt;span class=&quot;code-quote&quot;&gt;&quot;delayed 2:&quot;&lt;/span&gt;)
  (force delayed)
  (&lt;span class=&quot;code-keyword&quot;&gt;catch&lt;/span&gt; Exception ex (println ex)))&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;prints:&lt;/p&gt;

&lt;p&gt;delayed 1:a= true#&amp;lt;Exception java.lang.Exception&amp;gt;&lt;br/&gt;
delayed 2:a= nil#&amp;lt;Exception java.lang.Exception&amp;gt;&lt;/p&gt;</comment>
                    <comment id="30193" author="hank" created="Sun, 9 Dec 2012 01:31:54 -0600"  >&lt;p&gt;The above leads to dodgy outcomes such as: The following expression leads to an Exception on 1st evaluation and to &quot;w00t!&quot; on subsequent ones.&lt;/p&gt;

&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;(def delayed
  (let [a &lt;span class=&quot;code-keyword&quot;&gt;true&lt;/span&gt;]
    (delay
      (&lt;span class=&quot;code-keyword&quot;&gt;if&lt;/span&gt; a
        (&lt;span class=&quot;code-keyword&quot;&gt;throw&lt;/span&gt; (Exception.))
        &lt;span class=&quot;code-quote&quot;&gt;&quot;w00t!&quot;&lt;/span&gt;))))&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;Try it like this:&lt;/p&gt;

&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;(&lt;span class=&quot;code-keyword&quot;&gt;try&lt;/span&gt;
  (print &lt;span class=&quot;code-quote&quot;&gt;&quot;delayed 1:&quot;&lt;/span&gt; )
  (println (force delayed))
  (&lt;span class=&quot;code-keyword&quot;&gt;catch&lt;/span&gt; Exception ex (println ex)))

(&lt;span class=&quot;code-keyword&quot;&gt;try&lt;/span&gt;
  (print &lt;span class=&quot;code-quote&quot;&gt;&quot;delayed 2:&quot;&lt;/span&gt;)
  (println (force delayed))
  (&lt;span class=&quot;code-keyword&quot;&gt;catch&lt;/span&gt; Exception ex (println ex)))&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;Results in:&lt;br/&gt;
delayed 1:#&amp;lt;Exception java.lang.Exception&amp;gt;&lt;br/&gt;
delayed 2:w00t!&lt;/p&gt;

&lt;p&gt;This code shows that the problem is tied to the :once flag as suspected.&lt;/p&gt;

&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;(def test-once
  (let [a &lt;span class=&quot;code-keyword&quot;&gt;true&lt;/span&gt;]
    (^{:once &lt;span class=&quot;code-keyword&quot;&gt;true&lt;/span&gt;} fn* foo []
	    (println &lt;span class=&quot;code-quote&quot;&gt;&quot;a=&quot;&lt;/span&gt; a)
	    (&lt;span class=&quot;code-keyword&quot;&gt;throw&lt;/span&gt; (Exception.)))))&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;Invoking the fn twice will show &apos;a&apos; turning from &apos;true&apos; to &apos;nil&apos;, try it like this:&lt;/p&gt;

&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;(&lt;span class=&quot;code-keyword&quot;&gt;try&lt;/span&gt;
  (print &lt;span class=&quot;code-quote&quot;&gt;&quot;test-once 1:&quot;&lt;/span&gt;)
  (test-once)
  (&lt;span class=&quot;code-keyword&quot;&gt;catch&lt;/span&gt; Exception ex (println ex)))

(&lt;span class=&quot;code-keyword&quot;&gt;try&lt;/span&gt;
  (print &lt;span class=&quot;code-quote&quot;&gt;&quot;test-once 2:&quot;&lt;/span&gt;)
  (test-once)
  (&lt;span class=&quot;code-keyword&quot;&gt;catch&lt;/span&gt; Exception ex (println ex)))&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;Results in:&lt;br/&gt;
test-once 1:a= true&lt;br/&gt;
#&amp;lt;Exception java.lang.Exception&amp;gt;&lt;br/&gt;
test-once 2:a= nil&lt;br/&gt;
#&amp;lt;Exception java.lang.Exception&amp;gt;&lt;/p&gt;

&lt;p&gt;That doesn&apos;t happen when the ^{:once true} is removed. Now one could argue that above fn is invoked twice, which is exactly what one is not supposed to do when decorated with the :once flag, but I argue that an unsuccessful call doesn&apos;t count as invocation towards the :once flag. The delay and lazy-seq macros agree with me there as the resulting objects are not considered realized (as per realized? function) if the evaluation of the body throws an exception, and realization/evaluation of the body is therefore repeated on re-evaluation of the delay/lazy-seq.&lt;/p&gt;

&lt;p&gt;Try this using &lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;(realized? delayed)&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt; after the first evaluation in the code above. In the implementation this can be seen e.g. &lt;a href=&quot;https://github.com/clojure/clojure/blob/d0c380d9809fd242bec688c7134e900f0bbedcac/src/jvm/clojure/lang/Delay.java#L33&quot;&gt;here for clojure.lang.Delay&lt;/a&gt; (similarly for LazySeq), the body-fn is set to null (meaning realized) after the invocation returns &lt;b&gt;successfully&lt;/b&gt; only.&lt;/p&gt;

&lt;p&gt;The :once flag affects &lt;a href=&quot;https://github.com/clojure/clojure/blob/d0c380d9809fd242bec688c7134e900f0bbedcac/src/jvm/clojure/lang/Compiler.java#L4701&quot;&gt;this part of the compiler only&lt;/a&gt;. Some field is set to nil there in the course of a function invocation, for the good reason of letting the garbage compiler collect objects, however this should to be done after the function successfully completes only. Can this be changed?&lt;/p&gt;</comment>
                    <comment id="30240" author="hank" created="Sun, 16 Dec 2012 04:02:08 -0600"  >&lt;p&gt;A workaround for the case of the &apos;map&apos; function as described in the 1st comment, works as this: The original map function, if you take out the cases for several colls, the performance enhancements for chunked seqs and forcing the coll argument to a seq, looks like this:&lt;/p&gt;

&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;(defn map [f s]
  (lazy-seq
    (cons (f (first s)) (map f (&lt;span class=&quot;code-keyword&quot;&gt;rest&lt;/span&gt; s)))))&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;In my workaround I evaluate f &lt;b&gt;twice&lt;/b&gt;:&lt;/p&gt;

&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;(defn map [f s]
  (lazy-seq
    (f (first s))
    (cons (f (first s)) (map f (&lt;span class=&quot;code-keyword&quot;&gt;rest&lt;/span&gt; s)))))&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;Because the downstream functions that are slow to evaluate are all of the deref kind that cache their result (more lazy-seqs, delays, futures, promises), the InterruptedException can only happen during the 1st evaluation, while the tail call optimization that sets closed-over variables to nil (it pays to read this here: &lt;a href=&quot;http://clojure.org/lazy&quot;&gt;http://clojure.org/lazy&lt;/a&gt;) only happens on the second call. The first still creates an fn that captures the head of the sequence &apos;s&apos;, however this is not being held onto as it is not returned.&lt;/p&gt;

&lt;p&gt;I use this special version of map (and other, similarly rewritten functions based on lazy-seq such as iterate) when I want interruptible, restartable seq evaluations.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                                                                                            </customfields>
    </item>

<item>
            <title>[CLJ-1132] For record type Rec,  (instance? Rec (map-&gt;Rec {...})) need not return true, though (instance? Rec (Rec. ...)) does.</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1132</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;    (defrecord Rec ...)&lt;/p&gt;

&lt;p&gt;    (instance? Rec (Rec. ...))        ;=&amp;gt; true&lt;br/&gt;
    (instance? Rec (map-&amp;gt;Rec {...}))  ;=&amp;gt; can be false  &lt;br/&gt;
&lt;br/&gt;
This occurs when the code is wrapped in a tomcat servlet by `lein ring&lt;br/&gt;
uberwar`, but &lt;b&gt;not&lt;/b&gt; when run at the REPL or under Jetty, say.&lt;br/&gt;
&lt;br/&gt;
Although produced under ring, this seems to me to be a general problem&lt;br/&gt;
with the map-&amp;gt; constructor, as (true? (instance? Rec (map-&amp;gt;Rec {...})))&lt;br/&gt;
should be an invariant, regardless of the environment or context.&lt;br/&gt;
The problem seems to arise in some aspect of the class loading process:&lt;/p&gt;

&lt;p&gt;    (.getClassLoader Rec)                    ;=&amp;gt; WebappClassLoader (delegate: false, repositories: /WEB-INF/classes/, parent: org.apache.catalina.loader.StandardClassLoader@790bc49d)&lt;br/&gt;
    (.getClassLoader (class (Rec. ...)))     ;=&amp;gt; WebappClassLoader (same as the previous line)&lt;br/&gt;
    (.getClassLoader (class (map-&amp;gt;Rec ...))) ;=&amp;gt; clojure.lang.DynamicClassLoader@2e7227a8&lt;/p&gt;

&lt;p&gt;The map-&amp;gt;Rec delegates to the create method, which seems to be where the problem lies.&lt;/p&gt;

&lt;p&gt;The record namespace is AOT compiled, properly I think/hope, and the requisite classes &lt;br/&gt;
imported as they should be.&lt;/p&gt;

&lt;p&gt;I have attached a minimal web app that reproduces the problem and shows&lt;br/&gt;
the configuration. As a sanity check, I have also created a trivial &lt;br/&gt;
workaround defrecord* that creates a clojure-native map constructor, &lt;br/&gt;
for which the problem does not occur. See the README.md in the tar &lt;br/&gt;
file for usage details, and the project.clj for my configuration.&lt;/p&gt;

&lt;p&gt;Again, I&apos;ve only been able to reproduce the problem under Tomcat,&lt;br/&gt;
not under Jetty or at the REPL.&lt;/p&gt;</description>
                <environment>Apache Tomcat/6.0.24 JVM/1.6.0_26-b03  Linux 2.6.32-279.el6.x86_64&lt;br/&gt;
&lt;br/&gt;
Clojure 1.4.0,  Ring 1.1.6, Compojure 1.1.3, Lein-Ring Plugin 0.7.5 (for lein ring uberwar)&lt;br/&gt;
</environment>
            <key id="15902">CLJ-1132</key>
            <summary>For record type Rec,  (instance? Rec (map-&gt;Rec {...})) need not return true, though (instance? Rec (Rec. ...)) does.</summary>
                <type id="1" iconUrl="http://dev.clojure.org/jira/images/icons/bug.gif">Defect</type>
                                <priority id="4" iconUrl="http://dev.clojure.org/jira/images/icons/priority_minor.gif">Minor</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="cg-at">Christopher Genovese</reporter>
                        <labels>
                        <label>constructor</label>
                        <label>defrecord</label>
                    </labels>
                <created>Tue, 18 Dec 2012 10:58:29 -0600</created>
                <updated>Tue, 18 Dec 2012 10:58:29 -0600</updated>
                                    <version>Release 1.4</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                <attachments>
                    <attachment id="11766" name="recordbug.tgz" size="5373405" author="cg-at" created="Tue, 18 Dec 2012 10:58:29 -0600" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                                                                                            </customfields>
    </item>

<item>
            <title>[CLJ-1133] Certain actions on mutable fields in deftype lead to very strange error messages</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1133</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;Consider the following code:&lt;/p&gt;

&lt;p&gt;(definterface Test&lt;br/&gt;
  (^void fail []))&lt;/p&gt;

&lt;p&gt;(deftype TestImpl&lt;br/&gt;
  &lt;span class=&quot;error&quot;&gt;&amp;#91;^{:unsynchronized-mutable true :tag int} x&amp;#93;&lt;/span&gt;&lt;br/&gt;
  Test&lt;br/&gt;
  (fail &lt;span class=&quot;error&quot;&gt;&amp;#91;this&amp;#93;&lt;/span&gt;&lt;br/&gt;
    (set! x (dec x))))&lt;/p&gt;

&lt;p&gt;Its compilation fails with the following message:&lt;br/&gt;
CompilerException java.lang.VerifyError: (class: test/TestImpl, method: fail signature: ()V) Expecting to find integer on stack, compiling&lt;img class=&quot;emoticon&quot; src=&quot;http://dev.clojure.org/jira/images/icons/emoticons/sad.gif&quot; height=&quot;20&quot; width=&quot;20&quot; align=&quot;absmiddle&quot; alt=&quot;&quot; border=&quot;0&quot;/&gt;.../test.clj:27) &lt;/p&gt;

&lt;p&gt;The following code works:&lt;/p&gt;

&lt;p&gt;(definterface Test&lt;br/&gt;
  (^void fail []))&lt;/p&gt;

&lt;p&gt;(deftype TestImpl&lt;br/&gt;
  &lt;span class=&quot;error&quot;&gt;&amp;#91;^{:unsynchronized-mutable true :tag int} x&amp;#93;&lt;/span&gt;&lt;br/&gt;
  Test&lt;br/&gt;
  (fail &lt;span class=&quot;error&quot;&gt;&amp;#91;this&amp;#93;&lt;/span&gt;&lt;br/&gt;
    (set! x (int (dec x)))))&lt;/p&gt;

&lt;p&gt;The only change here is that I have wrapped (dec x) form into (int) call.&lt;/p&gt;

&lt;p&gt;I understand that in fact the former code should not work anyway (or at least should not work as I have expected) because (dec) is defined as a call to clojure.lang.Numbers.dec(), which is overloaded for double, long and Object only (in fact, changing :tag int to :tag long in the first example allows the program to compile).  However, the error message is completely uninformative and misleading; it also looks like that it is a consequence of compiler error. It is also not a problem of this concrete example; I found this error in more complex interface method implementation where (set!) call was right in the middle of its body.&lt;/p&gt;

&lt;p&gt;I&apos;m using Clojure 1.4.0 and have experienced this problem on Archlinux x86_64 and Windows 7 x86_64.&lt;/p&gt;

&lt;p&gt;Full stack trace of the error, in case it would be helpful:&lt;/p&gt;

&lt;p&gt;java.lang.VerifyError: (class: test/TestImpl, method: fail signature: ()V) Expecting to find integer on stack, compiling&lt;img class=&quot;emoticon&quot; src=&quot;http://dev.clojure.org/jira/images/icons/emoticons/sad.gif&quot; height=&quot;20&quot; width=&quot;20&quot; align=&quot;absmiddle&quot; alt=&quot;&quot; border=&quot;0&quot;/&gt;.../test.clj:27)&lt;br/&gt;
	at clojure.lang.Compiler.analyzeSeq(Compiler.java:6462)&lt;br/&gt;
	at clojure.lang.Compiler.analyze(Compiler.java:6262)&lt;br/&gt;
	at clojure.lang.Compiler.analyze(Compiler.java:6223)&lt;br/&gt;
	at clojure.lang.Compiler$BodyExpr$Parser.parse(Compiler.java:5618)&lt;br/&gt;
	at clojure.lang.Compiler$FnMethod.parse(Compiler.java:5054)&lt;br/&gt;
	at clojure.lang.Compiler$FnExpr.parse(Compiler.java:3674)&lt;br/&gt;
	at clojure.lang.Compiler.analyzeSeq(Compiler.java:6453)&lt;br/&gt;
	at clojure.lang.Compiler.analyze(Compiler.java:6262)&lt;br/&gt;
	at clojure.lang.Compiler.analyzeSeq(Compiler.java:6443)&lt;br/&gt;
	at clojure.lang.Compiler.analyze(Compiler.java:6262)&lt;br/&gt;
	at clojure.lang.Compiler.access$100(Compiler.java:37)&lt;br/&gt;
	at clojure.lang.Compiler$DefExpr$Parser.parse(Compiler.java:518)&lt;br/&gt;
	at clojure.lang.Compiler.analyzeSeq(Compiler.java:6455)&lt;br/&gt;
	at clojure.lang.Compiler.analyze(Compiler.java:6262)&lt;br/&gt;
	at clojure.lang.Compiler.analyzeSeq(Compiler.java:6443)&lt;br/&gt;
	at clojure.lang.Compiler.analyze(Compiler.java:6262)&lt;br/&gt;
	at clojure.lang.Compiler.analyze(Compiler.java:6223)&lt;br/&gt;
	at clojure.lang.Compiler$BodyExpr$Parser.parse(Compiler.java:5618)&lt;br/&gt;
	at clojure.lang.Compiler$LetExpr$Parser.parse(Compiler.java:5919)&lt;br/&gt;
	at clojure.lang.Compiler.analyzeSeq(Compiler.java:6455)&lt;br/&gt;
	at clojure.lang.Compiler.analyze(Compiler.java:6262)&lt;br/&gt;
	at clojure.lang.Compiler.analyze(Compiler.java:6223)&lt;br/&gt;
	at clojure.lang.Compiler$BodyExpr$Parser.parse(Compiler.java:5618)&lt;br/&gt;
	at clojure.lang.Compiler$FnMethod.parse(Compiler.java:5054)&lt;br/&gt;
	at clojure.lang.Compiler$FnExpr.parse(Compiler.java:3674)&lt;br/&gt;
	at clojure.lang.Compiler.analyzeSeq(Compiler.java:6453)&lt;br/&gt;
	at clojure.lang.Compiler.analyze(Compiler.java:6262)&lt;br/&gt;
	at clojure.lang.Compiler.eval(Compiler.java:6508)&lt;br/&gt;
	at clojure.lang.Compiler.load(Compiler.java:6952)&lt;br/&gt;
	at clojure.lang.Compiler.loadFile(Compiler.java:6912)&lt;br/&gt;
	at clojure.lang.RT$3.invoke(RT.java:307)&lt;br/&gt;
	at test$eval3224.invoke(NO_SOURCE_FILE:43)&lt;br/&gt;
	at clojure.lang.Compiler.eval(Compiler.java:6511)&lt;br/&gt;
	at clojure.lang.Compiler.eval(Compiler.java:6477)&lt;br/&gt;
	at clojure.core$eval.invoke(core.clj:2797)&lt;br/&gt;
	at clojure.main$repl$read_eval_print__6405.invoke(main.clj:245)&lt;br/&gt;
	at clojure.main$repl$fn__6410.invoke(main.clj:266)&lt;br/&gt;
	at clojure.main$repl.doInvoke(main.clj:266)&lt;br/&gt;
	at clojure.lang.RestFn.invoke(RestFn.java:421)&lt;br/&gt;
	at clojure.main$repl_opt.invoke(main.clj:332)&lt;br/&gt;
	at clojure.main$main.doInvoke(main.clj:428)&lt;br/&gt;
	at clojure.lang.RestFn.invoke(RestFn.java:397)&lt;br/&gt;
	at clojure.lang.Var.invoke(Var.java:411)&lt;br/&gt;
	at clojure.lang.AFn.applyToHelper(AFn.java:159)&lt;br/&gt;
	at clojure.lang.Var.applyTo(Var.java:532)&lt;br/&gt;
	at clojure.main.main(main.java:37)&lt;br/&gt;
Caused by: java.lang.VerifyError: (class: test/TestImpl, method: fail signature: ()V) Expecting to find integer on stack&lt;br/&gt;
	at java.lang.Class.forName0(Native Method)&lt;br/&gt;
	at java.lang.Class.forName(Class.java:264)&lt;br/&gt;
	at clojure.lang.RT.classForName(RT.java:2039)&lt;br/&gt;
	at clojure.lang.Compiler$HostExpr.maybeClass(Compiler.java:957)&lt;br/&gt;
	at clojure.lang.Compiler$HostExpr.access$400(Compiler.java:736)&lt;br/&gt;
	at clojure.lang.Compiler$NewExpr$Parser.parse(Compiler.java:2473)&lt;br/&gt;
	at clojure.lang.Compiler.analyzeSeq(Compiler.java:6455)&lt;br/&gt;
	... 45 more&lt;/p&gt;</description>
                <environment>Archlinux x86_64, Windows 7 x86_64</environment>
            <key id="15905">CLJ-1133</key>
            <summary>Certain actions on mutable fields in deftype lead to very strange error messages</summary>
                <type id="1" iconUrl="http://dev.clojure.org/jira/images/icons/bug.gif">Defect</type>
                                <priority id="4" iconUrl="http://dev.clojure.org/jira/images/icons/priority_minor.gif">Minor</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="dpx-infinity">Vladimir Matveev</reporter>
                        <labels>
                    </labels>
                <created>Tue, 18 Dec 2012 13:48:31 -0600</created>
                <updated>Wed, 19 Dec 2012 01:20:28 -0600</updated>
                                    <version>Release 1.4</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                        <comments>
                    <comment id="30255" author="dpx-infinity" created="Tue, 18 Dec 2012 13:51:17 -0600"  >&lt;p&gt;Shouldn&apos;t have set major priority; but I cannot edit issue again &lt;img class=&quot;emoticon&quot; src=&quot;http://dev.clojure.org/jira/images/icons/emoticons/sad.gif&quot; height=&quot;20&quot; width=&quot;20&quot; align=&quot;absmiddle&quot; alt=&quot;&quot; border=&quot;0&quot;/&gt;&lt;/p&gt;</comment>
                    <comment id="30263" author="jafingerhut" created="Wed, 19 Dec 2012 01:20:28 -0600"  >&lt;p&gt;Reduced priority to minor, since ticket creator could not do so themselves.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                                                                                            </customfields>
    </item>

<item>
            <title>[CLJ-835] defmulti doc string doesn&apos;t mention needing to be passed a var for the value of :hierarchy</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-835</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;The :hierarchy option for defmulti should be passed a var, but this is not mentioned in the doc string.&lt;/p&gt;

&lt;p&gt;The error message from passing the hierarchy directly is rather cryptic:&lt;/p&gt;

&lt;p&gt;Evaluation aborted on java.lang.ClassCastException: clojure.lang.PersistentArrayMap cannot be cast to clojure.lang.IRef (SOURCE_FORM_44:19).&lt;/p&gt;</description>
                <environment>1.2, 1.3 beta3</environment>
            <key id="14599">CLJ-835</key>
            <summary>defmulti doc string doesn&apos;t mention needing to be passed a var for the value of :hierarchy</summary>
                <type id="1" iconUrl="http://dev.clojure.org/jira/images/icons/bug.gif">Defect</type>
                                <priority id="4" iconUrl="http://dev.clojure.org/jira/images/icons/priority_minor.gif">Minor</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="hugoduncan">Hugo Duncan</reporter>
                        <labels>
                    </labels>
                <created>Fri, 2 Sep 2011 15:09:00 -0500</created>
                <updated>Wed, 19 Dec 2012 07:59:17 -0600</updated>
                                    <version>Release 1.2</version>
                                                        <due></due>
                    <votes>1</votes>
                        <watches>2</watches>
                        <comments>
                    <comment id="26815" author="mbrandmeyer" created="Wed, 14 Sep 2011 15:11:10 -0500"  >&lt;p&gt;Modified doctoring to clarify the usage of &lt;tt&gt;:hierarchy&lt;/tt&gt;.&lt;/p&gt;</comment>
                    <comment id="28429" author="scottlowe" created="Thu, 10 May 2012 17:16:19 -0500"  >&lt;p&gt;New patch: &apos;0001-&lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-835&quot; title=&quot;defmulti doc string doesn&amp;#39;t mention needing to be passed a var for the value of :hierarchy&quot;&gt;CLJ-835&lt;/a&gt;-Refine-doc-string-for-defmulti-hierarchy-opt.patch&apos; 10/May/12.&lt;/p&gt;

&lt;p&gt;I&apos;ve attached a new doc string patch in response to Andy Fingerhut&apos;s request posted here: &lt;a href=&quot;https://groups.google.com/forum/?fromgroups#!topic/clojure-dev/i7H82fJYL-U&quot;&gt;https://groups.google.com/forum/?fromgroups#!topic/clojure-dev/i7H82fJYL-U&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;Andy&apos;s request stated &quot;Attached patch seems to have spelling mistakes, and perhaps could be worded more clearly.&quot;&lt;/p&gt;

&lt;p&gt;I hope my new patch is an improvement upon what was there.&lt;/p&gt;

&lt;p&gt;This patch supersedes &apos;0001-Clarify-docstring-for-defmulti.patch&apos; from 14/Sep/11.&lt;/p&gt;</comment>
                    <comment id="29195" author="fogus" created="Thu, 16 Aug 2012 14:49:50 -0500"  >&lt;p&gt;This is a million times better than what was there before, but (who knew!?) it could be better. A couple points of contention:&lt;/p&gt;

&lt;ul&gt;
	&lt;li&gt;The order under the &lt;tt&gt;:hierarchy&lt;/tt&gt; section seems off. I would start with an overview of what a hierarchy is including a definition of the global hierarchy map (it&apos;s mentioned, but glossed over). I&apos;d then move on to an example impl. Finally, I&apos;d then add the discussion starting &quot;Multimethods expect...&quot; immediately followed by an example.&lt;/li&gt;
&lt;/ul&gt;


&lt;ul&gt;
	&lt;li&gt;In the &lt;tt&gt;isa?&lt;/tt&gt; example it would be great to show the return value.&lt;/li&gt;
&lt;/ul&gt;


&lt;ul&gt;
	&lt;li&gt;You mention that the hierarchy should be supplied as a reference, which is correct, however you talk about #&apos;.  The link between e.g. var and #&apos; could be a bit more explicit. Maybe the sentence about #&apos; could be parenthetical?&lt;/li&gt;
&lt;/ul&gt;


&lt;ul&gt;
	&lt;li&gt;It&apos;s ok to finish with a very small example of its use in &lt;tt&gt;defmethod&lt;/tt&gt;, in fact a simple example specifying methods for &lt;tt&gt;::shape&lt;/tt&gt; and &lt;tt&gt;::circle&lt;/tt&gt; would clarify the intent nicely.&lt;/li&gt;
&lt;/ul&gt;
</comment>
                    <comment id="30265" author="richhickey" created="Wed, 19 Dec 2012 07:58:57 -0600"  >&lt;p&gt;Please leave examples out of docs strings. Use precise language.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="10361" name="0001-Clarify-docstring-for-defmulti.patch" size="1058" author="mbrandmeyer" created="Wed, 14 Sep 2011 15:11:10 -0500" />
                    <attachment id="11188" name="0001-CLJ-835-Refine-doc-string-for-defmulti-hierarchy-opt.patch" size="1885" author="scottlowe" created="Thu, 10 May 2012 17:16:19 -0500" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_10002" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Approval</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10006">Incomplete</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                    <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10000" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Patch</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10001">Code</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[CLJ-1137] Metadata on a def gets evaluated twice</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1137</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;Metadata on the symbol of a def special form is evaluated twice.&lt;/p&gt;

&lt;p&gt;(def ^{:foo (println &quot;HA&quot;)} a [])&lt;/p&gt;

&lt;p&gt;prints out HA HA.  Offending line is in Compiler$DefExpr, fixed.&lt;/p&gt;</description>
                <environment></environment>
            <key id="15915">CLJ-1137</key>
            <summary>Metadata on a def gets evaluated twice</summary>
                <type id="1" iconUrl="http://dev.clojure.org/jira/images/icons/bug.gif">Defect</type>
                                <priority id="4" iconUrl="http://dev.clojure.org/jira/images/icons/priority_minor.gif">Minor</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="gshayban">Ghadi Shayban</reporter>
                        <labels>
                    </labels>
                <created>Fri, 21 Dec 2012 11:32:28 -0600</created>
                <updated>Fri, 21 Dec 2012 11:32:28 -0600</updated>
                                                                            <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                <attachments>
                    <attachment id="11772" name="CLJ-1137-eval-metadata-once.diff" size="889" author="gshayban" created="Fri, 21 Dec 2012 11:32:28 -0600" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10000" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Patch</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10001">Code</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[CLJ-1120] Introduce ex-message and ex-cause to abstract away the platform in dealing with ExceptionInfo</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1120</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;As described in the title. See &lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJS-429&quot; title=&quot;Data Conveying Exception: ex-data and ex-info&quot;&gt;&lt;del&gt;CLJS-429&lt;/del&gt;&lt;/a&gt;.&lt;/p&gt;</description>
                <environment></environment>
            <key id="15872">CLJ-1120</key>
            <summary>Introduce ex-message and ex-cause to abstract away the platform in dealing with ExceptionInfo</summary>
                <type id="4" iconUrl="http://dev.clojure.org/jira/images/icons/improvement.gif">Enhancement</type>
                                <priority id="4" iconUrl="http://dev.clojure.org/jira/images/icons/priority_minor.gif">Minor</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="michalmarczyk">Micha&#322; Marczyk</assignee>
                                <reporter username="michalmarczyk">Micha&#322; Marczyk</reporter>
                        <labels>
                    </labels>
                <created>Thu, 6 Dec 2012 06:19:15 -0600</created>
                <updated>Fri, 21 Dec 2012 23:03:36 -0600</updated>
                                                                            <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                        <comments>
                    <comment id="30177" author="michalmarczyk" created="Thu, 6 Dec 2012 06:23:10 -0600"  >&lt;p&gt;The attached patch implements ex-message and ex-cause to work on arbitrary Throwables.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="11749" name="0001-CLJ-1120-ex-message-ex-cause.patch" size="1357" author="michalmarczyk" created="Thu, 6 Dec 2012 06:23:10 -0600" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10000" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Patch</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10001">Code</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[CLJ-1134] star-directive in clojure.pprint/cl-format with an at-prefix (&quot;~n@*&quot;) do not obey its specifications</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1134</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;The star-directive in &lt;tt&gt;clojure.pprint/cl-format&lt;/tt&gt; with an at-prefix (&lt;tt&gt;&amp;#126;n@&amp;#42;&lt;/tt&gt;) does not obey its specifications according to &lt;a href=&quot;http://www.cs.cmu.edu/afs/cs.cmu.edu/project/ai-repository/ai/html/cltl/clm/node200.html#SECTION002633000000000000000&quot;&gt;Common Lisp the Language, 2nd Edition&lt;/a&gt;. There are two bugs within &lt;tt&gt;&amp;#126;n@&amp;#42;&lt;/tt&gt; as of right now:&lt;/p&gt;

&lt;ol&gt;
	&lt;li&gt;When &lt;tt&gt;&amp;#126;n@&amp;#42;&lt;/tt&gt; is supposed to jump forward over more than one argument, it jumps one step backward as if it had seen &lt;tt&gt;&amp;#126;:&amp;#42;&lt;/tt&gt;. For instance, &lt;tt&gt;(cl-format nil &quot;~D ~3@*~D&quot; 0 1 2 3)&lt;/tt&gt; will return &lt;tt&gt;&quot;0 0&quot;&lt;/tt&gt; and not &lt;tt&gt;&quot;0 3&quot;&lt;/tt&gt; as expected.&lt;/li&gt;
	&lt;li&gt;When &lt;tt&gt;&amp;#126;@&amp;#42;&lt;/tt&gt; is seen, the formatter is supposed to jump to the first argument (as &lt;tt&gt;n&lt;/tt&gt; defaults to &lt;tt&gt;0&lt;/tt&gt;, see specification linked above). However, whenever a &lt;tt&gt;&amp;#126;@&amp;#42;&lt;/tt&gt;-directive is seen, the formatter jumps to the second argument instead.&lt;/li&gt;
&lt;/ol&gt;


&lt;h4&gt;&lt;a name=&quot;What%28smallsetof%29stepswillreproducetheproblem%3F&quot;&gt;&lt;/a&gt;What (small set of) steps will reproduce the problem?&lt;/h4&gt;

&lt;p&gt;Inside a clean Clojure repl, perform these steps:&lt;/p&gt;
&lt;div class=&quot;preformatted panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;preformattedContent panelContent&quot;&gt;
&lt;pre&gt;user=&amp;gt; (require &apos;[clojure.pprint :refer [cl-format]])
nil
user=&amp;gt; (cl-format nil &quot;~D ~3@*~D&quot; 0 1 2 3)
&quot;0 0&quot;                                           ;; Expected: &quot;0 3&quot;
user=&amp;gt; (cl-format nil &quot;~D~D~D~D ~@*~D&quot; 0 1 2 3)
&quot;0123 1&quot;                                        ;; Expected: &quot;0123 0&quot;
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;h4&gt;&lt;a name=&quot;Whatistheexpectedoutput%3FWhatdoyouseeinstead%3F&quot;&gt;&lt;/a&gt;What is the expected output? What do you see instead?&lt;/h4&gt;

&lt;p&gt;The expected output is &lt;tt&gt;&quot;0 3&quot;&lt;/tt&gt; and &lt;tt&gt;&quot;0123 0&quot;&lt;/tt&gt;, but is &lt;tt&gt;&quot;0 0&quot;&lt;/tt&gt; and &lt;tt&gt;&quot;0123 1&quot;&lt;/tt&gt; as shown above.&lt;/p&gt;

&lt;h4&gt;&lt;a name=&quot;Whatversionareyouusing%3F&quot;&gt;&lt;/a&gt;What version are you using?&lt;/h4&gt;

&lt;p&gt;Tested on both &lt;tt&gt;1.4.0&lt;/tt&gt; and &lt;tt&gt;1.5.0-beta2&lt;/tt&gt;, both have the defect described.&lt;/p&gt;

&lt;h4&gt;&lt;a name=&quot;Pleaseprovideanyadditionalinformationbelow.&quot;&gt;&lt;/a&gt;Please provide any additional information below.&lt;/h4&gt;

&lt;p&gt;The format strings which reproduces the problem has been compared with the &lt;tt&gt;format&lt;/tt&gt; function from the Common Lisp implementations SBCL, CLisp and Clozure. All of them print the expected output.&lt;/p&gt;</description>
                <environment></environment>
            <key id="15907">CLJ-1134</key>
            <summary>star-directive in clojure.pprint/cl-format with an at-prefix (&quot;~n@*&quot;) do not obey its specifications</summary>
                <type id="1" iconUrl="http://dev.clojure.org/jira/images/icons/bug.gif">Defect</type>
                                <priority id="4" iconUrl="http://dev.clojure.org/jira/images/icons/priority_minor.gif">Minor</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="hypirion">Jean Niklas L&apos;orange</reporter>
                        <labels>
                        <label>bug</label>
                        <label>pprint</label>
                    </labels>
                <created>Tue, 18 Dec 2012 20:34:25 -0600</created>
                <updated>Wed, 26 Dec 2012 19:57:30 -0600</updated>
                                    <version>Release 1.4</version>
                <version>Release 1.5</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>2</watches>
                        <comments>
                    <comment id="30261" author="hypirion" created="Tue, 18 Dec 2012 21:28:03 -0600"  >&lt;p&gt;Patch attached.&lt;/p&gt;

&lt;p&gt;It may be easier to read the changes the patch does from within JIRA instead from the commit message, so I&apos;ve added it here:&lt;/p&gt;

&lt;p&gt;This solves two issues as specified by #&lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-1134&quot; title=&quot;star-directive in clojure.pprint/cl-format with an at-prefix (&amp;quot;~n@*&amp;quot;) do not obey its specifications&quot;&gt;CLJ-1134&lt;/a&gt;. Issue #1 is solved by doing a&lt;br/&gt;
relative jump forward within &lt;tt&gt;absolute-reposition&lt;/tt&gt; in &lt;tt&gt;cl_format.clj&lt;/tt&gt;, line 114 by&lt;br/&gt;
switching &lt;tt&gt;(- (:pos navigator) position)&lt;/tt&gt; with &lt;tt&gt;(- position (:pos navigator))&lt;/tt&gt;.&lt;/p&gt;

&lt;p&gt;Issue #2 is handled by changing the default &lt;tt&gt;n&lt;/tt&gt;-parameter to &lt;tt&gt;*&lt;/tt&gt; depending on&lt;br/&gt;
whether the &lt;tt&gt;@&lt;/tt&gt;-prefix is placed or not. If it is placed, then &lt;tt&gt;n&lt;/tt&gt; defaults to&lt;br/&gt;
0, otherwise it defaults to 1.&lt;/p&gt;

&lt;p&gt;In addition, new tests have been appended to &lt;tt&gt;test_cl_format.clj&lt;/tt&gt; to ensure the&lt;br/&gt;
correctness of this patch. The tests have been tested on the Common Lisp&lt;br/&gt;
implementation GNU CLISP 2.49, which presumably handle the &lt;tt&gt;~n@*&lt;/tt&gt;&lt;br/&gt;
correctly. This patch and GNU CLISP returns the same output for each format&lt;br/&gt;
call, sans case for printed symbols; Common Lisp has case-insensitive symbols,&lt;br/&gt;
whereas Clojure has not.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="11767" name="clj-1134-star-directive-in-cl-format.txt" size="4067" author="hypirion" created="Tue, 18 Dec 2012 21:28:03 -0600" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10000" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Patch</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10002">Code and Test</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[CLJ-1010] A left-to-right-variant of `comp`</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1010</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;The function composition function `comp` is quite inefficient in cases like `(apply comp large-seq-of-fns)`, because its arity-greater-than-3 version reverses the seq.&lt;/p&gt;

&lt;p&gt;I would be great if there was an alternative `comp*` (or whatever) function which is just like `comp` but composes left-to-right.&lt;/p&gt;</description>
                <environment></environment>
            <key id="15524">CLJ-1010</key>
            <summary>A left-to-right-variant of `comp`</summary>
                <type id="4" iconUrl="http://dev.clojure.org/jira/images/icons/improvement.gif">Enhancement</type>
                                <priority id="4" iconUrl="http://dev.clojure.org/jira/images/icons/priority_minor.gif">Minor</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="tsdh">Tassilo Horn</reporter>
                        <labels>
                        <label>enhancement</label>
                        <label>patch</label>
                    </labels>
                <created>Mon, 11 Jun 2012 04:57:55 -0500</created>
                <updated>Thu, 14 Jun 2012 18:27:23 -0500</updated>
                                                                            <due></due>
                    <votes>0</votes>
                        <watches>1</watches>
                        <comments>
                    <comment id="28772" author="tsdh" created="Mon, 11 Jun 2012 05:16:50 -0500"  >&lt;p&gt;Here&apos;s an implementation.&lt;/p&gt;</comment>
                    <comment id="28776" author="tsdh" created="Mon, 11 Jun 2012 12:41:07 -0500"  >&lt;p&gt;There&apos;s something strange with my patch.  The creation of a composition of a huge seq of functions is much faster with `comp*` than with `comp`, which is expected, because the seq doesn&apos;t need to be reversed.&lt;/p&gt;

&lt;p&gt;The strange thing however is that the compositions created with `comp` evaluate about 10-20% faster than those created with `comp*` although the arbitrary-arity version of `comp` is defined in terms of `comp*`: `(apply comp* (reverse (list* f1 f2 f3 fs)))`.&lt;/p&gt;

&lt;p&gt;For some benchmarking details, see: &lt;a href=&quot;https://groups.google.com/d/msg/clojure/MizwTxHwLE4/hGLrMfetlP8J&quot;&gt;https://groups.google.com/d/msg/clojure/MizwTxHwLE4/hGLrMfetlP8J&lt;/a&gt;&lt;/p&gt;</comment>
                    <comment id="28802" author="tsdh" created="Thu, 14 Jun 2012 02:32:38 -0500"  >&lt;p&gt;Here&apos;s some benchmark:&lt;/p&gt;

&lt;div class=&quot;preformatted panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;preformattedContent panelContent&quot;&gt;
&lt;pre&gt;user&amp;gt; (use &apos;criterium.core)
nil
user&amp;gt; (let [coll (doall (take 1000000 (repeat inc)))
	   f1 (apply comp* coll) 
	   f2 (apply comp coll)] 
	   (bench (f1 0) :verbose) 
	   (println &quot;---------------------------------------&quot;)
	   (bench (f2 0) :verbose))
amd64 Linux 3.4.2-gentoo 2 cpu(s)
OpenJDK 64-Bit Server VM 22.0-b10
Runtime arguments: -agentlib:jdwp=transport=dt_socket,server=y,suspend=n -XX:+TieredCompilation -Xmx1G -Dclojure.compile.path=/home/horn/Repos/clj/testi/target/classes -Dtesti.version=0.1.0-SNAPSHOT -Dclojure.debug=false
Evaluation count             : 600
             Execution time mean : 112.324465 ms  95.0% CI: (112.247218 ms, 112.380682 ms)
    Execution time std-deviation : 6.513809 ms  95.0% CI: (6.477450 ms, 6.553029 ms)
         Execution time lower ci : 105.609401 ms  95.0% CI: (105.609401 ms, 105.622918 ms)
         Execution time upper ci : 122.353763 ms  95.0% CI: (122.353763 ms, 122.405315 ms)
---------------------------------------
amd64 Linux 3.4.2-gentoo 2 cpu(s)
OpenJDK 64-Bit Server VM 22.0-b10
Runtime arguments: -agentlib:jdwp=transport=dt_socket,server=y,suspend=n -XX:+TieredCompilation -Xmx1G -Dclojure.compile.path=/home/horn/Repos/clj/testi/target/classes -Dtesti.version=0.1.0-SNAPSHOT -Dclojure.debug=false
Evaluation count             : 1440
             Execution time mean : 43.519663 ms  95.0% CI: (43.516732 ms, 43.524062 ms)
    Execution time std-deviation : 492.299089 us  95.0% CI: (490.829889 us, 494.198137 us)
         Execution time lower ci : 42.781398 ms  95.0% CI: (42.781398 ms, 42.781398 ms)
         Execution time upper ci : 44.157311 ms  95.0% CI: (44.157311 ms, 44.158513 ms)
nil
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;</comment>
                    <comment id="28803" author="tsdh" created="Thu, 14 Jun 2012 03:40:08 -0500"  >&lt;p&gt;Ok, I&apos;ve tracked down the performance difference.  This comes from the fact that `reverse` creates a clojure.lang.PersistentList which can be iterated much faster than a (fully realized) LazySeq.  If you provide your fncoll in `(apply comp* fncoll)` as vector or list, the application of the created composition is as fast as for `comp`.&lt;/p&gt;

&lt;p&gt;So for me, the patch is good and makes sense.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="11307" name="0001-CLJ-1010-Add-a-left-to-right-version-of-comp-comp.patch" size="2569" author="tsdh" created="Mon, 11 Jun 2012 05:16:50 -0500" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10000" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Patch</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10001">Code</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[CLJ-1094] Zero-arity versions of every-pred and some-fn</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1094</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;This patch adds zero-arity versions of every-pred and some-fn with these semantics.&lt;/p&gt;

&lt;div class=&quot;preformatted panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;preformattedContent panelContent&quot;&gt;
&lt;pre&gt;(every-pred) === (constantly true)
(some-fn)    === (constantly nil)
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;These variants are useful in situations like the following:&lt;/p&gt;

&lt;div class=&quot;preformatted panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;preformattedContent panelContent&quot;&gt;
&lt;pre&gt;;; compute-preds-for may return zero or many predicate fns
(let [preds (compute-preds-for something)]
  (filter (apply every-pred preds) some-coll))
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;</description>
                <environment></environment>
            <key id="15780">CLJ-1094</key>
            <summary>Zero-arity versions of every-pred and some-fn</summary>
                <type id="4" iconUrl="http://dev.clojure.org/jira/images/icons/improvement.gif">Enhancement</type>
                                <priority id="4" iconUrl="http://dev.clojure.org/jira/images/icons/priority_minor.gif">Minor</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="tsdh">Tassilo Horn</reporter>
                        <labels>
                        <label>patch</label>
                        <label>test</label>
                    </labels>
                <created>Thu, 25 Oct 2012 07:08:28 -0500</created>
                <updated>Thu, 25 Oct 2012 07:12:35 -0500</updated>
                                                                            <due></due>
                    <votes>1</votes>
                        <watches>2</watches>
                        <comments>
                    <comment id="29799" author="tsdh" created="Thu, 25 Oct 2012 07:12:35 -0500"  >&lt;p&gt;This is the thread where Max Penet suggested to have 0-arity versions of the two fns:&lt;/p&gt;

&lt;p&gt;  &lt;a href=&quot;https://groups.google.com/forum/?fromgroups=#!topic/clojure/IRlN-4LH_U0&quot;&gt;https://groups.google.com/forum/?fromgroups=#!topic/clojure/IRlN-4LH_U0&lt;/a&gt;&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="11611" name="0001-Add-zero-arity-variants-for-every-pred-and-some-fn.patch" size="3462" author="tsdh" created="Thu, 25 Oct 2012 07:08:28 -0500" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10000" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Patch</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10002">Code and Test</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[CLJ-1112] Var *loading-verbosely* should initialize from a JVM system property</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1112</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;I often find myself adding :verbose to a (require) or (use) clause of my (ns) in order to debug problems (especially macros, or bad namespace declarations). It would be very nice if I could define a JVM system property (say -Dclojure.load-verbosely=true) to default &lt;b&gt;loading-verbosely&lt;/b&gt; to true for a REPL session, or as part of a build. &lt;/p&gt;

&lt;p&gt;Sometimes I just like to see that namespaces load as a measure of progress, when starting an application, or when running a set of tests.&lt;/p&gt;</description>
                <environment></environment>
            <key id="15845">CLJ-1112</key>
            <summary>Var *loading-verbosely* should initialize from a JVM system property</summary>
                <type id="4" iconUrl="http://dev.clojure.org/jira/images/icons/improvement.gif">Enhancement</type>
                                <priority id="4" iconUrl="http://dev.clojure.org/jira/images/icons/priority_minor.gif">Minor</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="hlewisship">Howard Lewis Ship</reporter>
                        <labels>
                        <label>patch</label>
                    </labels>
                <created>Wed, 21 Nov 2012 13:19:20 -0600</created>
                <updated>Thu, 22 Nov 2012 02:14:32 -0600</updated>
                                    <version>Release 1.4</version>
                                                        <due></due>
                    <votes>1</votes>
                        <watches>1</watches>
                        <comments>
                    <comment id="30006" author="tsdh" created="Thu, 22 Nov 2012 02:12:02 -0600"  >&lt;p&gt;This patch implements the suggested feature.&lt;/p&gt;

&lt;p&gt;The new system property is called &lt;tt&gt;clojure.core.loading-verbosely&lt;/tt&gt; in analogy to the existing &lt;tt&gt;clojure.compile.warn-on-reflection&lt;/tt&gt;.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="11697" name="0001-Allow-setting-loading-verbosely-by-system-property.patch" size="1456" author="tsdh" created="Thu, 22 Nov 2012 02:12:02 -0600" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10000" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Patch</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10001">Code</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[CLJ-1130] Invoking a static method with the wrong number of arguments results in a NoSuchFieldException, rather than a proper message that the arguments could not be matched to the method</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1130</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;My code inadventently invoked a method that expected a single parameter, but passed no parameters.&lt;/p&gt;

&lt;p&gt;The exception:&lt;/p&gt;
&lt;div class=&quot;preformatted panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;preformattedContent panelContent&quot;&gt;
&lt;pre&gt;Exception in thread &quot;main&quot; java.lang.NoSuchFieldException: getService, compiling:(com/annadaletech/nexus/services/registry.clj:168)
	at clojure.lang.Compiler.analyzeSeq(Compiler.java:6462)
	at clojure.lang.Compiler.analyze(Compiler.java:6262)
	at clojure.lang.Compiler.analyzeSeq(Compiler.java:6443)
	at clojure.lang.Compiler.analyze(Compiler.java:6262)
	at clojure.lang.Compiler.access$100(Compiler.java:37)
	at clojure.lang.Compiler$LetExpr$Parser.parse(Compiler.java:5883)
....
Caused by: java.lang.NoSuchFieldException: getService
	at java.lang.Class.getField(Class.java:1520)
	at clojure.lang.Compiler$StaticFieldExpr.&amp;lt;init&amp;gt;(Compiler.java:1180)
	at clojure.lang.Compiler$HostExpr$Parser.parse(Compiler.java:923)
	at clojure.lang.Compiler.analyzeSeq(Compiler.java:6455)
	... 78 more
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;That threw me for a bit; really, it looks like the compiler is attempting to access a field and invoke it as an IFn.  However, a proper message would be &quot;getService() requires 1 parameter, not 0&quot; (or something to that effect).  Even &quot;invalid number of parameters for SmashRuntime/getService()&quot; would be better.&lt;/p&gt;</description>
                <environment></environment>
            <key id="15898">CLJ-1130</key>
            <summary>Invoking a static method with the wrong number of arguments results in a NoSuchFieldException, rather than a proper message that the arguments could not be matched to the method</summary>
                <type id="1" iconUrl="http://dev.clojure.org/jira/images/icons/bug.gif">Defect</type>
                                <priority id="4" iconUrl="http://dev.clojure.org/jira/images/icons/priority_minor.gif">Minor</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="hlewisship">Howard Lewis Ship</reporter>
                        <labels>
                        <label>feedback</label>
                    </labels>
                <created>Mon, 17 Dec 2012 17:57:44 -0600</created>
                <updated>Sun, 6 Jan 2013 18:44:47 -0600</updated>
                                    <version>Release 1.4</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                        <comments>
                    <comment id="30382" author="michael-drogalis" created="Sun, 6 Jan 2013 18:44:47 -0600"  >&lt;p&gt;It looks like it&apos;s first trying to resolve a field by name, since field access with &lt;tt&gt;/&lt;/tt&gt; is legal. For example:&lt;/p&gt;

&lt;p&gt;&lt;tt&gt;user=&amp;gt; (Integer/parseInt)&lt;/tt&gt;&lt;br/&gt;
&lt;tt&gt;CompilerException java.lang.NoSuchFieldException: parseInt, compiling:(NO_SOURCE_PATH:1)&lt;/tt&gt;&lt;/p&gt;

&lt;p&gt;&lt;tt&gt;user=&amp;gt; (Integer/MAX_VALUE)&lt;/tt&gt;&lt;br/&gt;
&lt;tt&gt;2147483647&lt;/tt&gt;&lt;/p&gt;

&lt;p&gt;Would trying to resolve a method before a field fix this?&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                                                                                            </customfields>
    </item>

<item>
            <title>[CLJ-1030] Misleading ClassCastException when coercing a String to int</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1030</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;Observed behaviour&lt;/p&gt;

&lt;p&gt;(int &quot;0&quot;) =&amp;gt;&lt;br/&gt;
java.lang.ClassCastException: java.lang.String cannot be cast to java.lang.Character&lt;/p&gt;

&lt;p&gt;Expected behaviour&lt;br/&gt;
(int &quot;0&quot;) =&amp;gt;&lt;br/&gt;
java.lang.ClassCastException: java.lang.String cannot be cast to java.lang.Integer&lt;br/&gt;
or &lt;br/&gt;
IllegalArgumentException&lt;/p&gt;</description>
                <environment></environment>
            <key id="15591">CLJ-1030</key>
            <summary>Misleading ClassCastException when coercing a String to int</summary>
                <type id="4" iconUrl="http://dev.clojure.org/jira/images/icons/improvement.gif">Enhancement</type>
                                <priority id="4" iconUrl="http://dev.clojure.org/jira/images/icons/priority_minor.gif">Minor</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="ordnungswidrig">Philipp Meier</reporter>
                        <labels>
                        <label>bug</label>
                    </labels>
                <created>Wed, 25 Jul 2012 06:13:21 -0500</created>
                <updated>Sun, 6 Jan 2013 20:52:40 -0600</updated>
                                    <version>Release 1.4</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>1</watches>
                        <comments>
                    <comment id="29532" author="jafingerhut" created="Mon, 24 Sep 2012 11:20:07 -0500"  >&lt;p&gt;If someone wants to improve the behavior of int in this case, they should also consider similar improvements to the error messages for unchecked-int, char, and unchecked-char.&lt;/p&gt;</comment>
                    <comment id="30383" author="michael-drogalis" created="Sun, 6 Jan 2013 20:45:00 -0600"  >&lt;p&gt;Patch improved-int-char-casting-error-messages.diff on January 6, 2013.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="11793" name="improved-int-char-casting-error-messages.diff" size="3855" author="michael-drogalis" created="Sun, 6 Jan 2013 20:45:00 -0600" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10000" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Patch</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10002">Code and Test</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[CLJ-1086] Support arity-1 for -&gt;&gt;</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1086</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;Currently (as of Clojure 1.4) -&amp;gt;&amp;gt; doesn&apos;t support arity-1, though -&amp;gt; does. Arity-1 for -&amp;gt;&amp;gt; would be useful to let somebody comment out forms as follows:&lt;/p&gt;

&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;(-&amp;gt;&amp;gt; foo
  #_(bar baz)
  #_quux)&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;Discussion: &lt;a href=&quot;https://groups.google.com/forum/?fromgroups=#!topic/clojure/_IVl0Tb7Au4&quot;&gt;https://groups.google.com/forum/?fromgroups=#!topic/clojure/_IVl0Tb7Au4&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;My name on contributor list page &lt;a href=&quot;http://clojure.org/contributing&quot;&gt;http://clojure.org/contributing&lt;/a&gt; is: Shantanu Kumar&lt;/p&gt;</description>
                <environment>Clojure and ClojureScript</environment>
            <key id="15748">CLJ-1086</key>
            <summary>Support arity-1 for -&gt;&gt;</summary>
                <type id="4" iconUrl="http://dev.clojure.org/jira/images/icons/improvement.gif">Enhancement</type>
                                <priority id="4" iconUrl="http://dev.clojure.org/jira/images/icons/priority_minor.gif">Minor</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="kumarshantanu">Shantanu Kumar</reporter>
                        <labels>
                    </labels>
                <created>Fri, 12 Oct 2012 13:39:09 -0500</created>
                <updated>Sat, 12 Jan 2013 18:48:06 -0600</updated>
                                    <version>Release 1.1</version>
                <version>Release 1.2</version>
                <version>Release 1.3</version>
                <version>Release 1.4</version>
                                                        <due></due>
                    <votes>2</votes>
                        <watches>1</watches>
                        <comments>
                    <comment id="29909" author="jafingerhut" created="Thu, 8 Nov 2012 13:37:03 -0600"  >&lt;p&gt;Shantanu, you give your name on the contributing page, but I don&apos;t see it there.  Is your CA in transit, perhaps?&lt;/p&gt;</comment>
                    <comment id="29910" author="kumarshantanu" created="Thu, 8 Nov 2012 13:43:15 -0600"  >&lt;p&gt;@Andy I can see my name on the contributors page when I search for the text &quot;Shantanu&quot;. My CA was submitted more than a year ago.&lt;/p&gt;</comment>
                    <comment id="29911" author="jafingerhut" created="Thu, 8 Nov 2012 13:53:45 -0600"  >&lt;p&gt;Right you are.  I somehow accidentally got my browser to enable case matching, and was expecting it to search case insensitively.  Sorry for the noise.&lt;/p&gt;</comment>
                    <comment id="30427" author="vemv" created="Sat, 12 Jan 2013 18:48:06 -0600"  >&lt;p&gt;Just for the record, the patch provided at &lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-1121&quot;&gt;http://dev.clojure.org/jira/browse/CLJ-1121&lt;/a&gt; addresses this issue.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="11556" name="thread-last-arity-1.diff" size="835" author="kumarshantanu" created="Fri, 12 Oct 2012 13:39:09 -0500" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10000" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Patch</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10001">Code</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[CLJ-1033] pr-str and read-string don&apos;t handle @ symbols inside keywords properly</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1033</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;user=&amp;gt; (read-string (pr-str {(keyword &lt;span class=&quot;code-quote&quot;&gt;&quot;key@other&quot;&lt;/span&gt;) :stuff}))
RuntimeException Map literal must contain an even number of forms  clojure.lang.Util.runtimeException (Util.java:170)&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;pr-str emits &quot;{:key@other :stuff}&quot;, which read-string fails to interpret correctly. Either pr-str needs to escape the @ symbol, or read-string needs to handle the symbol inside a keyword.&lt;/p&gt;

&lt;p&gt;Background: I&apos;m passing a map with email addresses as keys through Storm bolts, which require a thrift-serializable form. Using the pr-str/read-string combo fails on these keys, so I&apos;ve fallen back to JSON serialization. &lt;/p&gt;</description>
                <environment>Ubuntu 12.04 LTS; Java 1.7.0_05 Java HotSpot(TM) Client VM</environment>
            <key id="15600">CLJ-1033</key>
            <summary>pr-str and read-string don&apos;t handle @ symbols inside keywords properly</summary>
                <type id="4" iconUrl="http://dev.clojure.org/jira/images/icons/improvement.gif">Enhancement</type>
                                <priority id="4" iconUrl="http://dev.clojure.org/jira/images/icons/priority_minor.gif">Minor</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="stevenruppert">Steven Ruppert</reporter>
                        <labels>
                        <label>reader</label>
                    </labels>
                <created>Thu, 26 Jul 2012 11:25:38 -0500</created>
                <updated>Sun, 13 Jan 2013 22:58:37 -0600</updated>
                                    <version>Release 1.4</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                        <comments>
                    <comment id="29101" author="stu" created="Fri, 10 Aug 2012 12:51:33 -0500"  >&lt;p&gt;The &apos;@&apos; character is not a legal character for keywords or symbols (see &lt;a href=&quot;http://clojure.org/reader&quot;&gt;http://clojure.org/reader&lt;/a&gt;). Recategorized as enhancement request.&lt;/p&gt;</comment>
                    <comment id="29102" author="stevenruppert" created="Fri, 10 Aug 2012 13:04:23 -0500"  >&lt;p&gt;Then why doesn&apos;t (keyword &quot;keywith@&quot;) throw an exception? It seems inconsistent with your statement.&lt;/p&gt;</comment>
                    <comment id="29435" author="jafingerhut" created="Thu, 13 Sep 2012 14:23:29 -0500"  >&lt;p&gt;It is a long standing property of Clojure that it does not throw exceptions for everything that is illegal.&lt;/p&gt;</comment>
                    <comment id="29468" author="stevenruppert" created="Mon, 17 Sep 2012 14:16:01 -0500"  >&lt;p&gt;Yeah, but read-string clearly does. Is there a good reason that the &quot;keyword&quot; function &lt;em&gt;can&apos;t&lt;/em&gt; throw an exception? With the other special rules on namespaces within symbol names, the &quot;keyword&quot; function really should be doing validation.&lt;/p&gt;

&lt;p&gt;Another solution would be to allow a ruby-like :&quot;symbol with disallowed characters&quot; literal, but that would also be confusing with how the namespace is handled.&lt;/p&gt;

&lt;p&gt;&lt;a href=&quot;https://groups.google.com/forum/?fromgroups=#!topic/clojure/Ct5v9w0yNAE&quot;&gt;https://groups.google.com/forum/?fromgroups=#!topic/clojure/Ct5v9w0yNAE&lt;/a&gt; has some older discussion on this topic. &lt;/p&gt;</comment>
                    <comment id="29471" author="jafingerhut" created="Mon, 17 Sep 2012 19:43:54 -0500"  >&lt;p&gt;Disclaimer: I&apos;m not a Clojure/core member, just an interested contributor who doesn&apos;t know all the design decisions that were made here.&lt;/p&gt;

&lt;p&gt;Steven, I think perhaps a couple of concerns are: (1) doing such checks would be slower than not doing them, and (2) implementing such checks means having to update them if/when the rules for legal symbols, keywords, namespace names, etc. change.&lt;/p&gt;

&lt;p&gt;Would you be interested in writing strict versions of functions like symbol and keyword for addition to a contrib library?  And test suites that try to hit a significant number of corner cases in the rules for what is legal and what is not?  I mean those as serious questions, not rhetorical ones.  This would permit people that want to use the strict versions of these functions to do so, and at the same time make it easy to measure performance differences between the strict and loose versions.&lt;/p&gt;</comment>
                    <comment id="30435" author="stevenruppert" created="Sun, 13 Jan 2013 22:58:37 -0600"  >&lt;p&gt;Looking back at this, the root cause of the problem is that the {pr} function, although it by default &quot;print&lt;span class=&quot;error&quot;&gt;&amp;#91;s&amp;#93;&lt;/span&gt; in a way that objects can be read by the reader&quot; &lt;span class=&quot;error&quot;&gt;&amp;#91;0&amp;#93;&lt;/span&gt;, doesn&apos;t always do so. Thus, the easiest &quot;fix&quot; is to change its docstring to warn that not all keywords can be read back.&lt;/p&gt;

&lt;p&gt;The deeper problem is that symbol don&apos;t have a reader form that can represent all actually possible keywords (in this case, those with &quot;@&quot; in them). Restricting the actually-possible keywords to match the reader form, i.e. writing a strict &quot;keyword&quot; &lt;b&gt;function&lt;/b&gt; actually seems like a worse solution overall to me. The better solution would be to somehow extend the keyword reader form to allow it to express all possible keywords, possibly ruby&apos;s :&quot;keyword&quot; syntax. Plus, that solution would avoid having to keep hypothetical strict keyword/symbol functions in sync with reader operation, and write test cases for that, and so on.&lt;/p&gt;

&lt;p&gt;Thus, the resolution of this bug comes down to how far we&apos;re willing to go. Changing the docstring would be the easiest, but extending the keyword form would be the &quot;best&quot; resolution, IMO.&lt;/p&gt;

&lt;p&gt;&lt;span class=&quot;error&quot;&gt;&amp;#91;0&amp;#93;&lt;/span&gt;: &lt;a href=&quot;http://clojuredocs.org/clojure_core/clojure.core/pr&quot;&gt;http://clojuredocs.org/clojure_core/clojure.core/pr&lt;/a&gt;&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_10002" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Approval</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10003">Vetted</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                    <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                                                                                            </customfields>
    </item>

<item>
            <title>[CLJ-1149] Unhelpful error message from :use (and use function) when arguments are malformed</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1149</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;the following exception happens when you have something like this(bad):&lt;/p&gt;

&lt;p&gt;(ns runtime.util-test&lt;br/&gt;
  (:use &lt;span class=&quot;error&quot;&gt;&amp;#91;midje.sweet :reload-all&amp;#93;&lt;/span&gt;))&lt;/p&gt;

&lt;p&gt;as opposed to any of these(correct):&lt;/p&gt;

&lt;p&gt;(ns runtime.util-test&lt;br/&gt;
  (:use midje.sweet :reload-all))&lt;/p&gt;

&lt;p&gt;(ns runtime.util-test&lt;br/&gt;
(:use &lt;span class=&quot;error&quot;&gt;&amp;#91;midje.sweet&amp;#93;&lt;/span&gt; :reload-all))&lt;/p&gt;

&lt;p&gt;and the exception is:&lt;br/&gt;
Exception in thread &quot;main&quot; java.lang.IllegalArgumentException: No value supplied for key: true&lt;br/&gt;
        at clojure.lang.PersistentHashMap.create(PersistentHashMap.java:77)&lt;br/&gt;
        at clojure.core$hash_map.doInvoke(core.clj:365)&lt;br/&gt;
        at clojure.lang.RestFn.applyTo(RestFn.java:137)&lt;br/&gt;
        at clojure.core$apply.invoke(core.clj:617)&lt;br/&gt;
        at clojure.core$load_lib.doInvoke(core.clj:5352)&lt;br/&gt;
        at clojure.lang.RestFn.applyTo(RestFn.java:142)&lt;br/&gt;
        at clojure.core$apply.invoke(core.clj:619)&lt;br/&gt;
        at clojure.core$load_libs.doInvoke(core.clj:5403)&lt;br/&gt;
        at clojure.lang.RestFn.applyTo(RestFn.java:137)&lt;br/&gt;
        at clojure.core$apply.invoke(core.clj:621)&lt;br/&gt;
        at clojure.core$use.doInvoke(core.clj:5497)&lt;/p&gt;

&lt;p&gt;Note that this is similar to the equally unhelpful message shown in &lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-1140&quot;&gt;http://dev.clojure.org/jira/browse/CLJ-1140&lt;/a&gt; although that is a different root cause.&lt;/p&gt;

&lt;p&gt;Probably best to enhance the `use` function to validate its arguments before trying to apply hash-map?&lt;/p&gt;</description>
                <environment></environment>
            <key id="15967">CLJ-1149</key>
            <summary>Unhelpful error message from :use (and use function) when arguments are malformed</summary>
                <type id="4" iconUrl="http://dev.clojure.org/jira/images/icons/improvement.gif">Enhancement</type>
                                <priority id="4" iconUrl="http://dev.clojure.org/jira/images/icons/priority_minor.gif">Minor</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="seancorfield">Sean Corfield</reporter>
                        <labels>
                    </labels>
                <created>Thu, 17 Jan 2013 18:37:27 -0600</created>
                <updated>Thu, 17 Jan 2013 18:37:27 -0600</updated>
                                    <version>Release 1.4</version>
                <version>Release 1.5</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                                                                                            </customfields>
    </item>

<item>
            <title>[CLJ-764] (partition 0 seq) and (parition-all 0 seq) are infinite sequences of empty sequences</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-764</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;(partition n seq) and (partition-all n seq) are implemented by taking n and dropping n from seq.  When n=0 this becomes an infinite sequence of empty sequences.&lt;/p&gt;

&lt;p&gt;While conceptionally this makes sense, I think practically it may surprise people, and perhaps it should return an empty sequence or a sequence of a single empty sequence.&lt;/p&gt;</description>
                <environment></environment>
            <key id="14380">CLJ-764</key>
            <summary>(partition 0 seq) and (parition-all 0 seq) are infinite sequences of empty sequences</summary>
                <type id="1" iconUrl="http://dev.clojure.org/jira/images/icons/bug.gif">Defect</type>
                                <priority id="4" iconUrl="http://dev.clojure.org/jira/images/icons/priority_minor.gif">Minor</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="pjstadig">Paul Stadig</reporter>
                        <labels>
                    </labels>
                <created>Mon, 21 Mar 2011 09:20:57 -0500</created>
                <updated>Mon, 21 Jan 2013 05:40:07 -0600</updated>
                                    <version>Release 1.1</version>
                <version>Release 1.2</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>2</watches>
                        <comments>
                    <comment id="26324" author="pjstadig" created="Mon, 21 Mar 2011 09:22:32 -0500"  >&lt;p&gt;Ugh!  I didn&apos;t mean for this to be major priority, and I can&apos;t seem to edit it after the fact.&lt;/p&gt;</comment>
                    <comment id="30466" author="mikera" created="Mon, 21 Jan 2013 05:40:07 -0600"  >&lt;p&gt;I think the current behaviour is logically more correct than returning a empty sequence or a single empty sequence.&lt;/p&gt;

&lt;p&gt;In particular, I would expect (partition n infinite-seq) to return an infinite sequence of sequences of length n, for any value of n &amp;gt;= 0. Anything else would be very surprising.&lt;/p&gt;

&lt;p&gt;The only other sensible option would be throwing an exception, on the philosophical grounds that it isn&apos;t possible to partition a non-empty sequence into sub-sequences of length 0. But I think that changing behaviour in this way would break backwards compatibility for no obvious gain.&lt;/p&gt;

&lt;p&gt;I suggest closing this issue.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                                                                                            </customfields>
    </item>

<item>
            <title>[CLJ-1148] adds docstring support to defonce, and stops it from stomping existing metadata</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1148</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;Two issues here:&lt;/p&gt;

&lt;p&gt;1) defonce doesn&apos;t support docstrings, although def does, so it would be nice to bring the two in line with each other&lt;/p&gt;

&lt;p&gt;2) defonce can stomp metadata, like this:&lt;/p&gt;

&lt;p&gt;(defonce ^:private foo 5)&lt;br/&gt;
#&apos;user/foo&lt;br/&gt;
(meta #&apos;foo) --&amp;gt; the private is there&lt;br/&gt;
(defone foo 10)&lt;br/&gt;
foo is still 5&lt;br/&gt;
(meta #&apos;foo) --&amp;gt; the private has been lost&lt;/p&gt;</description>
                <environment></environment>
            <key id="15966">CLJ-1148</key>
            <summary>adds docstring support to defonce, and stops it from stomping existing metadata</summary>
                <type id="4" iconUrl="http://dev.clojure.org/jira/images/icons/improvement.gif">Enhancement</type>
                                <priority id="4" iconUrl="http://dev.clojure.org/jira/images/icons/priority_minor.gif">Minor</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="joegallo">Joe Gallo</reporter>
                        <labels>
                    </labels>
                <created>Thu, 17 Jan 2013 17:16:40 -0600</created>
                <updated>Thu, 17 Jan 2013 17:16:40 -0600</updated>
                                    <version>Release 1.5</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>1</watches>
                                <attachments>
                    <attachment id="11805" name="0001-new-defonce-hotness.patch" size="1226" author="joegallo" created="Thu, 17 Jan 2013 17:16:40 -0600" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10000" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Patch</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10001">Code</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[CLJ-1082] Subvecs of primitive vectors cannot be reduced</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1082</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;I could reproduce on current 10/05 git.&lt;/p&gt;

&lt;p&gt;Reduce doesn&apos;t work on subvecs of primitive vectors.&lt;br/&gt;
Root cause seems to be that RT/subvec and APersistentVector$SubVector make assumptions about implementation&lt;/p&gt;

&lt;p&gt;If reduce on a subvec doesn&apos;t work then neither will nice ops like fold.&lt;/p&gt;

&lt;p&gt;How to cause: &lt;/p&gt;

&lt;p&gt;(let &lt;span class=&quot;error&quot;&gt;&amp;#91;prim-vec (into (vector-of :long) (range 10000))&amp;#93;&lt;/span&gt;&lt;br/&gt;
  (reduce + (subvec prim-vec 1 500)))&lt;/p&gt;

&lt;p&gt;-&amp;gt;&amp;gt; ClassCastException clojure.core.Vec cannot be cast to clojure.lang.PersistentVector  clojure.lang.APersistentVector$SubVector.iterator (APersistentVector.java:523)&lt;/p&gt;
</description>
                <environment>1.7.0-08, OS X 10.8</environment>
            <key id="15733">CLJ-1082</key>
            <summary>Subvecs of primitive vectors cannot be reduced</summary>
                <type id="1" iconUrl="http://dev.clojure.org/jira/images/icons/bug.gif">Defect</type>
                                <priority id="4" iconUrl="http://dev.clojure.org/jira/images/icons/priority_minor.gif">Minor</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="gshayban">Ghadi Shayban</reporter>
                        <labels>
                    </labels>
                <created>Fri, 5 Oct 2012 18:49:21 -0500</created>
                <updated>Sat, 26 Jan 2013 07:29:55 -0600</updated>
                                                                            <due></due>
                    <votes>0</votes>
                        <watches>2</watches>
                        <comments>
                    <comment id="30056" author="halgari" created="Tue, 27 Nov 2012 11:52:48 -0600"  >&lt;p&gt;Confirmed to be broken on master. Vetting. Not sure what it&apos;s going to take to fix this, however. If this is of intrest for you, you might want to help push it along by providing a patch. &lt;/p&gt;</comment>
                    <comment id="30058" author="jafingerhut" created="Tue, 27 Nov 2012 12:09:26 -0600"  >&lt;p&gt;There is no code or ticket for this yet, but I wanted to mention that I&apos;ve begun working on an implementation of RRB-Tree (Relaxed Radix Balanced Tree) vectors for Clojure (see discussion at &lt;a href=&quot;https://groups.google.com/forum/?fromgroups=#!topic/clojure-dev/xnbtzTVEK9A&quot;&gt;https://groups.google.com/forum/?fromgroups=#!topic/clojure-dev/xnbtzTVEK9A&lt;/a&gt;).  Assuming it is no big deal to get reducers to work on such vectors, subvec could be implemented in O(log n) time in such a way that the result was the same concrete type of vector as you started with, and thus reducers would work on them, too.&lt;/p&gt;

&lt;p&gt;It would mean O(log n) time for subvec instead of today&apos;s O(1), but this would likely fix other limitations that exist today with subvec&apos;s, e.g. &lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-761&quot; title=&quot;print-dup generates call to nonexistent method for APersistentVector$SubVector&quot;&gt;CLJ-761&lt;/a&gt;.&lt;/p&gt;</comment>
                    <comment id="30461" author="mikera" created="Sun, 20 Jan 2013 05:14:04 -0600"  >&lt;p&gt;I have a fix for this and a regression test in the tree below:&lt;/p&gt;

&lt;p&gt;&lt;a href=&quot;https://github.com/mikera/clojure/tree/winfix&quot;&gt;https://github.com/mikera/clojure/tree/winfix&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;Not sure how best to make this into a patch though - I also have the pprint fix in here (&lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-1076&quot; title=&quot;pprint tests fail on Windows, expecting \n&quot;&gt;CLJ-1076&lt;/a&gt;)&lt;/p&gt;</comment>
                    <comment id="30462" author="mikera" created="Sun, 20 Jan 2013 18:41:50 -0600"  >&lt;p&gt;Attached a patch that I created with: &lt;/p&gt;

&lt;p&gt;git format-patch winfix --stdout HEAD~3..HEAD &amp;gt; clj-1082.patch&lt;/p&gt;

&lt;p&gt;Does this do the trick? I had to use the HEAD~3..HEAD to just get the most recent 3 commits and exclude the pprint changes that I needed in order to build on Windows.&lt;/p&gt;</comment>
                    <comment id="30463" author="mikera" created="Sun, 20 Jan 2013 18:42:24 -0600"  >&lt;p&gt;Patch for &lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-1082&quot; title=&quot;Subvecs of primitive vectors cannot be reduced&quot;&gt;CLJ-1082&lt;/a&gt;, containing 3 commits&lt;/p&gt;</comment>
                    <comment id="30465" author="jafingerhut" created="Mon, 21 Jan 2013 01:11:04 -0600"  >&lt;p&gt;Mike, your patch clj-1082.patch applies cleanly to latest master for me, so looks like you found one way to do it.&lt;/p&gt;

&lt;p&gt;Another would be as follows, and closer to the directions on the JIRA workflow page: &lt;a href=&quot;http://dev.clojure.org/display/design/JIRA+workflow&quot;&gt;http://dev.clojure.org/display/design/JIRA+workflow&lt;/a&gt; (but not identical).  Note that these commands would work on Mac OS X or Linux.  I&apos;m not sure what the correct corresponding command would be on Windows for the &quot;git am&quot; step below, unless that just happens to work because Windows and/or git implement the input redirection with &quot;&amp;lt;&quot; somehow.&lt;/p&gt;

&lt;ol&gt;
	&lt;li&gt;Check out a fresh repo&lt;br/&gt;
$ git clone git://github.com/clojure/clojure.git&lt;br/&gt;
$ cd clojure&lt;/li&gt;
&lt;/ol&gt;


&lt;ol&gt;
	&lt;li&gt;Apply the patch for &lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-1076&quot; title=&quot;pprint tests fail on Windows, expecting \n&quot;&gt;CLJ-1076&lt;/a&gt; to the master branch.  This step isn&apos;t on the JIRA workflow page.&lt;br/&gt;
$ git am --keep-cr -s &amp;lt; clj-1076-fix-tests-on-windows-patch-v1.txt&lt;/li&gt;
&lt;/ol&gt;


&lt;ol&gt;
	&lt;li&gt;Create a branch for yourself&lt;br/&gt;
$ git checkout -b fix-clj-1082&lt;/li&gt;
&lt;/ol&gt;


&lt;ol&gt;
	&lt;li&gt;After editing to make your changes, commit them to the current fix-clj-1082 branch&lt;br/&gt;
$ git commit -a -m &quot;fixed annoying bug, refs #42&quot;&lt;/li&gt;
&lt;/ol&gt;


&lt;p&gt;From there on down it is the same as the instructions on the JIRA workflow page.  The &quot;git format-patch master --stdout &amp;gt; file.patch&quot; will create a patch for the changes you have made in the current branch fix-clj-1082 starting from the master branch, which has the &lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-1076&quot; title=&quot;pprint tests fail on Windows, expecting \n&quot;&gt;CLJ-1076&lt;/a&gt; fix because of the &apos;git am&apos; command above.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="11807" name="clj-1082.patch" size="3892" author="mikera" created="Sun, 20 Jan 2013 18:42:24 -0600" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_10002" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Approval</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10003">Vetted</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                    <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10000" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Patch</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10002">Code and Test</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[CLJ-1080] Eliminate many uses of reflection in Clojure code</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1080</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;There are dozens of uses of reflection in Clojure code that can be eliminated by adding suitable type hints.  This patch adds the necessary type hints for most of those.&lt;/p&gt;</description>
                <environment></environment>
            <key id="15729">CLJ-1080</key>
            <summary>Eliminate many uses of reflection in Clojure code</summary>
                <type id="4" iconUrl="http://dev.clojure.org/jira/images/icons/improvement.gif">Enhancement</type>
                                <priority id="4" iconUrl="http://dev.clojure.org/jira/images/icons/priority_minor.gif">Minor</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="jafingerhut">Andy Fingerhut</reporter>
                        <labels>
                    </labels>
                <created>Sun, 30 Sep 2012 11:36:18 -0500</created>
                <updated>Thu, 7 Feb 2013 08:54:50 -0600</updated>
                                    <version>Release 1.4</version>
                <version>Release 1.5</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>1</watches>
                        <comments>
                    <comment id="29581" author="jafingerhut" created="Sun, 30 Sep 2012 11:39:03 -0500"  >&lt;p&gt;Patch clj-1080-eliminate-many-reflection-warnings-patch-v1.txt dated Sep 30 2012 adds type hints to eliminate many uses of reflection in Clojure core code.&lt;/p&gt;</comment>
                    <comment id="29945" author="jafingerhut" created="Wed, 14 Nov 2012 13:26:02 -0600"  >&lt;p&gt;clj-1080-eliminate-many-reflection-warnings-patch-v2.txt dated Nov 14 2012 is identical to the previous patch (to be removed soon), except it applies cleanly to latest master.&lt;/p&gt;</comment>
                    <comment id="30563" author="jafingerhut" created="Thu, 7 Feb 2013 08:54:33 -0600"  >&lt;p&gt;clj-1080-eliminate-many-reflection-warnings-patch-v3.txt dated Feb 7 2013 is identical to the previous patch (to be removed soon), except it applies cleanly to latest master.  One type hint in the patch was added due to a different change, and was no longer needed in the patch.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="11841" name="clj-1080-eliminate-many-reflection-warnings-patch-v3.txt" size="19090" author="jafingerhut" created="Thu, 7 Feb 2013 08:54:33 -0600" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10000" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Patch</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10001">Code</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[CLJ-1159] clojure.java.io/delete-file doesn&apos;t return the status of the deletion(true/false)</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1159</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;initially reported it here(somehow):&lt;br/&gt;
&lt;a href=&quot;https://groups.google.com/d/msg/clojure/T9Kvr0IL0kg/wcKBfR9w_1sJ&quot;&gt;https://groups.google.com/d/msg/clojure/T9Kvr0IL0kg/wcKBfR9w_1sJ&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;Basically clojure.java.io/delete-file doesn&apos;t ever return false (even when silently is true, it returns the value of silently), it&apos;s due to how it&apos;s implemented - but it&apos;s obvious from the code, so I&apos;ll stop here.&lt;/p&gt;

&lt;p&gt;Thanks.&lt;/p&gt;

&lt;p&gt;PS: this is what I&apos;m using as my current workaround:&lt;br/&gt;
(defn delete-file&lt;br/&gt;
&quot;&lt;br/&gt;
an implementation that returns the true/false status&lt;br/&gt;
which clojure.java.io/delete-file doesn&apos;t do(tested in 1.5.0-RC14)&lt;br/&gt;
&quot;&lt;br/&gt;
  [f &amp;amp; &lt;span class=&quot;error&quot;&gt;&amp;#91;silently&amp;#93;&lt;/span&gt;]&lt;br/&gt;
  (let &lt;span class=&quot;error&quot;&gt;&amp;#91;ret (.delete (clojure.java.io/file f))&amp;#93;&lt;/span&gt;&lt;br/&gt;
    (cond (or ret silently)&lt;br/&gt;
      ret&lt;br/&gt;
      :else&lt;br/&gt;
      (throw (java.io.IOException. (str &quot;Couldn&apos;t delete &quot; f)))&lt;br/&gt;
      )&lt;br/&gt;
    )&lt;br/&gt;
  )&lt;/p&gt;

&lt;p&gt;I&apos;m sure you guys can find a better way, but as a clojure newbie(really!) that&apos;s what I have.&lt;/p&gt;</description>
                <environment>any</environment>
            <key id="15999">CLJ-1159</key>
            <summary>clojure.java.io/delete-file doesn&apos;t return the status of the deletion(true/false)</summary>
                <type id="1" iconUrl="http://dev.clojure.org/jira/images/icons/bug.gif">Defect</type>
                                <priority id="4" iconUrl="http://dev.clojure.org/jira/images/icons/priority_minor.gif">Minor</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="atkaaz">AtKaaZ</reporter>
                        <labels>
                        <label>delete-file</label>
                        <label>evil</label>
                        <label>or</label>
                    </labels>
                <created>Sun, 10 Feb 2013 13:55:52 -0600</created>
                <updated>Sun, 10 Feb 2013 14:21:28 -0600</updated>
                                    <version>Release 1.5</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>1</watches>
                        <comments>
                    <comment id="30575" author="atkaaz" created="Sun, 10 Feb 2013 14:01:08 -0600"  >&lt;p&gt;I kinda just realized it affects all versions since and including 1.2, because it appears that its implementation was the same since then.&lt;/p&gt;

&lt;p&gt;If it&apos;s not meant to return the result of the delete, maybe it should specifically return nil and/or the doc say something?&lt;/p&gt;</comment>
                    <comment id="30576" author="seancorfield" created="Sun, 10 Feb 2013 14:21:28 -0600"  >&lt;p&gt;As noted in a thread on the Clojure ML, you can pass a known value in the second argument position to detect a delete that failed:&lt;/p&gt;

&lt;p&gt;&lt;tt&gt;(clojure.java.io/delete-file some-file :not-deleted)&lt;/tt&gt;&lt;/p&gt;

&lt;p&gt;This returns true on success and :not-deleted on failure.&lt;/p&gt;

&lt;p&gt;However the docstring could be better worded to make that intention clear. Perhaps:&lt;/p&gt;

&lt;p&gt;&lt;tt&gt;Delete file f. Return true if it succeeds. If silently is nil or false, raise an exception if it fails, else return the value of silently.&lt;/tt&gt;&lt;br/&gt;
&lt;tt&gt;This allows you to detect whether the delete succeeded without catching an exception by passing a non-true truthy value as the second argument.&lt;/tt&gt;&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                                                                                            </customfields>
    </item>

<item>
            <title>[CLJ-706] make use of deprecated namespaces/vars easier to spot</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-706</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;From the mailing list &lt;a href=&quot;http://groups.google.com/group/clojure/msg/c41d909bd58e4534&quot;&gt;http://groups.google.com/group/clojure/msg/c41d909bd58e4534&lt;/a&gt;. It is easy to use deprecated namespaces without knowing you are doing so. The documentation warnings are small, and there is no compiler warning.&lt;/p&gt;

&lt;p&gt;Some possibilities include:&lt;/p&gt;

&lt;ol&gt;
	&lt;li&gt;much more visible deprecation styling in the documentation&lt;/li&gt;
	&lt;li&gt;stderr warnings when referencing a deprecated thing.&lt;/li&gt;
&lt;/ol&gt;


&lt;p&gt;I don&apos;t love the idea of stderr warnings on all the time. Rich: is there an approach to this that you would like to see a patch for?&lt;/p&gt;</description>
                <environment></environment>
            <key id="14315">CLJ-706</key>
            <summary>make use of deprecated namespaces/vars easier to spot</summary>
                <type id="4" iconUrl="http://dev.clojure.org/jira/images/icons/improvement.gif">Enhancement</type>
                                <priority id="4" iconUrl="http://dev.clojure.org/jira/images/icons/priority_minor.gif">Minor</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="stu">Stuart Halloway</reporter>
                        <labels>
                    </labels>
                <created>Wed, 5 Jan 2011 20:39:01 -0600</created>
                <updated>Wed, 13 Feb 2013 00:38:18 -0600</updated>
                                                                            <due></due>
                    <votes>2</votes>
                        <watches>2</watches>
                        <comments>
                    <comment id="26099" author="richhickey" created="Fri, 7 Jan 2011 09:38:32 -0600"  >&lt;p&gt;I don&apos;t mind warning to stderr&lt;/p&gt;</comment>
                    <comment id="29815" author="lvanderhart" created="Fri, 26 Oct 2012 13:37:06 -0500"  >&lt;p&gt;706-deprecated-var-warning.diff adds warnings when using deprecated vars. The other three patches clean up deprecation warnings.&lt;/p&gt;</comment>
                    <comment id="29816" author="jafingerhut" created="Fri, 26 Oct 2012 14:23:20 -0500"  >&lt;p&gt;Great stuff.  I looked through the first patch, and didn&apos;t see anything in there that lets someone disable deprecation warnings from the command line, the way that &lt;b&gt;warn-on-reflection&lt;/b&gt; can today be set to true with a command line option.&lt;/p&gt;

&lt;p&gt;Is that something important to have for deprecation warnings?&lt;/p&gt;</comment>
                    <comment id="29835" author="jafingerhut" created="Sun, 28 Oct 2012 16:57:00 -0500"  >&lt;p&gt;I was hoping it would be quick and easy to add source file, line, and column info to the deprecation warning messages.  It isn&apos;t as easy as adding them to the format() call, because the method analyzeSymbol doesn&apos;t receive these values as args.  Is this deprecation check being done in a place where it is not easy to relate it to the source file, line, and column?  Could it be done in a place where that info is easily available?&lt;/p&gt;</comment>
                    <comment id="29864" author="gshayban" created="Mon, 29 Oct 2012 01:02:25 -0500"  >&lt;p&gt;Another patch - this time to warn on loading deprecated namespaces, instead of vars. This patch requires the first one.&lt;/p&gt;

&lt;p&gt;Re: line/column, I&apos;ll figure out how to thread the compile context through if it&apos;s desired.&lt;/p&gt;

&lt;p&gt;Re: Compile flag.  I have a patch for this also, but I&apos;m still verifying how to invoke.  How is warn-on-reflection set by command line?&lt;/p&gt;</comment>
                    <comment id="29865" author="jafingerhut" created="Mon, 29 Oct 2012 01:43:58 -0500"  >&lt;p&gt;Re: Compile flag.  Don&apos;t hold off on implementing a flag if you want to, but it might be worth hearing from others whether such a command line option is even desired.  I was asking in hopes of eliciting such a response.&lt;/p&gt;

&lt;p&gt;For the way that it is handled in the Clojure compiler, search for REFLECTION_WARNING_PROP and related code in Compile.java.  If you invoke the Clojure compiler directly via a Java command line, use -Dclojure.compile.warn-on-reflection=true (default is false).  See the recent email thread sent to Clojure Dev Google group if you want to know how to do it via ant or Maven.  Link: &lt;a href=&quot;https://mail.google.com/mail/?shva=1#label/clojure-dev/13aa0e34530196c3&quot;&gt;https://mail.google.com/mail/?shva=1#label/clojure-dev/13aa0e34530196c3&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;There is also a separate command-line flag called &lt;b&gt;compiler-options&lt;/b&gt; (see Compile.java) that is implemented as a map inside the compiler.  It was added more recently than &lt;b&gt;warn-on-reflection&lt;/b&gt;, and might be the preferred method to add more such options, to avoid having to continue to add more arguments to the pushThreadBindings calls done in several places.&lt;/p&gt;</comment>
                    <comment id="29867" author="gshayban" created="Mon, 29 Oct 2012 10:36:00 -0500"  >&lt;p&gt;Thanks, Andy.&lt;/p&gt;

&lt;p&gt;Alternately for the last ns patch, it is equivalent to call (print-method msg &lt;b&gt;err&lt;/b&gt;), rather than binding &lt;b&gt;out&lt;/b&gt; to &lt;b&gt;err&lt;/b&gt;, may be more readable.  I&apos;ll be glad to send that in if it&apos;s preferable.&lt;/p&gt;</comment>
                    <comment id="30581" author="jafingerhut" created="Wed, 13 Feb 2013 00:38:18 -0600"  >&lt;p&gt;706-deprecated-var-warning-patch-v2.txt dated Feb 12 2013 is identical to 706-deprecated-var-warning.diff dated Oct 26 2012, except it applies cleanly to latest master.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="11617" name="706-deprecated-var-warning.diff" size="6119" author="lvanderhart" created="Fri, 26 Oct 2012 13:37:06 -0500" />
                    <attachment id="11851" name="706-deprecated-var-warning-patch-v2.txt" size="6099" author="jafingerhut" created="Wed, 13 Feb 2013 00:38:18 -0600" />
                    <attachment id="11619" name="706-fix-deprecation-warnings-agents.diff" size="1106" author="lvanderhart" created="Fri, 26 Oct 2012 13:37:06 -0500" />
                    <attachment id="11620" name="706-fix-deprecation-warnings-on-replicate.diff" size="3031" author="lvanderhart" created="Fri, 26 Oct 2012 13:37:06 -0500" />
                    <attachment id="11618" name="706-fix-deprecation-warning-test-junit.diff" size="2669" author="lvanderhart" created="Fri, 26 Oct 2012 13:37:06 -0500" />
                    <attachment id="11638" name="706-warning-on-deprecated-ns.diff" size="942" author="gshayban" created="Mon, 29 Oct 2012 01:02:25 -0500" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10000" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Patch</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10001">Code</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[CLJ-1138] data-reader returning nil causes exception</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1138</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;If a data-reader returns nil, the reader throws java.lang.RuntimeException: No dispatch macro...  The error message implies that there is no dispatch macro for whatever the first character of the tag happens to be.&lt;/p&gt;

&lt;p&gt;Here&apos;s a simple example:&lt;/p&gt;

&lt;p&gt;    (binding &lt;span class=&quot;error&quot;&gt;&amp;#91;*data-readers* {&apos;f/ignore (constantly nil)}&amp;#93;&lt;/span&gt; (read-string &quot;#f/ignore 42 10&quot;))&lt;/p&gt;

&lt;p&gt;RuntimeException No dispatch macro for: f  clojure.lang.Util.runtimeException (Util.java:219)&lt;/p&gt;</description>
                <environment>clojure 1.5 beta2, Mac OS X 10.8.2, java version &amp;quot;1.6.0_37&amp;quot;</environment>
            <key id="15916">CLJ-1138</key>
            <summary>data-reader returning nil causes exception</summary>
                <type id="1" iconUrl="http://dev.clojure.org/jira/images/icons/bug.gif">Defect</type>
                                <priority id="4" iconUrl="http://dev.clojure.org/jira/images/icons/priority_minor.gif">Minor</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="steveminer@gmail.com">Steve Miner</reporter>
                        <labels>
                        <label>reader</label>
                    </labels>
                <created>Sat, 22 Dec 2012 08:41:18 -0600</created>
                <updated>Thu, 14 Feb 2013 15:06:47 -0600</updated>
                                    <version>Release 1.4</version>
                <version>Release 1.5</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>1</watches>
                        <comments>
                    <comment id="30289" author="steveminer@gmail.com" created="Sat, 22 Dec 2012 09:43:27 -0600"  >&lt;p&gt;clj-1138-allow-data-reader-to-return-nil-instead-of-throwing.patch allows a data-reader to return nil instead of throwing.  Does sanity check that possible tag or record isJavaIdentifierStart().  Gives better error message for special characters that might actually be dispatch macros (rather than assuming it&apos;s a tagged literal).&lt;/p&gt;</comment>
                    <comment id="30291" author="steveminer@gmail.com" created="Sat, 22 Dec 2012 10:06:06 -0600"  >&lt;p&gt;clj-1138-data-reader-return-nil-for-no-op.patch allows a data-reader returning nil to be treated as a no-op by the reader (like #_).  nil is not normally a useful value (actually it causes an exception in Clojure 1.4 through 1.5 beta2) for a data-reader to return.  With this patch, one could get something like a conditional feature reader using data-readers.&lt;/p&gt;</comment>
                    <comment id="30292" author="steveminer@gmail.com" created="Sat, 22 Dec 2012 10:26:43 -0600"  >&lt;p&gt;clj-1138-allow-data-reader-to-return-nil-instead-of-throwing.patch is the first patch to consider.  It merely allows nil as a value from a data-reader and returns nil as the final value.  I think it does what was originally intended for dispatch macros, and gives a better error message in many cases (mostly typos).&lt;/p&gt;

&lt;p&gt;The second patch, clj-1138-data-reader-return-nil-for-no-op.patch, depends on the other being applied first.  It takes an extra step to treat a nil value returned from a data-reader as a no-op for the reader (like #_).&lt;/p&gt;</comment>
                    <comment id="30310" author="steveminer@gmail.com" created="Sun, 23 Dec 2012 11:52:28 -0600"  >&lt;p&gt;It turns out that you can work around the original problem by having your data-reader return &apos;(quote nil) instead of plain nil.  That expression conveniently evaluates to nil so you can get a nil if necessary.  This also works after applying the patches so there&apos;s still a way to return nil if you really want it.&lt;/p&gt;

&lt;p&gt;    (binding &lt;span class=&quot;error&quot;&gt;&amp;#91;*data-readers* {&apos;x/nil (constantly &apos;(quote nil))}&amp;#93;&lt;/span&gt; (read-string &quot;#x/nil 42&quot;))&lt;br/&gt;
    ;=&amp;gt; (quote nil)&lt;/p&gt;</comment>
                    <comment id="30565" author="jafingerhut" created="Thu, 7 Feb 2013 09:20:27 -0600"  >&lt;p&gt;Patch clj-1138-allow-data-reader-to-return-nil-instead-of-throwing.patch dated Dec 22 2012 still applies cleanly to latest master if you use the following command:&lt;/p&gt;

&lt;p&gt;% git am --keep-cr -s --ignore-whitespace &amp;lt; clj-1138-allow-data-reader-to-return-nil-instead-of-throwing.patch&lt;/p&gt;

&lt;p&gt;Without the --ignore-whitespace option, the patch fails only because some whitespace was changed in Clojure master recently.&lt;/p&gt;</comment>
                    <comment id="30584" author="jafingerhut" created="Wed, 13 Feb 2013 11:24:11 -0600"  >&lt;p&gt;OK, now with latest master (1.5.0-RC15 at this time), patch clj-1138-allow-data-reader-to-return-nil-instead-of-throwing.patch no longer applies cleanly, not even using --ignore-whitespace in the &apos;git am&apos; command given above.  Steve, if you could see what needs to be updated, that would be great.  Using the patch command as suggested in the &quot;Updating stale patches&quot; section of &lt;a href=&quot;http://dev.clojure.org/display/design/JIRA+workflow&quot;&gt;http://dev.clojure.org/display/design/JIRA+workflow&lt;/a&gt; wasn&apos;t enough, so it should probably be carefully examined by hand to see what needs updating.&lt;/p&gt;</comment>
                    <comment id="30599" author="steveminer@gmail.com" created="Thu, 14 Feb 2013 12:21:27 -0600"  >&lt;p&gt;I removed my patches.  Things have changes recently with the LispReader and new EdnReader.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                                                                                            </customfields>
    </item>

<item>
            <title>[CLJ-970] extend/implement parameterized types (generics)</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-970</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;When extending parameterized types, class files can track the original signatures of the superclass and super interfaces so that the original types can be obtained at run time.  This runtime reflection is used in some Java frameworks, and implementing it in Clojure can enable interop.  See &lt;a href=&quot;http://groups.google.com/group/clojure/browse_thread/thread/5efd692804df3f47/1336e591c2eedfa1&quot;&gt;http://groups.google.com/group/clojure/browse_thread/thread/5efd692804df3f47/1336e591c2eedfa1&lt;/a&gt; for examples of this request.&lt;/p&gt;

&lt;p&gt;This proposal checks the :parameters keyword in type meta information.  If a parameter is found, it is added to the class signature.&lt;/p&gt;</description>
                <environment></environment>
            <key id="15324">CLJ-970</key>
            <summary>extend/implement parameterized types (generics)</summary>
                <type id="4" iconUrl="http://dev.clojure.org/jira/images/icons/improvement.gif">Enhancement</type>
                                <priority id="4" iconUrl="http://dev.clojure.org/jira/images/icons/priority_minor.gif">Minor</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="jim.blomo">Jim Blomo</assignee>
                                <reporter username="jim.blomo">Jim Blomo</reporter>
                        <labels>
                    </labels>
                <created>Tue, 10 Apr 2012 01:33:49 -0500</created>
                <updated>Fri, 1 Mar 2013 09:46:59 -0600</updated>
                                    <version>Release 1.5</version>
                                                        <due></due>
                    <votes>1</votes>
                        <watches>4</watches>
                        <comments>
                    <comment id="28143" author="jim.blomo" created="Sat, 14 Apr 2012 11:30:17 -0500"  >&lt;p&gt;2012-04-14 extend-implement-parameterized-types.diff is the correctly formatted `git format-patch master` for this change.  It supersedes clojure-parameterized-generics.diff from 2012-04-10.&lt;/p&gt;</comment>
                    <comment id="29230" author="jafingerhut" created="Sun, 19 Aug 2012 05:00:31 -0500"  >&lt;p&gt;Patch clj-970-extend-implement-parameterized-types-patch2.txt dated Aug 19 2012 is identical to Jim Blomo&apos;s patch extend-implement-parameterized-types.diff dated Apr 14 2012, except it has updated context lines so that it applies cleanly to latest master as of today.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="11450" name="clj-970-extend-implement-parameterized-types-patch2.txt" size="5525" author="jafingerhut" created="Sun, 19 Aug 2012 05:00:31 -0500" />
                    <attachment id="11049" name="extend-implement-parameterized-types.diff" size="5594" author="jim.blomo" created="Sat, 14 Apr 2012 11:30:17 -0500" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10000" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Patch</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10002">Code and Test</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[CLJ-1073] Make print-sequential interruptible</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1073</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;This allows print-sequential to be interrupted by Thread.interrupt(), rather than requiring clients to resort to Thread.stop(). This is especially helpful when printing very large sequences.&lt;/p&gt;

&lt;p&gt;See also clojure-dev discussion at &lt;a href=&quot;https://groups.google.com/d/topic/clojure-dev/vs0RNUQXiYE/discussion&quot;&gt;https://groups.google.com/d/topic/clojure-dev/vs0RNUQXiYE/discussion&lt;/a&gt;&lt;/p&gt;</description>
                <environment></environment>
            <key id="15713">CLJ-1073</key>
            <summary>Make print-sequential interruptible</summary>
                <type id="4" iconUrl="http://dev.clojure.org/jira/images/icons/improvement.gif">Enhancement</type>
                                <priority id="4" iconUrl="http://dev.clojure.org/jira/images/icons/priority_minor.gif">Minor</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="trptcolin">Colin Jones</reporter>
                        <labels>
                        <label>patch</label>
                    </labels>
                <created>Fri, 21 Sep 2012 16:10:46 -0500</created>
                <updated>Fri, 1 Mar 2013 10:18:01 -0600</updated>
                                    <version>Release 1.4</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>2</watches>
                        <comments>
                    <comment id="29522" author="jafingerhut" created="Fri, 21 Sep 2012 19:04:21 -0500"  >&lt;p&gt;In a quickly hacked up performance test on Mac OS X 10.6.8 + Oracle/Apple JDK 1.6.0_35 which I can attach, I saw about a 9% to 10% slowdown for Colin&apos;s patch in printing large vectors.&lt;/p&gt;

&lt;p&gt;I have a modified patch that only calls Thread/interrupted after every 20 items are printed, and with that version the slowdown versus the original code was about 3% to 4%.&lt;/p&gt;

&lt;p&gt;Colin, would there be any down side to checking Thread/interrupted less often for your purposes?&lt;/p&gt;

&lt;p&gt;To run performance test, edit attachment compile.sh to point at your clojure.jar, put file perftest-print.clj in the same directory, and run ./compile.sh    It should work on Mac or Linux.&lt;/p&gt;</comment>
                    <comment id="29523" author="jafingerhut" created="Sat, 22 Sep 2012 10:47:08 -0500"  >&lt;p&gt;clj-1073-allow-thread-interrupt-in-print-sequential-patch.txt dated Sep 22 2012 is similar to Colin&apos;s patch 0001-Allow-thread-interruption-in-print-sequential.patch dated Sep 21 2012, except it only checks interrupted status every 20 (or maybe 21?) times through the loop in print-sequential.  It is the one that is 3-4% slower than the current latest master Clojure code in my performance test mentioned above, versus Colin&apos;s patch which is about 9-10% slower on that test.&lt;/p&gt;</comment>
                    <comment id="29700" author="stu" created="Fri, 19 Oct 2012 15:31:32 -0500"  >&lt;p&gt;Is this primarily intended for dev-time use? I wouldn&apos;t want to lose performance for this if there is any way to implement it as a dev-time feature.&lt;/p&gt;</comment>
                    <comment id="29701" author="trptcolin" created="Fri, 19 Oct 2012 16:27:09 -0500"  >&lt;p&gt;Andy: The only caveat I can think of with checking Thread/interrupted less often is in the case of deeply nested collections.&lt;/p&gt;

&lt;p&gt;Stu: Dev-time use was the original reason for opening this, yes. But I can imagine it being needed for anytime a thread can be interrupted, whether that&apos;s by ctrl-c or other means.&lt;/p&gt;

&lt;p&gt;My original thinking, performance-wise, was that once we&apos;re already doing IO, we&apos;re probably not too concerned with CPU-bound checks like this, so I didn&apos;t bother with it. I guess with an SSD that&apos;s not as likely to be true.&lt;/p&gt;

&lt;p&gt;Locally (w/ my SSD), I&apos;m seeing that Andy&apos;s benchmark of printing a million numbers is about a second slower than the baseline with my original patch (12.08s -&amp;gt; 13.10s), and about the same with Andy&apos;s patch (12.08s -&amp;gt; 11.75s). Decreasing to a thousand numbers doesn&apos;t really show any difference (every version completes in ~1.3s). Bumping to 2 million adds 2 seconds above the baseline with my patch, and Andy&apos;s is again just a bit faster than the baseline (somehow). Bumping to 5 million runs me out of heap space &lt;img class=&quot;emoticon&quot; src=&quot;http://dev.clojure.org/jira/images/icons/emoticons/smile.gif&quot; height=&quot;20&quot; width=&quot;20&quot; align=&quot;absmiddle&quot; alt=&quot;&quot; border=&quot;0&quot;/&gt;&lt;/p&gt;</comment>
                    <comment id="29913" author="jafingerhut" created="Thu, 8 Nov 2012 16:16:24 -0600"  >&lt;p&gt;clj-1073-add-print-interruptibly-patch-v1.txt dated Nov 8 2012 is the same idea as Colin&apos;s patch 0001-Allow-thread-interruption-in-print-sequential.patch dated Sep 21 2012, except it only checks (Thread/interrupted) if a new var &lt;b&gt;print-interruptibly&lt;/b&gt; is true.  Its default value is false.&lt;/p&gt;

&lt;p&gt;Performance results of the perftest-print.clj program, as driven by the test.sh script, for Clojure 1.5-beta1 and with two different patches.  All run times are elapsed, in seconds, and sorted in increasing order for easier comparison.&lt;/p&gt;

&lt;p&gt;Executive summary: Performance results when &lt;b&gt;print-interruptibly&lt;/b&gt; is left at default false value are pretty much same as today.  With &lt;b&gt;print-interruptibly&lt;/b&gt; bound to true, performance results are slower, as expected, and about the same as with Colin&apos;s patch.&lt;/p&gt;

&lt;p&gt;Original 1.5-beta1 unchanged:&lt;br/&gt;
13.75 13.80 13.83 13.87 13.93&lt;/p&gt;

&lt;p&gt;With this new &lt;b&gt;print-interruptibly&lt;/b&gt; patch, with &lt;b&gt;print-interruptibly&lt;/b&gt;&lt;br/&gt;
at default false value:&lt;br/&gt;
13.86 13.91 14.01 14.08 14.14&lt;/p&gt;

&lt;p&gt;With this new &lt;b&gt;print-interruptibly&lt;/b&gt; patch, with &lt;b&gt;print-interruptibly&lt;/b&gt;&lt;br/&gt;
bound to true while printing (so a slightly modified version of&lt;br/&gt;
perftest-print.clj that does (binding &lt;span class=&quot;error&quot;&gt;&amp;#91;*print-interruptibly* true&amp;#93;&lt;/span&gt;&lt;br/&gt;
...) around the heart of the code):&lt;br/&gt;
15.29 15.44 15.45 15.62 15.63&lt;/p&gt;

&lt;p&gt;With patch 0001-Allow-thread-interruption-in-print-sequential.patch&lt;br/&gt;
applied:&lt;br/&gt;
15.38 15.46 15.48 15.49 15.50&lt;/p&gt;</comment>
                    <comment id="29933" author="trptcolin" created="Mon, 12 Nov 2012 13:37:10 -0600"  >&lt;p&gt;Andy&apos;s latest patch looks good &amp;amp; makes it easy for the REPL and other interruptible scenarios to opt into the &quot;safe&quot; behavior. I would personally have preferred to have the &quot;safe&quot; behavior on by default, but can understand the performance concerns, and this gets me what I really wanted.&lt;/p&gt;</comment>
                    <comment id="30122" author="halgari" created="Fri, 30 Nov 2012 15:09:07 -0600"  >&lt;p&gt;Vetting as it sounds like the performance issues are taken care of. &lt;/p&gt;</comment>
                    <comment id="30580" author="jafingerhut" created="Wed, 13 Feb 2013 00:28:34 -0600"  >&lt;p&gt;clj-1073-add-print-interruptibly-patch-v2.txt dated Feb 12 2013 is identical to clj-1073-add-print-interruptibly-patch-v1.txt dated Nov 8 2012 (soon to be removed) except that it applies cleanly to latest master.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="11517" name="0001-Allow-thread-interruption-in-print-sequential.patch" size="1260" author="trptcolin" created="Fri, 21 Sep 2012 16:10:46 -0500" />
                    <attachment id="11850" name="clj-1073-add-print-interruptibly-patch-v2.txt" size="3902" author="jafingerhut" created="Wed, 13 Feb 2013 00:28:34 -0600" />
                    <attachment id="11519" name="perftest-print.clj" size="284" author="jafingerhut" created="Fri, 21 Sep 2012 19:05:46 -0500" />
                    <attachment id="11518" name="test.sh" size="298" author="jafingerhut" created="Fri, 21 Sep 2012 19:05:34 -0500" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_10002" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Approval</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10003">Vetted</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                    <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10000" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Patch</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10001">Code</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[CLJ-1162] Error Message when calling deref on a non-IDeref is unhelpful</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1162</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;If you just type &quot;@1&quot; is the repl, on previous versions you&apos;ll get an error that Long cannot be cast to IDeref.  In 1.5, the error message is that it cannot be cast to java.util.concurrent.Future.  This is because it assumes that anything that isn&apos;t an IDeref is automatically a Future.  The deref method should generate a custom error stating that the type you&apos;ve passed in is neither an IDeref nor a Future. &lt;/p&gt;</description>
                <environment>Found this on ubuntu, lein 2, Clojure 1.5 snapshot, but it&amp;#39;s obvious from inspection</environment>
            <key id="16003">CLJ-1162</key>
            <summary>Error Message when calling deref on a non-IDeref is unhelpful</summary>
                <type id="4" iconUrl="http://dev.clojure.org/jira/images/icons/improvement.gif">Enhancement</type>
                                <priority id="4" iconUrl="http://dev.clojure.org/jira/images/icons/priority_minor.gif">Minor</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="julian">Julian Birch</reporter>
                        <labels>
                    </labels>
                <created>Tue, 12 Feb 2013 03:01:23 -0600</created>
                <updated>Fri, 1 Mar 2013 10:18:22 -0600</updated>
                                    <version>Release 1.5</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>1</watches>
                                <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                                                                                            </customfields>
    </item>

<item>
            <title>[CLJ-991] partition-by reducer</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-991</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description></description>
                <environment></environment>
            <key id="15428">CLJ-991</key>
            <summary>partition-by reducer</summary>
                <type id="4" iconUrl="http://dev.clojure.org/jira/images/icons/improvement.gif">Enhancement</type>
                                <priority id="4" iconUrl="http://dev.clojure.org/jira/images/icons/priority_minor.gif">Minor</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="hiredman">Kevin Downey</reporter>
                        <labels>
                        <label>enhancement</label>
                        <label>patch</label>
                        <label>patch,</label>
                    </labels>
                <created>Thu, 10 May 2012 20:08:20 -0500</created>
                <updated>Mon, 4 Mar 2013 14:49:42 -0600</updated>
                                                                            <due></due>
                    <votes>0</votes>
                        <watches>2</watches>
                        <comments>
                    <comment id="29140" author="richhickey" created="Tue, 14 Aug 2012 13:52:39 -0500"  >&lt;p&gt;I&apos;d like to see something much faster than this.&lt;/p&gt;</comment>
                    <comment id="29161" author="hiredman" created="Wed, 15 Aug 2012 01:58:59 -0500"  >&lt;p&gt;For reference here is a benchmark of a non-reducers (seq based) process that uses partition-by&lt;/p&gt;

&lt;div class=&quot;preformatted panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;preformattedContent panelContent&quot;&gt;
&lt;pre&gt;user=&amp;gt; (def x (vec (range 1e6)))
#&apos;user/x
user=&amp;gt; (bench (reduce + (map count (partition-by #(or (zero? (mod % 3)) (zero? (mod % 5))) x))))
Evaluation count             : 60
             Execution time mean : 1.072157 sec  95.0% CI: (1.070606 sec, 1.073381 sec)
    Execution time std-deviation : 165.818282 ms  95.0% CI: (163.873585 ms, 168.271261 ms)
         Execution time lower ci : 972.562000 ms  95.0% CI: (972.562000 ms, 973.301850 ms)
         Execution time upper ci : 1.419148 sec  95.0% CI: (1.419148 sec, 1.419148 sec)

Found 7 outliers in 60 samples (11.6667 %)
	low-severe	 2 (3.3333 %)
	low-mild	 5 (8.3333 %)
 Variance from outliers : 85.8489 % Variance is severely inflated by outliers
nil
user=&amp;gt;
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;Same again using r/partition-by from reducer-partition-by.diff&lt;/p&gt;
&lt;div class=&quot;preformatted panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;preformattedContent panelContent&quot;&gt;
&lt;pre&gt;user=&amp;gt; (bench (r/reduce + (r/map count (r/partition-by #(or (zero? (mod % 3)) (zero? (mod % 5))) x))))
Evaluation count             : 60
             Execution time mean : 1.418350 sec  95.0% CI: (1.417738 sec, 1.418948 sec)
    Execution time std-deviation : 66.736477 ms  95.0% CI: (66.186568 ms, 67.610777 ms)
         Execution time lower ci : 1.370419 sec  95.0% CI: (1.370419 sec, 1.370419 sec)
         Execution time upper ci : 1.544151 sec  95.0% CI: (1.544151 sec, 1.544156 sec)

Found 10 outliers in 60 samples (16.6667 %)
	low-severe	 2 (3.3333 %)
	low-mild	 8 (13.3333 %)
 Variance from outliers : 33.5591 % Variance is moderately inflated by outliers
nil
user=&amp;gt; 
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;(using &lt;a href=&quot;https://github.com/hugoduncan/criterium&quot;&gt;https://github.com/hugoduncan/criterium&lt;/a&gt; for benchmarking)&lt;/p&gt;</comment>
                    <comment id="29163" author="hiredman" created="Wed, 15 Aug 2012 02:17:20 -0500"  >&lt;p&gt;same again for r/partition-by from reducers-partition-by2.diff&lt;/p&gt;
&lt;div class=&quot;preformatted panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;preformattedContent panelContent&quot;&gt;
&lt;pre&gt;user=&amp;gt; (bench (r/reduce + (r/map count (r/partition-by #(or (zero? (mod % 3)) (zero? (mod % 5))) x))))
Evaluation count             : 180
             Execution time mean : 307.596806 ms  95.0% CI: (307.271339 ms, 307.961550 ms)
    Execution time std-deviation : 34.060809 ms  95.0% CI: (33.613169 ms, 34.416837 ms)
         Execution time lower ci : 285.339333 ms  95.0% CI: (285.339333 ms, 285.339333 ms)
         Execution time upper ci : 385.087950 ms  95.0% CI: (385.087950 ms, 385.087950 ms)

Found 10 outliers in 60 samples (16.6667 %)
	low-severe	 4 (6.6667 %)
	low-mild	 6 (10.0000 %)
 Variance from outliers : 73.8053 % Variance is severely inflated by outliers
nil
user=&amp;gt; 
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;same again driven using r/fold (for grins) instead of r/reduce&lt;/p&gt;
&lt;div class=&quot;preformatted panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;preformattedContent panelContent&quot;&gt;
&lt;pre&gt;user=&amp;gt; (bench (r/fold + (r/map count (r/partition-by #(or (zero? (mod % 3)) (zero? (mod % 5))) x))))
Evaluation count             : 360
             Execution time mean : 215.214486 ms  95.0% CI: (214.915417 ms, 215.664236 ms)
    Execution time std-deviation : 36.588464 ms  95.0% CI: (36.305548 ms, 36.847846 ms)
         Execution time lower ci : 185.575000 ms  95.0% CI: (185.575000 ms, 185.575000 ms)
         Execution time upper ci : 287.605175 ms  95.0% CI: (286.547833 ms, 287.605175 ms)

Found 6 outliers in 60 samples (10.0000 %)
	low-severe	 3 (5.0000 %)
	low-mild	 3 (5.0000 %)
 Variance from outliers : 87.6303 % Variance is severely inflated by outliers
nil
user=&amp;gt; 
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;reducers-partition-by2.diff is faster, but I am not wild about introducing a type and a protocol. also not sure about the CollFold impl.&lt;/p&gt;</comment>
                    <comment id="29167" author="richhickey" created="Wed, 15 Aug 2012 06:58:45 -0500"  >&lt;p&gt;Let&apos;s leave fold out for this first patch, please.&lt;/p&gt;</comment>
                    <comment id="29184" author="hiredman" created="Wed, 15 Aug 2012 14:34:40 -0500"  >&lt;p&gt;reducer-partition-by3.diff is a cleaned up version of reducer-partition-by2.diff without fold&lt;/p&gt;</comment>
                    <comment id="29736" author="devn" created="Sat, 20 Oct 2012 19:07:00 -0500"  >&lt;p&gt;Per Andy Fingerhut&apos;s email reducer-partition-by3.diff was failing to apply. This patch should apply cleanly to current master.&lt;/p&gt;</comment>
                    <comment id="29886" author="jafingerhut" created="Thu, 1 Nov 2012 18:59:50 -0500"  >&lt;p&gt;Presumptuously changing Approval from Incomplete to None, since the reason for its being marked Incomplete seems to have been addressed with the latest patch.&lt;/p&gt;</comment>
                    <comment id="30697" author="hiredman" created="Mon, 4 Mar 2013 14:49:42 -0600"  >&lt;p&gt;should this be assigned to someone?&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="11427" name="reducer-partition-by2.diff" size="3061" author="hiredman" created="Wed, 15 Aug 2012 02:11:03 -0500" />
                    <attachment id="11435" name="reducer-partition-by3.diff" size="2636" author="hiredman" created="Wed, 15 Aug 2012 14:34:40 -0500" />
                    <attachment id="11591" name="reducer-partition-by4.diff" size="2647" author="devn" created="Sat, 20 Oct 2012 19:07:00 -0500" />
                    <attachment id="11190" name="reducer-partition-by.diff" size="2657" author="hiredman" created="Thu, 10 May 2012 20:08:20 -0500" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10000" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Patch</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10002">Code and Test</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[CLJ-1141] Allow pre and post-conditions in defprotocol and deftype macros</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1141</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;The fn special form and the defn macro allow pre- and post-conditions. It would be nice if one could use that conditions also in method declarations of the defprotocol and deftype macro.&lt;/p&gt;

&lt;p&gt;Currently I use the extend function as workaround where one can specify the methods using a map of keyword-name and fn special form.&lt;/p&gt;</description>
                <environment>Dos not matter.</environment>
            <key id="15937">CLJ-1141</key>
            <summary>Allow pre and post-conditions in defprotocol and deftype macros</summary>
                <type id="4" iconUrl="http://dev.clojure.org/jira/images/icons/improvement.gif">Enhancement</type>
                                <priority id="4" iconUrl="http://dev.clojure.org/jira/images/icons/priority_minor.gif">Minor</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="akiel">Alexander Kiel</reporter>
                        <labels>
                    </labels>
                <created>Wed, 2 Jan 2013 05:08:13 -0600</created>
                <updated>Mon, 7 Jan 2013 17:28:42 -0600</updated>
                                    <version>Release 1.4</version>
                                                        <due></due>
                    <votes>1</votes>
                        <watches>3</watches>
                        <comments>
                    <comment id="30381" author="michael-drogalis" created="Sun, 6 Jan 2013 18:22:35 -0600"  >&lt;p&gt;Using &lt;tt&gt;:pre&lt;/tt&gt; and &lt;tt&gt;:post&lt;/tt&gt;, IMO, isn&apos;t a good idea. Handling assertions is a two part game. The mechanism needs to account for both detection and reaction, and the latter is missing.&lt;/p&gt;

&lt;p&gt;This isn&apos;t a perfect work-around, as it&apos;s a little verbose, but using &lt;a href=&quot;https://github.com/MichaelDrogalis/dire&quot;&gt;Dire&lt;/a&gt; might work better than using extend. In addition, you get the &quot;reaction&quot; functionality that&apos;s missing from &lt;tt&gt;:pre&lt;/tt&gt; and &lt;tt&gt;:post&lt;/tt&gt;&lt;/p&gt;

&lt;p&gt;Example for protocol preconditions: &lt;a href=&quot;https://gist.github.com/4471276&quot;&gt;https://gist.github.com/4471276&lt;/a&gt;&lt;/p&gt;</comment>
                    <comment id="30396" author="akiel" created="Mon, 7 Jan 2013 11:52:08 -0600"  >&lt;p&gt;@Michael I read your &lt;a href=&quot;https://gist.github.com/4471276&quot;&gt;gist&lt;/a&gt; and the README of &lt;a href=&quot;https://github.com/MichaelDrogalis/dire&quot;&gt;Dire&lt;/a&gt;. I think the supervision concept of Erlang has it&apos;s places but I don&apos;t like it for pre- and post-conditions. For me, such conditions have two proposes: &lt;/p&gt;

&lt;ol&gt;
	&lt;li&gt;they should document the code and&lt;/li&gt;
	&lt;li&gt;they should fail fast to detect failures early.&lt;/li&gt;
&lt;/ol&gt;


&lt;p&gt;To support my first point, your pre- and post-conditions are just lexical too far away from the actual function definition. For the second point: I think in the case of violations the program should just crash. One could maybe wrap some part of the program with one of your exception supervisors handling an AssertionError. But I don&apos;t think that handling pre- and post-condition violations for individual functions is a good thing.&lt;/p&gt;</comment>
                    <comment id="30402" author="michael-drogalis" created="Mon, 7 Jan 2013 17:28:42 -0600"  >&lt;p&gt;@Alexander Indeed, your points are correct. Dire is meant to be exactly what you described. Lexically removed from application logic, and opportunity to recover from crashing. That was my best shot at aiding your needs quickly, anyway. &lt;img class=&quot;emoticon&quot; src=&quot;http://dev.clojure.org/jira/images/icons/emoticons/smile.gif&quot; height=&quot;20&quot; width=&quot;20&quot; align=&quot;absmiddle&quot; alt=&quot;&quot; border=&quot;0&quot;/&gt;&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                                                                                            </customfields>
    </item>

<item>
            <title>[CLJ-1172] Cross-linking between clojure.lang.Compiler and clojure.lang.RT</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1172</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;This is my code (an example):&lt;/p&gt;

&lt;div class=&quot;preformatted panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;preformattedContent panelContent&quot;&gt;
&lt;pre&gt;import clojure.lang.Compiler;
import clojure.lang.RT;
import clojure.lang.Var;

Compiler.load(&quot;(+ 5 %)&quot;);
Var foo = RT.var(&quot;bar&quot;, &quot;foo&quot;);
Object result = foo.invoke(10);
assert result.toString().equals(&quot;15&quot;);
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;This is what I&apos;m getting:&lt;/p&gt;

&lt;div class=&quot;preformatted panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;preformattedContent panelContent&quot;&gt;
&lt;pre&gt;ava.lang.ExceptionInInitializerError
	at clojure.lang.Compiler.&amp;lt;clinit&amp;gt;(Compiler.java:47)
	at foo.main(Main.java:75)
Caused by: java.lang.NullPointerException
	at clojure.lang.RT.baseLoader(RT.java:2043)
	at clojure.lang.RT.load(RT.java:417)
	at clojure.lang.RT.load(RT.java:411)
	at clojure.lang.RT.doInit(RT.java:447)
	at clojure.lang.RT.&amp;lt;clinit&amp;gt;(RT.java:329)
	... 36 more
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;The same code worked just fine with version 1.4. Looks like &lt;tt&gt;Compiler&lt;/tt&gt; is using &lt;tt&gt;RT&lt;/tt&gt; and &lt;tt&gt;RT&lt;/tt&gt; is using &lt;tt&gt;Compiler&lt;/tt&gt;, both statically.&lt;/p&gt;</description>
                <environment>version 1.5.0-RC17</environment>
            <key id="16032">CLJ-1172</key>
            <summary>Cross-linking between clojure.lang.Compiler and clojure.lang.RT</summary>
                <type id="1" iconUrl="http://dev.clojure.org/jira/images/icons/bug.gif">Defect</type>
                                <priority id="4" iconUrl="http://dev.clojure.org/jira/images/icons/priority_minor.gif">Minor</priority>
                    <status id="4" iconUrl="http://dev.clojure.org/jira/images/icons/status_reopened.gif">Reopened</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="yegor256">Yegor Bugayenko</reporter>
                        <labels>
                    </labels>
                <created>Thu, 28 Feb 2013 06:30:50 -0600</created>
                <updated>Sat, 23 Mar 2013 10:31:23 -0500</updated>
                                    <version>Release 1.5</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>1</watches>
                        <comments>
                    <comment id="30694" author="yegor256" created="Mon, 4 Mar 2013 11:40:51 -0600"  >&lt;p&gt;I cross-posted this question to SO: &lt;a href=&quot;http://stackoverflow.com/questions/15207596&quot;&gt;http://stackoverflow.com/questions/15207596&lt;/a&gt;&lt;/p&gt;</comment>
                    <comment id="30699" author="yegor256" created="Tue, 5 Mar 2013 00:04:37 -0600"  >&lt;p&gt;calling &lt;tt&gt;RT.init()&lt;/tt&gt; before &lt;tt&gt;Compiler.load()&lt;/tt&gt; solves the problem&lt;/p&gt;</comment>
                    <comment id="30700" author="jafingerhut" created="Tue, 5 Mar 2013 04:17:34 -0600"  >&lt;p&gt;Yegor, do you consider it OK to close this ticket as not being a problem, or at least one with a reasonable workaround?&lt;/p&gt;</comment>
                    <comment id="30702" author="yegor256" created="Tue, 5 Mar 2013 13:11:57 -0600"  >&lt;p&gt;Yes, of course. Let&apos;s close it.&lt;/p&gt;</comment>
                    <comment id="30703" author="jafingerhut" created="Tue, 5 Mar 2013 18:14:13 -0600"  >&lt;p&gt;Ticket submitter agrees that this is not an issue, or that there is a reasonable workaround.&lt;/p&gt;</comment>
                    <comment id="30752" author="jafingerhut" created="Wed, 13 Mar 2013 00:58:46 -0500"  >&lt;p&gt;This issue came up again on the Clojure group.  &lt;a href=&quot;https://groups.google.com/forum/?hl=en_US&amp;amp;fromgroups=#!topic/clojure/2xdLNMb9yyQ&quot;&gt;https://groups.google.com/forum/?hl=en_US&amp;amp;fromgroups=#!topic/clojure/2xdLNMb9yyQ&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;I did some testing, and the issue did not exist in Clojure 1.5.0-RC3 and before, and it has existed since 1.5.0-RC4.  There was only one commit between those two points:&lt;/p&gt;

&lt;p&gt;    &lt;a href=&quot;https://github.com/clojure/clojure/commit/9b80a552fdabeabdd93951a625b55ae49c2f8d83&quot;&gt;https://github.com/clojure/clojure/commit/9b80a552fdabeabdd93951a625b55ae49c2f8d83&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;Maybe this new behavior is an intended consequence of that change.  I don&apos;t know.  In any case, it seems like perhaps the &quot;No need to call RT.init() anymore&quot; message might be outdated?&lt;/p&gt;</comment>
                    <comment id="30753" author="jafingerhut" created="Wed, 13 Mar 2013 00:59:59 -0500"  >&lt;p&gt;Reopening since it came up again, and there is some more info known about the issue.  I&apos;ll let someone who knows more about the issue decide whether to close it.&lt;/p&gt;</comment>
                    <comment id="30806" author="appodictic" created="Sat, 23 Mar 2013 10:31:23 -0500"  >&lt;p&gt;Doing this RT.load(&quot;clojure/core&quot;); at the top works avoids the message from RT.init()&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                                                                                            </customfields>
    </item>

<item>
            <title>[CLJ-1004] ArrayChunk implements Seqable</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1004</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;I&apos;ve found it helpful to be able to iterate over ArrayChunks.  Implementing Seqable means they can be used by most collections functions.&lt;/p&gt;</description>
                <environment></environment>
            <key id="15485">CLJ-1004</key>
            <summary>ArrayChunk implements Seqable</summary>
                <type id="4" iconUrl="http://dev.clojure.org/jira/images/icons/improvement.gif">Enhancement</type>
                                <priority id="4" iconUrl="http://dev.clojure.org/jira/images/icons/priority_minor.gif">Minor</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="jim.blomo">Jim Blomo</assignee>
                                <reporter username="jim.blomo">Jim Blomo</reporter>
                        <labels>
                    </labels>
                <created>Mon, 28 May 2012 18:53:55 -0500</created>
                <updated>Mon, 25 Mar 2013 23:10:02 -0500</updated>
                                                                            <due></due>
                    <votes>0</votes>
                        <watches>1</watches>
                        <comments>
                    <comment id="28636" author="jim.blomo" created="Mon, 28 May 2012 19:55:02 -0500"  >&lt;p&gt;2012-05-28 implements the seq method for vec and vector-of. It uses the array backing ArrayChunk to construct a sequence.  Simple tests are included.&lt;/p&gt;</comment>
                    <comment id="30673" author="stu" created="Fri, 1 Mar 2013 09:44:37 -0600"  >&lt;p&gt;Please add discussion of motivating use cases.&lt;/p&gt;</comment>
                    <comment id="30822" author="jim.blomo" created="Mon, 25 Mar 2013 23:10:02 -0500"  >&lt;p&gt;This was motivated by the desire to implement chunk-sequence-aware functions in Clojure elegantly.  Currently, dealing with ArrayChunks in Clojure is clumsy because few of the functions dealing with collections will work with non-seqables.  This functionality will mostly be used by implementers since end users shouldn&apos;t care if their sequence is chunked or not.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="11264" name="arraychunk-seq-10004.diff" size="2946" author="jim.blomo" created="Mon, 28 May 2012 19:55:02 -0500" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10000" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Patch</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10002">Code and Test</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[CLJ-1177] clojure.java.io/resource and non-ASCII characters</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1177</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;clojure.java.io/resource corrupts path containing UTF-8 characters without issuing warning.&lt;/p&gt;

&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;user=&amp;gt; (&lt;span class=&quot;code-object&quot;&gt;System&lt;/span&gt;/getProperty &lt;span class=&quot;code-quote&quot;&gt;&quot;java.runtime.version&quot;&lt;/span&gt;)
&lt;span class=&quot;code-quote&quot;&gt;&quot;1.8.0-ea-b79&quot;&lt;/span&gt;
user=&amp;gt; (clojure-version)
&lt;span class=&quot;code-quote&quot;&gt;&quot;1.5.0&quot;&lt;/span&gt;
user=&amp;gt; (&lt;span class=&quot;code-object&quot;&gt;System&lt;/span&gt;/getProperty &lt;span class=&quot;code-quote&quot;&gt;&quot;user.dir&quot;&lt;/span&gt;)
&lt;span class=&quot;code-quote&quot;&gt;&quot;/dir/d&#233;f&quot;&lt;/span&gt;
user=&amp;gt; (clojure.java.io/resource &lt;span class=&quot;code-quote&quot;&gt;&quot;myfile.txt&quot;&lt;/span&gt;)
#&amp;lt;URL file:/dir/d%c3%a9f/resources/myfile.txt&amp;gt;
user=&amp;gt; (slurp (clojure.java.io/resource &lt;span class=&quot;code-quote&quot;&gt;&quot;myfile.txt&quot;&lt;/span&gt;) :encoding &lt;span class=&quot;code-quote&quot;&gt;&quot;UTF-8&quot;&lt;/span&gt;)
FileNotFoundException /dir/d&#195;&#169;f/resources/myfile.txt (No such file or directory)  java.io.FileInputStream.open (FileInputStream.java:-2)&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;</description>
                <environment></environment>
            <key id="16062">CLJ-1177</key>
            <summary>clojure.java.io/resource and non-ASCII characters</summary>
                <type id="4" iconUrl="http://dev.clojure.org/jira/images/icons/improvement.gif">Enhancement</type>
                                <priority id="4" iconUrl="http://dev.clojure.org/jira/images/icons/priority_minor.gif">Minor</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="trevor">Trevor Wennblom</reporter>
                        <labels>
                        <label>bug</label>
                        <label>enhancement</label>
                    </labels>
                <created>Thu, 7 Mar 2013 16:54:43 -0600</created>
                <updated>Sun, 10 Mar 2013 17:56:52 -0500</updated>
                                    <version>Release 1.5</version>
                                                        <due></due>
                    <votes>1</votes>
                        <watches>0</watches>
                        <comments>
                    <comment id="30713" author="jafingerhut" created="Fri, 8 Mar 2013 00:10:22 -0600"  >&lt;p&gt;Below is a workaround, at least.  I don&apos;t know, but perhaps the as-file method for URLs in io.clj of Clojure, the part that converts %hh sequences to a character with code point in the range 0 through 255, is at least partly at fault here.  I don&apos;t know right now if it is possible to modify that code to handle the general case of whatever character encoding munging is going on here to when .getResource creates the URL object.&lt;/p&gt;


&lt;p&gt;clojure.java.io/resource is documented to return a Java object of type java.net.URL, which seems like it does %hh escaping of many characters.  Reference &lt;span class=&quot;error&quot;&gt;&amp;#91;1&amp;#93;&lt;/span&gt; to a Java bug from 2001 where a Java user was surprised by the then-recent change in behavior of the getResource method &lt;span class=&quot;error&quot;&gt;&amp;#91;2&amp;#93;&lt;/span&gt;.&lt;/p&gt;

&lt;p&gt;Doing a little searching I found this StackOverflow question &lt;span class=&quot;error&quot;&gt;&amp;#91;3&amp;#93;&lt;/span&gt;, which has what might be a workaround.  I tried it on my Mac OS X 10.6 system running JDK 1.6 and it seemed to work:&lt;/p&gt;

&lt;p&gt;(slurp (.getContent (clojure.java.io/resource &quot;abc&#237;d/foo.txt&quot;)))&lt;/p&gt;

&lt;p&gt;That getContent is a method for class java.net.URL &lt;span class=&quot;error&quot;&gt;&amp;#91;4&amp;#93;&lt;/span&gt;&lt;/p&gt;

&lt;p&gt;&lt;span class=&quot;error&quot;&gt;&amp;#91;1&amp;#93;&lt;/span&gt; &lt;a href=&quot;http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4466485&quot;&gt;http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4466485&lt;/a&gt;&lt;br/&gt;
&lt;span class=&quot;error&quot;&gt;&amp;#91;2&amp;#93;&lt;/span&gt; &lt;a href=&quot;http://docs.oracle.com/javase/1.5.0/docs/api/java/lang/Class.html#getResource%28java.lang.String%29&quot;&gt;http://docs.oracle.com/javase/1.5.0/docs/api/java/lang/Class.html#getResource%28java.lang.String%29&lt;/a&gt;&lt;br/&gt;
&lt;span class=&quot;error&quot;&gt;&amp;#91;3&amp;#93;&lt;/span&gt; &lt;a href=&quot;http://stackoverflow.com/questions/13013629/best-international-alternative-to-javas-getclass-getresource&quot;&gt;http://stackoverflow.com/questions/13013629/best-international-alternative-to-javas-getclass-getresource&lt;/a&gt;&lt;br/&gt;
&lt;span class=&quot;error&quot;&gt;&amp;#91;4&amp;#93;&lt;/span&gt; &lt;a href=&quot;http://docs.oracle.com/javase/1.5.0/docs/api/java/net/URL.html#getContent%28%29&quot;&gt;http://docs.oracle.com/javase/1.5.0/docs/api/java/net/URL.html#getContent%28%29&lt;/a&gt;&lt;/p&gt;</comment>
                    <comment id="30716" author="trevor" created="Fri, 8 Mar 2013 09:56:22 -0600"  >&lt;p&gt;Hi Andy,&lt;/p&gt;

&lt;p&gt;Thanks for the background and suggestions, that&apos;s very helpful.&lt;/p&gt;

&lt;p&gt;I&apos;m gradually learning Clojure with no Java experience. In this case I was searching for the preferred Clojure way to access items in directories declared under :resource-paths in a Leiningen project.clj file. Perhaps clojure.java.io/resource isn&apos;t the best way to do this as it&apos;s possibly too tied to the expectation for a URI instead of a more general IRI.&lt;/p&gt;

&lt;p&gt;You&apos;re suggested workaround did work for my use case:&lt;/p&gt;

&lt;p&gt;(slurp (.getContent (clojure.java.io/resource &quot;abc&#237;d/foo.txt&quot;)))&lt;/p&gt;

&lt;p&gt;but hopefully there would be more native/direct Clojure way to accomplish the same eventually.&lt;/p&gt;

&lt;p&gt;I don&apos;t know if java.net.IDN would be useful internally as a fix in clojure.java.io/resource &#8212; I&apos;m assuming not since it wasn&apos;t added until Java 6.&lt;span class=&quot;error&quot;&gt;&amp;#91;1&amp;#93;&lt;/span&gt;&lt;/p&gt;

&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;user=&amp;gt; (&lt;span class=&quot;code-keyword&quot;&gt;import&lt;/span&gt; &apos;java.net.IDN)
java.net.IDN
user=&amp;gt; (java.net.IDN/toASCII &lt;span class=&quot;code-quote&quot;&gt;&quot;/dir/d&#233;f&quot;&lt;/span&gt;)
&lt;span class=&quot;code-quote&quot;&gt;&quot;xn--/dir/df-gya&quot;&lt;/span&gt;
user=&amp;gt; (java.net.IDN/toUnicode &lt;span class=&quot;code-quote&quot;&gt;&quot;xn--/dir/df-gya&quot;&lt;/span&gt;)
&lt;span class=&quot;code-quote&quot;&gt;&quot;/dir/d&#233;f&quot;&lt;/span&gt;&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;


&lt;p&gt;&lt;span class=&quot;error&quot;&gt;&amp;#91;1&amp;#93;&lt;/span&gt;: &lt;a href=&quot;http://docs.oracle.com/javase/6/docs/api/java/net/IDN.html&quot;&gt;http://docs.oracle.com/javase/6/docs/api/java/net/IDN.html&lt;/a&gt;&lt;/p&gt;</comment>
                    <comment id="30717" author="jafingerhut" created="Fri, 8 Mar 2013 13:30:05 -0600"  >&lt;p&gt;Patch clj-1177-patch-v1.txt dated Mar 8 2013 is an attempt to solve this issue, in what I think may be a correct way.  As specified in RFC 3986, when taking a Unicode string and making a URL of it, it should be encoded in UTF-8 and then each individual byte is subject to the %HH hex encoding.  This patch reverses that to turn URLs into file names.&lt;/p&gt;

&lt;p&gt;Tested on Mac OS X 10.6 with a command line like this (it doesn&apos;t work without the -Dfile.encoding=UTF-8 option on my Mac, probably because the default encoding is MacRoman):&lt;/p&gt;

&lt;p&gt;% java -cp clojure.jar:path/to/resource -Dfile.encoding=UTF-8 clojure.main&lt;br/&gt;
user=&amp;gt; (require &apos;&lt;span class=&quot;error&quot;&gt;&amp;#91;clojure.java.io :as io&amp;#93;&lt;/span&gt;)&lt;br/&gt;
nil&lt;br/&gt;
user=&amp;gt; (io/resource &quot;abc&#237;d/foo.txt&quot;)&lt;br/&gt;
#&amp;lt;URL &lt;a href=&quot;file:/Users/jafinger/clj/clj-ns-browser/resource/abc%c3%add/foo.txt&quot;&gt;file:/Users/jafinger/clj/clj-ns-browser/resource/abc%c3%add/foo.txt&lt;/a&gt;&amp;gt;&lt;br/&gt;
user=&amp;gt; (slurp (io/resource &quot;abc&#237;d/foo.txt&quot;))&lt;br/&gt;
&quot;The quick brown fox jumped over the l&#225;zy d&#246;g!\n&quot;&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="11900" name="clj-1177-patch-v1.txt" size="2673" author="jafingerhut" created="Fri, 8 Mar 2013 13:30:05 -0600" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10000" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Patch</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10001">Code</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[CLJ-1026] Mixed end-of-line endings in the source code</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1026</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;While examining some of the Clojure source code, I discovered that some files had mixed line endings, or CRLF line endings on a non-Windows box.  Using &lt;tt&gt;.gitattributes&lt;/tt&gt;, we can correct that so that files have the right endings for the platform that it&apos;s on.&lt;/p&gt;</description>
                <environment></environment>
            <key id="15579">CLJ-1026</key>
            <summary>Mixed end-of-line endings in the source code</summary>
                <type id="4" iconUrl="http://dev.clojure.org/jira/images/icons/improvement.gif">Enhancement</type>
                                <priority id="4" iconUrl="http://dev.clojure.org/jira/images/icons/priority_minor.gif">Minor</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="jszakmeister">John Szakmeister</reporter>
                        <labels>
                    </labels>
                <created>Tue, 17 Jul 2012 14:25:22 -0500</created>
                <updated>Sat, 30 Mar 2013 08:44:15 -0500</updated>
                                                                            <due></due>
                    <votes>2</votes>
                        <watches>1</watches>
                        <comments>
                    <comment id="28990" author="jszakmeister" created="Tue, 17 Jul 2012 14:26:39 -0500"  >&lt;p&gt;Patch to fix line endings and introduce .gitattributes.&lt;/p&gt;</comment>
                    <comment id="29011" author="stu" created="Fri, 20 Jul 2012 16:47:34 -0500"  >&lt;p&gt;This looks like a change to every line in the world, which makes it hard to vet. Also: will it render incompatible all other outstanding patches at the time it is applied?&lt;/p&gt;</comment>
                    <comment id="29019" author="jszakmeister" created="Sat, 21 Jul 2012 06:52:36 -0500"  >&lt;p&gt;You can use &lt;tt&gt;git diff -w $(git merge-base HEAD master)&lt;/tt&gt; to see the actual diff minus the line ending change.  Here it is inline:&lt;/p&gt;

&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;:: git diff -w $(git merge-base HEAD master)
diff --git a/.gitattributes b/.gitattributes
&lt;span class=&quot;code-keyword&quot;&gt;new&lt;/span&gt; file mode 100644
index 0000000..7b89cfa
--- /dev/&lt;span class=&quot;code-keyword&quot;&gt;null&lt;/span&gt;
+++ b/.gitattributes
@@ -0,0 +1,6 @@
+*.txt           text
+*.clj           text
+*.html          text
+*.js            text
+*.css           text
+*.java          text diff=java&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;Also, no, it won&apos;t render all the outstanding patches incompatible.  For one, it seems like the files that have the eols mixed or in CRLF aren&apos;t touched much.  I also went through the majority of outstanding patches and couldn&apos;t fix one that conflicts.  Secondly, &lt;tt&gt;format-patch&lt;/tt&gt; emits the patch inline and is intended to be sent via email.  SMTP says that all lines must end with CRLF, so line endings are effectively lost.  So git will convert it to the right line ending on application.&lt;/p&gt;

&lt;p&gt;It can conflict with any outstanding &lt;b&gt;branches&lt;/b&gt; that you may have.  Supplying the renormalization option on merge can help:&lt;/p&gt;

&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;git merge -X renormalize &amp;lt;branch-name&amp;gt;&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;Or, you can enable this by default for your repository:&lt;/p&gt;

&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;git config --local merge.renormalize &lt;span class=&quot;code-keyword&quot;&gt;true&lt;/span&gt;&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;If you think it&apos;s too much trouble, let&apos;s just drop it though.&lt;/p&gt;</comment>
                    <comment id="29104" author="stu" created="Fri, 10 Aug 2012 13:15:58 -0500"  >&lt;p&gt;Patch does not apply on my working copy of Clojure. I am using&lt;/p&gt;

&lt;div class=&quot;preformatted panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;preformattedContent panelContent&quot;&gt;
&lt;pre&gt;git am -s ...
/Users/stu/repos/clojure/.git/rebase-apply/patch:344: trailing whitespace.
  p {  	
/Users/stu/repos/clojure/.git/rebase-apply/patch:350: space before tab in indent.
  	margin-left: 0.5in;
error: patch failed: epl-v10.html:1
error: epl-v10.html: patch does not apply
error: patch failed: src/jvm/clojure/asm/AnnotationVisitor.java:1
error: src/jvm/clojure/asm/AnnotationVisitor.java: patch does not apply
error: patch failed: src/jvm/clojure/asm/AnnotationWriter.java:1
error: src/jvm/clojure/asm/AnnotationWriter.java: patch does not apply
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;I am willing to do this, just inept. &lt;img class=&quot;emoticon&quot; src=&quot;http://dev.clojure.org/jira/images/icons/emoticons/smile.gif&quot; height=&quot;20&quot; width=&quot;20&quot; align=&quot;absmiddle&quot; alt=&quot;&quot; border=&quot;0&quot;/&gt;&lt;/p&gt;</comment>
                    <comment id="29105" author="jafingerhut" created="Fri, 10 Aug 2012 13:21:40 -0500"  >&lt;p&gt;Stuart, I updated this page &lt;a href=&quot;http://dev.clojure.org/display/design/JIRA+workflow&quot;&gt;http://dev.clojure.org/display/design/JIRA+workflow&lt;/a&gt; a while back when I had trouble applying some patches involving files with carriage return line endings.  I did some Googling on git docs and found the option &apos;--keep-cr&apos; that seems to help in such cases.  Try that out.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="11384" name="0001-Introduce-end-of-line-normalization.patch" size="1078968" author="jszakmeister" created="Tue, 17 Jul 2012 14:26:39 -0500" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10000" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Patch</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10001">Code</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[CLJ-1189] Map-destructuring :or fumble needs compiler warning</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1189</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;Here is a map-destructuring blunder that I wish the compiler warned about: &lt;/p&gt;

&lt;p&gt;(defn server&lt;br/&gt;
  [{servlet ::servlet&lt;br/&gt;
    type ::type&lt;br/&gt;
    :or {::type :jetty}&lt;br/&gt;
    :as service-map}]&lt;/p&gt;

&lt;p&gt;It would be splendid to get a warning that :or keys that are not symbols being bound have no effect. &lt;/p&gt;

&lt;p&gt;The incomplete code snippet above comes from Pedestal.service 0.1.0. &lt;/p&gt;

&lt;p&gt;Here is a complete one-line example with the coding error: &lt;/p&gt;

&lt;p&gt;user&amp;gt; (defn picnic &lt;span class=&quot;error&quot;&gt;&amp;#91;{botulism :botulism :or {:botulism 6}}&amp;#93;&lt;/span&gt; botulism) &lt;br/&gt;
#&apos;user/picnic &lt;br/&gt;
user&amp;gt; (picnic {}) &lt;br/&gt;
nil &lt;br/&gt;
user&amp;gt; ;; I intended 6. &lt;/p&gt;</description>
                <environment></environment>
            <key id="16118">CLJ-1189</key>
            <summary>Map-destructuring :or fumble needs compiler warning</summary>
                <type id="1" iconUrl="http://dev.clojure.org/jira/images/icons/bug.gif">Defect</type>
                                <priority id="4" iconUrl="http://dev.clojure.org/jira/images/icons/priority_minor.gif">Minor</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="pbwolf">Phill Wolf</reporter>
                        <labels>
                    </labels>
                <created>Sun, 31 Mar 2013 08:02:44 -0500</created>
                <updated>Sun, 31 Mar 2013 08:02:44 -0500</updated>
                                    <version>Release 1.5</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                                                                                            </customfields>
    </item>

<item>
            <title>[CLJ-1191] Improve apropos to show some indication of namespace of symbols found</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1191</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;apropos does find all symbols in all namespaces that match the argument, but the return value gives no clue as to which namespace the found symbols are in.  It can even return multiple occurrences of the same symbol, which only gives a clue that the symbol exists in more than one namespace, but not which ones.  For example:&lt;/p&gt;

&lt;p&gt;user=&amp;gt; (apropos &quot;replace&quot;)&lt;br/&gt;
(postwalk-replace prewalk-replace replace re-quote-replacement replace replace-first)&lt;/p&gt;

&lt;p&gt;It would be nice if the returned symbols could indicate the namespace, either always, or if the found symbol is not in the current namespace.&lt;/p&gt;</description>
                <environment></environment>
            <key id="16128">CLJ-1191</key>
            <summary>Improve apropos to show some indication of namespace of symbols found</summary>
                <type id="4" iconUrl="http://dev.clojure.org/jira/images/icons/improvement.gif">Enhancement</type>
                                <priority id="4" iconUrl="http://dev.clojure.org/jira/images/icons/priority_minor.gif">Minor</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="jafingerhut">Andy Fingerhut</reporter>
                        <labels>
                    </labels>
                <created>Thu, 4 Apr 2013 19:52:30 -0500</created>
                <updated>Fri, 5 Apr 2013 13:34:10 -0500</updated>
                                    <version>Release 1.5</version>
                <version>Release 1.6</version>
                                                        <due></due>
                    <votes>1</votes>
                        <watches>2</watches>
                        <comments>
                    <comment id="30876" author="jafingerhut" created="Thu, 4 Apr 2013 20:25:56 -0500"  >&lt;p&gt;Path clj-1191-patch-v1.txt enhances apropos to put a namespace/ qualifier before every symbol found that is not in the current namespace &lt;b&gt;ns&lt;/b&gt;.  It also finds the shortest namespace alias if there is more than one.  Examples of output with patch:&lt;/p&gt;

&lt;p&gt;user=&amp;gt; (apropos &quot;replace&quot;)&lt;br/&gt;
(replace clojure.string/re-quote-replacement clojure.string/replace clojure.string/replace-first clojure.walk/postwalk-replace clojure.walk/prewalk-replace)&lt;/p&gt;

&lt;p&gt;user=&amp;gt; (require &apos;&lt;span class=&quot;error&quot;&gt;&amp;#91;clojure.string :as str&amp;#93;&lt;/span&gt;)&lt;br/&gt;
nil&lt;br/&gt;
user=&amp;gt; (apropos &quot;replace&quot;)&lt;br/&gt;
(replace clojure.walk/postwalk-replace clojure.walk/prewalk-replace str/re-quote-replacement str/replace str/replace-first)&lt;/p&gt;

&lt;p&gt;user=&amp;gt; (in-ns &apos;clojure.string)&lt;br/&gt;
#&amp;lt;Namespace clojure.string&amp;gt;&lt;br/&gt;
clojure.string=&amp;gt; (clojure.repl/apropos &quot;replace&quot;)&lt;br/&gt;
(re-quote-replacement replace replace-by replace-first replace-first-by replace-first-char replace-first-str clojure.core/replace clojure.walk/postwalk-replace clojure.walk/prewalk-replace)&lt;/p&gt;</comment>
                    <comment id="30879" author="trptcolin" created="Fri, 5 Apr 2013 13:34:10 -0500"  >&lt;p&gt;+1 &lt;/p&gt;

&lt;p&gt;apropos as it already stands is quite helpful for already-referred vars, but not for vars that are only in other nses.&lt;/p&gt;

&lt;p&gt;This update includes the information someone would need to further investigate the output.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="11942" name="clj-1191-patch-v1.txt" size="2704" author="jafingerhut" created="Thu, 4 Apr 2013 20:25:56 -0500" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10000" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Patch</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10001">Code</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[CLJ-976] Implement reader literal and print support for PersistentQueue data structure</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-976</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;Clojure&apos;s PersistentQueue structure has been in the language for quite some time now and has found its way into a fair share of codebases. However, the creation of queues is a two step operation often of the form:&lt;/p&gt;

&lt;div class=&quot;preformatted panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;preformattedContent panelContent&quot;&gt;
&lt;pre&gt;(conj clojure.lang.PersistentQueue/EMPTY :a :b :c)

;=&amp;gt; #&amp;lt;PersistentQueue clojure.lang.PersistentQueue@78d5f6bc&amp;gt;
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;A better experience might be the following:&lt;/p&gt;

&lt;div class=&quot;preformatted panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;preformattedContent panelContent&quot;&gt;
&lt;pre&gt;#queue [:a :b :c]

;=&amp;gt; #queue [:a :b :c]

(pop #queue [:a :b :c])

;=&amp;gt; #queue [:b :c]
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;This syntax is proposed and discussed in the Clojure-dev group at &lt;a href=&quot;https://groups.google.com/forum/?fromgroups#!topic/clojure-dev/GQqus5Wycno&quot;&gt;https://groups.google.com/forum/?fromgroups#!topic/clojure-dev/GQqus5Wycno&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;Open question: Should the queue literal&apos;s arguments eval?  The implications of this are illustrated below:&lt;/p&gt;

&lt;div class=&quot;preformatted panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;preformattedContent panelContent&quot;&gt;
&lt;pre&gt;;; non-eval case
#queue [1 2 (+ 1 2)]

;=&amp;gt; #queue [1 2 (+ 1 2)]


;; eval case
#queue [1 2 (+ 1 2)]

;=&amp;gt; #queue [1 2 3]
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;The answer to this open question will determine the implementation.&lt;/p&gt;</description>
                <environment></environment>
            <key id="15370">CLJ-976</key>
            <summary>Implement reader literal and print support for PersistentQueue data structure</summary>
                <type id="4" iconUrl="http://dev.clojure.org/jira/images/icons/improvement.gif">Enhancement</type>
                                <priority id="4" iconUrl="http://dev.clojure.org/jira/images/icons/priority_minor.gif">Minor</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="fogus">Fogus</assignee>
                                <reporter username="fogus">Fogus</reporter>
                        <labels>
                        <label>data-structures</label>
                        <label>queue</label>
                        <label>reader</label>
                        <label>tagged-literals</label>
                    </labels>
                <created>Fri, 27 Apr 2012 09:31:36 -0500</created>
                <updated>Sat, 6 Apr 2013 08:07:20 -0500</updated>
                                    <version>Release 1.5</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>4</watches>
                        <comments>
                    <comment id="28290" author="steveminer@gmail.com" created="Fri, 27 Apr 2012 10:18:19 -0500"  >&lt;p&gt;I think the non-eval behavior would be consistent with the other reader literals in Clojure 1.4.  It&apos;s definitely better for interop where some other language implementation could be expected to handle a few literal representations, but not the evaluation of Clojure expressions.  Use a regular function if the args need evaluation.&lt;/p&gt;</comment>
                    <comment id="28291" author="cemerick" created="Fri, 27 Apr 2012 10:19:50 -0500"  >&lt;p&gt;The precedent of records seems relevant:&lt;/p&gt;

&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;=&amp;gt; (defrecord A [b])
user.A
=&amp;gt; #user.A[(+ 4 5)]
#user.A{:b (+ 4 5)}
=&amp;gt; #user.A{:b (+ 4 5)}
#user.A{:b (+ 4 5)}&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;This continues to make sense, as otherwise queues would need to print with an extra &lt;tt&gt;(quote &#8230;)&lt;/tt&gt; form around lists &#8212; which records neatly avoid:&lt;/p&gt;

&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;=&amp;gt; (A. &apos;(+ 4 5))
#user.A{:b (+ 4 5)}&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;Does this mean that a &lt;tt&gt;queue&lt;/tt&gt; fn (analogous to &lt;tt&gt;vector&lt;/tt&gt;, maybe) will also make an appearance?  It&apos;d be handy for HOF usage.&lt;/p&gt;</comment>
                    <comment id="28293" author="fogus" created="Fri, 27 Apr 2012 11:00:12 -0500"  >&lt;p&gt;Added a patch for the tagged literal support ONLY. This is only one part of the total solution. This provides the read-string and printing capability. I&apos;d like more discussion around the eval side before I get dive into the compiler.&lt;/p&gt;</comment>
                    <comment id="28298" author="pmbauer" created="Fri, 27 Apr 2012 18:45:48 -0500"  >&lt;p&gt;In addition to Chas&apos; observations on consistency with record literals, would eval in queue literals open up the same security hole as #=, needing to respect *&lt;b&gt;read-eval&lt;/b&gt;*?&lt;br/&gt;
When needing eval inside a queue literal, embedding a #= seems more apropos.&lt;/p&gt;</comment>
                    <comment id="28385" author="fogus" created="Fri, 4 May 2012 13:14:29 -0500"  >&lt;p&gt;Evalable queue literal support.&lt;/p&gt;</comment>
                    <comment id="28430" author="jafingerhut" created="Thu, 10 May 2012 17:54:13 -0500"  >&lt;p&gt;Neither of the patches &lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-976&quot; title=&quot;Implement reader literal and print support for PersistentQueue data structure&quot;&gt;CLJ-976&lt;/a&gt;-queue-literal-tagged-parse-support-only.diff dated Apr 27, 2012 nor &lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-976&quot; title=&quot;Implement reader literal and print support for PersistentQueue data structure&quot;&gt;CLJ-976&lt;/a&gt;-queue-literal-eval.diff dated May 4, 2012 apply cleanly to latest master as of May 10, 2012.&lt;/p&gt;</comment>
                    <comment id="28454" author="fogus" created="Fri, 11 May 2012 10:15:35 -0500"  >&lt;p&gt;Updated patch file to merge with latest master.&lt;/p&gt;</comment>
                    <comment id="29008" author="fogus" created="Fri, 20 Jul 2012 13:14:37 -0500"  >&lt;p&gt;New patch with support fixed for syntax-quote.&lt;/p&gt;</comment>
                    <comment id="29212" author="stuart.sierra" created="Fri, 17 Aug 2012 12:41:10 -0500"  >&lt;p&gt;Patch does not apply as of commit f5f4faf95051f794c9bfa0315e4457b600c84cef&lt;/p&gt;</comment>
                    <comment id="29214" author="fogus" created="Fri, 17 Aug 2012 15:06:18 -0500"  >&lt;p&gt;Weird. I was able to download the &lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-976&quot; title=&quot;Implement reader literal and print support for PersistentQueue data structure&quot;&gt;CLJ-976&lt;/a&gt;-queue-literal-eval-and-synquote.diff patch and apply it to HEAD as of just now (f5f4faf95051f794c9bfa0315e4457b600c84cef). There were whitespace warnings, but the patch applied, compiles and passes all tests.&lt;/p&gt;
</comment>
                    <comment id="29217" author="jafingerhut" created="Fri, 17 Aug 2012 19:29:01 -0500"  >&lt;p&gt;With latest head I was able to successfully apply patch &lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-976&quot; title=&quot;Implement reader literal and print support for PersistentQueue data structure&quot;&gt;CLJ-976&lt;/a&gt;-queue-literal-eval-and-synquote.diff with this command:&lt;/p&gt;

&lt;p&gt;git am --keep-cr -s &amp;lt; &lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-976&quot; title=&quot;Implement reader literal and print support for PersistentQueue data structure&quot;&gt;CLJ-976&lt;/a&gt;-queue-literal-eval-and-synquote.diff&lt;/p&gt;

&lt;p&gt;with some warnings, but successfully applied.  If I try it without the --keep-cr option, the patch fails to apply.  I believe this is often a sign that either one of the files being patched, or the patch itself, contains CR/LF line endings, which some of the Clojure source files definitely do.&lt;/p&gt;

&lt;p&gt;The command above (with --keep-cr) is currently the one recommended for applying patches on page &lt;a href=&quot;http://dev.clojure.org/display/design/JIRA+workflow&quot;&gt;http://dev.clojure.org/display/design/JIRA+workflow&lt;/a&gt; in section &quot;Screening Tickets&quot;.  I added the suggested --keep-cr option after running across another patch that applied with the option, but not without it.&lt;/p&gt;
</comment>
                    <comment id="29281" author="jafingerhut" created="Tue, 28 Aug 2012 17:45:26 -0500"  >&lt;p&gt;Presumptuously changing Approval from Incomplete back to Test, since the latest patch does apply cleanly if --keep-cr option is used.&lt;/p&gt;</comment>
                    <comment id="29408" author="richhickey" created="Sat, 8 Sep 2012 06:48:32 -0500"  >&lt;p&gt;this needs more time&lt;/p&gt;</comment>
                    <comment id="29480" author="fogus" created="Tue, 18 Sep 2012 08:15:58 -0500"  >&lt;p&gt;Rich, &lt;/p&gt;

&lt;p&gt;Do you mind providing a little more detail?  I would be happy to make any changes if needed. However, if it&apos;s just a matter of its relationship to EDN and/or waiting until the next release then I am happy to wait.  In either case, I&apos;d like to complete this or push it to the back of my mind. Thanks.&lt;/p&gt;</comment>
                    <comment id="29602" author="jafingerhut" created="Fri, 5 Oct 2012 07:49:12 -0500"  >&lt;p&gt;clj-976-queue-literal-eval-and-synquote-patch-v2.txt dated Oct 5 2012 is identical to Fogus&apos;s patch &lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-976&quot; title=&quot;Implement reader literal and print support for PersistentQueue data structure&quot;&gt;CLJ-976&lt;/a&gt;-queue-literal-eval-and-synquote.diff dated Jul 20 2012.  It simply removes one line addition to clojure.iml that Rich has since added in a different commit, so that this patch now applies cleanly to latest master.&lt;/p&gt;</comment>
                    <comment id="29665" author="jafingerhut" created="Tue, 16 Oct 2012 12:20:27 -0500"  >&lt;p&gt;clj-976-queue-literal-eval-and-synquote-patch-v3.txt dated oct 16 2012 is identical to Fogus&apos;s patch &lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-976&quot; title=&quot;Implement reader literal and print support for PersistentQueue data structure&quot;&gt;CLJ-976&lt;/a&gt;-queue-literal-eval-and-synquote.diff dated Jul 20 2012. It simply removes one line addition to clojure.iml that Rich has since added in a different commit, so that this patch now applies cleanly to latest master.&lt;/p&gt;</comment>
                    <comment id="29730" author="jafingerhut" created="Sat, 20 Oct 2012 12:26:05 -0500"  >&lt;p&gt;Fogus, with the recent commit of a patch for &lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-1070&quot; title=&quot;PersistentQueue&amp;#39;s hash function does not match its equality&quot;&gt;&lt;del&gt;CLJ-1070&lt;/del&gt;&lt;/a&gt;, my touched-up patch clj-976-queue-literal-eval-and-synquote-patch-v3.txt dated Oct 16 2012 doesn&apos;t apply cleanly.  In this case it isn&apos;t simply a few lines of context that have changed, it is the interfaces that PersistentQueue implements have been changed.  It might be best if you take a look at the latest code and the patch and consider how it should be updated.&lt;/p&gt;</comment>
                    <comment id="30884" author="steveminer@gmail.com" created="Sat, 6 Apr 2013 08:07:20 -0500"  >&lt;p&gt;Related to &lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-1078&quot; title=&quot;Added queue, queue* and queue? to clojure.core&quot;&gt;CLJ-1078&lt;/a&gt;.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="11392" name="CLJ-976-queue-literal-eval-and-synquote.diff" size="15932" author="fogus" created="Fri, 20 Jul 2012 13:14:37 -0500" />
                    <attachment id="11566" name="clj-976-queue-literal-eval-and-synquote-patch-v3.txt" size="15688" author="jafingerhut" created="Tue, 16 Oct 2012 12:20:26 -0500" />
                    <attachment id="11200" name="CLJ-976-queue-literal-eval.diff" size="13229" author="fogus" created="Fri, 11 May 2012 10:15:35 -0500" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_10002" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Approval</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10013">Test</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                    <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10000" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Patch</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10002">Code and Test</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[CLJ-1053] Locals still cleared too aggressively on delay in specific cases</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1053</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;This seems to be an extension of &lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-232&quot;&gt;#CLJ-232&lt;/a&gt;. Locals are still cleared too aggressively in some specific instances: If the delay throws an exception when realized, and you dereference a local within the delay, the local may or may not be cleared depending on its need in the tail positions (without any obvious pattern). Examples of functions which works as intended and doesn&apos;t work as intended follows.&lt;/p&gt;

&lt;div class=&quot;preformatted panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;preformattedContent panelContent&quot;&gt;
&lt;pre&gt;(def d (let [y (delay 0)]
         (delay (if (zero? @y) (/ 0 0) (/ @y 1))))) ; works properly

(def d (let [y (delay 0)]
         (delay (if (zero? @y) (/ 0 0) (/ 1 1))))) ; does not work properly

(def d (let [y (delay 0)]
         (delay (if (zero? @y) (/ @y 0) (/ 1 1))))) ; does not work properly

(def d (let [y (delay 0)]
         (delay (if (zero? @y) (/ @y 0) (/ @y 1))))) ; does not work properly

(def d (let [y (delay 0)]
         (delay @y (/ 0 0)))) ; does not work properly

(def d (let [y (delay 0)]
         (delay @y (/ 0 0) @y))) ; works properly
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;
&lt;p&gt;By &quot;works&quot;, &lt;tt&gt;d&lt;/tt&gt; will throw &quot;ArithmeticException Divide by zero&quot; every single time it is dereferenced. By &quot;does not work&quot;, &lt;tt&gt;d&lt;/tt&gt; will throw &quot;ArithmeticException Divide by zero&quot; on first dereferencing, but from second and onwards it will throw &quot;NullPointerException   &lt;span class=&quot;error&quot;&gt;&amp;#91;trace missing&amp;#93;&lt;/span&gt;&quot;.&lt;/p&gt;</description>
                <environment></environment>
            <key id="15657">CLJ-1053</key>
            <summary>Locals still cleared too aggressively on delay in specific cases</summary>
                <type id="1" iconUrl="http://dev.clojure.org/jira/images/icons/bug.gif">Defect</type>
                                <priority id="4" iconUrl="http://dev.clojure.org/jira/images/icons/priority_minor.gif">Minor</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="hypirion">Jean Niklas L&apos;orange</reporter>
                        <labels>
                    </labels>
                <created>Thu, 30 Aug 2012 17:25:56 -0500</created>
                <updated>Tue, 9 Apr 2013 11:55:52 -0500</updated>
                                    <version>Release 1.4</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>4</watches>
                        <comments>
                    <comment id="30919" author="hypirion" created="Tue, 9 Apr 2013 11:55:52 -0500"  >&lt;p&gt;With Clojure 1.5.1, the trace is given and returns &lt;tt&gt;NullPointerException   clojure.core/deref-future (core.clj:2NullPointerException   clojure.core/deref-future (core.clj:2108)108)&lt;/tt&gt;, which refers to a &lt;a href=&quot;https://github.com/clojure/clojure/blob/clojure-1.5.1/src/clj/clojure/core.clj#L2108&quot;&gt;&lt;tt&gt;.get&lt;/tt&gt; call&lt;/a&gt;. The stacktrace reveals the following:&lt;/p&gt;

&lt;div class=&quot;preformatted panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;preformattedContent panelContent&quot;&gt;
&lt;pre&gt;NullPointerException 
	clojure.core/deref-future (core.clj:2108)
	clojure.core/deref (core.clj:2129)
	user/fn--1/fn--4 (NO_SOURCE_FILE:2)
	clojure.lang.Delay.deref (Delay.java:33)
	clojure.core/deref (core.clj:2128)
	user/eval13 (NO_SOURCE_FILE:-1)
	clojure.lang.Compiler.eval (Compiler.java:6619)
	clojure.lang.Compiler.eval (Compiler.java:6582)
	clojure.core/eval (core.clj:2852)
	clojure.main/repl/read-eval-print--6588/fn--6591 (main.clj:259)
	clojure.main/repl/read-eval-print--6588 (main.clj:259)
	clojure.main/repl/fn--6597 (main.clj:277)
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                                                                                            </customfields>
    </item>

<item>
            <title>[CLJ-1195] emit-hinted-impl expands to non-ns-qualified invocation of &apos;fn&apos;</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1195</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;(ns plumbing.tmp&lt;br/&gt;
  (:refer-clojure :exclude &lt;span class=&quot;error&quot;&gt;&amp;#91;fn&amp;#93;&lt;/span&gt;))&lt;/p&gt;

&lt;p&gt;(defprotocol Foo&lt;br/&gt;
  (foo &lt;span class=&quot;error&quot;&gt;&amp;#91;this&amp;#93;&lt;/span&gt;))&lt;/p&gt;

&lt;p&gt;(extend-protocol Foo&lt;br/&gt;
  Object&lt;br/&gt;
  (foo &lt;span class=&quot;error&quot;&gt;&amp;#91;this&amp;#93;&lt;/span&gt;))&lt;/p&gt;

&lt;p&gt;yields &lt;/p&gt;

&lt;p&gt;CompilerException java.lang.RuntimeException: Unable to resolve symbol: fn in this context, compiling&lt;img class=&quot;emoticon&quot; src=&quot;http://dev.clojure.org/jira/images/icons/emoticons/sad.gif&quot; height=&quot;20&quot; width=&quot;20&quot; align=&quot;absmiddle&quot; alt=&quot;&quot; border=&quot;0&quot;/&gt;/Users/w01fe/prismatic/prismatic/plumbing/src/plumbing/tmp.clj:7:1)&lt;/p&gt;

&lt;p&gt;This makes it difficult to construct a namespace that provides a replacement def for fn.&lt;/p&gt;</description>
                <environment>Mac os X Clojure 1.5.1</environment>
            <key id="16134">CLJ-1195</key>
            <summary>emit-hinted-impl expands to non-ns-qualified invocation of &apos;fn&apos;</summary>
                <type id="1" iconUrl="http://dev.clojure.org/jira/images/icons/bug.gif">Defect</type>
                                <priority id="4" iconUrl="http://dev.clojure.org/jira/images/icons/priority_minor.gif">Minor</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="jawolfe">Jason Wolfe</reporter>
                        <labels>
                    </labels>
                <created>Tue, 9 Apr 2013 22:23:47 -0500</created>
                <updated>Tue, 9 Apr 2013 22:23:47 -0500</updated>
                                    <version>Release 1.5</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                                                                                            </customfields>
    </item>

<item>
            <title>[CLJ-1185] `reductions should respect `reduced</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1185</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;This returns 16:&lt;/p&gt;

&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;(reduce (fn [acc x]
          (let [x&apos; (* x x)]
            (&lt;span class=&quot;code-keyword&quot;&gt;if&lt;/span&gt; (&amp;gt; x&apos; 10)
              (reduced x&apos;)
              x&apos;)))
        (range))&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;But replacing `reduce with `reductions will never terminate:&lt;/p&gt;

&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;(reductions (fn [acc x]
              (let [x&apos; (* x x)]
                (&lt;span class=&quot;code-keyword&quot;&gt;if&lt;/span&gt; (&amp;gt; x&apos; 10)
                  (reduced x&apos;)
                  x&apos;)))
            (range))&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;This is because `reductions ignores &apos;clojure.lang.Reduced, it never tests for `reduced?&lt;/p&gt;

&lt;p&gt;I know that I only just discovered the `reduced, function, but `reductions is a big part of my debugging process, so it&apos;s unfortunate that they don&apos;t work together.&lt;/p&gt;</description>
                <environment></environment>
            <key id="16094">CLJ-1185</key>
            <summary>`reductions should respect `reduced</summary>
                <type id="4" iconUrl="http://dev.clojure.org/jira/images/icons/improvement.gif">Enhancement</type>
                                <priority id="4" iconUrl="http://dev.clojure.org/jira/images/icons/priority_minor.gif">Minor</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="bbloom">Brandon Bloom</reporter>
                        <labels>
                    </labels>
                <created>Sat, 16 Mar 2013 18:09:34 -0500</created>
                <updated>Wed, 10 Apr 2013 17:08:45 -0500</updated>
                                                                            <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                        <comments>
                    <comment id="30775" author="bbloom" created="Sat, 16 Mar 2013 18:10:44 -0500"  >&lt;p&gt;Attaching patch&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="11921" name="CLJ-1181-v001.patch" size="1024" author="bbloom" created="Sat, 16 Mar 2013 18:10:44 -0500" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10000" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Patch</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10001">Code</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[CLJ-823] Piping seque into seque can deadlock</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-823</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;I&apos;m not sure if this is a supported scenario, but the following deadlocks in Clojure 1.3:&lt;/p&gt;

&lt;p&gt;&lt;tt&gt;(let [xs (seque (range 150000))&lt;/tt&gt;&lt;br/&gt;
&lt;tt&gt;ys (seque (filter odd? xs))]&lt;/tt&gt;&lt;br/&gt;
&lt;tt&gt;(apply + ys))&lt;/tt&gt;&lt;/p&gt;

&lt;p&gt;As I understand it, the problem is that ys&apos; fill takes place on an agent thread, so when it calls xs&apos; drain, the &lt;tt&gt;(send-off agt fill)&lt;/tt&gt; does not immediately trigger xs&apos; fill, but is instead put on the nested list to be performed when ys&apos; agent returns. Unfortunately, ys&apos; fill will eventually block trying to take from xs, and so it never returns and the pending send-offs are never sent. Wrapping the send-off in drain to:&lt;/p&gt;

&lt;p&gt;&lt;tt&gt;(future (send-off agt fill))&lt;/tt&gt;&lt;/p&gt;

&lt;p&gt;is a simple (probably not optimal) way to fix the deadlock.&lt;/p&gt;</description>
                <environment>Windows 7; JVM 1.6; Clojure 1.3 beta 1</environment>
            <key id="14557">CLJ-823</key>
            <summary>Piping seque into seque can deadlock</summary>
                <type id="1" iconUrl="http://dev.clojure.org/jira/images/icons/bug.gif">Defect</type>
                                <priority id="4" iconUrl="http://dev.clojure.org/jira/images/icons/priority_minor.gif">Minor</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="glchapman">Greg Chapman</reporter>
                        <labels>
                    </labels>
                <created>Wed, 3 Aug 2011 13:28:22 -0500</created>
                <updated>Fri, 12 Apr 2013 09:23:49 -0500</updated>
                                    <version>Release 1.3</version>
                                                        <due></due>
                    <votes>1</votes>
                        <watches>2</watches>
                        <comments>
                    <comment id="30401" author="pmonks" created="Mon, 7 Jan 2013 15:43:29 -0600"  >&lt;p&gt;Reproduced on 1.4.0 and 1.5.0-RC1 as well, albeit with this example:&lt;/p&gt;

&lt;p&gt;(seque 3 (seque 3 (range 10)))&lt;/p&gt;</comment>
                    <comment id="30852" author="stu" created="Sat, 30 Mar 2013 09:16:33 -0500"  >&lt;p&gt;release-pending-sends?&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_10002" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Approval</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10003">Vetted</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                    <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                                                                                            </customfields>
    </item>

<item>
            <title>[CLJ-1198] Apply metadata to primitive fns causes them to lose their primitive-ness</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1198</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;user&amp;gt; (def f (fn &lt;span class=&quot;error&quot;&gt;&amp;#91;^long x&amp;#93;&lt;/span&gt; x))&lt;br/&gt;
#&apos;user/f&lt;br/&gt;
user&amp;gt; (.invokePrim (with-meta f {}) 1)&lt;br/&gt;
IllegalArgumentException No matching method found: invokePrim for class clojure.lang.AFunction$1  clojure.lang.Reflector.invokeMatchingMethod (Reflector.java:53)&lt;br/&gt;
user&amp;gt; (contains? (ancestors (class f)) clojure.lang.IFn$LO)&lt;br/&gt;
true&lt;br/&gt;
user&amp;gt; (contains? (ancestors (class (with-meta f {}))) clojure.lang.IFn$LO)&lt;br/&gt;
false&lt;/p&gt;

&lt;p&gt;We&apos;re working on libraries that use metadata on functions to track information about their arguments (schemata, etc), and this currently blocks us from fully supporting primitive fns. &lt;/p&gt;</description>
                <environment></environment>
            <key id="16138">CLJ-1198</key>
            <summary>Apply metadata to primitive fns causes them to lose their primitive-ness</summary>
                <type id="1" iconUrl="http://dev.clojure.org/jira/images/icons/bug.gif">Defect</type>
                                <priority id="4" iconUrl="http://dev.clojure.org/jira/images/icons/priority_minor.gif">Minor</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="jawolfe">Jason Wolfe</reporter>
                        <labels>
                    </labels>
                <created>Sat, 13 Apr 2013 00:27:45 -0500</created>
                <updated>Sat, 13 Apr 2013 00:27:45 -0500</updated>
                                    <version>Release 1.5</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                                                                                            </customfields>
    </item>

<item>
            <title>[CLJ-1199] Record values are not &apos;eval&apos;uated, unlike values of PersistentMap:</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1199</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;I&apos;m not sure if this is by design, but it caught me off guard.  &lt;/p&gt;

&lt;p&gt;user&amp;gt; (defrecord A &lt;span class=&quot;error&quot;&gt;&amp;#91;x&amp;#93;&lt;/span&gt;)&lt;br/&gt;
user.A&lt;/p&gt;

&lt;p&gt;user&amp;gt; (eval (hash-map :x `long))&lt;br/&gt;
{:x #&amp;lt;core$long clojure.core$long@5de54eb7&amp;gt;}&lt;br/&gt;
user&amp;gt; (eval (-&amp;gt;A `long))&lt;br/&gt;
#user.A{:x clojure.core/long}&lt;br/&gt;
user&amp;gt; (eval (map-&amp;gt;A (hash-map :x `long)))&lt;br/&gt;
#user.A{:x clojure.core/long}&lt;/p&gt;

&lt;p&gt;and in case it matters, here&apos;s a simplified version of the real use case where this came up, with no eval &amp;#8211; just a macro:&lt;/p&gt;

&lt;p&gt;user&amp;gt; (defmacro munge-meta1 &lt;span class=&quot;error&quot;&gt;&amp;#91;x&amp;#93;&lt;/span&gt; (assoc x :schema (-&amp;gt;A (:schema (meta x)))))&lt;br/&gt;
#&apos;user/munge-meta1&lt;br/&gt;
user&amp;gt; (munge-meta1 ^{:schema long} {})&lt;br/&gt;
{:schema #user.A{:x long}}&lt;/p&gt;

&lt;p&gt;user&amp;gt; (defmacro munge-meta2 &lt;span class=&quot;error&quot;&gt;&amp;#91;x&amp;#93;&lt;/span&gt; (assoc x :schema (hash-map :x (:schema (meta x)))))&lt;br/&gt;
#&apos;user/munge-meta2&lt;br/&gt;
user&amp;gt; (munge-meta2 ^{:schema long} {})&lt;br/&gt;
{:schema {:x #&amp;lt;core$long clojure.core$long@5de54eb7&amp;gt;}}&lt;/p&gt;

&lt;p&gt;This seems to be fixed by moving the record creation post-evaluation, so it&apos;s not a big deal, just surprising (plus I haven&apos;t yet convinced myself that this will always work if the user&apos;s schema itself contains record-creating forms, although it seems to work OK):&lt;/p&gt;

&lt;p&gt;user&amp;gt; (defmacro munge-meta1 &lt;span class=&quot;error&quot;&gt;&amp;#91;x&amp;#93;&lt;/span&gt; (assoc x :schema `(-&amp;gt;A ~(:schema (meta x)))))&lt;br/&gt;
#&apos;user/munge-meta1&lt;br/&gt;
user&amp;gt; (munge-meta1 ^{:schema long} {})&lt;br/&gt;
{:schema #user.A{:x #&amp;lt;core$long clojure.core$long@5de54eb7&amp;gt;}}&lt;/p&gt;

&lt;p&gt;I brought this up on the mailing list here:&lt;/p&gt;

&lt;p&gt;&lt;a href=&quot;https://groups.google.com/forum/?fromgroups=#!topic/clojure-dev/UgD35E1RQTo&quot;&gt;https://groups.google.com/forum/?fromgroups=#!topic/clojure-dev/UgD35E1RQTo&lt;/a&gt;&lt;/p&gt;</description>
                <environment></environment>
            <key id="16139">CLJ-1199</key>
            <summary>Record values are not &apos;eval&apos;uated, unlike values of PersistentMap:</summary>
                <type id="1" iconUrl="http://dev.clojure.org/jira/images/icons/bug.gif">Defect</type>
                                <priority id="4" iconUrl="http://dev.clojure.org/jira/images/icons/priority_minor.gif">Minor</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="jawolfe">Jason Wolfe</reporter>
                        <labels>
                    </labels>
                <created>Sat, 13 Apr 2013 00:29:58 -0500</created>
                <updated>Sat, 13 Apr 2013 00:29:58 -0500</updated>
                                    <version>Release 1.5</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                                                                                            </customfields>
    </item>

<item>
            <title>[CLJ-1182] Regexp are never equal</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1182</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;The following (= #&quot;asd&quot; #&quot;asd&quot;) will return false in CLJ, even if they are the same.&lt;/p&gt;

&lt;p&gt;Consequently, everything with a regexp in it (lists, vectors, maps...) will never be equal.&lt;/p&gt;

&lt;p&gt;It seems to have been fixed for CLJS, but not for CLJ.&lt;br/&gt;
&lt;a href=&quot;https://github.com/clojure/clojurescript/commit/e35c3a57472fa62ae41591418a73794dc8ac6dde&quot;&gt;https://github.com/clojure/clojurescript/commit/e35c3a57472fa62ae41591418a73794dc8ac6dde&lt;/a&gt;&lt;/p&gt;</description>
                <environment></environment>
            <key id="16083">CLJ-1182</key>
            <summary>Regexp are never equal</summary>
                <type id="4" iconUrl="http://dev.clojure.org/jira/images/icons/improvement.gif">Enhancement</type>
                                <priority id="4" iconUrl="http://dev.clojure.org/jira/images/icons/priority_minor.gif">Minor</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="olenhad">Omer Iqbal</assignee>
                                <reporter username="frozenlock">Christian Fortin</reporter>
                        <labels>
                        <label>bug</label>
                    </labels>
                <created>Tue, 12 Mar 2013 13:28:59 -0500</created>
                <updated>Sat, 13 Apr 2013 21:13:52 -0500</updated>
                                    <version>Release 1.5</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>3</watches>
                        <comments>
                    <comment id="30746" author="olenhad" created="Tue, 12 Mar 2013 16:08:55 -0500"  >&lt;p&gt;added an implementation for the equiv method if both args are java.util.regex.Pattern&lt;/p&gt;</comment>
                    <comment id="30749" author="jafingerhut" created="Tue, 12 Mar 2013 17:54:40 -0500"  >&lt;p&gt;Omer, could you also include in your patch a few test cases?  At least one that validates that two regex&apos;s that should be equal, are equal, and another that two regex&apos;s that should be different, are non-equal.  Preferably the first of those tests should fail with the existing Clojure code, and pass with your changes.&lt;/p&gt;</comment>
                    <comment id="30754" author="olenhad" created="Wed, 13 Mar 2013 05:39:13 -0500"  >&lt;p&gt;I updated the patch with some tests. Hope I added them in the correct file. I also changed the implementation a bit, by instead of adding another implementation of equiv with a different signature, checking the type of the Object in the equiv method with signature (Object k1, Object k2).&lt;br/&gt;
For the sake of consistency I also added an EquivPred implementation, though I&apos;m not entirely sure when its used.&lt;/p&gt;</comment>
                    <comment id="30757" author="jafingerhut" created="Wed, 13 Mar 2013 13:04:58 -0500"  >&lt;p&gt;All comments here refer to the patch named fix-&lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-1182&quot; title=&quot;Regexp are never equal&quot;&gt;CLJ-1182&lt;/a&gt;.diff dated Mar 13, 2013.&lt;/p&gt;

&lt;p&gt;The location for the new tests looks reasonable.  However, note that your new patch has your old changes plus some new ones, not just the new ones.  In particular, the new signature for equiv is still in your latest patch.  You should start from a clean pull of the latest Clojure master and make only the changes you want when creating a patch, not build on top of previous changes you have made.&lt;/p&gt;

&lt;p&gt;Also, there are several whitespace-only changes in your patch that should not be included.&lt;/p&gt;</comment>
                    <comment id="30758" author="olenhad" created="Wed, 13 Mar 2013 13:39:09 -0500"  >&lt;p&gt;I uploaded a clean patch, removing the whitespace diff and only adding the latest changes. Thanks for clarifying the workflow!&lt;br/&gt;
Just to clarify, this refers to the patch named fix-&lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-1182&quot; title=&quot;Regexp are never equal&quot;&gt;CLJ-1182&lt;/a&gt;.diff dated Mar 13 1:34 PM&lt;/p&gt;</comment>
                    <comment id="30835" author="stu" created="Fri, 29 Mar 2013 05:46:25 -0500"  >&lt;p&gt;I am recategorizing this as an enhancement, because if this is a bug it is a bug in Java &amp;#8211; the Java Patterns class documents being immutable, but apparently does not implement .equals.&lt;/p&gt;

&lt;p&gt;Other recent &quot;make Clojure more complicated to work around problems in Java&quot; patches have been rejected, and I suspect this one will be too, because it might impact the performance of equality everywhere.&lt;/p&gt;</comment>
                    <comment id="30940" author="stu" created="Fri, 12 Apr 2013 09:04:57 -0500"  >&lt;p&gt;At first pass, Rich and I both believe that, as regex equality is undecidable, that Java made the right choice in using identity for equality, that this ticket should be declined, and the ClojureScript should revert to match.&lt;/p&gt;

&lt;p&gt;But leaving this ticket open for now so that ClojureScript dev can weigh in.&lt;/p&gt;</comment>
                    <comment id="30941" author="michael-drogalis" created="Fri, 12 Apr 2013 09:32:14 -0500"  >&lt;p&gt;What do you mean when you say &quot;undecidable&quot;?&lt;/p&gt;</comment>
                    <comment id="30942" author="aredington" created="Fri, 12 Apr 2013 10:03:45 -0500"  >&lt;p&gt;If Regex instances were interned by the reader, but still used identity for equality, then code like&lt;/p&gt;

&lt;p&gt;(= #&quot;abc&quot; #&quot;abc&quot;)&lt;/p&gt;

&lt;p&gt;would return true, but it wouldn&apos;t diverge in the definition of equality for regular expressions between Java and Clojure.&lt;/p&gt;</comment>
                    <comment id="30943" author="fogus" created="Fri, 12 Apr 2013 10:13:02 -0500"  >&lt;p&gt;Undecidable means that for any given regular expression, there is no single way to write it.  For example #&quot;&lt;span class=&quot;error&quot;&gt;&amp;#91;a&amp;#93;&lt;/span&gt;&quot; #&quot;a&quot; both match the same strings, but are they the same?  Maybe.  But how can we decide if /any/ given regular expression matches all of the same strings as any other?  The answer is, you can&apos;t.  Java does provide a Pattern#pattern method that returns the string that was used to build it, but I&apos;m not sure if that could/should be used as a basis for equality given the potential perf hit.&lt;/p&gt;</comment>
                    <comment id="30944" author="bendlas" created="Fri, 12 Apr 2013 10:31:54 -0500"  >&lt;p&gt;I posted in Stu&apos;s thread: &lt;a href=&quot;https://groups.google.com/d/topic/clojure-dev/OTPNJQbPtds/discussion&quot;&gt;https://groups.google.com/d/topic/clojure-dev/OTPNJQbPtds/discussion&lt;/a&gt;&lt;br/&gt;
TL;DR: Disagree with undecidability, agree with reverting to identity based equality&lt;/p&gt;</comment>
                    <comment id="30945" author="michael-drogalis" created="Fri, 12 Apr 2013 10:32:49 -0500"  >&lt;p&gt;That makes sense to me. Thanks Fogus.&lt;/p&gt;</comment>
                    <comment id="30947" author="bendlas" created="Fri, 12 Apr 2013 21:42:19 -0500"  >&lt;p&gt;From my post to the ml thread, it might not be entirely clear, why I don&apos;t think we should implement equality for host regexes:&lt;/p&gt;

&lt;p&gt;It would involve parsing and would leave a lot of room for errors and platform-idiosycracies to leak. And it would be different for every platform.&lt;/p&gt;

&lt;p&gt;As Alexander said, I also think this ticket could be resolved by interning regex literals, akin to keywords. That, however, would warrant a design page first, because there are tradeoffs to be made about how far the interning should go.&lt;/p&gt;</comment>
                    <comment id="30948" author="richhickey" created="Sat, 13 Apr 2013 08:51:17 -0500"  >&lt;p&gt;Why are we spending time on this? Where is the problem statement? Does someone actually need this for a real world purpose not solved by using regex strings as keys?&lt;/p&gt;</comment>
                    <comment id="30957" author="michael-drogalis" created="Sat, 13 Apr 2013 21:13:52 -0500"  >&lt;p&gt;It was prompted as a matter of consistency, which I think is valid. I can&apos;t think of a good reason to use regex&apos;s as keys though.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="11913" name="fix-CLJ-1182.diff" size="2628" author="olenhad" created="Wed, 13 Mar 2013 13:34:11 -0500" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_10002" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Approval</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10120">Triaged</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                    <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10000" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Patch</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10001">Code</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[CLJ-1074] Read/print round-trip for +/-Infinity and NaN</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1074</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;A few float-related forms (namely, Double/POSITIVE_INFINITY, Double/NEGATIVE_INFINITY, Double/NaN) are not eval-able after a round-trip via &lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;(read-string (binding [*print-dup* &lt;span class=&quot;code-keyword&quot;&gt;true&lt;/span&gt;] (pr-str f))&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;&lt;/p&gt;

&lt;p&gt;The two options I see are to provide print-method implementations for these and their Float cousins, or to make Infinity, -Infinity, +Infinity, and NaN readable values. Since it sounds like edn may want to provide a spec for these values (see  &lt;a href=&quot;https://groups.google.com/d/topic/clojure-dev/LeJpOhHxESs/discussion&quot;&gt;https://groups.google.com/d/topic/clojure-dev/LeJpOhHxESs/discussion&lt;/a&gt; and &lt;a href=&quot;https://github.com/edn-format/edn/issues/2&quot;&gt;https://github.com/edn-format/edn/issues/2&lt;/a&gt;), I think making these values directly readable as already printed is preferable. Something like Double/POSITIVE_INFINITY seems too low-level from edn&apos;s perspective, as it would refer to a Java class and constant.&lt;/p&gt;

&lt;p&gt;I&apos;m attaching a patch implementing reader support for Infinity, -Infinity, +Infinity, and NaN.&lt;/p&gt;</description>
                <environment></environment>
            <key id="15714">CLJ-1074</key>
            <summary>Read/print round-trip for +/-Infinity and NaN</summary>
                <type id="1" iconUrl="http://dev.clojure.org/jira/images/icons/bug.gif">Defect</type>
                                <priority id="4" iconUrl="http://dev.clojure.org/jira/images/icons/priority_minor.gif">Minor</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="trptcolin">Colin Jones</reporter>
                        <labels>
                        <label>patch</label>
                    </labels>
                <created>Fri, 21 Sep 2012 19:13:48 -0500</created>
                <updated>Mon, 3 Dec 2012 13:18:40 -0600</updated>
                                    <version>Release 1.4</version>
                                                        <due></due>
                    <votes>2</votes>
                        <watches>1</watches>
                        <comments>
                    <comment id="30167" author="halgari" created="Mon, 3 Dec 2012 11:34:16 -0600"  >&lt;p&gt;Please bring this up on clojure-dev. We&apos;ll be able to vet this ticket after that. &lt;/p&gt;
</comment>
                    <comment id="30168" author="trptcolin" created="Mon, 3 Dec 2012 13:18:40 -0600"  >&lt;p&gt;Should I respond to my original clojure-dev post about this (linked in the issue description above), or start a new one?&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="11520" name="0001-Read-Infinity-and-NaN.patch" size="1544" author="trptcolin" created="Fri, 21 Sep 2012 19:13:48 -0500" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10000" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Patch</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10002">Code and Test</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[CLJ-1200] RestFn &amp; ArraySeq performance</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1200</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;I was profiling one of my projects and noticed a hotspot inside functions using rest arguments.&lt;/p&gt;

&lt;p&gt;Most overloads of RestFn.invoke will construct an ArraySeq object. The ArraySeq constructor calls java.lang.Class.getComponentType, which seems to be pretty slow. The array&apos;s component type is cached in a field on the ArraySeq object for the sole purpose of passing it to Reflector.prepRet. I&apos;m not entirely sure of the total utility of prepRet, but it&apos;s clearly a no-op when passed Object.class, such as the case with the non-specialized base class of ArraySeq: the component type of object[] is Object.class.&lt;/p&gt;

&lt;p&gt;The attached patch eliminates the component type field from ArraySeq and passes Object.class to prepRet directly. It may be possible to eliminate calls to prepRet all together, but I&apos;ll assume that&apos;s a different ticket. With this patch, ArraySeq initialization no longer shows up as a hotspot when profiling.&lt;/p&gt;

&lt;p&gt;Before the patch:&lt;/p&gt;

&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;user=&amp;gt; (dotimes [n 10] (time (dotimes [i 5000000] ((fn [&amp;amp; args]) 1 2 3 4))))
&lt;span class=&quot;code-quote&quot;&gt;&quot;Elapsed time: 874.742 msecs&quot;&lt;/span&gt;
&lt;span class=&quot;code-quote&quot;&gt;&quot;Elapsed time: 900.277 msecs&quot;&lt;/span&gt;
&lt;span class=&quot;code-quote&quot;&gt;&quot;Elapsed time: 911.164 msecs&quot;&lt;/span&gt;
&lt;span class=&quot;code-quote&quot;&gt;&quot;Elapsed time: 872.132 msecs&quot;&lt;/span&gt;
&lt;span class=&quot;code-quote&quot;&gt;&quot;Elapsed time: 885.495 msecs&quot;&lt;/span&gt;
&lt;span class=&quot;code-quote&quot;&gt;&quot;Elapsed time: 897.537 msecs&quot;&lt;/span&gt;
&lt;span class=&quot;code-quote&quot;&gt;&quot;Elapsed time: 879.691 msecs&quot;&lt;/span&gt;
&lt;span class=&quot;code-quote&quot;&gt;&quot;Elapsed time: 888.52 msecs&quot;&lt;/span&gt;
&lt;span class=&quot;code-quote&quot;&gt;&quot;Elapsed time: 871.556 msecs&quot;&lt;/span&gt;
&lt;span class=&quot;code-quote&quot;&gt;&quot;Elapsed time: 1088.682 msecs&quot;&lt;/span&gt;&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;After the patch:&lt;/p&gt;

&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;user=&amp;gt; (dotimes [n 10] (time (dotimes [i 5000000] ((fn [&amp;amp; args]) 1 2 3 4))))
&lt;span class=&quot;code-quote&quot;&gt;&quot;Elapsed time: 628.144 msecs&quot;&lt;/span&gt;
&lt;span class=&quot;code-quote&quot;&gt;&quot;Elapsed time: 634.163 msecs&quot;&lt;/span&gt;
&lt;span class=&quot;code-quote&quot;&gt;&quot;Elapsed time: 617.397 msecs&quot;&lt;/span&gt;
&lt;span class=&quot;code-quote&quot;&gt;&quot;Elapsed time: 622.714 msecs&quot;&lt;/span&gt;
&lt;span class=&quot;code-quote&quot;&gt;&quot;Elapsed time: 646.743 msecs&quot;&lt;/span&gt;
&lt;span class=&quot;code-quote&quot;&gt;&quot;Elapsed time: 648.708 msecs&quot;&lt;/span&gt;
&lt;span class=&quot;code-quote&quot;&gt;&quot;Elapsed time: 629.223 msecs&quot;&lt;/span&gt;
&lt;span class=&quot;code-quote&quot;&gt;&quot;Elapsed time: 638.058 msecs&quot;&lt;/span&gt;
&lt;span class=&quot;code-quote&quot;&gt;&quot;Elapsed time: 725.473 msecs&quot;&lt;/span&gt;
&lt;span class=&quot;code-quote&quot;&gt;&quot;Elapsed time: 636.909 msecs&quot;&lt;/span&gt;&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;That&apos;s about a 30% reduction in execution time.&lt;/p&gt;

&lt;p&gt;Granted it only represents a change of 52 nanoseconds per RestFn invoke (181 ns to 129 ns), but this actually was a pretty decent win for a library that makes makes almost exclusively variadic function calls in a tight loop.&lt;/p&gt;</description>
                <environment></environment>
            <key id="16141">CLJ-1200</key>
            <summary>RestFn &amp; ArraySeq performance</summary>
                <type id="4" iconUrl="http://dev.clojure.org/jira/images/icons/improvement.gif">Enhancement</type>
                                <priority id="4" iconUrl="http://dev.clojure.org/jira/images/icons/priority_minor.gif">Minor</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="bbloom">Brandon Bloom</reporter>
                        <labels>
                        <label>patch</label>
                    </labels>
                <created>Sun, 14 Apr 2013 21:49:05 -0500</created>
                <updated>Thu, 18 Apr 2013 16:03:25 -0500</updated>
                                    <version>Release 1.5</version>
                                                        <due></due>
                    <votes>3</votes>
                        <watches>3</watches>
                                <attachments>
                    <attachment id="11958" name="no-getComponentType--v001.patch" size="3501" author="bbloom" created="Sun, 14 Apr 2013 21:49:05 -0500" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10000" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Patch</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10001">Code</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[CLJ-1201] There should also be writing in clojure.edn</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1201</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;In clojure.edn I see only &quot;read&quot; and &quot;read-string&quot;.&lt;/p&gt;

&lt;p&gt;For symmetry I expect &quot;write&quot; and &quot;write-string&quot; to be nearby. At first it could be just alias for &quot;pr&quot; and &quot;pr-str&quot;, but in furure they may limited version of &quot;pr&quot; which only produces valid input for clojure.edn/read.&lt;/p&gt;</description>
                <environment></environment>
            <key id="16142">CLJ-1201</key>
            <summary>There should also be writing in clojure.edn</summary>
                <type id="4" iconUrl="http://dev.clojure.org/jira/images/icons/improvement.gif">Enhancement</type>
                                <priority id="4" iconUrl="http://dev.clojure.org/jira/images/icons/priority_minor.gif">Minor</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="vi">Vitaly Shukela</reporter>
                        <labels>
                        <label>edn</label>
                    </labels>
                <created>Mon, 15 Apr 2013 08:20:01 -0500</created>
                <updated>Mon, 15 Apr 2013 08:20:01 -0500</updated>
                                    <version>Release 1.5</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>1</watches>
                                <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                                                                                            </customfields>
    </item>

<item>
            <title>[CLJ-1152] PermGen leak in multimethods and protocol fns</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1152</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;There is a PermGen memory leak that we have tracked down to protocol methods and multimethods called inside an &lt;tt&gt;eval&lt;/tt&gt;, because of the caches these methods use. The problem only arises when the value being cached is an instance of a class (such as a function or reify) that was defined inside the &lt;tt&gt;eval&lt;/tt&gt;. Thus extending &lt;tt&gt;IFn&lt;/tt&gt; or dispatching a multimethod on an &lt;tt&gt;IFn&lt;/tt&gt; are likely triggers.&lt;/p&gt;

&lt;p&gt;My fellow LonoClouder, &lt;b&gt;Jeff Dik&lt;/b&gt; describes how to reproduce and work around the problem:&lt;/p&gt;

&lt;p&gt;The easiest way that I have found to test this is to set &quot;&lt;tt&gt;-XX:MaxPermSize&lt;/tt&gt;&quot; to a reasonable value so you don&apos;t have to wait too long for the PermGen space to fill up, and to use &quot;&lt;tt&gt;-XX:+TraceClassLoading&lt;/tt&gt;&quot; and &quot;&lt;tt&gt;-XX:+TraceClassUnloading&lt;/tt&gt;&quot; to see the classes being loaded and unloaded.&lt;/p&gt;

&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeHeader panelHeader&quot; style=&quot;border-bottom-width: 1px;&quot;&gt;&lt;b&gt;leiningen project.clj&lt;/b&gt;&lt;/div&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;(defproject permgen-scratch &lt;span class=&quot;code-quote&quot;&gt;&quot;0.1.0-SNAPSHOT&quot;&lt;/span&gt;
  :dependencies [[org.clojure/clojure &lt;span class=&quot;code-quote&quot;&gt;&quot;1.5.0-RC1&quot;&lt;/span&gt;]]
  :jvm-opts [&lt;span class=&quot;code-quote&quot;&gt;&quot;-XX:MaxPermSize=32M&quot;&lt;/span&gt;
             &lt;span class=&quot;code-quote&quot;&gt;&quot;-XX:+TraceClassLoading&quot;&lt;/span&gt;
             &lt;span class=&quot;code-quote&quot;&gt;&quot;-XX:+TraceClassUnloading&quot;&lt;/span&gt;])&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;You can use &lt;tt&gt;lein swank 45678&lt;/tt&gt; and connect with slime in emacs via &lt;tt&gt;M-x slime-connect&lt;/tt&gt;.&lt;/p&gt;

&lt;p&gt;To monitor the PermGen usage, you can find the Java process to watch with &quot;&lt;tt&gt;jps -lmvV&lt;/tt&gt;&quot; and then run &quot;&lt;tt&gt;jstat -gcold &lt;ins&gt;&lt;em&gt;&amp;lt;PROCESS_ID&amp;gt;&lt;/em&gt;&lt;/ins&gt; 1s&lt;/tt&gt;&quot;. According to &lt;a href=&quot;http://docs.oracle.com/javase/7/docs/technotes/tools/share/jstat.html#gcold_option&quot;&gt;the jstat docs&lt;/a&gt;, the first column (PC) is the &quot;Current permanent space capacity (KB)&quot; and the second column (PU) is the &quot;Permanent space utilization (KB)&quot;. VisualVM is also a nice tool for monitoring this.&lt;/p&gt;

&lt;h2&gt;&lt;a name=&quot;Multimethodleak&quot;&gt;&lt;/a&gt;Multimethod leak&lt;/h2&gt;

&lt;p&gt;Evaluating the following code will run a loop that eval&apos;s &lt;tt&gt;(take* (fn foo []))&lt;/tt&gt;.&lt;/p&gt;

&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeHeader panelHeader&quot; style=&quot;border-bottom-width: 1px;&quot;&gt;&lt;b&gt;multimethod leak&lt;/b&gt;&lt;/div&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;(defmulti take* (fn [a] (type a)))

(defmethod take* clojure.lang.Fn
  [a]
  &apos;())

(def stop (atom &lt;span class=&quot;code-keyword&quot;&gt;false&lt;/span&gt;))
(def sleep-duration (atom 1000))

(defn run-loop []
  (when-not @stop
    (eval &apos;(take* (fn foo [])))
    (&lt;span class=&quot;code-object&quot;&gt;Thread&lt;/span&gt;/sleep @sleep-duration)
    (recur)))

(&lt;span class=&quot;code-keyword&quot;&gt;future&lt;/span&gt; (run-loop))

(reset! sleep-duration 0)&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;In the &lt;tt&gt;lein swank&lt;/tt&gt; session, you will see many lines like below listing the classes being created and loaded.&lt;/p&gt;

&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;[Loaded user$eval15802$foo__15803 from __JVM_DefineClass__]
[Loaded user$eval15802 from __JVM_DefineClass__]&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;These lines will stop once the PermGen space fills up.&lt;/p&gt;

&lt;p&gt;In the jstat monitoring, you&apos;ll see the amount of used PermGen space (PU) increase to the max and stay there.&lt;/p&gt;

&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;-    PC       PU        OC          OU       YGC    FGC    FGCT     GCT
 31616.0  31552.7    365952.0         0.0      4     0    0.000    0.129
 32000.0  31914.0    365952.0         0.0      4     0    0.000    0.129
 32768.0  32635.5    365952.0         0.0      4     0    0.000    0.129
 32768.0  32767.6    365952.0      1872.0      5     1    0.000    0.177
 32768.0  32108.2    291008.0     23681.8      6     2    0.827    1.006
 32768.0  32470.4    291008.0     23681.8      6     2    0.827    1.006
 32768.0  32767.2    698880.0     24013.8      8     4    1.073    1.258
 32768.0  32767.2    698880.0     24013.8      8     4    1.073    1.258
 32768.0  32767.2    698880.0     24013.8      8     4    1.073    1.258&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;A workaround is to run &lt;tt&gt;prefer-method&lt;/tt&gt; before the PermGen space is all used up, e.g.&lt;/p&gt;
&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;(prefer-method take* clojure.lang.Fn java.lang.&lt;span class=&quot;code-object&quot;&gt;Object&lt;/span&gt;)&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;Then, when the used PermGen space is close to the max, in the &lt;tt&gt;lein swank&lt;/tt&gt; session, you will see the classes created by the eval&apos;ing being unloaded.&lt;/p&gt;
&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;[Unloading class user$eval5950$foo__5951]
[Unloading class user$eval3814]
[Unloading class user$eval2902$foo__2903]
[Unloading class user$eval13414]&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;In the jstat monitoring, there will be a long pause when used PermGen space stays close to the max, and then it will drop down, and start increasing again when more eval&apos;ing occurs.&lt;/p&gt;

&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;-    PC       PU        OC          OU       YGC    FGC    FGCT     GCT
 32768.0  32767.9    159680.0     24573.4      6     2    0.167    0.391
 32768.0  32767.9    159680.0     24573.4      6     2    0.167    0.391
 32768.0  17891.3    283776.0     17243.9      6     2   50.589   50.813
 32768.0  18254.2    283776.0     17243.9      6     2   50.589   50.813&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;The &lt;tt&gt;defmulti&lt;/tt&gt; defines a cache that uses the dispatch values as keys. Each eval call in the loop defines a new foo class which is then added to the cache when &lt;tt&gt;take*&lt;/tt&gt; is called, preventing the class from ever being GCed.&lt;/p&gt;

&lt;p&gt;The prefer-method workaround works because it calls &lt;tt&gt;clojure.lang.MultiFn.preferMethod&lt;/tt&gt;, which calls the private &lt;tt&gt;MultiFn.resetCache&lt;/tt&gt; method, which completely empties the cache.&lt;/p&gt;

&lt;h2&gt;&lt;a name=&quot;Protocolleak&quot;&gt;&lt;/a&gt;Protocol leak&lt;/h2&gt;

&lt;p&gt;The leak with protocol methods similarly involves a cache. You see essentially the same behavior as the multimethod leak if you run the following code using protocols.&lt;/p&gt;

&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeHeader panelHeader&quot; style=&quot;border-bottom-width: 1px;&quot;&gt;&lt;b&gt;protocol leak&lt;/b&gt;&lt;/div&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;(defprotocol ITake (take* [a]))

(extend-type clojure.lang.Fn
  ITake
  (take* [&lt;span class=&quot;code-keyword&quot;&gt;this&lt;/span&gt;] &apos;()))

(def stop (atom &lt;span class=&quot;code-keyword&quot;&gt;false&lt;/span&gt;))
(def sleep-duration (atom 1000))

(defn run-loop []
  (when-not @stop
    (eval &apos;(take* (fn foo [])))
    (&lt;span class=&quot;code-object&quot;&gt;Thread&lt;/span&gt;/sleep @sleep-duration)
    (recur)))

(&lt;span class=&quot;code-keyword&quot;&gt;future&lt;/span&gt; (run-loop))

(reset! sleep-duration 0)&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;Again, the cache is in the &lt;tt&gt;take*&lt;/tt&gt; method itself, using each new &lt;tt&gt;foo&lt;/tt&gt; class as a key.&lt;/p&gt;

&lt;p&gt;A workaround is to run &lt;tt&gt;-reset-methods&lt;/tt&gt; on the protocol before the PermGen space is all used up, e.g.&lt;/p&gt;
&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;(-reset-methods ITake)&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;This works because &lt;tt&gt;-reset-methods&lt;/tt&gt; replaces the cache with an empty MethodImplCache.&lt;/p&gt;</description>
                <environment></environment>
            <key id="15981">CLJ-1152</key>
            <summary>PermGen leak in multimethods and protocol fns</summary>
                <type id="1" iconUrl="http://dev.clojure.org/jira/images/icons/bug.gif">Defect</type>
                                <priority id="4" iconUrl="http://dev.clojure.org/jira/images/icons/priority_minor.gif">Minor</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="chouser@n01se.net">Chouser</reporter>
                        <labels>
                    </labels>
                <created>Wed, 30 Jan 2013 09:00:47 -0600</created>
                <updated>Wed, 30 Jan 2013 09:10:08 -0600</updated>
                                    <version>Release 1.4</version>
                                                        <due></due>
                    <votes>1</votes>
                        <watches>0</watches>
                        <comments>
                    <comment id="30511" author="chouser@n01se.net" created="Wed, 30 Jan 2013 09:10:08 -0600"  >&lt;p&gt;I think the most obvious solution would be to constrain the size of the cache.  Adding an item to the cache is already not the fastest path, so a bit more work could be done to prevent the cache from growing indefinitely large. &lt;/p&gt;

&lt;p&gt;That does raise the question of what criteria to use.  Keep the first &lt;em&gt;n&lt;/em&gt; entries?  Keep the &lt;em&gt;n&lt;/em&gt; most recently used (which would require bookkeeping in the fast cache-hit path)? Keep the &lt;em&gt;n&lt;/em&gt; most recently added?&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                                                                                            </customfields>
    </item>

<item>
            <title>[CLJ-1204] hash is inconsistent with = for many BigInteger values</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1204</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;The function &lt;tt&gt;hash&lt;/tt&gt; is documented to be consistent with &lt;tt&gt;=&lt;/tt&gt;.  For many BigInteger values, &lt;tt&gt;hash&lt;/tt&gt; is inconsistent with &lt;tt&gt;=&lt;/tt&gt;.  This leads to incorrect behavior for data structures like hash maps that use &lt;tt&gt;hash&lt;/tt&gt;.&lt;/p&gt;

&lt;div class=&quot;preformatted panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;preformattedContent panelContent&quot;&gt;
&lt;pre&gt;user&amp;gt; (apply = [-1 -1N (biginteger -1)])
true
user&amp;gt; (map hash [-1 -1N (biginteger -1)])
(0 0 -1)

;; Incorrect return value with multiple keys = to each other
user&amp;gt; (assoc (hash-map -1N :should-be-replaced) (biginteger -1) :new-val)
{-1N :should-be-replaced, -1 :new-val}

;; array-map gives correct value, since it uses =, not hash
user&amp;gt; (assoc (array-map -1N :should-be-replaced) (biginteger -1) :new-val)
{-1N :new-val}
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;</description>
                <environment></environment>
            <key id="16150">CLJ-1204</key>
            <summary>hash is inconsistent with = for many BigInteger values</summary>
                <type id="1" iconUrl="http://dev.clojure.org/jira/images/icons/bug.gif">Defect</type>
                                <priority id="4" iconUrl="http://dev.clojure.org/jira/images/icons/priority_minor.gif">Minor</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="jafingerhut">Andy Fingerhut</reporter>
                        <labels>
                    </labels>
                <created>Thu, 18 Apr 2013 19:54:05 -0500</created>
                <updated>Thu, 25 Apr 2013 18:42:40 -0500</updated>
                                    <version>Release 1.4</version>
                <version>Release 1.5</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>1</watches>
                        <comments>
                    <comment id="30971" author="jafingerhut" created="Thu, 18 Apr 2013 20:10:38 -0500"  >&lt;p&gt;Patch clj-1204-make-hash-consistent-with-equal-for-bigintegers-v1.txt dated Apr 18 2013 takes the following approach to the issue:&lt;/p&gt;

&lt;p&gt;Change the behavior of hasheq so that when given a BigInteger value that could fit into a long, returns the same hash code as that long value.&lt;/p&gt;

&lt;p&gt;hasheq continues to return x.hashCode() if the BigInteger value does not fit into a long.  This is consistent with the hash value returned by a BigInt value that does not fit into a long.&lt;/p&gt;

&lt;p&gt;New tests are included, some of which fail without the change to hasheq, but pass with the change.&lt;/p&gt;</comment>
                    <comment id="30973" author="jafingerhut" created="Thu, 18 Apr 2013 20:19:54 -0500"  >&lt;p&gt;Overwrite patch with one that leaves out some unnecessary code.&lt;/p&gt;</comment>
                    <comment id="31002" author="jafingerhut" created="Thu, 25 Apr 2013 18:42:40 -0500"  >&lt;p&gt;Changing priority to minor, since I suppose one could work around this issue, if you were diligent about it, by converting all BigIntegers to BigInts before they are ever used in a place where they are hashed.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="11964" name="clj-1204-make-hash-consistent-with-equal-for-bigintegers-v1.txt" size="2173" author="jafingerhut" created="Thu, 18 Apr 2013 20:19:54 -0500" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10000" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Patch</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10002">Code and Test</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[CLJ-1206] &apos;eval&apos; of closures or fns with runtime metadata within a call expr yields &quot;No matching ctor found&quot; exceptions</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1206</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;I ran into some issues with &apos;eval&apos; when writing compilation strategies for Graph.  It seems these may have been known for some time &lt;span class=&quot;error&quot;&gt;&amp;#91;1&amp;#93;&lt;/span&gt;, but I couldn&apos;t find a ticket for them, so here we are.&lt;/p&gt;

&lt;p&gt;Clojure docs &lt;span class=&quot;error&quot;&gt;&amp;#91;2&amp;#93;&lt;/span&gt; say &quot;If the operator is not a special form or macro, the call is considered a function call. Both the operator and the operands (if any) are evaluated, from left to right,&quot;  and &quot;Any object other than those discussed above will evaluate to itself.&quot;  While bare fns do seem to evaluate to themselves in all cases, when in a call expression, the evaluation of the operator fails on fn objects that are closures or have run-time metadata applied:&lt;/p&gt;

&lt;p&gt;;; raw non-closures are fine&lt;br/&gt;
user&amp;gt; (eval (fn &lt;span class=&quot;error&quot;&gt;&amp;#91;x&amp;#93;&lt;/span&gt; (inc x))) &lt;br/&gt;
#&amp;lt;user$eval30559$fn_&lt;em&gt;30560 user$eval30559$fn&lt;/em&gt;_30560@354ee11c&amp;gt;&lt;/p&gt;

&lt;p&gt;;; raw closures are fine&lt;br/&gt;
user&amp;gt; (eval (let &lt;span class=&quot;error&quot;&gt;&amp;#91;y 1&amp;#93;&lt;/span&gt; (fn &lt;span class=&quot;error&quot;&gt;&amp;#91;x&amp;#93;&lt;/span&gt; (+ x y))))&lt;br/&gt;
#&amp;lt;user$eval30511$fn_&lt;em&gt;30512 user$eval30511$fn&lt;/em&gt;_30512@3bac3a34&amp;gt;&lt;/p&gt;

&lt;p&gt;;; non-closures in exprs are fine&lt;br/&gt;
user&amp;gt; (eval `(~(fn &lt;span class=&quot;error&quot;&gt;&amp;#91;x&amp;#93;&lt;/span&gt; (inc x)) 1))&lt;br/&gt;
2&lt;/p&gt;

&lt;p&gt;;; but closures in exprs cause an error&lt;br/&gt;
user&amp;gt; (eval `(~(let &lt;span class=&quot;error&quot;&gt;&amp;#91;y 1&amp;#93;&lt;/span&gt; (fn &lt;span class=&quot;error&quot;&gt;&amp;#91;x&amp;#93;&lt;/span&gt; (+ x y))) 1))&lt;br/&gt;
IllegalArgumentException No matching ctor found for class user$eval30535$fn__30536  clojure.lang.Reflector.invokeConstructor (Reflector.java:163)&lt;/p&gt;

&lt;p&gt;;; as do fns with metadata in exprs&lt;br/&gt;
user&amp;gt; (eval `(~(with-meta (fn &lt;span class=&quot;error&quot;&gt;&amp;#91;x&amp;#93;&lt;/span&gt; (inc x)) {:x 1}) 1))&lt;br/&gt;
IllegalArgumentException No matching ctor found for class clojure.lang.AFunction$1  clojure.lang.Reflector.invokeConstructor (Reflector.java:163)&lt;/p&gt;


&lt;p&gt;&lt;span class=&quot;error&quot;&gt;&amp;#91;1&amp;#93;&lt;/span&gt; &lt;a href=&quot;http://stackoverflow.com/a/11287181&quot;&gt;http://stackoverflow.com/a/11287181&lt;/a&gt;&lt;br/&gt;
&lt;span class=&quot;error&quot;&gt;&amp;#91;2&amp;#93;&lt;/span&gt; &lt;a href=&quot;http://clojure.org/evaluation&quot;&gt;http://clojure.org/evaluation&lt;/a&gt;&lt;/p&gt;</description>
                <environment></environment>
            <key id="16167">CLJ-1206</key>
            <summary>&apos;eval&apos; of closures or fns with runtime metadata within a call expr yields &quot;No matching ctor found&quot; exceptions</summary>
                <type id="1" iconUrl="http://dev.clojure.org/jira/images/icons/bug.gif">Defect</type>
                                <priority id="4" iconUrl="http://dev.clojure.org/jira/images/icons/priority_minor.gif">Minor</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="jawolfe">Jason Wolfe</reporter>
                        <labels>
                    </labels>
                <created>Sun, 28 Apr 2013 18:27:49 -0500</created>
                <updated>Sun, 28 Apr 2013 18:27:49 -0500</updated>
                                    <version>Release 1.5</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                                                                                            </customfields>
    </item>

<item>
            <title>[CLJ-1169] Add filename and line number to defn parameter declaration error</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1169</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;When mistyping parameter list in defn declaration, e.g.&lt;/p&gt;

&lt;p&gt;(defn test&lt;br/&gt;
 (some-error))&lt;/p&gt;

&lt;p&gt;error message shows name of parameter (without quotes), but not function name, filename or line number:&lt;/p&gt;

&lt;p&gt;Exception in thread &quot;main&quot; java.lang.IllegalArgumentException: Parameter declaration some-error should be a vector&lt;br/&gt;
        at clojure.core$assert_valid_fdecl.invoke(core.clj:6567)&lt;br/&gt;
        at clojure.core$sigs.invoke(core.clj:220)&lt;br/&gt;
        at clojure.core$defn.doInvoke(core.clj:294)&lt;br/&gt;
        at clojure.lang.RestFn.invoke(RestFn.java:467)&lt;br/&gt;
        at clojure.lang.Var.invoke(Var.java:427)&lt;br/&gt;
        at clojure.lang.AFn.applyToHelper(AFn.java:172)&lt;br/&gt;
        at clojure.lang.Var.applyTo(Var.java:532)&lt;br/&gt;
        at clojure.lang.Compiler.macroexpand1(Compiler.java:6366)&lt;br/&gt;
        at clojure.lang.Compiler.macroexpand(Compiler.java:6427)&lt;br/&gt;
        at clojure.lang.Compiler.eval(Compiler.java:6495)&lt;br/&gt;
        at clojure.lang.Compiler.load(Compiler.java:6952)&lt;br/&gt;
        at clojure.lang.Compiler.loadFile(Compiler.java:6912)&lt;br/&gt;
        at clojure.main$load_script.invoke(main.clj:283)&lt;br/&gt;
        at clojure.main$init_opt.invoke(main.clj:288)&lt;br/&gt;
        at clojure.main$initialize.invoke(main.clj:316)&lt;br/&gt;
        at clojure.main$null_opt.invoke(main.clj:349)&lt;br/&gt;
        at clojure.main$main.doInvoke(main.clj:427)&lt;br/&gt;
        at clojure.lang.RestFn.invoke(RestFn.java:421)&lt;br/&gt;
        at clojure.lang.Var.invoke(Var.java:419)&lt;br/&gt;
        at clojure.lang.AFn.applyToHelper(AFn.java:163)&lt;br/&gt;
        at clojure.lang.Var.applyTo(Var.java:532)&lt;br/&gt;
        at clojure.main.main(main.java:37)&lt;/p&gt;
</description>
                <environment>Windows</environment>
            <key id="16024">CLJ-1169</key>
            <summary>Add filename and line number to defn parameter declaration error</summary>
                <type id="4" iconUrl="http://dev.clojure.org/jira/images/icons/improvement.gif">Enhancement</type>
                                <priority id="4" iconUrl="http://dev.clojure.org/jira/images/icons/priority_minor.gif">Minor</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="metaclass">Andrei Kleschinski</reporter>
                        <labels>
                    </labels>
                <created>Fri, 22 Feb 2013 03:25:06 -0600</created>
                <updated>Sun, 10 Mar 2013 17:58:32 -0500</updated>
                                    <version>Release 1.4</version>
                <version>Release 1.5</version>
                                                        <due></due>
                    <votes>1</votes>
                        <watches>0</watches>
                        <comments>
                    <comment id="30642" author="metaclass" created="Fri, 22 Feb 2013 05:39:32 -0600"  >&lt;p&gt;Proposed patch for issue&lt;br/&gt;
Process exceptions in macroexpand1 and wraps them in CompilerException with source,line,column information.&lt;/p&gt;

&lt;p&gt;Also patch adds quotes around invalid symbol name in error message to make them more distinguishable from rest of message.&lt;/p&gt;
</comment>
                    <comment id="30672" author="jafingerhut" created="Fri, 1 Mar 2013 09:32:21 -0600"  >&lt;p&gt;Patch 0001-&lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-1169&quot; title=&quot;Add filename and line number to defn parameter declaration error&quot;&gt;CLJ-1169&lt;/a&gt;-proposed-patch.patch dated Feb 22 2013 causes several tests to fail.  Run &quot;./antsetup.sh&quot; then &quot;ant&quot; to see which ones (or &quot;mvn package&quot;).&lt;/p&gt;</comment>
                    <comment id="30676" author="metaclass" created="Fri, 1 Mar 2013 10:25:47 -0600"  >&lt;p&gt;Fix for failed unit-tests&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="11872" name="0001-CLJ-1169-proposed-patch.patch" size="2504" author="metaclass" created="Fri, 22 Feb 2013 05:39:32 -0600" />
                    <attachment id="11885" name="0002-CLJ-1169-fix-unit-tests.patch" size="3230" author="metaclass" created="Fri, 1 Mar 2013 10:25:47 -0600" />
                    <attachment id="11871" name="defn_error_message.clj" size="34" author="metaclass" created="Fri, 22 Feb 2013 03:25:06 -0600" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10000" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Patch</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10001">Code</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[CLJ-1117] Partition does not follow docs</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1117</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;The doc for partition states &quot;In case there are not enough padding elements, return a partition with less than n items.&quot;&lt;/p&gt;

&lt;p&gt;However, the behavior of this function is as follows:&lt;/p&gt;

&lt;p&gt;user=&amp;gt; (partition 3 (range 10))&lt;br/&gt;
((0 1 2) (3 4 5) (6 7 8))&lt;br/&gt;
user=&amp;gt; (partition 4 (range 10))&lt;br/&gt;
((0 1 2 3) (4 5 6 7))&lt;br/&gt;
user=&amp;gt; (partition 5 (range 10))&lt;br/&gt;
((0 1 2 3 4) (5 6 7 8 9))&lt;/p&gt;

&lt;p&gt;Either the doc should be updated to make it clear that not providing a pad will mean that items are dropped, or the functionality of partition should be fixed to the following:&lt;/p&gt;

&lt;p&gt;user=&amp;gt; (partition 3 (range 10))&lt;br/&gt;
((0 1 2) (3 4 5) (6 7 8) (9))&lt;/p&gt;</description>
                <environment>OS X, 10.8</environment>
            <key id="15864">CLJ-1117</key>
            <summary>Partition does not follow docs</summary>
                <type id="1" iconUrl="http://dev.clojure.org/jira/images/icons/bug.gif">Defect</type>
                                <priority id="4" iconUrl="http://dev.clojure.org/jira/images/icons/priority_minor.gif">Minor</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="halgari">Timothy Baldridge</reporter>
                        <labels>
                    </labels>
                <created>Thu, 29 Nov 2012 13:28:02 -0600</created>
                <updated>Fri, 17 May 2013 10:14:56 -0500</updated>
                                    <version>Release 1.6</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>2</watches>
                        <comments>
                    <comment id="30091" author="jafingerhut" created="Thu, 29 Nov 2012 14:15:09 -0600"  >&lt;p&gt;That would be a potentially breaking change for some people&apos;s code that uses partition.  partition-all behaves as you wish.&lt;/p&gt;

&lt;p&gt;Also, your concern with the documentation is for when there are padding elements specified as an argument, but your examples don&apos;t specify any padding elements.&lt;/p&gt;</comment>
                    <comment id="30094" author="halgari" created="Thu, 29 Nov 2012 14:55:11 -0600"  >&lt;p&gt;I agree, but I think the docs should then explicitly state: &quot;if no padding is given, not all input elements may be returned in the output partitions&quot; or something to that line. &lt;/p&gt;</comment>
                    <comment id="30101" author="jafingerhut" created="Thu, 29 Nov 2012 16:43:22 -0600"  >&lt;p&gt;More precise documentation of current behavior is always welcome in my opinion.&lt;/p&gt;</comment>
                    <comment id="31099" author="cldwalker" created="Fri, 17 May 2013 10:14:56 -0500"  >&lt;p&gt;I&apos;ve uploaded a patch that calls out when and how partition drops tail elements:&lt;br/&gt;
&quot;If a pad collection is not supplied, any tail elements that remain from dividing the input collection length by n will not be included in a partition.&quot;&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="11994" name="clj-1117.patch" size="1392" author="cldwalker" created="Fri, 17 May 2013 10:14:56 -0500" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10000" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Patch</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10001">Code</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[CLJ-1147] Threading macro (-&gt;) does not permit inline function declarations</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1147</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;(-&amp;gt; &lt;span class=&quot;error&quot;&gt;&amp;#91;1 2 3&amp;#93;&lt;/span&gt; (fn &lt;span class=&quot;error&quot;&gt;&amp;#91;args&amp;#93;&lt;/span&gt; apply + args))&lt;/p&gt;

&lt;p&gt;CompilerException java.lang.Exception: Unsupported binding form: 1, compiling:(NO_SOURCE_PATH:1:13)&lt;/p&gt;

&lt;p&gt;The expression is expanded to:&lt;/p&gt;

&lt;p&gt;(fn &lt;span class=&quot;error&quot;&gt;&amp;#91;1 2 3&amp;#93;&lt;/span&gt; &lt;span class=&quot;error&quot;&gt;&amp;#91;args&amp;#93;&lt;/span&gt; apply + args)&lt;/p&gt;

&lt;p&gt;If this is intended behaviour then at the least the compiler error message is confusing. It would be preferable if the -&amp;gt; macro checked for (fn..) before treating a form as a sequence and injecting the argument.&lt;/p&gt;</description>
                <environment></environment>
            <key id="15962">CLJ-1147</key>
            <summary>Threading macro (-&gt;) does not permit inline function declarations</summary>
                <type id="1" iconUrl="http://dev.clojure.org/jira/images/icons/bug.gif">Defect</type>
                                <priority id="4" iconUrl="http://dev.clojure.org/jira/images/icons/priority_minor.gif">Minor</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="sfnelson">Stephen Nelson</reporter>
                        <labels>
                    </labels>
                <created>Mon, 14 Jan 2013 21:17:51 -0600</created>
                <updated>Fri, 17 May 2013 14:56:30 -0500</updated>
                                    <version>Release 1.5</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                        <comments>
                    <comment id="30437" author="jafingerhut" created="Tue, 15 Jan 2013 00:56:46 -0600"  >&lt;p&gt;Note that this works as you might have hoped:&lt;/p&gt;

&lt;p&gt;(-&amp;gt; &lt;span class=&quot;error&quot;&gt;&amp;#91;1 2 3&amp;#93;&lt;/span&gt; ((fn &lt;span class=&quot;error&quot;&gt;&amp;#91;args&amp;#93;&lt;/span&gt; (apply + args))))&lt;/p&gt;

&lt;p&gt;because it expands into:&lt;/p&gt;

&lt;p&gt;((fn &lt;span class=&quot;error&quot;&gt;&amp;#91;args&amp;#93;&lt;/span&gt; (apply + args)) &lt;span class=&quot;error&quot;&gt;&amp;#91;1 2 3&amp;#93;&lt;/span&gt;)&lt;/p&gt;

&lt;p&gt;Your suggestion that -&amp;gt; check for (fn ...) before treating it as a sequence and injecting the argument leaves open the question: Why only (fn ...) should be treated specially?  Why not (let ...), (for ...), (doseq ...), etc?  And if you go that far, how do you decide what should be allowed and what not?&lt;/p&gt;</comment>
                    <comment id="31102" author="cldwalker" created="Fri, 17 May 2013 14:56:30 -0500"  >&lt;p&gt;I agree with Andy, that it&apos;s not realistic suggestion to check for fn,let,etc. Perhaps a doc fix would help here but I&apos;m not sure if we just want to call out (fn ...). I&apos;d recommend closing this unless Stephen speaks up.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                                                                                            </customfields>
    </item>

<item>
            <title>[CLJ-1131] Importing a non-existent class causes an exception that does not fully identify the source file</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1131</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;I&apos;m in the process of stripping out some OSGi support, and I missed one import.&lt;/p&gt;

&lt;p&gt;The exception identifies &quot;init.clj&quot;, but I&apos;d prefer to see the full path there, as I have a few different &quot;init.clj&quot; files in my overall project.&lt;/p&gt;

&lt;div class=&quot;preformatted panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;preformattedContent panelContent&quot;&gt;
&lt;pre&gt;:core-services:compileClojure
Reflection warning, com/annadaletech/nexus/services/registry.clj:37 - call to unregisterAll can&apos;t be resolved.
Reflection warning, com/annadaletech/nexus/services/registry.clj:131 - call to getConfiguration can&apos;t be resolved.
Reflection warning, com/annadaletech/nexus/services/registry.clj:150 - call to getConfiguration can&apos;t be resolved.
Exception in thread &quot;main&quot; java.lang.ClassNotFoundException: org.osgi.framework.ServiceRegistration, compiling:(init.clj:1)
	at clojure.lang.Compiler$InvokeExpr.eval(Compiler.java:3387)
	at clojure.lang.Compiler.compile1(Compiler.java:7035)
	at clojure.lang.Compiler.compile1(Compiler.java:7025)
	at clojure.lang.Compiler.compile(Compiler.java:7097)
	at clojure.lang.RT.compile(RT.java:387)
	at clojure.lang.RT.load(RT.java:427)
	at clojure.lang.RT.load(RT.java:400)
	at clojure.core$load$fn__4890.invoke(core.clj:5415)
	at clojure.core$load.doInvoke(core.clj:5414)
	at clojure.lang.RestFn.invoke(RestFn.java:408)
	at clojure.core$load_one.invoke(core.clj:5227)
	at clojure.core$compile$fn__4895.invoke(core.clj:5426)
	at clojure.core$compile.invoke(core.clj:5425)
	at clojuresque.tasks.compile$main$fn__64.invoke(compile.clj:23)
	at clojuresque.cli$with_command_line_STAR_.invoke(cli.clj:92)
	at clojuresque.tasks.compile$main.doInvoke(compile.clj:6)
	at clojure.lang.RestFn.applyTo(RestFn.java:137)
	at clojure.core$apply.invoke(core.clj:601)
	at clojure.lang.Var.invoke(Var.java:419)
	at clojuresque.Driver.main(Driver.java:39)
Caused by: java.lang.ClassNotFoundException: org.osgi.framework.ServiceRegistration
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;</description>
                <environment></environment>
            <key id="15899">CLJ-1131</key>
            <summary>Importing a non-existent class causes an exception that does not fully identify the source file</summary>
                <type id="1" iconUrl="http://dev.clojure.org/jira/images/icons/bug.gif">Defect</type>
                                <priority id="4" iconUrl="http://dev.clojure.org/jira/images/icons/priority_minor.gif">Minor</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="hlewisship">Howard Lewis Ship</reporter>
                        <labels>
                        <label>feedback</label>
                    </labels>
                <created>Mon, 17 Dec 2012 18:13:02 -0600</created>
                <updated>Fri, 17 May 2013 15:56:48 -0500</updated>
                                    <version>Release 1.4</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                        <comments>
                    <comment id="31104" author="cldwalker" created="Fri, 17 May 2013 15:56:48 -0500"  >&lt;p&gt;While it&apos;s reasonable to want this for your case, having long path names in a stacktrace could be inconvenient for others. I&apos;d recommend posting your desired change on the dev list - &lt;a href=&quot;https://groups.google.com/forum/?fromgroups#!forum/clojure-dev&quot;&gt;https://groups.google.com/forum/?fromgroups#!forum/clojure-dev&lt;/a&gt; . If they&apos;re ok with it, then I&apos;d recommend submitting a patch.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                                                                                            </customfields>
    </item>

<item>
            <title>[CLJ-704] range function has missing documentation</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-704</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;The range function&apos;s documentation does indicate the following usage:&lt;/p&gt;

&lt;p&gt;(range 10 0 -1) -&amp;gt; (10, 9, 8, 7, 6, 5, 4, 3, 2, 1)&lt;/p&gt;

&lt;p&gt;Current doc:&lt;/p&gt;

&lt;p&gt;Returns a lazy seq of nums from start (inclusive) to end&lt;br/&gt;
(exclusive), by step, where start defaults to 0, step to 1, and end&lt;br/&gt;
to infinity.&lt;/p&gt;

&lt;p&gt;Suggestion:&lt;/p&gt;

&lt;p&gt;Returns a lazy seq of nums from start (inclusive) to end&lt;br/&gt;
(exclusive), by step, where start defaults to 0, step to 1, and end&lt;br/&gt;
to infinity.&lt;/p&gt;

&lt;p&gt;Its also possible to step down rather than up, for example counting&lt;br/&gt;
backwards from 10 by -1: (range 10 0 -1).  &lt;/p&gt;</description>
                <environment>All</environment>
            <key id="14313">CLJ-704</key>
            <summary>range function has missing documentation</summary>
                <type id="4" iconUrl="http://dev.clojure.org/jira/images/icons/improvement.gif">Enhancement</type>
                                <priority id="5" iconUrl="http://dev.clojure.org/jira/images/icons/priority_trivial.gif">Trivial</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="mrhus">Maarten Hus</reporter>
                        <labels>
                    </labels>
                <created>Tue, 4 Jan 2011 19:32:56 -0600</created>
                <updated>Fri, 11 May 2012 09:32:21 -0500</updated>
                                    <version>Release 1.2</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>2</watches>
                        <comments>
                    <comment id="26134" author="raek" created="Sat, 15 Jan 2011 07:39:05 -0600"  >&lt;p&gt;The current doc actually mentions the &apos;step&apos; parameter briefly:&lt;/p&gt;

&lt;p&gt;&quot;&lt;span class=&quot;error&quot;&gt;&amp;#91;...&amp;#93;&lt;/span&gt; to end (exclusive), by &lt;b&gt;step&lt;/b&gt;, where start &lt;span class=&quot;error&quot;&gt;&amp;#91;...&amp;#93;&lt;/span&gt;&quot;&lt;/p&gt;

&lt;p&gt;But as this might be easy to miss, an addition to the doc is still a good idea, I think.&lt;/p&gt;

&lt;p&gt;My suggestion:&lt;/p&gt;

&lt;p&gt;Returns a lazy seq of nums from start (inclusive) to end&lt;br/&gt;
(exclusive), by step, where start defaults to 0, step to 1, and end&lt;br/&gt;
to infinity. &lt;b&gt;Step may be negative to count backwards.&lt;/b&gt;&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                                                                                            </customfields>
    </item>

<item>
            <title>[CLJ-1017] Metadata expressions are evaluated after the expression they affect</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1017</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;Repro:&lt;/p&gt;

&lt;p&gt;user=&amp;gt; (def x (atom 1))&lt;br/&gt;
#&apos;user/x&lt;br/&gt;
user=&amp;gt; ^{:foo (swap! x inc)} {:bar (swap! x inc)}&lt;br/&gt;
{:bar 2}&lt;br/&gt;
user=&amp;gt; (meta *1)&lt;br/&gt;
{:foo 3}&lt;/p&gt;

&lt;p&gt;Presumably this is because ^:foo x expands to (with-meta x {:foo true}) but probably should have reversed argument order or use a let expression.&lt;/p&gt;</description>
                <environment></environment>
            <key id="15551">CLJ-1017</key>
            <summary>Metadata expressions are evaluated after the expression they affect</summary>
                <type id="1" iconUrl="http://dev.clojure.org/jira/images/icons/bug.gif">Defect</type>
                                <priority id="5" iconUrl="http://dev.clojure.org/jira/images/icons/priority_trivial.gif">Trivial</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="bbloom">Brandon Bloom</reporter>
                        <labels>
                    </labels>
                <created>Sat, 23 Jun 2012 17:18:49 -0500</created>
                <updated>Sat, 23 Jun 2012 17:18:49 -0500</updated>
                                                                            <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                                                                                            </customfields>
    </item>

<item>
            <title>[CLJ-1027] Outdated documentation for gen-class&apos;s :exposes-methods option</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1027</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;The docstring for gen-class says the following regarding the :exposes-methods option:&lt;/p&gt;

&lt;p&gt;&quot;It is sometimes necessary to call the superclass&apos; implementation of an&lt;br/&gt;
overridden method. Those methods may be exposed and referred in &lt;br/&gt;
the new method implementation by a local name.&quot;&lt;/p&gt;

&lt;p&gt;To me, this suggests that supplying something like `{foo fooSuper}` allows me to use the symbol `fooSuper` in my new method implementation. Doing this actually results in an error while compiling because `fooSuper` cannot be resolved. It seems that what actually happens is that a `fooSuper` instance method is defined, which calls the superclass&apos;s implementation. The docstring should be updated to reflect this.&lt;/p&gt;</description>
                <environment></environment>
            <key id="15580">CLJ-1027</key>
            <summary>Outdated documentation for gen-class&apos;s :exposes-methods option</summary>
                <type id="1" iconUrl="http://dev.clojure.org/jira/images/icons/bug.gif">Defect</type>
                                <priority id="5" iconUrl="http://dev.clojure.org/jira/images/icons/priority_trivial.gif">Trivial</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="aperiodic">Dan Lidral-Porter</reporter>
                        <labels>
                        <label>docs</label>
                        <label>documentation</label>
                    </labels>
                <created>Wed, 18 Jul 2012 19:01:35 -0500</created>
                <updated>Wed, 18 Jul 2012 19:01:35 -0500</updated>
                                    <version>Release 1.4</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                                                                                            </customfields>
    </item>

<item>
            <title>[CLJ-1020] clojure.inspector/inspect-table gives up when first element of coll is nil</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1020</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;clojure.inspector/inspect-table gives up when first element of coll is nil. The patch provided is rather trivial...instead of blindly choosing the first element (which might be nil), it would be more convenient to choose the first element that is NOT nil and use its keys for columns...a similar issue exists with clojure.pprint/print-table where the keys of the first element are used (if not provided explicitly). The same is not true for &apos;inspect-table&apos; though. As a result, one cannot &apos;inspect&apos; a collection of maps where the first element is nil. My (trivial) patch looks for the first element which is NOT nil and uses its keys instead. Maps have to have the same length anyway so no problems there...&lt;/p&gt;</description>
                <environment>Ubuntu 12.04, Java 7, Clojure 1.4</environment>
            <key id="15563">CLJ-1020</key>
            <summary>clojure.inspector/inspect-table gives up when first element of coll is nil</summary>
                <type id="4" iconUrl="http://dev.clojure.org/jira/images/icons/improvement.gif">Enhancement</type>
                                <priority id="5" iconUrl="http://dev.clojure.org/jira/images/icons/priority_trivial.gif">Trivial</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="jimpil">Dimitrios Piliouras</reporter>
                        <labels>
                        <label>patch,</label>
                    </labels>
                <created>Mon, 2 Jul 2012 05:26:42 -0500</created>
                <updated>Thu, 13 Sep 2012 14:30:24 -0500</updated>
                                    <version>Release 1.4</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                        <comments>
                    <comment id="28981" author="jafingerhut" created="Thu, 12 Jul 2012 13:01:18 -0500"  >&lt;p&gt;clj-1020-inspect-table-skip-nil-rows-patch1.txt of July 12, 2012 is identical to inspector.patch of July 2, 2012, except it is in the desired git format.  Proper attribution is given to author Dimitrios Piliouras in the patch.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="11379" name="clj-1020-inspect-table-skip-nil-rows-patch1.txt" size="722" author="jafingerhut" created="Thu, 12 Jul 2012 13:01:18 -0500" />
                    <attachment id="11359" name="inspector.patch" size="329" author="jimpil" created="Mon, 2 Jul 2012 05:26:42 -0500" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10000" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Patch</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10001">Code</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[CLJ-1095] Allow map-indexed to accept multiple collections (a la map)</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1095</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;Bring external interface of map-indexed in line with map. Existing usages of map-indexed unchanged both in implementation and interface.&lt;/p&gt;

&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeHeader panelHeader&quot; style=&quot;border-bottom-width: 1px;&quot;&gt;&lt;b&gt;examples&lt;/b&gt;&lt;/div&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;(map vector (range 10 20) (range 30 35)) ;=&amp;gt; ([10 30] [11 31] [12 32] [13 33] [14 34])
(map-indexed vector (range 10 20) (range 30 35)) ;=&amp;gt; ([0 10 30] [1 11 31] [2 12 32] [3 13 33] [4 14 34])&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;The attached patch is not necessarily the best implementation (I haven&apos;t benchmarked it or tried any alternatives yet) but hopefully enough to start a conversation about whether this is an addition that is warranted. I know I wished for this behavior a few weeks ago though I ended up finding another way.&lt;/p&gt;

&lt;p&gt;(I haven&apos;t sent my CA yet, but I have it signed and ready to send in the next few days)&lt;/p&gt;</description>
                <environment></environment>
            <key id="15784">CLJ-1095</key>
            <summary>Allow map-indexed to accept multiple collections (a la map)</summary>
                <type id="4" iconUrl="http://dev.clojure.org/jira/images/icons/improvement.gif">Enhancement</type>
                                <priority id="5" iconUrl="http://dev.clojure.org/jira/images/icons/priority_trivial.gif">Trivial</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="bjeanes">Bo Jeanes</reporter>
                        <labels>
                    </labels>
                <created>Thu, 25 Oct 2012 16:30:01 -0500</created>
                <updated>Thu, 8 Nov 2012 14:58:13 -0600</updated>
                                                                            <due></due>
                    <votes>0</votes>
                        <watches>1</watches>
                        <comments>
                    <comment id="29802" author="aaron" created="Thu, 25 Oct 2012 17:11:09 -0500"  >&lt;p&gt;Can you add a test for the improved functionality?&lt;/p&gt;</comment>
                    <comment id="29803" author="bjeanes" created="Thu, 25 Oct 2012 17:20:56 -0500"  >&lt;p&gt;You bet. I tried to before submitting this but found no existing tests for map-indexed to expand upon. Given that, I decided to just start the conversation first. If you think this is a good addition, I&apos;ll find a place to stick the tests and add a new patch file.&lt;/p&gt;</comment>
                    <comment id="29804" author="bjeanes" created="Thu, 25 Oct 2012 20:05:14 -0500"  >&lt;p&gt;Add two unit tests for &lt;tt&gt;map-indexed&lt;/tt&gt;. One tests old behavior (single collection) and the second tests mapping across 3 collections. &lt;/p&gt;

&lt;p&gt;There were no existing tests for &lt;tt&gt;map-indexed&lt;/tt&gt; that I could see to expand upon (using &lt;tt&gt;git grep map-indexed src/clojure&lt;/tt&gt;)&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="11615" name="0001-map-indexed-accepts-multiple-collections.patch" size="2422" author="bjeanes" created="Thu, 25 Oct 2012 16:30:01 -0500" />
                    <attachment id="11616" name="0002-Add-test-for-multi-collection-map-indexed-fn.patch" size="924" author="bjeanes" created="Thu, 25 Oct 2012 20:05:14 -0500" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10000" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Patch</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10002">Code and Test</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[CLJ-1057] Var&apos;s .setDynamic does not set :dynamic in metadata</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1057</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;((juxt (comp :dynamic meta) #(.isDynamic %)) #&apos;*agent*)&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;</description>
                <environment></environment>
            <key id="15667">CLJ-1057</key>
            <summary>Var&apos;s .setDynamic does not set :dynamic in metadata</summary>
                <type id="1" iconUrl="http://dev.clojure.org/jira/images/icons/bug.gif">Defect</type>
                                <priority id="5" iconUrl="http://dev.clojure.org/jira/images/icons/priority_trivial.gif">Trivial</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="bbloom">Brandon Bloom</reporter>
                        <labels>
                    </labels>
                <created>Sun, 2 Sep 2012 13:06:21 -0500</created>
                <updated>Mon, 3 Dec 2012 09:10:16 -0600</updated>
                                                                            <due></due>
                    <votes>0</votes>
                        <watches>1</watches>
                        <comments>
                    <comment id="30151" author="halgari" created="Mon, 3 Dec 2012 09:10:16 -0600"  >&lt;p&gt;This is actually an enhancement as no where in the clojure code is provision made for syncing var&apos;s metadata and dynamic state. .isDynamic is the authoritative source, and the calling of .setDynamic is configured by the compiler. If you&apos;d like to see this change, please, feel free to bring it up on clojure-dev for a discussion.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                                                                                            </customfields>
    </item>

<item>
            <title>[CLJ-1115] multi arity into</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1115</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;Any reason why into isn&apos;t multi arity?&lt;/p&gt;

&lt;p&gt;(into to &amp;amp; froms) =&amp;gt; (reduce into to froms)&lt;/p&gt;


&lt;p&gt;(into #{} &lt;span class=&quot;error&quot;&gt;&amp;#91;3 3 4&amp;#93;&lt;/span&gt; &lt;span class=&quot;error&quot;&gt;&amp;#91;2 1&amp;#93;&lt;/span&gt; &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;quot;a&amp;quot;&amp;#93;&lt;/span&gt;) looks better than (reduce into #{} [&lt;span class=&quot;error&quot;&gt;&amp;#91;3 3 4&amp;#93;&lt;/span&gt; &lt;span class=&quot;error&quot;&gt;&amp;#91;2 1&amp;#93;&lt;/span&gt; &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;quot;a&amp;quot;&amp;#93;&lt;/span&gt;])&lt;/p&gt;</description>
                <environment></environment>
            <key id="15854">CLJ-1115</key>
            <summary>multi arity into</summary>
                <type id="4" iconUrl="http://dev.clojure.org/jira/images/icons/improvement.gif">Enhancement</type>
                                <priority id="5" iconUrl="http://dev.clojure.org/jira/images/icons/priority_trivial.gif">Trivial</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="yongqli">Yongqian Li</reporter>
                        <labels>
                    </labels>
                <created>Sun, 25 Nov 2012 07:50:56 -0600</created>
                <updated>Sun, 9 Dec 2012 07:39:55 -0600</updated>
                                                                            <due></due>
                    <votes>0</votes>
                        <watches>1</watches>
                        <comments>
                    <comment id="30051" author="halgari" created="Tue, 27 Nov 2012 11:25:46 -0600"  >&lt;p&gt;Seems to be a valid enhancement. I can&apos;t see any issues we&apos;d have with it. Vetted. &lt;/p&gt;</comment>
                    <comment id="30090" author="halgari" created="Thu, 29 Nov 2012 14:06:44 -0600"  >&lt;p&gt;Added patch &amp;amp; test. This patch retains the old performance characteristics of into in the case that there is only one collection argument. For example: (into [] &lt;span class=&quot;error&quot;&gt;&amp;#91;1 2 3&amp;#93;&lt;/span&gt;) . &lt;/p&gt;

&lt;p&gt;Since the multi-arity version will be slightly slower, I opted to provide it as a second body instead of unifying both into a single body. If someone has a problem with this, I can rewrite the patch. At least this way, into won&apos;t get slower. &lt;/p&gt;</comment>
                    <comment id="30195" author="richhickey" created="Sun, 9 Dec 2012 07:39:55 -0600"  >&lt;p&gt;This is a good example of an idea for an enhancement I haven&apos;t approved, and thus is not yet vetted.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="11726" name="multi-arity-into.diff" size="3156" author="halgari" created="Thu, 29 Nov 2012 14:06:44 -0600" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10000" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Patch</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10002">Code and Test</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[CLJ-1044] Enable refering to -&gt;type inside deftype</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1044</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;Inside defrecord is possible to refer to -&amp;gt;type-ctor, that is not possible inside deftype.&lt;br/&gt;
This patch adds an implicit declare, as done in defrecord&lt;/p&gt;</description>
                <environment></environment>
            <key id="15634">CLJ-1044</key>
            <summary>Enable refering to -&gt;type inside deftype</summary>
                <type id="4" iconUrl="http://dev.clojure.org/jira/images/icons/improvement.gif">Enhancement</type>
                                <priority id="5" iconUrl="http://dev.clojure.org/jira/images/icons/priority_trivial.gif">Trivial</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="bronsa">Nicola Mometto</reporter>
                        <labels>
                    </labels>
                <created>Sat, 18 Aug 2012 08:02:50 -0500</created>
                <updated>Sat, 15 Dec 2012 07:35:38 -0600</updated>
                                                                            <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                        <comments>
                    <comment id="30164" author="halgari" created="Mon, 3 Dec 2012 11:29:57 -0600"  >&lt;p&gt;Seems valid. Vetting. &lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="11442" name="001-enable-factory-ctor-inside-deftype.diff" size="835" author="bronsa" created="Sat, 18 Aug 2012 08:02:50 -0500" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10000" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Patch</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10001">Code</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[CLJ-980] Documentation for extend-type falsely implies that &amp; is allowed in protocol fn signatures</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-980</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;The documentation for extend-type contains the following example:&lt;/p&gt;

&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;(extend-type MyType 
    Countable
      (cnt [c] ...)
    Foo
      (bar [x y] ...)
      (baz ([x] ...) ([x y &amp;amp; zs] ...)))&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;However, &lt;tt&gt;&lt;span class=&quot;error&quot;&gt;&amp;#91;x y &amp;amp; zs&amp;#93;&lt;/span&gt;&lt;/tt&gt; is not a valid parameter list for a protocol fn. The documentation should be appropriately amended.&lt;/p&gt;</description>
                <environment></environment>
            <key id="15402">CLJ-980</key>
            <summary>Documentation for extend-type falsely implies that &amp; is allowed in protocol fn signatures</summary>
                <type id="1" iconUrl="http://dev.clojure.org/jira/images/icons/bug.gif">Defect</type>
                                <priority id="5" iconUrl="http://dev.clojure.org/jira/images/icons/priority_trivial.gif">Trivial</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="charles-dyfis-net">Charles Duffy</reporter>
                        <labels>
                        <label>documentation</label>
                    </labels>
                <created>Thu, 3 May 2012 12:08:35 -0500</created>
                <updated>Wed, 19 Dec 2012 08:00:13 -0600</updated>
                                                                            <due></due>
                    <votes>0</votes>
                        <watches>1</watches>
                        <comments>
                    <comment id="28599" author="jszakmeister" created="Fri, 25 May 2012 04:00:27 -0500"  >&lt;p&gt;v2 of the patch is simply converts the patch to git format.  I made sure that Mr. Duffy got proper attribution.  I also took a stab at a simple log message.  Any problems with the latter are mine, and I&apos;m happy to fix it up if necessary.&lt;/p&gt;</comment>
                    <comment id="29190" author="aaron" created="Wed, 15 Aug 2012 22:08:35 -0500"  >&lt;p&gt;This doesn&apos;t update the entire doc string. The expansion is updated, but the signature section isn&apos;t. Here&apos;s what shows up.&lt;/p&gt;

&lt;div class=&quot;preformatted panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;preformattedContent panelContent&quot;&gt;
&lt;pre&gt;user=&amp;gt; (doc extend-type)
-------------------------
clojure.core/extend-type
([t &amp;amp; specs])
Macro
  A macro that expands into an extend call. Useful when you are
  supplying the definitions explicitly inline, extend-type
  automatically creates the maps required by extend.  Propagates the
  class as a type hint on the first argument of all fns.

  (extend-type MyType 
    Countable
      (cnt [c] ...)
    Foo
      (bar [x y] ...)
      (baz ([x] ...) ([x y &amp;amp; zs] ...)))

  expands into:

  (extend MyType
   Countable
     {:cnt (fn [c] ...)}
   Foo
     {:baz (fn ([x] ...) ([x y ...] ...))
      :bar (fn [x y] ...)})
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;</comment>
                    <comment id="29267" author="tsdh" created="Sat, 25 Aug 2012 06:44:49 -0500"  >&lt;p&gt;This is very much related to &lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-1024&quot;&gt;http://dev.clojure.org/jira/browse/CLJ-1024&lt;/a&gt;.&lt;/p&gt;

&lt;p&gt;NOTE: While varargs are not supported in protocol declarations, dynamic extension of a protocol via extend (extend-type, extend-protocol) &lt;b&gt;does&lt;/b&gt; allow for varargs and also destructuring, cause the method impls are actually normal clojure functions.&lt;/p&gt;

&lt;p&gt;So if a Foo protocol declares a (foo &lt;span class=&quot;error&quot;&gt;&amp;#91;this a b c&amp;#93;&lt;/span&gt;) method, you can extend/extend-type/extend-protocol it dynamically using (foo &lt;span class=&quot;error&quot;&gt;&amp;#91;this &amp;amp; more&amp;#93;&lt;/span&gt; (do-magick)) where `a b c` are conflated into the `more` parameter.&lt;/p&gt;

&lt;p&gt;However, that doesn&apos;t work for method implementations defined by deftype, defrecord, and reify.&lt;/p&gt;

&lt;p&gt;So with respect to the facts, the example in the docstring is actually correct, so I&apos;m not sure if it should be changed.  However, what&apos;s supported in which cases should be documented better as it is right now.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="11164" name="clojure--extend-type-doc-fix.diff" size="408" author="charles-dyfis-net" created="Thu, 3 May 2012 12:08:35 -0500" />
                    <attachment id="11257" name="extended-type-doc-fix-v2.patch" size="755" author="jszakmeister" created="Fri, 25 May 2012 04:00:27 -0500" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_10002" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Approval</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10006">Incomplete</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                    <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10000" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Patch</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10001">Code</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[CLJ-1146] Symbol name starting with digits to defn throws &quot;Unmatched delimiter )&quot;</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1146</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;When trying to use an invalid symbol name when defining a function, the error message thrown is a confusing and wrong one. The error message is &quot;RuntimeException Unmatched delimiter: )  clojure.lang.Util.runtimeException (Util.java:219)&quot;, which unfortunately is the only message seen in nrepled emacs.&lt;/p&gt;

&lt;p&gt;$ java -jar clojure-1.5.0-RC2.jar&lt;br/&gt;
Clojure 1.5.0-RC2&lt;br/&gt;
user=&amp;gt; (defn 45fn [] nil)&lt;br/&gt;
NumberFormatException Invalid number: 45fn  clojure.lang.LispReader.readNumber (LispReader.java:255)&lt;br/&gt;
[]&lt;br/&gt;
nil&lt;br/&gt;
RuntimeException Unmatched delimiter: )  clojure.lang.Util.runtimeException (Util.java:219)&lt;/p&gt;

&lt;p&gt;Expected:&lt;br/&gt;
When trying to (defn or (def a thing with a non valid symbol name, the last thrown error message should be one stating that the given symbol name is not a valid one.&lt;/p&gt;</description>
                <environment>$java -jar clojure-1.5.0-RC2.jar&lt;br/&gt;
&lt;br/&gt;
$java -version&lt;br/&gt;
java version &amp;quot;1.6.0_37&amp;quot;&lt;br/&gt;
Java(TM) SE Runtime Environment (build 1.6.0_37-b06-434-10M3909)&lt;br/&gt;
Java HotSpot(TM) 64-Bit Server VM (build 20.12-b01-434, mixed mode)&lt;br/&gt;
Mac OS X:&lt;br/&gt;
System Version: Mac OS X 10.6.8 (10K549)&lt;br/&gt;
Kernel Version: Darwin 10.8.0&lt;br/&gt;
</environment>
            <key id="15961">CLJ-1146</key>
            <summary>Symbol name starting with digits to defn throws &quot;Unmatched delimiter )&quot;</summary>
                <type id="4" iconUrl="http://dev.clojure.org/jira/images/icons/improvement.gif">Enhancement</type>
                                <priority id="5" iconUrl="http://dev.clojure.org/jira/images/icons/priority_trivial.gif">Trivial</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="claj">Linus Ericsson</reporter>
                        <labels>
                        <label>reader</label>
                    </labels>
                <created>Sun, 13 Jan 2013 15:41:03 -0600</created>
                <updated>Sun, 13 Jan 2013 15:41:03 -0600</updated>
                                    <version>Release 1.5</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>1</watches>
                                <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                                                                                            </customfields>
    </item>

<item>
            <title>[CLJ-1060] &apos;list*&apos; returns not a list</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1060</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;Function &apos;list?&apos; returns sequence, but not a list.&lt;br/&gt;
It is a bit confusing.&lt;/p&gt;

&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;user=&amp;gt; (list? (list* 1 &apos;(2 3)))
&lt;span class=&quot;code-keyword&quot;&gt;false&lt;/span&gt;&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;</description>
                <environment></environment>
            <key id="15670">CLJ-1060</key>
            <summary>&apos;list*&apos; returns not a list</summary>
                <type id="1" iconUrl="http://dev.clojure.org/jira/images/icons/bug.gif">Defect</type>
                                <priority id="5" iconUrl="http://dev.clojure.org/jira/images/icons/priority_trivial.gif">Trivial</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="azhlobich">Andrei Zhlobich</reporter>
                        <labels>
                    </labels>
                <created>Mon, 3 Sep 2012 06:32:23 -0500</created>
                <updated>Fri, 18 Jan 2013 09:41:40 -0600</updated>
                                    <version>Release 1.4</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>2</watches>
                        <comments>
                    <comment id="29457" author="stu" created="Mon, 17 Sep 2012 06:52:32 -0500"  >&lt;p&gt;should the docstring for list* change to say it returns a seq?&lt;/p&gt;</comment>
                    <comment id="30057" author="halgari" created="Tue, 27 Nov 2012 11:58:18 -0600"  >&lt;p&gt;Is there a reason why we can&apos;t have list* actually return a list? The cost of creating a list vs a cons is negligible.&lt;/p&gt;</comment>
                    <comment id="30369" author="mnicky" created="Fri, 4 Jan 2013 14:02:16 -0600"  >&lt;p&gt;The question is what to do with the one-argument case of list*, because in cases like: (list* {:a 1 :b 2}) it doesn&apos;t return IPersistentList as well. I propose just applying &apos;list&apos;.&lt;/p&gt;

&lt;p&gt;I added patch &apos;list-star-fix.diff&apos; (dated 04/Jan/2013) with Cons implementing IPersistentList and doing (apply list args) in one-argument case of list*. To be able to use &apos;apply&apos; in list* I had to declare it before the definition of list* in the source code. The apply itself also uses list*, but luckily not the one-argument version of list*, so it should be safe... The patch also contains simple unit tests.&lt;/p&gt;

&lt;p&gt;Discussion is also here: &lt;a href=&quot;https://groups.google.com/forum/#!topic/clojure/co8lcKymfi8&quot;&gt;https://groups.google.com/forum/#!topic/clojure/co8lcKymfi8&lt;/a&gt;&lt;/p&gt;</comment>
                    <comment id="30370" author="michalmarczyk" created="Fri, 4 Jan 2013 16:11:56 -0600"  >&lt;p&gt;(apply list args) would make (list* (range)) hang, where currently it returns a partially-realized lazy seq. Also, even for non-lazy seqs &amp;#8211; possibly lists themselves &amp;#8211; it would always build a new list from scratch, right?&lt;/p&gt;

&lt;p&gt;Also, if I&apos;m reading the patch correctly, it would make 2+-ary list&amp;#42; overloads and cons return lists &amp;#8211; that is, IPersistentList instances &amp;#8211; always (Conses would now be lists), but repeatedly calling next on such a list might eventually produce a non-list. The only way around that would be to make all seqs into IPersistentLists &amp;#8211; that doesn&apos;t seem desirable at first glance...?&lt;/p&gt;

&lt;p&gt;On a side note, for the case where the final &quot;args&quot; argument is in fact a list, we already have a &quot;prepend many items&quot; function, namely conj. list&amp;#42; currently acts as the vararg variant of cons (in line with Lisp tradition); I&apos;m actually quite happy with that.&lt;/p&gt;</comment>
                    <comment id="30372" author="michalmarczyk" created="Fri, 4 Jan 2013 16:19:30 -0600"  >&lt;p&gt;I&apos;m in favour of the &quot;list&quot; -&amp;gt; &quot;seq&quot; tweak to the docstring though, assuming impl remains unchanged.&lt;/p&gt;</comment>
                    <comment id="30376" author="mnicky" created="Fri, 4 Jan 2013 18:13:37 -0600"  >&lt;p&gt;Yep, these are all valid points, thanks! I see this as a question whether the list* function is a list constructor or not. If yes (and it would be possible to implement it in a satisfactory way), it should probably return a list.&lt;/p&gt;

&lt;p&gt;We could avoid building a new list by sth like:&lt;/p&gt;
&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;(&lt;span class=&quot;code-keyword&quot;&gt;if&lt;/span&gt; (list? args)
  args
  (apply list args))&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;
&lt;p&gt;(btw, &apos;vec&apos; also creates a new vector even when the argument itself is a vector)&lt;/p&gt;

&lt;p&gt;The contract of next seems to be to return a seq, not a list - its docstring reads: &lt;em&gt;&quot;Returns a seq of the items after the first. Calls seq on its argument. If there are no more items, returns nil.&quot;&lt;/em&gt;&lt;/p&gt;

&lt;p&gt;Btw, in some Lisp/Scheme impls I checked, cons seems to be a list as well. E.g. in CLisp (and similar in Guile and Racket):&lt;/p&gt;
&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;&amp;gt; (listp (cons 2 &apos;()))
T
&amp;gt; (listp (list* 1 2 &apos;()))
T&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="11792" name="list-star-fix.diff" size="2783" author="mnicky" created="Fri, 4 Jan 2013 13:50:20 -0600" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10000" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Patch</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10002">Code and Test</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[CLJ-1151] Minor Code Cleanup in core.reducers: use required walk, drop this for coll</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1151</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;First, core.reducers requires clojure.walk :as walk, but does not use the alias.  &lt;br/&gt;
Second, the two arity implementation of coll-reduce in function reducer uses &apos;this&apos;, whereas similar implementations in that file use &apos;coll&apos;.  AFAICT it makes no difference to use &apos;coll&apos; (all tests pass, no change in performance) and it is more in line with the rest of the code.&lt;/p&gt;

&lt;p&gt;The two things seem small enough to be put into one cleanup case.&lt;/p&gt;</description>
                <environment></environment>
            <key id="15972">CLJ-1151</key>
            <summary>Minor Code Cleanup in core.reducers: use required walk, drop this for coll</summary>
                <type id="4" iconUrl="http://dev.clojure.org/jira/images/icons/improvement.gif">Enhancement</type>
                                <priority id="5" iconUrl="http://dev.clojure.org/jira/images/icons/priority_trivial.gif">Trivial</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="ska2342">Stefan Kamphausen</reporter>
                        <labels>
                    </labels>
                <created>Mon, 21 Jan 2013 16:43:30 -0600</created>
                <updated>Mon, 21 Jan 2013 16:43:30 -0600</updated>
                                    <version>Release 1.5</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                <attachments>
                    <attachment id="11810" name="tiny-reducers-cleanup.diff" size="1172" author="ska2342" created="Mon, 21 Jan 2013 16:43:30 -0600" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10000" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Patch</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10001">Code</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[CLJ-1088] repl/source could support protocol functions</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1088</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;user=&amp;gt; (source clojure.core.protocols/coll-reduce)
Source not found&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;But since the protocol fn&apos;s var&apos;s metadata points to the protocol var, and the protocol var knows the file and line where it was defined, it would be trivial to improve &apos;source&apos; to look like this:&lt;/p&gt;

&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;user=&amp;gt; (source clojure.core.protocols/coll-reduce)
(defprotocol CollReduce
  &quot;Protocol &lt;span class=&quot;code-keyword&quot;&gt;for&lt;/span&gt; collection types that can implement reduce faster than
  first/next recursion. Called by clojure.core/reduce. Baseline
  implementation defined in terms of Iterable.&quot;
  (coll-reduce [coll f] [coll f val]))&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;</description>
                <environment></environment>
            <key id="15763">CLJ-1088</key>
            <summary>repl/source could support protocol functions</summary>
                <type id="4" iconUrl="http://dev.clojure.org/jira/images/icons/improvement.gif">Enhancement</type>
                                <priority id="5" iconUrl="http://dev.clojure.org/jira/images/icons/priority_trivial.gif">Trivial</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="chouser@n01se.net">Chouser</reporter>
                        <labels>
                    </labels>
                <created>Sun, 21 Oct 2012 09:53:35 -0500</created>
                <updated>Sun, 21 Oct 2012 12:41:12 -0500</updated>
                                    <version>Release 1.5</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>1</watches>
                        <comments>
                    <comment id="29737" author="chouser@n01se.net" created="Sun, 21 Oct 2012 10:00:50 -0500"  >&lt;p&gt;Add one-line patch to clojure.repl/source so that it will find the protocol definition for a given protocol function.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="11592" name="0001-Add-support-for-protocol-fns-to-repl-source.-CLJ-1088.patch" size="1965" author="chouser@n01se.net" created="Sun, 21 Oct 2012 10:00:50 -0500" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10000" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Patch</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10001">Code</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[CLJ-1167] repl value of *file* is &quot;NO_SOURCE_PATH&quot;, of *source-path* is &quot;NO_SOURCE_FILE&quot;</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1167</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description></description>
                <environment></environment>
            <key id="16020">CLJ-1167</key>
            <summary>repl value of *file* is &quot;NO_SOURCE_PATH&quot;, of *source-path* is &quot;NO_SOURCE_FILE&quot;</summary>
                <type id="1" iconUrl="http://dev.clojure.org/jira/images/icons/bug.gif">Defect</type>
                                <priority id="5" iconUrl="http://dev.clojure.org/jira/images/icons/priority_trivial.gif">Trivial</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="marick">Brian Marick</reporter>
                        <labels>
                    </labels>
                <created>Tue, 19 Feb 2013 16:22:10 -0600</created>
                <updated>Tue, 19 Feb 2013 16:22:52 -0600</updated>
                                    <version>Release 1.5</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                        <comments>
                    <comment id="30620" author="marick" created="Tue, 19 Feb 2013 16:22:52 -0600"  >&lt;p&gt;Forgot to mention: I think it&apos;s intended to be the other way around, given the names.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                                                                                            </customfields>
    </item>

<item>
            <title>[CLJ-1078] Added queue, queue* and queue? to clojure.core</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1078</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;This patch adds functions for PersistentQueue. queue, queue? and queue* match the list functions of the same naming conventions. Patches include updates to tests. &lt;/p&gt;</description>
                <environment></environment>
            <key id="15723">CLJ-1078</key>
            <summary>Added queue, queue* and queue? to clojure.core</summary>
                <type id="4" iconUrl="http://dev.clojure.org/jira/images/icons/improvement.gif">Enhancement</type>
                                <priority id="5" iconUrl="http://dev.clojure.org/jira/images/icons/priority_trivial.gif">Trivial</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="halgari">Timothy Baldridge</reporter>
                        <labels>
                        <label>data-structures</label>
                        <label>queue</label>
                    </labels>
                <created>Wed, 26 Sep 2012 23:38:59 -0500</created>
                <updated>Sat, 6 Apr 2013 08:06:15 -0500</updated>
                                    <version>Release 1.5</version>
                                                        <due></due>
                    <votes>2</votes>
                        <watches>2</watches>
                        <comments>
                    <comment id="29551" author="jafingerhut" created="Fri, 28 Sep 2012 08:43:06 -0500"  >&lt;p&gt;Timothy, I tried applying both of these Sep 26, 2012 patches to latest Clojure master as of that date.  I had to apply 0001-make-PersistentQueue-ctor-public.patch by hand since it failed to apply using git or patch.  It built fine, but failed to pass several of the Clojure tests.  Have you looked into those test failures to see if you can find the cause and fix them?  I tested on Ubuntu 11.10 with Oracle JDK 1.6 and 1.7, and saw similar failures with both.&lt;/p&gt;</comment>
                    <comment id="29817" author="halgari" created="Fri, 26 Oct 2012 17:23:06 -0500"  >&lt;p&gt;Fixed the patch. Tests pass, created the patch, applied it to a different copy of the source and the tests still pass. So this new patch should be good to go.&lt;/p&gt;</comment>
                    <comment id="29818" author="jafingerhut" created="Fri, 26 Oct 2012 17:43:43 -0500"  >&lt;p&gt;Timothy, I&apos;m not sure how you are getting successful results when applying this patch.  Can you try the steps below and see what happens for you?  I get errors trying to apply the patch with latest Clojure master as of Oct 26, 2012.  Also please use the steps on the JIRA workflow page to create a git format patch (&lt;a href=&quot;http://dev.clojure.org/display/design/JIRA+workflow&quot;&gt;http://dev.clojure.org/display/design/JIRA+workflow&lt;/a&gt; under &quot;Development&quot; heading).&lt;/p&gt;

&lt;p&gt;% git clone git://github.com/clojure/clojure.git&lt;br/&gt;
% cd clojure&lt;br/&gt;
% patch -p1 &amp;lt; queues.patch&lt;br/&gt;
patching file src/clj/clojure/core.clj&lt;br/&gt;
patching file src/jvm/clojure/lang/PersistentQueue.java&lt;br/&gt;
Hunk #1 FAILED at 32.&lt;br/&gt;
1 out of 1 hunk FAILED &amp;#8211; saving rejects to file src/jvm/clojure/lang/PersistentQueue.java.rej&lt;br/&gt;
patching file test/clojure/test_clojure/data_structures.clj&lt;br/&gt;
Hunk #1 succeeded at 123 with fuzz 2.&lt;br/&gt;
Hunk #2 succeeded at 861 with fuzz 2.&lt;br/&gt;
Hunk #3 FAILED at 872.&lt;br/&gt;
1 out of 3 hunks FAILED &amp;#8211; saving rejects to file test/clojure/test_clojure/data_structures.clj.rej&lt;br/&gt;
patching file test/clojure/test_clojure/java_interop.clj&lt;/p&gt;</comment>
                    <comment id="29821" author="halgari" created="Fri, 26 Oct 2012 18:08:27 -0500"  >&lt;p&gt;I was using git apply. I tried the method you show above, and now I&apos;m seeing the same issues you show above. &lt;/p&gt;</comment>
                    <comment id="29822" author="jafingerhut" created="Fri, 26 Oct 2012 18:26:54 -0500"  >&lt;p&gt;Just so you know, the preferred way to create and apply patches are the &quot;git format-patch master --stdout &amp;gt; patch.txt&quot; to create a patch (after doing the branching commands described on the JIRA workflow page to create a branch for your changes), and the &quot;git am --keep-cr -s &amp;lt; patch.txt&quot; to apply a patch.  If a patch was created that way and applies cleanly with that command, then you are definitely good to go.&lt;/p&gt;

&lt;p&gt;The &quot;patch -p1 &amp;lt; patch.txt&quot; command is just a secondary method sometimes used to try to apply patches that aren&apos;t in the format produced above, or have errors when applying using that method.&lt;/p&gt;</comment>
                    <comment id="29824" author="halgari" created="Fri, 26 Oct 2012 21:15:43 -0500"  >&lt;p&gt;Just so you know, the preferred way to create and apply patches are the &quot;git format-patch master --stdout &amp;gt; patch.txt&quot; to create a patch (after doing the branching commands described on the JIRA workflow page to create a branch for your changes), and the &quot;git am --keep-cr -s &amp;lt; patch.txt&quot; to apply a patch. If a patch was created that way and applies cleanly with that command, then you are definitely good to go.&lt;/p&gt;

&lt;p&gt;The &quot;patch -p1 &amp;lt; patch.txt&quot; command is just a secondary method sometimes used to try to apply patches that aren&apos;t in the format produced above, or have errors when applying using that method.&lt;/p&gt;</comment>
                    <comment id="29825" author="halgari" created="Fri, 26 Oct 2012 21:16:07 -0500"  >&lt;p&gt;added patch&lt;/p&gt;</comment>
                    <comment id="29826" author="jafingerhut" created="Fri, 26 Oct 2012 21:37:45 -0500"  >&lt;p&gt;That one applies cleanly and passes all tests.  It should show up on the next list of prescreened patches.  Thanks.&lt;/p&gt;</comment>
                    <comment id="30086" author="richhickey" created="Thu, 29 Nov 2012 09:54:51 -0600"  >&lt;p&gt;we don&apos;t use the queue* convention elsewhere, e.g. vec and vector. I think queue should take a collection like vec and set. (queue &lt;span class=&quot;error&quot;&gt;&amp;#91;1 2 3&amp;#93;&lt;/span&gt;) could be made to &apos;adopt&apos; the collection as front.&lt;/p&gt;</comment>
                    <comment id="30215" author="jafingerhut" created="Tue, 11 Dec 2012 13:00:59 -0600"  >&lt;p&gt;Patch queue.patch dated Oct 26 2012 no longer applies cleanly after recent &lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-1000&quot; title=&quot;Performance drop in PersistentHashMap.valAt(...) in v.1.4 -- Util.hasheq(...) ?&quot;&gt;&lt;del&gt;CLJ-1000&lt;/del&gt;&lt;/a&gt; commits, but only because of one line of changed patch context.  It still applies cleanly with &quot;patch -p1 &amp;lt; queue.patch&quot;.  Not bothering to update the stale patch given Rich&apos;s comments suggesting more substantive changes.&lt;/p&gt;</comment>
                    <comment id="30883" author="steveminer@gmail.com" created="Sat, 6 Apr 2013 08:06:15 -0500"  >&lt;p&gt;See also &lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-976&quot; title=&quot;Implement reader literal and print support for PersistentQueue data structure&quot;&gt;CLJ-976&lt;/a&gt; (tagged literal support for PersistentQueue)&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="11622" name="queue.patch" size="6548" author="halgari" created="Fri, 26 Oct 2012 21:16:07 -0500" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10000" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Patch</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10002">Code and Test</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[CLJ-1192] vec function is substantially slower than into function</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1192</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;&lt;tt&gt;(vec coll)&lt;/tt&gt; and &lt;tt&gt;(into [] coll)&lt;/tt&gt; do exactly the same thing. However, due to &lt;tt&gt;into&lt;/tt&gt; using transients, it is substantially faster. On my machine:&lt;/p&gt;

&lt;p&gt;(time (dotimes &lt;span class=&quot;error&quot;&gt;&amp;#91;_ 100&amp;#93;&lt;/span&gt; (vec (range 100000))))&lt;br/&gt;
&quot;Elapsed time: 732.56 msecs&quot;&lt;/p&gt;

&lt;p&gt;(time (dotimes &lt;span class=&quot;error&quot;&gt;&amp;#91;_ 100&amp;#93;&lt;/span&gt; (into [] (range 100000))))&lt;br/&gt;
&quot;Elapsed time: 491.411 msecs&quot;&lt;/p&gt;

&lt;p&gt;This is consistently repeatable.&lt;/p&gt;

&lt;p&gt;Since &lt;tt&gt;vec&lt;/tt&gt;&apos;s sole purpose is to transform collections into vectors, it should do so at the maximum speed available.&lt;/p&gt;</description>
                <environment></environment>
            <key id="16129">CLJ-1192</key>
            <summary>vec function is substantially slower than into function</summary>
                <type id="1" iconUrl="http://dev.clojure.org/jira/images/icons/bug.gif">Defect</type>
                                <priority id="5" iconUrl="http://dev.clojure.org/jira/images/icons/priority_trivial.gif">Trivial</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="lvanderhart">Luke VanderHart</reporter>
                        <labels>
                    </labels>
                <created>Sat, 6 Apr 2013 14:06:22 -0500</created>
                <updated>Sun, 7 Apr 2013 17:50:41 -0500</updated>
                                    <version>Release 1.5</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                        <comments>
                    <comment id="30903" author="jafingerhut" created="Sun, 7 Apr 2013 17:50:41 -0500"  >&lt;p&gt;I am pretty sure that Clojure 1.5.1 also uses transient vectors for (vec (range n)) (probably also some earlier versions of Clojure, too).&lt;/p&gt;

&lt;p&gt;Look at vec in core.clj.  It checks whether its arg is a java.util.Collection, which lazy seqs are, so calls (clojure.lang.LazilyPersistentVector/create coll).&lt;/p&gt;

&lt;p&gt;LazilyPersistentVector&apos;s create method checks whether its argument is an ISeq, which lazy seqs are, so it calls PersistentVector.create(RT.seq(coll)).&lt;/p&gt;

&lt;p&gt;All 3 of PersistentVector&apos;s create() methods use transient vectors to build up the result.&lt;/p&gt;

&lt;p&gt;I suspect the difference in run times are not because of transients or not, but because of the way into uses reduce, and perhaps may also have something to do with the perhaps-unnecessary call to RT.seq in LazilyPersistentVector&apos;s create method (in this case, at least &amp;#8211; it is likely needed for other types of arguments).&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                                                                                            </customfields>
    </item>

<item>
            <title>[CLJ-999] Wrong link in gh-pages index (api-index.html)</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-999</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;The api-index.html includes wrong links for the following:&lt;/p&gt;
&lt;ul class=&quot;alternate&quot; type=&quot;square&quot;&gt;
	&lt;li&gt;All entries for all listed as part of clojure.test.tap&lt;/li&gt;
	&lt;li&gt;All entries for all listed as part of clojure.test.junit&lt;/li&gt;
	&lt;li&gt;All entries for all listed as part of clojure.core.protocols&lt;/li&gt;
&lt;/ul&gt;


&lt;p&gt;The links point to pages that do not exist. The problem is that the documentation for those entries is on a &quot;parent&quot; page, for example, the link clojure.core.protocols-api.html#clojure.core.protocols/internal-reduce should have been clojure.core-api.html#clojure.core.protocols/internal-reduce&lt;/p&gt;

&lt;p&gt;Not a huge bug for me, but you might want to get it fixed.&lt;/p&gt;

&lt;p&gt;And please give my huge thanks to whoever is in charge of the documentation, I&apos;m the developer behind Dash, a Mac OS X documentation browser, and I was in the process of creating a documentation set for Clojure, and because you guys have an index, you made my work 1000 times easier.&lt;/p&gt;</description>
                <environment></environment>
            <key id="15459">CLJ-999</key>
            <summary>Wrong link in gh-pages index (api-index.html)</summary>
                <type id="1" iconUrl="http://dev.clojure.org/jira/images/icons/bug.gif">Defect</type>
                                <priority id="5" iconUrl="http://dev.clojure.org/jira/images/icons/priority_trivial.gif">Trivial</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="tomfaulhaber">Tom Faulhaber</assignee>
                                <reporter username="bogdansrc">Bogdan Popescu</reporter>
                        <labels>
                        <label>docs</label>
                        <label>documentation</label>
                    </labels>
                <created>Fri, 18 May 2012 21:58:46 -0500</created>
                <updated>Fri, 10 May 2013 16:00:55 -0500</updated>
                                    <version>Release 1.3</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>1</watches>
                        <comments>
                    <comment id="30732" author="jafingerhut" created="Mon, 11 Mar 2013 15:01:12 -0500"  >&lt;p&gt;Is this fixed now?  Tom Faulhaber has regenerated the docs after the recent Clojure 1.5 release, and I think updated other things besides, so it might be.&lt;/p&gt;</comment>
                    <comment id="30734" author="tomfaulhaber" created="Mon, 11 Mar 2013 16:43:15 -0500"  >&lt;p&gt;Nope, not fixed.&lt;/p&gt;

&lt;p&gt;This one either slipped by me or came in right when I was changing jobs so didn&apos;t stick in my brain.&lt;/p&gt;

&lt;p&gt;I&apos;ll take a look now. Thanks for the report, Bogdan, and thanks for the bump, Andy to get it on my radar.&lt;/p&gt;</comment>
                    <comment id="31081" author="cldwalker" created="Fri, 10 May 2013 16:00:55 -0500"  >&lt;p&gt;Tom, I&apos;m happy to help if you need it. Could you document on a wiki page how autodoc is run here? I couldn&apos;t find such a page.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10000" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Patch</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10000">None</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>

<item>
            <title>[CLJ-1209] Teach clojure.test reporting about ex-info/ex-data</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1209</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;When clojure.test/deftest does error reports on unexpected exceptions it currently ignores ExceptionInfo and the valuable ex-data it carries. So this patch simple prints this data, it might be helpful to pprint or format it in another way but this was good enough for me.&lt;/p&gt;

&lt;p&gt;See example from my tests: &lt;a href=&quot;https://gist.github.com/thheller/5559391&quot;&gt;https://gist.github.com/thheller/5559391&lt;/a&gt;&lt;/p&gt;
</description>
                <environment></environment>
            <key id="16182">CLJ-1209</key>
            <summary>Teach clojure.test reporting about ex-info/ex-data</summary>
                <type id="4" iconUrl="http://dev.clojure.org/jira/images/icons/improvement.gif">Enhancement</type>
                                <priority id="5" iconUrl="http://dev.clojure.org/jira/images/icons/priority_trivial.gif">Trivial</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="thheller">Thomas Heller</reporter>
                        <labels>
                    </labels>
                <created>Sat, 11 May 2013 04:12:35 -0500</created>
                <updated>Sat, 11 May 2013 04:12:35 -0500</updated>
                                                                            <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                <attachments>
                    <attachment id="11989" name="clj-test-print-ex-data.diff" size="1313" author="thheller" created="Sat, 11 May 2013 04:12:35 -0500" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10000" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Patch</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10001">Code</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>
</channel>
</rss>