<!--
RSS generated by JIRA (4.4#649-r158309) at Thu Jun 20 04:53:04 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+ORDER+BY+updated+DESC%2C+priority+DESC%2C+created+ASC&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+ORDER+BY+updated+DESC%2C+priority+DESC%2C+created+ASC</link>
        <description>An XML representation of a search request</description>
                <language>en-us</language>
                        <issue start="0" end="1000" total="1014"/>
                <build-info>
            <version>4.4</version>
            <build-number>649</build-number>
            <build-date>25-07-2011</build-date>
        </build-info>
<item>
            <title>[CLJ-1220] instance? should either verify all operands or throw if more than one passed</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1220</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;(instance? Number 1)        ;; =&amp;gt; true&lt;br/&gt;
(instance? Number &quot;a&quot;)      ;; =&amp;gt; false&lt;br/&gt;
(instance? Number 1 &quot;a&quot;)    ;; =&amp;gt; true&lt;/p&gt;

&lt;p&gt;I find behavior of the last expression very surprising, I would&lt;br/&gt;
expect it to either desugar to logical &quot;and&quot; over all operands:&lt;/p&gt;

&lt;p&gt;(and (instance? Number 1) (instance? Number &quot;a&quot;) ...)&lt;/p&gt;

&lt;p&gt;Or throw &quot;Wrong number of args (3) passed to instance?&quot; exception.&lt;/p&gt;</description>
                <environment></environment>
            <key id="16243">CLJ-1220</key>
            <summary>instance? should either verify all operands or throw if more than one passed</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="gozala">Irakli Gozalishvili</reporter>
                        <labels>
                    </labels>
                <created>Wed, 19 Jun 2013 13:56:04 -0500</created>
                <updated>Wed, 19 Jun 2013 17:32:14 -0500</updated>
                                    <version>Release 1.5</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                        <comments>
                    <comment id="31314" author="jafingerhut" created="Wed, 19 Jun 2013 17:32:14 -0500"  >&lt;p&gt;Irakli, one of the patches for &lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-1171&quot; title=&quot;Compiler macro for clojure.core/instance? disregards lexical shadows on class names&quot;&gt;CLJ-1171&lt;/a&gt; addresses this issue by causing (instance? Number 1 &quot;a&quot;) to throw a Wrong number of args (3) passed to core$instance-QMARK- ArityException.&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-1219] Make identical? variadic</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1219</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;(= 1 1 1)             ;; =&amp;gt; true&lt;br/&gt;
(= 1 1 2)             ;; =&amp;gt; false&lt;br/&gt;
(== 1 1 1)            ;; =&amp;gt; true&lt;br/&gt;
(== 1 1 2)            ;; =&amp;gt; false&lt;br/&gt;
(identical? 1 1 1)    ;; ArityException Wrong number of args (3) passed to: core$identical-QMARK-  clojure.lang.AFn.throwArity (AFn.java:437)&lt;/p&gt;

&lt;p&gt;I think it would make far more sense to make identical? consistent with all other comparison operators&lt;br/&gt;
and allow it to take variadic number of arguments.&lt;/p&gt;</description>
                <environment></environment>
            <key id="16242">CLJ-1219</key>
            <summary>Make identical? variadic</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="gozala">Irakli Gozalishvili</reporter>
                        <labels>
                    </labels>
                <created>Wed, 19 Jun 2013 13:44:56 -0500</created>
                <updated>Wed, 19 Jun 2013 13:44:56 -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-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>Wed, 19 Jun 2013 10:51:27 -0500</updated>
                                                                            <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                        <comments>
                    <comment id="31311" author="stu" created="Wed, 19 Jun 2013 10:07:14 -0500"  >&lt;p&gt;Am I right in assuming that the only way we will know this works is by trying it in a release? &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="31312" author="stuart.sierra" created="Wed, 19 Jun 2013 10:51:27 -0500"  >&lt;p&gt;Yes.&lt;/p&gt;</comment>
                </comments>
                    <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_10002" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Approval</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10007">Ok</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-1218] mapcat is not very lazy</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1218</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;The following expression prints &lt;tt&gt;1234&lt;/tt&gt; and returns &lt;tt&gt;1&lt;/tt&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;(first (mapcat #(&lt;span class=&quot;code-keyword&quot;&gt;do&lt;/span&gt; (print %) [%]) &apos;(1 2 3 4 5 6 7)))&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;The reason is that &lt;tt&gt;(apply concat args)&lt;/tt&gt; is not maximally lazy in its arguments, and indeed will realize the first four before returning the first item. This in turn is essentially unavoidable for a variadic &lt;tt&gt;concat&lt;/tt&gt;.&lt;/p&gt;

&lt;p&gt;This could either be fixed just in &lt;tt&gt;mapcat&lt;/tt&gt;, or by adding a new function (to &lt;tt&gt;clojure.core&lt;/tt&gt;?) that is a non-variadic equivalent to &lt;tt&gt;concat&lt;/tt&gt;, and reimplementing &lt;tt&gt;mapcat&lt;/tt&gt; with it:&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 join
  &lt;span class=&quot;code-quote&quot;&gt;&quot;Lazily concatenates a sequence-of-sequences into a flat sequence.&quot;&lt;/span&gt;
  [s]
  (lazy-seq (concat (first s) (concats (&lt;span class=&quot;code-keyword&quot;&gt;rest&lt;/span&gt; s)))))&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;</description>
                <environment></environment>
            <key id="16232">CLJ-1218</key>
            <summary>mapcat is not very lazy</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="gfredericks">Gary Fredericks</reporter>
                        <labels>
                    </labels>
                <created>Sun, 16 Jun 2013 22:10:34 -0500</created>
                <updated>Mon, 17 Jun 2013 07:54:44 -0500</updated>
                                    <version>Release 1.5</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                        <comments>
                    <comment id="31288" author="gfredericks" created="Mon, 17 Jun 2013 07:54:44 -0500"  >&lt;p&gt;I realized that &lt;tt&gt;concat&lt;/tt&gt; could actually be made lazier without changing its semantics, if it had a single &lt;tt&gt;&lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;amp; args&amp;#93;&lt;/span&gt;&lt;/tt&gt; clause that was then implemented similarly to &lt;tt&gt;join&lt;/tt&gt; above.&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-1217] for consumes sequence argument more eagerly than necessary</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1217</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;In a call like (do (for &lt;span class=&quot;error&quot;&gt;&amp;#91;x (do (println &amp;quot;realized&amp;quot;) nil)&amp;#93;&lt;/span&gt; x) nil), no elements of the for comprehension are ever requested, and so it is not actually necessary to evaluate the inner do-block. However, this expression causes &quot;realized&quot; to be printed, because the first sequence-expression in for is evaluated even if no items are ever requested from the output lazy-seq.&lt;/p&gt;

&lt;p&gt;It&apos;s not documented whether this is intended or unintentional, but I was surprised by this behavior, and a brief unscientific survey on #clojure suggests that other users, even &quot;old hands&quot; who&apos;ve been using clojure for years, don&apos;t expect this either.&lt;/p&gt;

&lt;p&gt;I&apos;ve attached a patch that wraps the problematic expression in a lazy-seq call. This is not quite ideal, because it means that the first iteration is &quot;lazied&quot; twice, as in ((fn step &lt;span class=&quot;error&quot;&gt;&amp;#91;s&amp;#93;&lt;/span&gt; (lazy-seq ...)) (lazy-seq xs)), but a change to make this not happen would be much broader in scope, and this seemed the least dangerous.&lt;/p&gt;</description>
                <environment></environment>
            <key id="16228">CLJ-1217</key>
            <summary>for consumes sequence argument more eagerly than necessary</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="amalloy">Alan Malloy</reporter>
                        <labels>
                    </labels>
                <created>Fri, 14 Jun 2013 14:35:23 -0500</created>
                <updated>Fri, 14 Jun 2013 14:36:08 -0500</updated>
                                                                            <due></due>
                    <votes>0</votes>
                        <watches>1</watches>
                                <attachments>
                    <attachment id="12030" name="0001-Don-t-realize-seq-exprs-in-for-unless-necessary.patch" size="841" author="amalloy" created="Fri, 14 Jun 2013 14:35:23 -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-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>Fri, 14 Jun 2013 14:17:35 -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>
                    <comment id="31266" author="amalloy" created="Fri, 14 Jun 2013 14:17:35 -0500"  >&lt;p&gt;I&apos;m pretty sure the difference is that into uses reduce: since reducers were added in 1.5, chunked sequences know how to reduce themselves without creating unnecessary cons cells. PersistentVector/create doesn&apos;t use reduce, so it has to allocate a cons cell for each item in the sequence.&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-1125] Clojure can leak memory when used in a servlet container</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1125</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;When used within a servlet container&lt;br/&gt;
(Jetty/Tomcat/JBossAS/Immutant/etc), the thread locals Var.dvals (used&lt;br/&gt;
to store dynamic bindings) and LockingTransaction.transaction (used to&lt;br/&gt;
store the currently active transaction(s)) prevent all of the classes&lt;br/&gt;
loaded by an application&apos;s clojure runtime from being garbage collected, &lt;br/&gt;
resulting in a memory leak.&lt;/p&gt;

&lt;p&gt;The issue comes from threads living beyond the lifetime of a&lt;br/&gt;
deployment - servlet containers use thread pools that are shared&lt;br/&gt;
across all applications within the container. Currently, the dvals and&lt;br/&gt;
transaction thread locals are not discarded when they are no longer&lt;br/&gt;
needed, causing their contents to retain a hard reference to their&lt;br/&gt;
classloaders, which, in turn, causes all of the classes loaded under&lt;br/&gt;
the application&apos;s classloader to be retained until the thread exits&lt;br/&gt;
(which is generally at JVM shutdown).&lt;/p&gt;

&lt;p&gt;I&apos;ve attached a patch that does the following:&lt;/p&gt;

&lt;ul&gt;
	&lt;li&gt;Var.dvals is now removed when the thread bindings are popped&lt;/li&gt;
	&lt;li&gt;Var.dvals no longer has an initialValue, so checking to see if it is&lt;br/&gt;
  set will no longer set it to an empty Frame&lt;/li&gt;
	&lt;li&gt;The outer transaction in LockingTransaction.transaction now removes&lt;br/&gt;
  the thread local when it is finished&lt;/li&gt;
&lt;/ul&gt;


&lt;p&gt;There is still the opportunity for memory leaks if agents or futures &lt;br/&gt;
are used, and the executors used for them are not shutdown when the&lt;br/&gt;
app is undeployed. That&apos;s a solvable problem, but should probably be&lt;br/&gt;
solved by the containers themselves (and/or the war generation tools) &lt;br/&gt;
instead of in clojure itself.&lt;/p&gt;

&lt;p&gt;This patch has a small performance impact: its use of a try/finally &lt;br/&gt;
around running transactions to remove the outer transaction adds &lt;br/&gt;
4-6 microseconds to each transaction call on my hardware.&lt;/p&gt;

&lt;p&gt;Providing an automated test for this patch is difficult - I&apos;ve tested&lt;br/&gt;
it locally with repeated deployments to a container while monitoring&lt;br/&gt;
GC and permgen. All of clojure&apos;s tests pass with it applied.&lt;/p&gt;

&lt;p&gt;The above is a condensation of:&lt;br/&gt;
&lt;a href=&quot;https://groups.google.com/d/topic/clojure-dev/3CXDe8_9G58/discussion&quot;&gt;https://groups.google.com/d/topic/clojure-dev/3CXDe8_9G58/discussion&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;I&apos;m happy to provide whatever feedback/work is needed to get this&lt;br/&gt;
applied.&lt;/p&gt;</description>
                <environment></environment>
            <key id="15882">CLJ-1125</key>
            <summary>Clojure can leak memory when used in a servlet container</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="stu">Stuart Halloway</assignee>
                                <reporter username="tcrawley">Toby Crawley</reporter>
                        <labels>
                    </labels>
                <created>Tue, 11 Dec 2012 15:01:15 -0600</created>
                <updated>Fri, 14 Jun 2013 10:56:13 -0500</updated>
                                                    <fixVersion>Release 1.6</fixVersion>
                                        <due></due>
                    <votes>9</votes>
                        <watches>8</watches>
                        <comments>
                    <comment id="31088" author="trptcolin" created="Mon, 13 May 2013 19:30:16 -0500"  >&lt;p&gt;This patch works great for me to avoid OOM/PermGen crashes from classloaders being retained &lt;span class=&quot;error&quot;&gt;&amp;#91;mine is a non-servlet use case&amp;#93;&lt;/span&gt;.&lt;/p&gt;</comment>
                    <comment id="31141" author="stu" created="Fri, 24 May 2013 09:43:33 -0500"  >&lt;p&gt;Does Tomcat create warnings for Clojure, as described e.g. &lt;a href=&quot;http://stackoverflow.com/questions/5292349/is-this-very-likely-to-create-a-memory-leak-in-tomcat&quot;&gt;here&lt;/a&gt;?&lt;/p&gt;

&lt;p&gt;If so, does this patch make the warnings go away?&lt;/p&gt;</comment>
                    <comment id="31142" author="tcrawley" created="Fri, 24 May 2013 09:56:14 -0500"  >&lt;p&gt;Stu: that&apos;s a good question. I&apos;ll take a look at Tomcat this afternoon.&lt;/p&gt;</comment>
                    <comment id="31143" author="stu" created="Fri, 24 May 2013 10:04:04 -0500"  >&lt;p&gt;The code that calls transaction.remove() seems unncessarily subtle.   There are two exits from the method, and only one is protected by the finally block.&lt;/p&gt;

&lt;p&gt;If the &quot;outer&quot; case was a top-level if, the logic would be more clear, and only the &quot;outer&quot; case would need try/finally, which might reduce the performance penalty in the case of deeply nested dosyncs.&lt;/p&gt;

&lt;p&gt;Did your transaction overhead of 4-6 microseconds test only one level of dosync, or many?&lt;/p&gt;</comment>
                    <comment id="31144" author="stu" created="Fri, 24 May 2013 10:13:35 -0500"  >&lt;p&gt;Because the unwind code calls &lt;tt&gt;remove&lt;/tt&gt; at the top (as opposed to &lt;tt&gt;set(null)&lt;/tt&gt;), the code should now be safe for use with Clojure-defined &lt;tt&gt;ThreadLocal&lt;/tt&gt; subclasses.&lt;/p&gt;

&lt;p&gt;Therefore, Var&apos;s use of an &lt;tt&gt;initialValue&lt;/tt&gt; should be irrelevant to this patch, and it should be possible to fix this bug with a patch half the size of the current patch, touching only &lt;tt&gt;LockingTransaction.runInTransaction&lt;/tt&gt; and &lt;tt&gt;Var.popThreadBindings&lt;/tt&gt;.&lt;/p&gt;</comment>
                    <comment id="31263" author="tcrawley" created="Fri, 14 Jun 2013 07:38:45 -0500"  >&lt;h3&gt;&lt;a name=&quot;re%3ATomcatThreadLocalwarnings&quot;&gt;&lt;/a&gt;re: Tomcat ThreadLocal warnings&lt;/h3&gt;

&lt;p&gt;With Clojure 1.5.1 using my test app (linked below), I see:&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;Jun 14, 2013 6:35:22 AM org.apache.catalina.loader.WebappClassLoader checkThreadLocalMapForLeaks
SEVERE: The web application [/leak] created a ThreadLocal with key of type [clojure.lang.Var$1] (value [clojure.lang.Var$1@4902919]) and a value of type [clojure.lang.Var.Frame] (value [clojure.lang.Var$Frame@147a2aa6]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak.
Jun 14, 2013 6:35:22 AM org.apache.catalina.loader.WebappClassLoader checkThreadLocalMapForLeaks
SEVERE: The web application [/leak] created a ThreadLocal with key of type [java.lang.ThreadLocal] (value [java.lang.ThreadLocal@608602ca]) and a value of type [clojure.lang.LockingTransaction] (value [clojure.lang.LockingTransaction@7e214d47]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak.
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;With the original patch (threadlocal-removal-tcrawley-2012-12-11.diff) and the one attached today (threadlocal-removal-tcrawley-2013-06-14.diff), I no longer see these warnings.&lt;/p&gt;

&lt;h3&gt;&lt;a name=&quot;re%3Athe%7B%7BLockingTransaction.runInTransaction%7D%7Dchanges&quot;&gt;&lt;/a&gt;re: the &lt;tt&gt;LockingTransaction.runInTransaction&lt;/tt&gt; changes&lt;/h3&gt;

&lt;p&gt;In today&apos;s patch (threadlocal-removal-tcrawley-2013-06-14.diff), I modified &lt;tt&gt;runInTransaction&lt;/tt&gt; to have one exit point, and only wrap a call to &lt;tt&gt;run&lt;/tt&gt; with a try/finally in the outer transaction case. It does introduce two locations where &lt;tt&gt;run&lt;/tt&gt; can be called to preserve the case where an inner transaction has null info:&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; &lt;span class=&quot;code-keyword&quot;&gt;public&lt;/span&gt; &lt;span class=&quot;code-object&quot;&gt;Object&lt;/span&gt; runInTransaction(Callable fn) &lt;span class=&quot;code-keyword&quot;&gt;throws&lt;/span&gt; Exception{
	LockingTransaction t = transaction.get();
        &lt;span class=&quot;code-object&quot;&gt;Object&lt;/span&gt; ret;
	&lt;span class=&quot;code-keyword&quot;&gt;if&lt;/span&gt;(t == &lt;span class=&quot;code-keyword&quot;&gt;null&lt;/span&gt;) {
            transaction.set(t = &lt;span class=&quot;code-keyword&quot;&gt;new&lt;/span&gt; LockingTransaction());
            &lt;span class=&quot;code-keyword&quot;&gt;try&lt;/span&gt; {
                ret = t.run(fn);
            } &lt;span class=&quot;code-keyword&quot;&gt;finally&lt;/span&gt; {
                transaction.remove();
            }
        } &lt;span class=&quot;code-keyword&quot;&gt;else&lt;/span&gt; {
            &lt;span class=&quot;code-keyword&quot;&gt;if&lt;/span&gt;(t.info != &lt;span class=&quot;code-keyword&quot;&gt;null&lt;/span&gt;) {
                ret = fn.call();
            } &lt;span class=&quot;code-keyword&quot;&gt;else&lt;/span&gt; {
                ret = t.run(fn);
            }
        }

        &lt;span class=&quot;code-keyword&quot;&gt;return&lt;/span&gt; ret;
}&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;However, this will likely not reduce the speed penalty I observed in my testing, as I was only using a single level of &lt;tt&gt;dosync&lt;/tt&gt; when capturing timing data.&lt;/p&gt;

&lt;h3&gt;&lt;a name=&quot;re%3Aremoving%7B%7BinitialValue%7D%7Dfrom%7B%7Bdvals%7D%7D&quot;&gt;&lt;/a&gt;re: removing &lt;tt&gt;initialValue&lt;/tt&gt; from &lt;tt&gt;dvals&lt;/tt&gt;&lt;/h3&gt;

&lt;p&gt;My original solution kept &lt;tt&gt;initialValue&lt;/tt&gt;, but I then apparently discovered cases where the leak still occurred (see the &lt;a href=&quot;https://groups.google.com/d/topic/clojure-dev/3CXDe8_9G58/discussion&quot;&gt;mailing list thread&lt;/a&gt;).&lt;/p&gt;

&lt;p&gt;Unfortunately, I can neither recreate that case, nor find in my notes, test code, or the clojure code a reason why keeping &lt;tt&gt;initialValue&lt;/tt&gt; would allow the ThreadLocals to leak when &lt;tt&gt;popThreadBindings&lt;/tt&gt; is patched (assuming one doesn&apos;t call &lt;tt&gt;Var.getThreadBindings&lt;/tt&gt; from Java without calling &lt;tt&gt;Var.popThreadBindings&lt;/tt&gt;).&lt;/p&gt;

&lt;p&gt;Therefore, I&apos;ve attached a simpler patch (threadlocal-removal-tcrawley-2013-06-14.diff) that just patches &lt;tt&gt;LockingTransaction.runInTransaction&lt;/tt&gt; and &lt;tt&gt;Var.popThreadBindings&lt;/tt&gt;.&lt;/p&gt;

&lt;p&gt;I&apos;ve also created a &lt;a href=&quot;https://github.com/tobias/threadlocal-leak-check&quot;&gt;project&lt;/a&gt; that demonstrates the leak with 1.5.1, and that the leak does not appear with this patch applied to 1.6.0-master. See its &lt;a href=&quot;https://github.com/tobias/threadlocal-leak-check#threadlocal-leak-check&quot;&gt;README&lt;/a&gt; for usage details.&lt;/p&gt;

&lt;p&gt;The patched version of 1.6.0-master is available as &lt;tt&gt;&lt;span class=&quot;error&quot;&gt;&amp;#91;org.clojars.tcrawley/clojure &amp;quot;1.6.0-clearthreadlocals&amp;quot;&amp;#93;&lt;/span&gt;&lt;/tt&gt; if anyone wants to give it a try in their own projects. Note that since its group isn&apos;t &apos;org.clojure&apos;, you may need to add exclusions to your project to prevent another version of clojure being included.&lt;/p&gt;</comment>
                    <comment id="31265" author="jafingerhut" created="Fri, 14 Jun 2013 10:56:13 -0500"  >&lt;p&gt;Presumptuously changing ticket approval from Incomplete back to its former Vetted state, since Toby&apos;s comments and new patch seem to address the comments that led Stu to change it to Incomplete.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="11756" name="threadlocal-removal-tcrawley-2012-12-11.diff" size="3685" author="tcrawley" created="Tue, 11 Dec 2012 15:01:15 -0600" />
                    <attachment id="12029" name="threadlocal-removal-tcrawley-2013-06-14.diff" size="2157" author="tcrawley" created="Fri, 14 Jun 2013 07:39:16 -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-827] unsigned-bit-shift-right</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-827</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;Add a clojure equivalent of &amp;gt;&amp;gt;&amp;gt;.&lt;/p&gt;

&lt;p&gt;A simple version of this is implemented here (&lt;a href=&quot;https://github.com/joegallo/clojure/tree/unsigned-bit-shift-right&quot;&gt;https://github.com/joegallo/clojure/tree/unsigned-bit-shift-right&lt;/a&gt;), and just follows the example set by shift-right.&lt;/p&gt;

&lt;p&gt;The downside of this implementation is that it treats all integer types as longs, and shifts them accordingly, which yields different results than you would get in java.  A previous version of this did not have the same problem, when BitOps was its own thing.  I&apos;m not sure if this limitation is acceptable and appropriate, or needs to be worked around (my inclination is the latter).&lt;/p&gt;</description>
                <environment></environment>
            <key id="14572">CLJ-827</key>
            <summary>unsigned-bit-shift-right</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="joegallo">Joe Gallo</reporter>
                        <labels>
                    </labels>
                <created>Tue, 9 Aug 2011 11:42:09 -0500</created>
                <updated>Mon, 10 Jun 2013 01:57:52 -0500</updated>
                                                    <fixVersion>Release 1.6</fixVersion>
                                        <due></due>
                    <votes>12</votes>
                        <watches>3</watches>
                        <comments>
                    <comment id="27276" author="joegallo" created="Fri, 11 Nov 2011 12:58:31 -0600"  >&lt;p&gt;I just realized (with the asssistance of Paul Stadig) that just doing only longs is probably sufficient, as you can get the integer version if you really want it: &lt;/p&gt;

&lt;p&gt;&amp;gt; (int (bit-and Integer/MAX_VALUE (unsigned-bit-shift-right -5 1)))&lt;br/&gt;
2147483645 &lt;/p&gt;

&lt;p&gt;Of course, that&apos;s less efficient than just doing it directly with java, but it&apos;s enough that I think my concern from the previous comment is addressed.&lt;/p&gt;
</comment>
                    <comment id="27579" author="timmc" created="Mon, 16 Jan 2012 18:01:02 -0600"  >&lt;p&gt;I have attached &quot;0001-&lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-827&quot; title=&quot;unsigned-bit-shift-right&quot;&gt;CLJ-827&lt;/a&gt;-Add-bit-shift-right-logical.patch&quot;, which implements a logical bit-shift-right using the same JVM bytecode as &amp;gt;&amp;gt;&amp;gt;.&lt;/p&gt;

&lt;p&gt;The patch mimics the implementations of &amp;lt;&amp;lt; and &amp;gt;&amp;gt;.&lt;/p&gt;</comment>
                    <comment id="30534" author="stu" created="Sat, 2 Feb 2013 17:09:24 -0600"  >&lt;p&gt;For context, this feature appears to be needed for Clojure-in-Clojure data structures: &lt;a href=&quot;https://groups.google.com/d/msg/clojure-dev/iAwH7CLSFzE/6wzDH4RS1YQJ&quot;&gt;https://groups.google.com/d/msg/clojure-dev/iAwH7CLSFzE/6wzDH4RS1YQJ&lt;/a&gt;&lt;/p&gt;</comment>
                    <comment id="30570" author="michalmarczyk" created="Fri, 8 Feb 2013 05:31:06 -0600"  >&lt;p&gt;Just wanted to note that I&apos;ve introduced this operation to ClojureScript when implementing PersistentHashMap. The name over there is bit-shift-right-zero-fill. Would it be alright for Clojure to use that name? Failing that, ClojureScript would probably have to change to match.&lt;/p&gt;</comment>
                    <comment id="31153" author="cldwalker" created="Fri, 24 May 2013 14:23:24 -0500"  >&lt;p&gt;I&apos;ve added clj-827-unsigned-bit-shift-right-with-tests.patch which builds off of Tim&apos;s patch and adds tests. I also renamed the new fn to unsigned-bit-shift-right after chatting with Rich.&lt;/p&gt;

&lt;p&gt;@Michal - This may mean you need to rename the cljs fn. After this lands on master, I can open a ticket with a patch if you&apos;d like.&lt;/p&gt;</comment>
                    <comment id="31192" author="michalmarczyk" created="Fri, 31 May 2013 15:43:02 -0500"  >&lt;p&gt;@Gabriel: Thanks! &lt;tt&gt;bit-shift-right-zero-fill&lt;/tt&gt; is not marked private in ClojureScript, so it&apos;ll be a breaking change; if it&apos;s going to happen eventually (that is, if the name is settled), I suppose it&apos;s best to make it without waiting for Clojure.&lt;/p&gt;

&lt;p&gt;At any rate, I went ahead and created &lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJS-514&quot; title=&quot;Coordinate with Clojure on unsigned-bit-shift-right function name&quot;&gt;CLJS-514&lt;/a&gt; to track the coordination effort. No patch attached; if you&apos;d like to do the patching on both sides, that would be cool, otherwise I&apos;ll be happy to provide the CLJS patch.&lt;/p&gt;</comment>
                    <comment id="31208" author="cldwalker" created="Mon, 3 Jun 2013 10:10:17 -0500"  >&lt;p&gt;@Michal - I didn&apos;t mark it private. Are we taking about the same with-tests.patch? I&apos;ll try to get around to the cljs patch but feel free to beat me to it if I&apos;m slow.&lt;/p&gt;</comment>
                    <comment id="31242" author="michalmarczyk" created="Mon, 10 Jun 2013 01:57:52 -0500"  >&lt;p&gt;@Gabriel: I mean it&apos;s not marked private in ClojureScript, so ClojureScript already exports the ...-zero-fill name, technically speaking. As per David Nolen&apos;s comment on &lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJS-514&quot; title=&quot;Coordinate with Clojure on unsigned-bit-shift-right function name&quot;&gt;CLJS-514&lt;/a&gt;, this is probably not a big deal.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="10694" name="0001-add-unsigned-bit-shift-right.patch" size="2301" author="joegallo" created="Fri, 11 Nov 2011 13:03:06 -0600" />
                    <attachment id="10776" name="0001-CLJ-827-Add-bit-shift-right-logical.patch" size="3261" author="timmc" created="Mon, 16 Jan 2012 18:01:02 -0600" />
                    <attachment id="12007" name="clj-827-unsigned-bit-shift-right-with-tests.patch" size="9110" author="cldwalker" created="Fri, 24 May 2013 14:19:49 -0500" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_10002" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Approval</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10004">Screened</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-1184] Evaling #{do ...} or [do ...] is treated as the do special form</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1184</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;Evaluating a persistent collection for which the function &apos;first&apos; returns the symbol &apos;do&apos; leads to that collection being treated as the do special form, even though it may be a vector or even a set. IMHO, the expected result would be to report that &apos;do&apos; cannot be resolved. For the cause, see the if condition on line 6604 of Compiler.java in clojure-1.5.1.&lt;/p&gt;

&lt;p&gt;E.g.:&lt;br/&gt;
&lt;span class=&quot;error&quot;&gt;&amp;#91;do 1 2&amp;#93;&lt;/span&gt;&lt;br/&gt;
;=&amp;gt; 2&lt;/p&gt;

&lt;p&gt;#{&quot;hello&quot; &quot;goodbye&quot; do}&lt;br/&gt;
;=&amp;gt; &quot;hello&quot;&lt;br/&gt;
; Wat?&lt;/p&gt;</description>
                <environment></environment>
            <key id="16093">CLJ-1184</key>
            <summary>Evaling #{do ...} or [do ...] is treated as the do special form</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="jirkamarsik">Ji&#345;&#237; Mar&#353;&#237;k</reporter>
                        <labels>
                        <label>Compiler</label>
                        <label>bug</label>
                    </labels>
                <created>Sat, 16 Mar 2013 08:56:32 -0500</created>
                <updated>Sun, 9 Jun 2013 16:31:55 -0500</updated>
                                    <version>Release 1.5</version>
                                <fixVersion>Release 1.6</fixVersion>
                                        <due></due>
                    <votes>0</votes>
                        <watches>2</watches>
                        <comments>
                    <comment id="31169" author="gfredericks" created="Sun, 26 May 2013 14:13:28 -0500"  >&lt;p&gt;Attached a patch that changes IPersistentCollection to ISeq on the referenced line, and a regression test.&lt;/p&gt;</comment>
                    <comment id="31236" author="bronsa" created="Sun, 9 Jun 2013 14:52:11 -0500"  >&lt;p&gt;As found out on #clojure, there are still some cases where the symbol &quot;do&quot; behaves in unexpected ways that this patch doesn&apos;t address.&lt;/p&gt;

&lt;p&gt;user=&amp;gt; ((fn &lt;span class=&quot;error&quot;&gt;&amp;#91;do&amp;#93;&lt;/span&gt; do) 1)&lt;br/&gt;
nil&lt;br/&gt;
user=&amp;gt; (let &lt;span class=&quot;error&quot;&gt;&amp;#91;do 1&amp;#93;&lt;/span&gt; do)&lt;br/&gt;
nil&lt;/p&gt;</comment>
                    <comment id="31237" author="gfredericks" created="Sun, 9 Jun 2013 15:00:21 -0500"  >&lt;p&gt;Presumably the same issue is the difference between&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;(let [x 5] &lt;span class=&quot;code-keyword&quot;&gt;do&lt;/span&gt; x)&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;which returns &lt;tt&gt;5&lt;/tt&gt; and&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;(let [x 5] &lt;span class=&quot;code-keyword&quot;&gt;do&lt;/span&gt; &lt;span class=&quot;code-keyword&quot;&gt;do&lt;/span&gt; x)&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt; which gives a compile error.&lt;/p&gt;</comment>
                    <comment id="31239" author="bronsa" created="Sun, 9 Jun 2013 16:31:55 -0500"  >&lt;p&gt;This is actually a different bug.&lt;br/&gt;
I created another ticket with patch+test see &lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-1216&quot;&gt;http://dev.clojure.org/jira/browse/CLJ-1216&lt;/a&gt;&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="12015" name="CLJ-1184-p1.patch" size="1676" author="gfredericks" created="Sun, 26 May 2013 14:13:28 -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-1216] Evaling ((fn [do] do) 1) returns nil while ((fn [do] do do) 1) returns 1</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1216</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;user=&amp;gt; ((fn &lt;span class=&quot;error&quot;&gt;&amp;#91;do&amp;#93;&lt;/span&gt; do) 1)&lt;br/&gt;
nil&lt;/p&gt;

&lt;p&gt;user=&amp;gt; ((fn &lt;span class=&quot;error&quot;&gt;&amp;#91;do&amp;#93;&lt;/span&gt; (do do)) 1)&lt;br/&gt;
1&lt;/p&gt;

&lt;p&gt;user=&amp;gt; ((fn [] do))&lt;br/&gt;
nil&lt;/p&gt;

&lt;p&gt;user=&amp;gt; ((fn [] do do))&lt;br/&gt;
CompilerException java.lang.RuntimeException: Unable to resolve symbol: do in this context, compiling:(NO_SOURCE_PATH:0:0) &lt;/p&gt;</description>
                <environment></environment>
            <key id="16222">CLJ-1216</key>
            <summary>Evaling ((fn [do] do) 1) returns nil while ((fn [do] do do) 1) returns 1</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="bronsa">Nicola Mometto</reporter>
                        <labels>
                    </labels>
                <created>Sun, 9 Jun 2013 16:29:14 -0500</created>
                <updated>Sun, 9 Jun 2013 16:31:22 -0500</updated>
                                                                            <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                        <comments>
                    <comment id="31238" author="bronsa" created="Sun, 9 Jun 2013 16:31:22 -0500"  >&lt;p&gt;This patch creates a DoExpr class and makes DoExpr.Parser the DO special form parser.&lt;/p&gt;

&lt;p&gt;DoExpr.Parser simply removes the &apos;do&apos; symbol and delegates to BodyExpr, that was previously done by BodyExpr incorrectly.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="12025" name="0001-Create-a-DoExpr.Parser-class-that-delegates-to-BodyE.patch" size="2181" author="bronsa" created="Sun, 9 Jun 2013 16:31:22 -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>Fri, 7 Jun 2013 19:35:06 -0500</updated>
                                    <version>Release 1.5</version>
                                                        <due></due>
                    <votes>3</votes>
                        <watches>3</watches>
                        <comments>
                    <comment id="31221" author="ztellman" created="Fri, 7 Jun 2013 17:40:38 -0500"  >&lt;p&gt;As a data point, I was recently profiling a Hadoop job where the code made heavy use of &apos;partial&apos;, which apparently unlike &apos;comp&apos; and &apos;juxt&apos;, always uses apply &lt;span class=&quot;error&quot;&gt;&amp;#91;1&amp;#93;&lt;/span&gt;.  As a result, .getComponentType accounted for 41% of the overall compute time.  This might be as much a comment on the implementation of partial as anything else, but it certainly shows that this can have a significant effect on performance.&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;https://github.com/clojure/clojure/blob/master/src/clj/clojure/core.clj#L2388&quot;&gt;https://github.com/clojure/clojure/blob/master/src/clj/clojure/core.clj#L2388&lt;/a&gt;&lt;/p&gt;</comment>
                    <comment id="31222" author="hiredman" created="Fri, 7 Jun 2013 17:46:43 -0500"  >&lt;p&gt;prepRet usage appears to be all about enforcing canonical Boolean values, so I think using Object.class is not the best. Maybe splitting ArraySeq in to ArraySeq and ArraySeqBoolean would be better. ArraySeq would no longer do a prepRet and ArraySeqBoolean would&lt;/p&gt;</comment>
                    <comment id="31223" author="hiredman" created="Fri, 7 Jun 2013 19:19:48 -0500"  >&lt;p&gt;ArraySeq actually already has specialized implementations, and interestingly the specialized boolean implementation doesn&apos;t call prepRet&lt;/p&gt;</comment>
                    <comment id="31224" author="hiredman" created="Fri, 7 Jun 2013 19:35:06 -0500"  >&lt;p&gt;The ArraySeq split I proposed above will fail if you have an array of Objects that happen to be Booleans, it seems like the best bet would be something like preRet that did a instanceof Boolean check without the requirement of passing in a class&lt;/p&gt;</comment>
                </comments>
                    <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-1083] Incorrect ArityException message for function names containing -&gt;</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1083</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;user=&amp;gt; (defn a-&amp;gt;b [])&lt;br/&gt;
#&apos;user/a-&amp;gt;b&lt;br/&gt;
user=&amp;gt; (a-&amp;gt;b 1)&lt;br/&gt;
ArityException Wrong number of args (1) passed to: user$a  clojure.lang.AFn.throwArity (AFn.java:437)&lt;/p&gt;

&lt;p&gt;Note that the reported function name in the stack trace is &quot;user$a&quot;, where it should be &quot;user$a-&amp;gt;b&quot; (or some mangled variant thereof?)&lt;/p&gt;

&lt;p&gt;See discussion here: &lt;a href=&quot;https://groups.google.com/d/msg/clojure/PVNoLclhhB0/_NWqyE0cPAUJ&quot;&gt;https://groups.google.com/d/msg/clojure/PVNoLclhhB0/_NWqyE0cPAUJ&lt;/a&gt;&lt;/p&gt;</description>
                <environment></environment>
            <key id="15742">CLJ-1083</key>
            <summary>Incorrect ArityException message for function names containing -&gt;</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="alexnixon">Alex Nixon</reporter>
                        <labels>
                    </labels>
                <created>Tue, 9 Oct 2012 11:18:48 -0500</created>
                <updated>Fri, 7 Jun 2013 14:01:34 -0500</updated>
                                    <version>Release 1.2</version>
                <version>Release 1.3</version>
                <version>Release 1.4</version>
                <version>Release 1.5</version>
                                <fixVersion>Release 1.6</fixVersion>
                                        <due></due>
                    <votes>2</votes>
                        <watches>1</watches>
                        <comments>
                    <comment id="30034" author="halgari" created="Mon, 26 Nov 2012 10:27:31 -0600"  >&lt;p&gt;Fix for this defect.&lt;/p&gt;</comment>
                    <comment id="30035" author="halgari" created="Mon, 26 Nov 2012 10:30:13 -0600"  >&lt;p&gt;The throwArity now attempts to locate and call clojure.main/demunge. If it finds the function it invokes it and uses the returned string in the error. Otherwise it just throws the actual class name. This results in the following behaviour:&lt;/p&gt;

&lt;p&gt;user=&amp;gt; (defn a-&amp;gt;b [])&lt;br/&gt;
#&apos;user/a-&amp;gt;b&lt;br/&gt;
user=&amp;gt; (a-&amp;gt;b 32)&lt;br/&gt;
ArityException Wrong number of args (1) passed to: user/a-&amp;gt;b  clojure.lang.AFn.throwArity (AFn.java:449)&lt;br/&gt;
user=&amp;gt; &lt;/p&gt;</comment>
                    <comment id="31146" author="stu" created="Fri, 24 May 2013 11:35:04 -0500"  >&lt;p&gt;Timothy: Why the empty catch block? I don&apos;t see anything in the try block whose failure we would want to ignore.&lt;/p&gt;</comment>
                    <comment id="31188" author="halgari" created="Thu, 30 May 2013 14:02:13 -0500"  >&lt;p&gt;The demunge function is created inside of a .clj file. So it is possible that we could hit this exception before demunge exists. The try simply says &quot;if we can get a better error message, use it. Otherwise, fall back to the old (half-broken) method of getting method names&quot;&lt;/p&gt;</comment>
                    <comment id="31220" author="jafingerhut" created="Fri, 7 Jun 2013 14:01:34 -0500"  >&lt;p&gt;Presumptuously changing approval from Incomplete back to its former value of Vetted after Timothy responded to what I believe is the reason it was marked Incomplete (Stu&apos;s question).&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="11710" name="better-throw-arity-messages.diff" size="1340" author="halgari" created="Mon, 26 Nov 2012 10:27:31 -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-1215] Mention where to position docstring when using pre/postconditions on the Special Forms page</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1215</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;The description of pre- and post-conditions doesn&apos;t mention where docstring should be when using them. Placing it wrong will lead to the conditions to be ignored.&lt;/p&gt;

&lt;p&gt;At &lt;a href=&quot;http://clojure.org/Special%20Forms--(fn%20name?%20&quot;&gt;http://clojure.org/Special%20Forms--(fn%20name?%20&lt;/a&gt;&lt;span class=&quot;error&quot;&gt;&amp;#91;params*%20&amp;#93;&lt;/span&gt;%20condition-map?%20exprs*), change&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;(fn name? [params* ] condition-map? exprs*)&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;
&lt;p&gt;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;(fn name? [params* ] condition-map? docstring? exprs*)&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;or at least mention it in the description or use it in the example.&lt;/p&gt;

&lt;p&gt;Thank you!&lt;/p&gt;</description>
                <environment></environment>
            <key id="16220">CLJ-1215</key>
            <summary>Mention where to position docstring when using pre/postconditions on the Special Forms page</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="jakubholynet">Jakub Holy</reporter>
                        <labels>
                        <label>documentation</label>
                    </labels>
                <created>Fri, 7 Jun 2013 03:14:24 -0500</created>
                <updated>Fri, 7 Jun 2013 03:14:24 -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-1214] Compiler runs out of memory on a small snippet of code</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1214</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;Clojure compiler runs out of memory when loading the attached file. Transcript 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;$ java -cp ~/.m2/repository/org/clojure/clojure/1.5.1/clojure-1.5.1.jar:. clojure.main
Clojure 1.5.1
user=&amp;gt; (load &quot;fubar&quot;)
OutOfMemoryError GC overhead limit exceeded  [trace missing]
user=&amp;gt; 
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;The file contents are:&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 fu.bar)

  (defn foo[l] (concat (drop-last l) (repeat (last l))))

  (def ^:const bar (foo [#(print &quot;&quot;) #(println &quot;;&quot;)]))

  bar
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;If I remove the metadata on bar, it works. Removal of namespace seems to fix it as well. Pretty strange.&lt;/p&gt;

&lt;p&gt;Although I realize this code is not quite kosher, it would be nice to have the compiler deal with it.&lt;/p&gt;</description>
                <environment>Linux 3.2.0-39-generic </environment>
            <key id="16215">CLJ-1214</key>
            <summary>Compiler runs out of memory on a small snippet of code</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="praki">Praki Prakash</reporter>
                        <labels>
                    </labels>
                <created>Fri, 31 May 2013 21:33:04 -0500</created>
                <updated>Sun, 2 Jun 2013 04:56:38 -0500</updated>
                                    <version>Release 1.5</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                        <comments>
                    <comment id="31196" author="jafingerhut" created="Sat, 1 Jun 2013 19:40:03 -0500"  >&lt;p&gt;If you really do have &apos;bar&apos; on a line by itself at the end of file fubar.clj, it seems you are asking it to evaluate the value of bar, which by the definitions is an infinite list, and will of course exhaust all available memory if you attempt to evaluate it.&lt;/p&gt;

&lt;p&gt;It seems to me the more odd thing is not that it runs out of memory as shown, but that it does &lt;b&gt;not&lt;/b&gt; run out of memory when you remove the metadata on bar.&lt;/p&gt;

&lt;p&gt;What is the purpose of having &apos;bar&apos; on a line by itself at the end of the file?&lt;/p&gt;

&lt;p&gt;If I try this but remove &apos;bar&apos; as the last line of the file, loading the file causes no errors regardless of whether there is metadata on bar&apos;s definition or not.  It is strange that doing (load &quot;fubar&quot;) followed by (first fu.bar/bar) seems to go into an infinite loop if the :const is there on bar, but quickly returns the correct answer if the metadata is removed.&lt;/p&gt;</comment>
                    <comment id="31197" author="praki" created="Sat, 1 Jun 2013 20:40:55 -0500"  >&lt;p&gt;This code snippet is a minimal test case to show that the compiler runs out of memory. What I meant by &quot;it works&quot; was that the compiler doesn&apos;t run out of memory and successfully loads the file (or in my real code base, the namespace is compiled).&lt;/p&gt;

&lt;p&gt;In my code, I use bar (or whatever the real thing is) as source of sequence of functions. The sole reference to bar is needed to trigger this issue. I believe that bar is not being fully evaluated here and thus no infinite loop. If I try to print it, yes, it will ultimately fail.&lt;/p&gt;
</comment>
                    <comment id="31198" author="praki" created="Sat, 1 Jun 2013 21:04:11 -0500"  >&lt;p&gt;Having thought about this a bit more, it seems to me that when bar is annotated with const, the compiler is trying to evaluate the associated expression which exhausts the heap? I have never looked at the compiler source and thus not sure if this is what is happening. If it is, then it seems like one should be really careful when adding metadata.&lt;/p&gt;

&lt;p&gt;That still leaves the other question about the namespace requirement to cause memory exhaustion. I quite distinctly recall having to add the namespace when trying to come up with minimal test case to reproduce the bug.&lt;/p&gt;

&lt;p&gt;If you think this is really user error, I would accept it &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="31199" author="jafingerhut" created="Sun, 2 Jun 2013 04:56:38 -0500"  >&lt;p&gt;It is not just any old metadata that causes this issue, only :const metadata.  I tried testing with :const replaced with :dynamic and :private, and there was no problem.&lt;/p&gt;

&lt;p&gt;This might shed some light on the issue: &lt;a href=&quot;https://github.com/clojure/clojure/blob/master/changes.md#215-const-defs&quot;&gt;https://github.com/clojure/clojure/blob/master/changes.md#215-const-defs&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;It appears that ^:const is causing the compiler to evaluate the value at compile time.  The value in your example is unbounded, so that can never complete.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="12020" name="fubar.clj" size="127" author="praki" created="Fri, 31 May 2013 21:33: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>
                                                                                                            </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;Original patch added functions for PersistentQueue. queue, queue? and queue* match the list functions of the same naming conventions. Patches include updates to tests. &lt;/p&gt;

&lt;p&gt;In the updated patch, &quot;queue&quot; accepts a single collection argument as per Rich&apos;s suggestion, and does not provide a &quot;queue*&quot;.&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>Fri, 31 May 2013 10:05:34 -0500</updated>
                                    <version>Release 1.5</version>
                                                        <due></due>
                    <votes>3</votes>
                        <watches>3</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>
                    <comment id="31137" author="eigenhombre" created="Thu, 23 May 2013 20:54:15 -0500"  >&lt;p&gt;Don&apos;t want to step on Timothy B&apos;s toes here, but it looks straightforward to adopt his patch to implement Rich&apos;s suggestion.  I&apos;d offer to give it a whack if nobody else wants the ticket now.&lt;/p&gt;</comment>
                    <comment id="31164" author="eigenhombre" created="Sun, 26 May 2013 09:04:43 -0500"  >&lt;p&gt;Discussion initiated on clojure-dev: &lt;a href=&quot;https://groups.google.com/forum/?fromgroups#!topic/clojure-dev/2BOqHm24Vc4&quot;&gt;https://groups.google.com/forum/?fromgroups#!topic/clojure-dev/2BOqHm24Vc4&lt;/a&gt;&lt;/p&gt;</comment>
                    <comment id="31189" author="eigenhombre" created="Fri, 31 May 2013 09:58:24 -0500"  >&lt;p&gt;This patch (if accepted) supersedes Timothy Baldridge&apos;s patch; it implements &quot;queue&quot; and &quot;queue?&quot; (but not &quot;queue*&quot;); &quot;queue&quot; accepts a collection rather than being a variadic function, as per Rich&apos;s suggestion.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="12018" name="clj-1048-queue-takes-collections.diff" size="4726" author="eigenhombre" created="Fri, 31 May 2013 09:58:24 -0500" />
                    <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-1212] Silent truncation/downcasting of primitive type on reflection call to overloaded method (Math/abs)</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1212</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;I realise relying on reflection when calling these kinds of methods isn&apos;t a great idea performance-wise, but it shouldn&apos;t lead to incorrect or dangerous behaviour.&lt;/p&gt;

&lt;p&gt;Here it seems to trigger a silent downcast of the input longs, giving a truncated integer output:&lt;/p&gt;

&lt;p&gt;user&amp;gt; (defn f &lt;span class=&quot;error&quot;&gt;&amp;#91;a b&amp;#93;&lt;/span&gt; (Math/abs (- a b)))&lt;br/&gt;
Reflection warning, NO_SOURCE_PATH:1:15 - call to abs can&apos;t be resolved.&lt;br/&gt;
#&apos;user/f&lt;br/&gt;
user&amp;gt; (f 1000000000000 2000000000000)&lt;br/&gt;
727379968&lt;br/&gt;
user&amp;gt; (class (f 1000000000000 2000000000000))&lt;br/&gt;
java.lang.Integer&lt;br/&gt;
user&amp;gt; (defn f &lt;span class=&quot;error&quot;&gt;&amp;#91;^long a ^long b&amp;#93;&lt;/span&gt; (Math/abs (- a b)))&lt;br/&gt;
#&apos;user/f&lt;br/&gt;
user&amp;gt; (f 1000000000000 2000000000000)&lt;br/&gt;
1000000000000&lt;br/&gt;
user&amp;gt; (class (f 1000000000000 2000000000000))&lt;br/&gt;
java.lang.Long&lt;/p&gt;</description>
                <environment>Clojure 1.5.1&lt;br/&gt;
OpenJDK Runtime Environment (IcedTea6 1.12.5) (6b27-1.12.5-0ubuntu0.12.04.1)</environment>
            <key id="16206">CLJ-1212</key>
            <summary>Silent truncation/downcasting of primitive type on reflection call to overloaded method (Math/abs)</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="matthjw">Matthew Willson</reporter>
                        <labels>
                    </labels>
                <created>Tue, 28 May 2013 12:47:26 -0500</created>
                <updated>Wed, 29 May 2013 15:19:00 -0500</updated>
                                    <version>Release 1.5</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                        <comments>
                    <comment id="31180" author="matthjw" created="Tue, 28 May 2013 12:50:57 -0500"  >&lt;p&gt;For an even simpler way to replicate the issue:&lt;/p&gt;

&lt;p&gt;user&amp;gt; (#(Math/abs %) 1000000000000)&lt;br/&gt;
Reflection warning, NO_SOURCE_PATH:1:3 - call to abs can&apos;t be resolved.&lt;br/&gt;
727379968&lt;/p&gt;</comment>
                    <comment id="31181" author="jafingerhut" created="Tue, 28 May 2013 13:36:51 -0500"  >&lt;p&gt;I was able to reproduce the behavior you see with these Java 6 JVMs on Ubuntu 12.04.2:&lt;/p&gt;

&lt;p&gt;java version &quot;1.6.0_27&quot;&lt;br/&gt;
OpenJDK Runtime Environment (IcedTea6 1.12.5) (6b27-1.12.5-0ubuntu0.12.04.1)&lt;br/&gt;
OpenJDK 64-Bit Server VM (build 20.0-b12, mixed mode)&lt;/p&gt;

&lt;p&gt;java version &quot;1.6.0_45&quot;&lt;br/&gt;
Java(TM) SE Runtime Environment (build 1.6.0_45-b06)&lt;br/&gt;
Java HotSpot(TM) 64-Bit Server VM (build 20.45-b01, mixed mode)&lt;/p&gt;

&lt;p&gt;However, I tried two Java 7 JVMs, and it gave the following behavior which looks closer to what you would hope for.  I do not know what is the precise difference between Java 6 and Java 7 that leads to this behavior difference, but this is some evidence that this has something to do with Java 6 vs. Java 7.&lt;/p&gt;

&lt;p&gt;user=&amp;gt; (set! &lt;b&gt;warn-on-reflection&lt;/b&gt; true)&lt;br/&gt;
true&lt;br/&gt;
user=&amp;gt; (defn f &lt;span class=&quot;error&quot;&gt;&amp;#91;a b&amp;#93;&lt;/span&gt; (Math/abs (- a b)))&lt;br/&gt;
Reflection warning, NO_SOURCE_PATH:1:15 - call to abs can&apos;t be resolved.&lt;br/&gt;
#&apos;user/f&lt;br/&gt;
user=&amp;gt; (f 1000000000000 2000000000000)&lt;br/&gt;
1000000000000&lt;br/&gt;
user=&amp;gt; (class (f 1000000000000 2000000000000))&lt;br/&gt;
java.lang.Long&lt;/p&gt;

&lt;p&gt;Above behavior observed with Clojure 1.5.1 on these JVMs:&lt;/p&gt;

&lt;p&gt;Ubuntu 12.04.2 plus this JVM:&lt;br/&gt;
java version &quot;1.7.0_21&quot;&lt;br/&gt;
Java(TM) SE Runtime Environment (build 1.7.0_21-b11)&lt;br/&gt;
Java HotSpot(TM) 64-Bit Server VM (build 23.21-b01, mixed mode)&lt;/p&gt;

&lt;p&gt;Mac OS X 10.8.3 plus this JVM:&lt;br/&gt;
java version &quot;1.7.0_15&quot;&lt;br/&gt;
Java(TM) SE Runtime Environment (build 1.7.0_15-b03)&lt;br/&gt;
Java HotSpot(TM) 64-Bit Server VM (build 23.7-b01, mixed mode)&lt;/p&gt;</comment>
                    <comment id="31182" author="matthjw" created="Wed, 29 May 2013 05:17:01 -0500"  >&lt;p&gt;Ah, interesting.&lt;br/&gt;
Maybe it&apos;s a difference in the way the reflection API works in java 7?&lt;/p&gt;

&lt;p&gt;Here&apos;s the bytecode generated incase anyone&apos;s curious:&lt;/p&gt;

&lt;p&gt;public java.lang.Object invoke(java.lang.Object);&lt;br/&gt;
  Code:&lt;br/&gt;
   0:	ldc	#14; //String java.lang.Math&lt;br/&gt;
   2:	invokestatic	#20; //Method java/lang/Class.forName:(Ljava/lang/String;)Ljava/lang/Class;&lt;br/&gt;
   5:	ldc	#22; //String abs&lt;br/&gt;
   7:	iconst_1&lt;br/&gt;
   8:	anewarray	#24; //class java/lang/Object&lt;br/&gt;
   11:	dup&lt;br/&gt;
   12:	iconst_0&lt;br/&gt;
   13:	aload_1&lt;br/&gt;
   14:	aconst_null&lt;br/&gt;
   15:	astore_1&lt;br/&gt;
   16:	aastore&lt;br/&gt;
   17:	invokestatic	#30; //Method clojure/lang/Reflector.invokeStaticMethod:(Ljava/lang/Class;Ljava/lang/String;[Ljava/lang/Object;)Ljava/lang/Object;&lt;br/&gt;
   20:	areturn&lt;/p&gt;</comment>
                    <comment id="31183" author="matthjw" created="Wed, 29 May 2013 05:20:49 -0500"  >&lt;p&gt;Just an idea (and maybe this is what&apos;s happening under java 7?) but given it&apos;s a static method and all available overloaded variants are presumably known at compile time, perhaps it could generate code along the lines of:&lt;/p&gt;

&lt;p&gt;(cond&lt;br/&gt;
  (instance? Long x) (Math/abs (long x))&lt;br/&gt;
  (instance? Integer x) (Math/abs (int x))&lt;br/&gt;
  ;; ...&lt;br/&gt;
  )&lt;/p&gt;</comment>
                    <comment id="31184" author="jafingerhut" created="Wed, 29 May 2013 15:19:00 -0500"  >&lt;p&gt;In Reflector.java method invokeStaticMethod(Class c, String methodName, Object[] args) there is a call to getMethods() followed by a call to invokeMatchingMethod().  getMethods() returns the 4 java.lang.Math/abs methods in different orders on Java 6 and 7, causing invokeMatchingMethod() to pick a different one on the two JVMs:&lt;/p&gt;

&lt;p&gt;java version &quot;1.6.0_39&quot;&lt;br/&gt;
Java(TM) SE Runtime Environment (build 1.6.0_39-b04)&lt;br/&gt;
Java HotSpot(TM) 64-Bit Server VM (build 20.14-b01, mixed mode)&lt;/p&gt;

&lt;p&gt;user=&amp;gt; (pprint (seq (clojure.lang.Reflector/getMethods java.lang.Math 1 &quot;abs&quot; true)))&lt;br/&gt;
(#&amp;lt;Method public static int java.lang.Math.abs(int)&amp;gt;&lt;br/&gt;
 #&amp;lt;Method public static long java.lang.Math.abs(long)&amp;gt;&lt;br/&gt;
 #&amp;lt;Method public static float java.lang.Math.abs(float)&amp;gt;&lt;br/&gt;
 #&amp;lt;Method public static double java.lang.Math.abs(double)&amp;gt;)&lt;br/&gt;
nil&lt;/p&gt;


&lt;p&gt;java version &quot;1.7.0_21&quot;&lt;br/&gt;
Java(TM) SE Runtime Environment (build 1.7.0_21-b11)&lt;br/&gt;
Java HotSpot(TM) 64-Bit Server VM (build 23.21-b01, mixed mode)&lt;/p&gt;

&lt;p&gt;user=&amp;gt; (pprint (seq (clojure.lang.Reflector/getMethods java.lang.Math 1 &quot;abs&quot; true)))&lt;br/&gt;
(#&amp;lt;Method public static double java.lang.Math.abs(double)&amp;gt;&lt;br/&gt;
 #&amp;lt;Method public static float java.lang.Math.abs(float)&amp;gt;&lt;br/&gt;
 #&amp;lt;Method public static long java.lang.Math.abs(long)&amp;gt;&lt;br/&gt;
 #&amp;lt;Method public static int java.lang.Math.abs(int)&amp;gt;)&lt;br/&gt;
nil&lt;/p&gt;


&lt;p&gt;That might be a sign of undesirable behavior in invokeMatchingMethod() that is too dependent upon the order of methods given to it.&lt;/p&gt;

&lt;p&gt;As you mention, type hinting is good for avoiding the significant performance hit of reflection.&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-1213] consistency with def and Unbound</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1213</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;In this example I&apos;d expect `b` to return `Unbound` for consistency.&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;Clojure 1.5.1
user=&amp;gt; (def a &lt;span class=&quot;code-quote&quot;&gt;&quot;MyA&quot;&lt;/span&gt;)
#&apos;user/a
user=&amp;gt; (def a &lt;span class=&quot;code-quote&quot;&gt;&quot;MyA2&quot;&lt;/span&gt;)
#&apos;user/a
user=&amp;gt; (def b &lt;span class=&quot;code-quote&quot;&gt;&quot;MyB&quot;&lt;/span&gt;)
#&apos;user/b
user=&amp;gt; (def b) ;; unbound b
#&apos;user/b
user=&amp;gt; (def c) ;; unbound c
#&apos;user/c
user=&amp;gt; a
&lt;span class=&quot;code-quote&quot;&gt;&quot;MyA2&quot;&lt;/span&gt;
user=&amp;gt; b
&lt;span class=&quot;code-quote&quot;&gt;&quot;MyB&quot;&lt;/span&gt;
user=&amp;gt; c
#&amp;lt;Unbound Unbound: #&apos;user/c&amp;gt;&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;</description>
                <environment></environment>
            <key id="16208">CLJ-1213</key>
            <summary>consistency with def and Unbound</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="trevor">Trevor Wennblom</reporter>
                        <labels>
                    </labels>
                <created>Wed, 29 May 2013 14:47:58 -0500</created>
                <updated>Wed, 29 May 2013 14:47: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-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>Tue, 28 May 2013 11:54:55 -0500</updated>
                                    <version>Release 1.5</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>2</watches>
                        <comments>
                    <comment id="31171" author="gfredericks" created="Sun, 26 May 2013 15:00:33 -0500"  >&lt;p&gt;Attached a patch that implements the old behavior (can&apos;t cast to IDeref), which strikes me as good enough considering the support for j.u.c.Future seems rather an edge case (being that clojure&apos;s futures are themselves IDeref).&lt;/p&gt;

&lt;p&gt;The weirdest thing I did was to use clojure.core/cast to unconditionally throw a ClassCastException. Let me know if that&apos;s weird and I&apos;ll do something different.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="12016" name="CLJ-1162-p1.patch" size="1792" author="gfredericks" created="Sun, 26 May 2013 15:00: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>
                                            <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>Tue, 28 May 2013 11:52:12 -0500</updated>
                                    <version>Release 1.5</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>1</watches>
                        <comments>
                    <comment id="31163" author="gfredericks" created="Sun, 26 May 2013 08:25:15 -0500"  >&lt;p&gt;Should this be a warning or an exception? I don&apos;t know of any similar example of the compiler giving a warning, so I would expect the latter.&lt;/p&gt;</comment>
                    <comment id="31165" author="gfredericks" created="Sun, 26 May 2013 09:54:14 -0500"  >&lt;p&gt;Added a patch that throws an exception when :or is not a map or its keys are not symbols. Also some tests.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="12014" name="CLJ-1189-p1.patch" size="2850" author="gfredericks" created="Sun, 26 May 2013 09:54: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-787] transient blows up when passed a vector created by subvec</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-787</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;Subvectors created with subvec from a PersistentVector cannot be made transient:&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;transient&lt;/span&gt; (subvec [1 2 3 4] 2))
ClassCastException clojure.lang.APersistentVector$SubVector cannot be &lt;span class=&quot;code-keyword&quot;&gt;cast&lt;/span&gt; to clojure.lang.IEditableCollection  clojure.core/&lt;span class=&quot;code-keyword&quot;&gt;transient&lt;/span&gt; (core.clj:2864)&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;
</description>
                <environment></environment>
            <key id="14413">CLJ-787</key>
            <summary>transient blows up when passed a vector created by subvec</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="aredington">Alexander Redington</reporter>
                        <labels>
                    </labels>
                <created>Tue, 3 May 2011 07:23:56 -0500</created>
                <updated>Tue, 28 May 2013 11:50:25 -0500</updated>
                                    <version>Backlog</version>
                                <fixVersion>Release 1.6</fixVersion>
                                        <due></due>
                    <votes>0</votes>
                        <watches>3</watches>
                        <comments>
                    <comment id="26477" author="stuart.sierra" created="Tue, 31 May 2011 09:28:01 -0500"  >&lt;p&gt;Confirmed. APersistentVector$SubVector does not implement IEditableCollection.&lt;/p&gt;

&lt;p&gt;The current implementation of TransientVector depends on implementation details of PersistentVector, so it is not a trivial fix. The simplest fix might be to implement IEditableCollection.asTransient in SubVector by creating a new PersistentVector, but I do not know the performance implications.&lt;/p&gt;</comment>
                    <comment id="31160" author="gfredericks" created="Sat, 25 May 2013 20:11:40 -0500"  >&lt;p&gt;We could get the same performance characteristics as SubVector by creating a TransientSubVector based on an underlying TransientVector, right?&lt;/p&gt;

&lt;p&gt;Preparing a patch to that effect.&lt;/p&gt;</comment>
                    <comment id="31161" author="gfredericks" created="Sat, 25 May 2013 22:58:13 -0500"  >&lt;p&gt;Text from the commit msg:&lt;/p&gt;

&lt;p&gt;Made two assumptions:&lt;/p&gt;

&lt;ul class=&quot;alternate&quot; type=&quot;square&quot;&gt;
	&lt;li&gt;It&apos;s okay for TransientSubVector to delegate the ensureEditable&lt;br/&gt;
    functionality to the underlying TransientVector (sometimes&lt;br/&gt;
    explicitely, sometimes implicitely) &amp;#8211; calling ensureEditable&lt;br/&gt;
    explicitely also requires that the field for the underlying vector&lt;br/&gt;
    be the concrete TransientVector type rather than the&lt;br/&gt;
    ITransientVector interface.&lt;/li&gt;
	&lt;li&gt;When an operation that would throw an exception on a&lt;br/&gt;
    PersistentVector happens from the wrong thread (or after&lt;br/&gt;
    persistent!), we throw that exception rather than the&lt;br/&gt;
    IllegalAccessError that transients throw when accessed&lt;br/&gt;
    inappropriately.&lt;/li&gt;
&lt;/ul&gt;
</comment>
                </comments>
                    <attachments>
                    <attachment id="12013" name="CLJ-787-p1.patch" size="5870" author="gfredericks" created="Sat, 25 May 2013 22:58:13 -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-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>Sun, 26 May 2013 15:39:07 -0500</updated>
                                                                            <due></due>
                    <votes>0</votes>
                        <watches>1</watches>
                        <comments>
                    <comment id="31173" author="gfredericks" created="Sun, 26 May 2013 15:39:07 -0500"  >&lt;p&gt;I had the idea recently that the factory fn was useful partly for being a redefinable var, e.g. that you could wrap with contracts or anything else. This idea would preclude that.&lt;/p&gt;

&lt;p&gt;It makes sense though if the only purpose of &lt;tt&gt;-&amp;gt;Foo&lt;/tt&gt; is to avoid having to &lt;tt&gt;:import&lt;/tt&gt; something.&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-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>Sun, 26 May 2013 15:17:29 -0500</updated>
                                    <version>Release 1.4</version>
                <version>Release 1.5</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>1</watches>
                        <comments>
                    <comment id="31172" author="gfredericks" created="Sun, 26 May 2013 15:17:29 -0500"  >&lt;p&gt;I believe this applies to require 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-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>Sun, 26 May 2013 14:21:55 -0500</updated>
                                    <version>Release 1.5</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>1</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>
                    <comment id="31117" author="sfnelson" created="Sun, 19 May 2013 22:29:46 -0500"  >&lt;p&gt;I&apos;m happy with Andy&apos;s synopsis of the problem, and it&apos;s reasonable not to change the behaviour of the threading macro specifically for (fn..).&lt;/p&gt;

&lt;p&gt;However, this is a mistake that I&apos;m sure many others make/have made and it&apos;s hard to diagnose what is going wrong without dumping interpreted form &amp;#8211; hardly a reasonable expectation for a novice user.&lt;/p&gt;

&lt;p&gt;Before closing this issue, I&apos;d like to see improved failure reporting, such as causing the threading macro to throw a compile error or warning if passed a raw (unwrapped) function declaration (are there legitimate use cases this would affect?).&lt;/p&gt;</comment>
                    <comment id="31170" author="gfredericks" created="Sun, 26 May 2013 14:21:55 -0500"  >&lt;p&gt;Throwing an error on (-&amp;gt; &lt;span class=&quot;error&quot;&gt;&amp;#91;1 2 3&amp;#93;&lt;/span&gt; (fn ...)) would certainly affect any perverse individual using a local redefinition of &apos;fn.&lt;/p&gt;

&lt;p&gt;I think the best that can be done here is a mention in the docstring.&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-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>Sun, 26 May 2013 08:20:55 -0500</updated>
                                    <version>Release 1.5</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>1</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>
                    <comment id="31162" author="gfredericks" created="Sun, 26 May 2013 08:20:55 -0500"  >&lt;p&gt;This reminds me of an issue with `lein run` that resulted from it trying to figure out whether you wanted to run a namespace or a java class:&lt;/p&gt;

&lt;p&gt;&lt;a href=&quot;https://github.com/technomancy/leiningen/issues/1182&quot;&gt;https://github.com/technomancy/leiningen/issues/1182&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>
                                                                                                        <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-873] Allow the function / to be referred to in namespaces other than clojure.core</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-873</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;The attached patch gives the programmer the option of referring to the division function in namespaces other than just clojure.core.  For example,&lt;/p&gt;

&lt;p&gt;(ns foo&lt;br/&gt;
  (:require &lt;span class=&quot;error&quot;&gt;&amp;#91;cljs.core :as core&amp;#93;&lt;/span&gt;))&lt;br/&gt;
(apply core// &apos;(1 2 3))&lt;/p&gt;

&lt;p&gt;The above lines do not compile without this patch.&lt;/p&gt;</description>
                <environment></environment>
            <key id="15000">CLJ-873</key>
            <summary>Allow the function / to be referred to in namespaces other than clojure.core</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="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="chrismgray">Chris Gray</reporter>
                        <labels>
                    </labels>
                <created>Thu, 10 Nov 2011 09:48:56 -0600</created>
                <updated>Sat, 25 May 2013 14:05:26 -0500</updated>
                                    <version>Release 1.1</version>
                <version>Release 1.2</version>
                <version>Release 1.3</version>
                <version>Release 1.4</version>
                                <fixVersion>Release 1.6</fixVersion>
                                        <due></due>
                    <votes>7</votes>
                        <watches>6</watches>
                        <comments>
                    <comment id="27274" author="chrismgray" created="Thu, 10 Nov 2011 09:50:19 -0600"  >&lt;p&gt;I have signed the CA and it is in the mail. &lt;/p&gt;</comment>
                    <comment id="27329" author="chrismgray" created="Sun, 20 Nov 2011 18:21:20 -0600"  >&lt;p&gt;My CA has now been applied.  This patch is quite simple &amp;#8211; can someone have a look at it please?&lt;/p&gt;</comment>
                    <comment id="27437" author="alexmiller" created="Fri, 9 Dec 2011 09:34:21 -0600"  >&lt;p&gt;FYI, I have run into this in actual code as well (implementing a query language function library).  &lt;/p&gt;</comment>
                    <comment id="27863" author="jafingerhut" created="Fri, 24 Feb 2012 20:00:48 -0600"  >&lt;p&gt;clj-873-namespace-divides-patch.txt is same as Chris&apos;s, just updated to apply cleanly to latest master as of Feb 24, 2012.&lt;/p&gt;

&lt;p&gt;The test he added does fail without the code fix, and passes with it.  He is now on the list of contributors.&lt;/p&gt;</comment>
                    <comment id="28059" author="chrismgray" created="Fri, 30 Mar 2012 13:11:39 -0500"  >&lt;p&gt;A short further discussion of this patch appeared here: &lt;a href=&quot;http://groups.google.com/group/clojure-dev/browse_thread/thread/f095980802a82747/b723726c77c1ec64&quot;&gt;http://groups.google.com/group/clojure-dev/browse_thread/thread/f095980802a82747/b723726c77c1ec64&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;Also, I assume this bug is what is referred to in Clojurescript&apos;s core.cljs, where it says &quot;;; FIXME: waiting on cljs.core//&quot;&lt;/p&gt;</comment>
                    <comment id="29768" author="stu" created="Mon, 22 Oct 2012 19:12:55 -0500"  >&lt;p&gt;Thanks all. It is nice to have supporting real-world stories such as Alex&apos;s in the comments.&lt;/p&gt;</comment>
                    <comment id="29769" author="jafingerhut" created="Mon, 22 Oct 2012 19:19:21 -0500"  >&lt;p&gt;I should have added a comment here a while back if it would have helped, but David Nolen&apos;s &lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-930&quot; title=&quot;cljs.core// does not work in ClojureScript&quot;&gt;&lt;del&gt;CLJ-930&lt;/del&gt;&lt;/a&gt; was closed as a duplicate of this one.&lt;/p&gt;</comment>
                    <comment id="30347" author="bbloom" created="Wed, 2 Jan 2013 00:49:35 -0600"  >&lt;p&gt;This also affects a two of my libraries: 1) CSS generation library I&apos;m working on, which wants to be able to do division with pixels and other units. 2) Factjor which defines binary math operators against a stack.&lt;/p&gt;</comment>
                    <comment id="31138" author="bronsa" created="Fri, 24 May 2013 08:39:11 -0500"  >&lt;p&gt;clojure.lang.EdnReader should get patched aswell.&lt;/p&gt;</comment>
                    <comment id="31156" author="bronsa" created="Sat, 25 May 2013 11:48:21 -0500"  >&lt;p&gt;I&apos;m reopening it, attaching a patch for EdnReader&lt;/p&gt;</comment>
                    <comment id="31158" author="jafingerhut" created="Sat, 25 May 2013 12:37:12 -0500"  >&lt;p&gt;Nicola, I noticed yesterday that LispReader.java still contains values SLASH and CLOJURE_SLASH that are no longer used after the patch was applied yesterday for this ticket.  Would you mind including the removal of those in your patch, too?&lt;/p&gt;</comment>
                    <comment id="31159" author="bronsa" created="Sat, 25 May 2013 14:05:26 -0500"  >&lt;p&gt;Andy, I&apos;ve updated 0001-Fix-&lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-873&quot; title=&quot;Allow the function / to be referred to in namespaces other than clojure.core&quot;&gt;CLJ-873&lt;/a&gt;-for-EdnReader-too.patch to remove SLASH and CLOJURE_SLASH as you suggested.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="12011" name="0001-Fix-CLJ-873-for-EdnReader-too.patch" size="2494" author="bronsa" created="Sat, 25 May 2013 14:05:26 -0500" />
                    <attachment id="10964" name="clj-873-namespace-divides-patch.txt" size="2665" author="jafingerhut" created="Fri, 24 Feb 2012 20:00:48 -0600" />
                    <attachment id="10692" name="namespace-divides.diff" size="2810" author="chrismgray" created="Thu, 10 Nov 2011 09:48:56 -0600" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_10002" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Approval</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10007">Ok</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>Sat, 25 May 2013 12:39:35 -0500</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>
                    <comment id="31150" author="jafingerhut" created="Fri, 24 May 2013 13:11:13 -0500"  >&lt;p&gt;Patch clj-1074-read-infinity-and-nan-patch-v2.txt dated May 24 2013 is identical to 0001-Read-Infinity-and-NaN.patch dated Sep 21 2012, except it applies cleanly to latest master.  The older patch conflicts with a recent commit made for &lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-873&quot; title=&quot;Allow the function / to be referred to in namespaces other than clojure.core&quot;&gt;CLJ-873&lt;/a&gt;.&lt;/p&gt;</comment>
                    <comment id="31157" author="bronsa" created="Sat, 25 May 2013 11:55:54 -0500"  >&lt;p&gt;clj-1074-read-infinity-and-nan-patch-v2-plus-edn-reader.patch is the same as clj-1074-read-infinity-and-nan-patch-v2.txt except it patches EdnReader too, but it must be applied after #&lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-873&quot; title=&quot;Allow the function / to be referred to in namespaces other than clojure.core&quot;&gt;CLJ-873&lt;/a&gt; 0001-Fix-&lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-873&quot; title=&quot;Allow the function / to be referred to in namespaces other than clojure.core&quot;&gt;CLJ-873&lt;/a&gt;-for-EdnReader-too.patch get merged&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" />
                    <attachment id="12010" name="clj-1074-read-infinity-and-nan-patch-v2-plus-edn-reader.patch" size="2429" author="bronsa" created="Sat, 25 May 2013 11:55: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-1211] Protocol call sites emit many unused fields and bytecodes</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1211</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;Three unused instance member fields are emitted by emitProto() in the compiler - seems that at some point it was for inline caching of protocol implementations, but it looks like that&apos;s all handled by MethodImplCache now.&lt;/p&gt;

&lt;p&gt;This patch eliminates it, and brings down protocol heavy classes like the new ManyToManyChannel in core.async from 120+ fields down to 23 fields, mostly Var caches.&lt;/p&gt;

&lt;p&gt;There should be a lot less bytecode in such classes now, and less memory overhead.&lt;/p&gt;</description>
                <environment></environment>
            <key id="16202">CLJ-1211</key>
            <summary>Protocol call sites emit many unused fields and bytecodes</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="6" iconUrl="http://dev.clojure.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="2">Declined</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="gshayban">Ghadi Shayban</reporter>
                        <labels>
                    </labels>
                <created>Sat, 25 May 2013 10:35:30 -0500</created>
                <updated>Sat, 25 May 2013 10:49:26 -0500</updated>
                    <resolved>Sat, 25 May 2013 10:49:26 -0500</resolved>
                                                                    <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                        <comments>
                    <comment id="31155" author="gshayban" created="Sat, 25 May 2013 10:49:26 -0500"  >&lt;p&gt;Needs work&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="12008" name="protocol-sites.diff" size="3286" author="gshayban" created="Sat, 25 May 2013 10:35:30 -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-322] Enhance AOT compilation process to emit classfiles only for explicitly-specified namespaces</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-322</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;Summary: still needs decision on implementation approach.&lt;/p&gt;

&lt;p&gt;This was &lt;a href=&quot;https://www.assembla.com/spaces/clojure-contrib/tickets/23&quot;&gt;originally/erroneously reported&lt;/a&gt; by Howard Lewis Ship in the clojure-contrib assembla:&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;My build file specifies the namespaces to AOT compile but &lt;span class=&quot;code-keyword&quot;&gt;if&lt;/span&gt; I include another namespace
(even from a JAR dependency) that is not AOT compiled, the other namespace will be compiled as well.

In my &lt;span class=&quot;code-keyword&quot;&gt;case&lt;/span&gt;, I was using clojure-contrib&apos;s clojure.contrib.str-utils2 namespace, and I got a bunch of
clojure/contrib/str_utils2 classes in my output directory.

I think that the AOT compiler should NOT precompile any namespaces that are transitively reached,
only namespaces in the set specified by the command line are appropriate.

As currently coded, you will frequently find unwanted third-party dependencies in your output JARs;
further, &lt;span class=&quot;code-keyword&quot;&gt;if&lt;/span&gt; multiple parties depend on the same JARs, &lt;span class=&quot;code-keyword&quot;&gt;this&lt;/span&gt; could cause bloating and duplication in the
eventual runtime classpath.&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;Having the option of shipping either all AOT-compiled classfiles or mixed source/AOT depending upon one&apos;s distribution requirements would make that phase of work with a clojure codebase significantly easier and less error-prone.  The only question in my mind is what the default should be.  We&apos;re all used to the current behaviour, but I&apos;d guess that any nontrivial project where the form of the distributable matters (i.e. the source/AOT mix), providing as much control as possible by default makes the most sense.  Given the tooling that most people are using, it&apos;s trivial (and common practice, IIUC) to provide a comprehensive list of namespaces one wishes to compile, so making that the default shouldn&apos;t be a hurdle to anyone.  If an escape hatch is desired, a --transitive switch to clojure.lang.Compile could be added.&lt;/p&gt;</description>
                <environment></environment>
            <key id="13719">CLJ-322</key>
            <summary>Enhance AOT compilation process to emit classfiles only for explicitly-specified namespaces</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="3" iconUrl="http://dev.clojure.org/jira/images/icons/status_inprogress.gif">In Progress</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="cemerick">Chas Emerick</reporter>
                        <labels>
                    </labels>
                <created>Thu, 29 Apr 2010 00:20:00 -0500</created>
                <updated>Fri, 24 May 2013 13:25:25 -0500</updated>
                                                    <fixVersion>Release 1.6</fixVersion>
                                        <due></due>
                    <votes>12</votes>
                        <watches>11</watches>
                        <comments>
                    <comment id="23775" author="importer" created="Tue, 28 Sep 2010 00:18:00 -0500"  >&lt;p&gt;Converted from &lt;a href=&quot;http://www.assembla.com/spaces/clojure/tickets/322&quot;&gt;http://www.assembla.com/spaces/clojure/tickets/322&lt;/a&gt;&lt;br/&gt;
Attachments:&lt;br/&gt;
aot-transitivity-option-compat-322.diff - &lt;a href=&quot;https://www.assembla.com/spaces/clojure/documents/aI7Eu-HeGr35ImeJe5cbLA/download/aI7Eu-HeGr35ImeJe5cbLA&quot;&gt;https://www.assembla.com/spaces/clojure/documents/aI7Eu-HeGr35ImeJe5cbLA/download/aI7Eu-HeGr35ImeJe5cbLA&lt;/a&gt;&lt;br/&gt;
aot-transitivity-option-322.diff - &lt;a href=&quot;https://www.assembla.com/spaces/clojure/documents/aIWFiWHeGr35ImeJe5cbLA/download/aIWFiWHeGr35ImeJe5cbLA&quot;&gt;https://www.assembla.com/spaces/clojure/documents/aIWFiWHeGr35ImeJe5cbLA/download/aIWFiWHeGr35ImeJe5cbLA&lt;/a&gt;&lt;/p&gt;</comment>
                    <comment id="23776" author="importer" created="Tue, 28 Sep 2010 00:18:00 -0500"  >&lt;p&gt;hlship said: I&apos;d like to reinforce this.  I&apos;ve been doing research on Clojure build tools for an upcoming talk and all of them (Maven, Leiningen, Gradle) have the same problem: the AOT compile extends from the desired namespaces (such as one containing a :gen-class)  to every reached namespace.  This is going to cause a real ugliness when application A uses libraries B and C that both depend on library D (such as clojure-contrib) and B and C are thus both bloated with duplicate, unwanted AOT compiled  classes from the library D.&lt;/p&gt;</comment>
                    <comment id="23777" author="importer" created="Tue, 28 Sep 2010 00:18:00 -0500"  >&lt;p&gt;cemerick said: This behaviour is an implementation detail of Clojure&apos;s AOT compilation process, and is orthogonal to any particular build tooling.&lt;/p&gt;

&lt;p&gt;I am working on a patch that would provide a mechanism for such tooling to disable this default behaviour.&lt;/p&gt;</comment>
                    <comment id="23778" author="importer" created="Tue, 28 Sep 2010 00:18:00 -0500"  >&lt;p&gt;cemerick said: A first cut of a change to address this issue is here (&lt;b&gt;caution, work in progress!&lt;/b&gt;):&lt;/p&gt;

&lt;p&gt;&lt;a href=&quot;http://github.com/cemerick/clojure/commit/6f14e0790c0d283a7e44056adf1bb3f36bb16e0e&quot;&gt;http://github.com/cemerick/clojure/commit/6f14e0790c0d283a7e44056adf1bb3f36bb16e0e&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;This makes available a new recognized system property, &lt;tt&gt;clojure.compiler.transitive&lt;/tt&gt;, which defaults to &lt;tt&gt;true&lt;/tt&gt;.  When set/bound to false (i.e. &lt;tt&gt;-Dclojure.compiler.transitive=false&lt;/tt&gt; when using &lt;tt&gt;clojure.lang.Compile&lt;/tt&gt;), only the first loaded file (either the ns named in the call to &lt;tt&gt;compile&lt;/tt&gt; or each of the namespaces named as arguments to &lt;tt&gt;clojure.lang.Compile&lt;/tt&gt;) will have classfiles written to disk.&lt;/p&gt;

&lt;p&gt;This means that this compilation invocation:&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 -cp &amp;lt;your classpath&amp;gt; -Dclojure.compiler.transitive=&lt;span class=&quot;code-keyword&quot;&gt;false&lt;/span&gt; clojure.lang.Compile com.bar com.baz&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;
&lt;p&gt;will generate classfiles only for &lt;tt&gt;com.bar&lt;/tt&gt; and &lt;tt&gt;com.baz&lt;/tt&gt;, but not for any of the namespaces or other files they load, require, or use.&lt;/p&gt;

&lt;hr /&gt;
&lt;p&gt;The only shortcoming of this WIP patch is that classfiles &lt;b&gt;are&lt;/b&gt; still generated for proxy and gen-class classes defined outside of the explicitly-named namespaces.  What I thought was a solution for this ended up breaking the loading of generated interfaces (as produced by defprotocol, etc).&lt;/p&gt;

&lt;p&gt;I&apos;ll take a second look at this before the end of the week, but wanted to get this out there so as to get any comments people might have.&lt;/p&gt;</comment>
                    <comment id="23779" author="importer" created="Tue, 28 Sep 2010 00:18:00 -0500"  >&lt;p&gt;technomancy said: Looks good, but I&apos;m having trouble getting it to work. I tried compiling from master of Chas&apos;s fork on github, but I still got the all the .class files generated with -Dclojure.compiler.transitive=false. It could be a quirk of the way I&apos;m using ant to fork off processes though. Is it possible to set it using System/setProperty, or must it be given as a property on the command-line?&lt;/p&gt;</comment>
                    <comment id="23780" author="importer" created="Tue, 28 Sep 2010 00:18:00 -0500"  >&lt;p&gt;cemerick said: Bah, that&apos;s just bad documentation. :-/&lt;/p&gt;

&lt;p&gt;The system property is only provided by &lt;tt&gt;clojure.lang.Compile&lt;/tt&gt;; the value of it drives the binding of &lt;tt&gt;clojure.core/&lt;b&gt;transitive-compile&lt;/b&gt;&lt;/tt&gt;, which has a root binding of true.&lt;/p&gt;

&lt;p&gt;You should be able to configure the transitivity the same way you configure &lt;tt&gt;&lt;b&gt;compile-path&lt;/b&gt;&lt;/tt&gt; (system prop to &lt;tt&gt;clojure.lang.Compile&lt;/tt&gt; or a direct binding when at the REPL, etc).&lt;/p&gt;

&lt;p&gt;If not, ping me in irc or elsewhere.&lt;/p&gt;</comment>
                    <comment id="23781" author="importer" created="Tue, 28 Sep 2010 00:18:00 -0500"  >&lt;p&gt;meikelbrandmeyer said: I think, excluding parts &apos;load&apos;ed is a little strong. I have some namespaces which load several parts from different files, but which belong to the same namespace. The most prominent example of such a case is clojure.core itself. I&apos;m find with stopping require and use, but load is a bit too much, I&apos;d say.&lt;/p&gt;</comment>
                    <comment id="23782" author="importer" created="Tue, 28 Sep 2010 00:18:00 -0500"  >&lt;p&gt;technomancy said: Chas: Thanks; will give that a go.&lt;/p&gt;

&lt;p&gt;Meikel: Do people actually use load outside of clojure.core? I thought it was only used there because clojure.core is a &quot;special&quot; namespace where you want more vars to be available than can reasonably fit in a single file. Splitting up a namespace into several files is quite unadvisable otherwise.&lt;/p&gt;</comment>
                    <comment id="23783" author="importer" created="Tue, 28 Sep 2010 00:18:00 -0500"  >&lt;p&gt;technomancy said: I can confirm that this works for me modulo the proxy/gen-class issue that Chas mentioned. I would love to see this in Clojure 1.2; it would really clean up a lot of build-related issues.&lt;/p&gt;</comment>
                    <comment id="23784" author="importer" created="Tue, 28 Sep 2010 00:18:00 -0500"  >&lt;p&gt;meikelbrandmeyer said: I used it several times and this is the first time, I hear that it is unadvisable to do so. Even with a lower number of Vars in the namespace (c.c is here certainly exceptional) and might be of use to split several &quot;sections&quot; of code which belong to the same namespace but have different functionality. Whether to use a big comment in the source to indicate the section or split things into subfiles is a matter of taste. But it&apos;s a perfectly reasonable thing todo.&lt;/p&gt;

&lt;p&gt;Another use case, where I use this (and c.c.lazy-xml, IIRC) is to conditionally load code depending on whether a dependency is available or not. Eg. vimclojure uses c.c.pprint and c.c.stacktrace/clj-stacktrace transparently depending on their availability.&lt;/p&gt;

&lt;p&gt;There are perfectly legal uses of load. I don&apos;t see any &quot;unadvisable&quot; here.&lt;/p&gt;</comment>
                    <comment id="23785" author="importer" created="Tue, 28 Sep 2010 00:18:00 -0500"  >&lt;p&gt;cemerick said: Thanks, Meikel; I had forgotten about that use case, as I don&apos;t use load directly myself at all.  I probably wouldn&apos;t say it&apos;s inadvisable, just mostly unnecessary.  In any case, that&apos;s a good catch.  It complicates things a bit, but we&apos;ll see what happens.  I&apos;m going to take another whack at resolving the proxy/gen-class case and narrowing the impact of nontransitivity to use and require later tonight.&lt;/p&gt;

&lt;p&gt;I agree wholeheartedly that this should be in 1.2, assuming the technical bits work out.  This has been an irritant for quite a long time.  I actually believe that nontransitivity should be the &lt;b&gt;default&lt;/b&gt; &amp;#8211; no one wants or expects to have classfiles show up for dependencies show up when a project is AOT-compiled.  I think the only negative impact would be whoever still fiddles with compilation at the REPL, and doesn&apos;t use maven or lein &amp;#8211; and even then, it&apos;s just a matter of binding another var.&lt;/p&gt;</comment>
                    <comment id="23786" author="importer" created="Tue, 28 Sep 2010 00:18:00 -0500"  >&lt;p&gt;meikelbrandmeyer said: Then the var should be added to the default bindings in the clojure.main repl. Then it&apos;s set!-able like the other vars &#65533;&#65533;&#65533; &lt;b&gt;warn-on-reflection&lt;/b&gt; and friends.&lt;/p&gt;</comment>
                    <comment id="23787" author="importer" created="Tue, 28 Sep 2010 00:18:00 -0500"  >&lt;p&gt;cemerick said: This is looking pretty good (&lt;b&gt;still WIP&lt;/b&gt;):&lt;/p&gt;

&lt;p&gt;&lt;a href=&quot;http://github.com/cemerick/clojure/commit/fedfb022ecef420a932b3d69c182ec7a8e5960a6&quot;&gt;http://github.com/cemerick/clojure/commit/fedfb022ecef420a932b3d69c182ec7a8e5960a6&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;Thank you again for mentioning load, Meikel: it was very helpful in resolving the proxy/gen-class issue as well.&lt;/p&gt;

&lt;p&gt;Just a single data point: the jar produced by the medium-sized project I&apos;ve been using for testing the changes has shrunk from 1.8MB to less than 1MB.  That&apos;s not the only reason this is a good change, but it&apos;s certainly a nice side-effect.&lt;/p&gt;</comment>
                    <comment id="23788" author="importer" created="Tue, 28 Sep 2010 00:18:00 -0500"  >&lt;p&gt;cemerick said: [&lt;a href=&quot;file:aIWFiWHeGr35ImeJe5cbLA&quot;&gt;file:aIWFiWHeGr35ImeJe5cbLA&lt;/a&gt;]&lt;/p&gt;</comment>
                    <comment id="23789" author="importer" created="Tue, 28 Sep 2010 00:18:00 -0500"  >&lt;p&gt;cemerick said: [&lt;a href=&quot;file:aI7Eu-HeGr35ImeJe5cbLA&quot;&gt;file:aI7Eu-HeGr35ImeJe5cbLA&lt;/a&gt;]&lt;/p&gt;</comment>
                    <comment id="23790" author="importer" created="Tue, 28 Sep 2010 00:18:00 -0500"  >&lt;p&gt;cemerick said: Patched attached.  The &lt;del&gt;compat&lt;/del&gt; one retains the current default behaviour &lt;span class=&quot;error&quot;&gt;&amp;#91;*transitive-compile* true&amp;#93;&lt;/span&gt;, the other changes the default so that transitivity is a non-default option.  At least of those I&apos;ve spoken to about this, the latter is preferred.&lt;/p&gt;

&lt;p&gt;The user impact of changing the default would be:&lt;/p&gt;

&lt;ol&gt;
	&lt;li&gt;The result of compiling from the REPL will change. Getting back current behaviour would require adding a &lt;span class=&quot;error&quot;&gt;&amp;#91;*transitive-compile* true&amp;#93;&lt;/span&gt; binding to the existing bindings one must set when compiling from the REPL.&lt;/li&gt;
	&lt;li&gt;The same as #1 goes for those scripting AOT compilation via &lt;tt&gt;clojure.lang.Compile&lt;/tt&gt; as well (whether by shell scripts, ant, etc).&lt;/li&gt;
	&lt;li&gt;Those using lein, clojure-maven-plugin, gradle, and others will likely have a new option provided by those tools, and perhaps a different default than the language&apos;s.  I suspect those using such tools would much prefer a change from the default behaviour in any case.&lt;/li&gt;
&lt;/ol&gt;
</comment>
                    <comment id="23791" author="importer" created="Tue, 28 Sep 2010 00:18:00 -0500"  >&lt;p&gt;hlship said: Just had a brain-storm:&lt;/p&gt;

&lt;p&gt;How about an option to support  transitive compilation, but only if the Clojure source file being compiled as a file: URL (i.e., its a local file on the file system, not a file stored in a JAR). That would make it easier to use compilation on the local project without transitively compiling imported libraries, such as clojure-contrib.&lt;/p&gt;

&lt;p&gt;So &lt;b&gt;transitive-compile&lt;/b&gt; should be a keyword, not a boolean, with values :all (for 1.1 behavior), :none (to compile only the exact specified namespaces) or :local (to compile transitively, but only for local files, not source files from JARs).&lt;/p&gt;</comment>
                    <comment id="23792" author="importer" created="Tue, 28 Sep 2010 00:18:00 -0500"  >&lt;p&gt;cemerick said: (Crossposted to the clojure-dev list)&lt;/p&gt;

&lt;p&gt;I thought about this some, and I don&apos;t think that&apos;s a good idea, at least for now.  I&apos;m uncomfortable with semantics changing depending upon where code is being loaded from &amp;#8211; which, depending upon a tool&apos;s implementation, might be undefined.  E.g. if the com.foo.bar ns is available in source form in one directory, but as classes from a jar, and classpaths aren&apos;t being constructed in a stable fashion, then the results of compilation will change.&lt;/p&gt;

&lt;p&gt;If we decide that special treatment depending upon the source of code is warranted in the future, that&apos;s a fairly straightforward thing to do w.r.t. the API &amp;#8211; we could have :all and :local as you suggest, with nil representing :none.&lt;/p&gt;</comment>
                    <comment id="23793" author="importer" created="Tue, 28 Sep 2010 00:18:00 -0500"  >&lt;p&gt;stu said: Rich is not comfortable enough with the implementation complexity of this patch (e.g. the guard clause for proxies and gen-class) to slide this in as a minor fix under the wire for 1.2. &lt;/p&gt;

&lt;p&gt;Better to live with the pain we know a little longer than ship something we don&apos;t have enough experience with to be confident.&lt;/p&gt;</comment>
                    <comment id="25949" author="cemerick" created="Fri, 19 Nov 2010 21:28:37 -0600"  >&lt;p&gt;Updated patch to cleanly apply to HEAD and address issues raised by screening done by &lt;a href=&quot;http://groups.google.com/group/clojure-dev/msg/0771729b72e04c9e&quot;&gt;Cosmin Stejerean&lt;/a&gt;.  Also includes proper tests.&lt;/p&gt;

&lt;p&gt;&lt;b&gt;Note: this patch&apos;s tests require the fix for&lt;/b&gt; &lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-432&quot; title=&quot;deftype does not work if containing ns contains dashes&quot;&gt;&lt;del&gt;CLJ-432&lt;/del&gt;&lt;/a&gt;!&lt;/p&gt;</comment>
                    <comment id="25971" author="stu" created="Mon, 29 Nov 2010 07:18:41 -0600"  >&lt;p&gt;the &quot;-resolved&quot; patch resolves a conflict in main.clj&lt;/p&gt;</comment>
                    <comment id="25972" author="stu" created="Mon, 29 Nov 2010 07:25:20 -0600"  >&lt;p&gt;Several questions:&lt;/p&gt;

&lt;ol&gt;
	&lt;li&gt;I am getting an ant build error: &quot;/Users/stuart/repos/clojure/build.xml:137: java.io.FileNotFoundException: Could not locate clojure/test_clojure/aot/nontransitive__init.class or clojure/test_clojure/aot/nontransitive.clj on classpath:&quot;&lt;/li&gt;
	&lt;li&gt;It feels icky to have a method named writeClassFile that, under some circumstances, does &lt;b&gt;not&lt;/b&gt; write a class file, but instead loads it via a dynamic loader. Maybe this is just a naming issue.&lt;/li&gt;
	&lt;li&gt;Are there any other ways to accomplish the goals of &lt;tt&gt;&lt;b&gt;load-level&lt;/b&gt;&lt;/tt&gt;? Or, taking the other side, if we are going to have a &lt;b&gt;load-level&lt;/b&gt;, are there other possible consumers who might have different needs?&lt;/li&gt;
	&lt;li&gt;(Minor) Why the &lt;tt&gt;use :only&lt;/tt&gt; idiom instead of just &lt;tt&gt;require&lt;/tt&gt;?&lt;/li&gt;
&lt;/ol&gt;
</comment>
                    <comment id="26023" author="stuart.sierra" created="Fri, 10 Dec 2010 15:34:32 -0600"  >&lt;p&gt;An alternative approach: patch write-classes-1.diff.gz&lt;/p&gt;

&lt;p&gt;From &lt;a href=&quot;https://github.com/stuartsierra/clojure/tree/write-classes&quot;&gt;my forked branch&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;What this patch does:&lt;/p&gt;

&lt;ul&gt;
	&lt;li&gt;Keeps &apos;compile&apos; and &apos;&lt;b&gt;compile-files&lt;/b&gt;&apos; exactly the same&lt;/li&gt;
	&lt;li&gt;Adds &apos;compile-write-classes&apos; to write .class files for specifically named classes&lt;/li&gt;
	&lt;li&gt;Minor compiler changes to support this&lt;/li&gt;
&lt;/ul&gt;


&lt;p&gt;This approach was prompted by the following observations:&lt;/p&gt;

&lt;ul&gt;
	&lt;li&gt;Java interop is the dominant reason for needing .class files&lt;/li&gt;
	&lt;li&gt;Things other than namespaces can generate classes for Java interop:
	&lt;ul&gt;
		&lt;li&gt;deftype/defrecord&lt;/li&gt;
		&lt;li&gt;defprotocol&lt;/li&gt;
		&lt;li&gt;gen-class/gen-interface&lt;/li&gt;
	&lt;/ul&gt;
	&lt;/li&gt;
	&lt;li&gt;For library releases, we want to control which .class files are emitted on a per-class basis, not per-namespace&lt;/li&gt;
	&lt;li&gt;Some legitimate uses of AOT compilation will want transitive compilation
	&lt;ul&gt;
		&lt;li&gt;Pre-compiling an entire application before release&lt;/li&gt;
	&lt;/ul&gt;
	&lt;/li&gt;
&lt;/ul&gt;
</comment>
                    <comment id="26024" author="cemerick" created="Fri, 10 Dec 2010 16:04:25 -0600"  >&lt;p&gt;S. Halloway: My apologies, I didn&apos;t know you had commented.  I thought that, having assigned this issue to myself, I&apos;d be notified of updates. &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;

&lt;p&gt;FWIW, I aim to review your comments and SS&apos; approach over the weekend.&lt;/p&gt;</comment>
                    <comment id="26035" author="cemerick" created="Thu, 16 Dec 2010 07:36:22 -0600"  >&lt;p&gt;S. Halloway:&lt;/p&gt;

&lt;p&gt;1. Certainly shouldn&apos;t happen.  AFAIK, others have screened the patch, presumably with a successful build.&lt;br/&gt;
2. Agreed; given the approach, I think it&apos;s just a bad name.&lt;br/&gt;
3. Yes, I think S. Sierra&apos;s is one.  See my next comment.&lt;br/&gt;
4. Because the &lt;tt&gt;:use&lt;/tt&gt; form was already there. I&apos;ve actually been using that form of &lt;tt&gt;:use&lt;/tt&gt; more and more; I&apos;ve found that easier than occasionally having to shuffle around specs between &lt;tt&gt;:use&lt;/tt&gt; and &lt;tt&gt;:require&lt;/tt&gt;. I think I&apos;m aping Chris Houser in that regard.&lt;/p&gt;</comment>
                    <comment id="26036" author="cemerick" created="Thu, 16 Dec 2010 09:00:03 -0600"  >&lt;p&gt;I think S. Sierra&apos;s approach is fundamentally superior what I offered.  I have two suggestions: one slight perspective change (which implies no change in the actual implementation), and an idea for an even simpler approach (at least from a user perspective), in that order.&lt;/p&gt;

&lt;p&gt;While interop is the driving requirement behind AOT, I absolutely do not want to have to keep an updated enumeration of all of the classes resulting from each and every &lt;tt&gt;defrecord&lt;/tt&gt; et al. usages in my &lt;tt&gt;pom.xml&lt;/tt&gt;/&lt;tt&gt;project.clj&lt;/tt&gt; (and I wouldn&apos;t wish the task of ferreting those usages and their resulting classnames on any build tool author).&lt;/p&gt;

&lt;p&gt;Right now, &lt;tt&gt;&amp;#42;compile-write-classes&amp;#42;&lt;/tt&gt; is documented to be a set of classname strings, but could just as easily be any other function.  &lt;tt&gt;&amp;#42;compile-write-classes&amp;#42;&lt;/tt&gt; should be documented to accept any predicate function (renamed to e.g. &lt;tt&gt;&amp;#42;compile-write-class?&amp;#42;&lt;/tt&gt;?).  There&apos;s no reason why it shouldn&apos;t be bound to, e.g. &lt;tt&gt;#(re-matches #&quot;foo\.bar\.[\w&amp;#95;]+$&quot; %)&lt;/tt&gt; if I know that all my records are defined in the &lt;tt&gt;foo.bar&lt;/tt&gt; namespace.&lt;/p&gt;

&lt;p&gt;To go along with that, I think some package/classname-globbing utilities along with corresponding options to &lt;tt&gt;clojure.lang.Compile&lt;/tt&gt; would be most welcome.  Classname munging rules are not exactly obvious, and it&apos;d be good to make things a little easier for users in this regard.&lt;/p&gt;

&lt;hr /&gt;

&lt;h5&gt;&lt;a name=&quot;Anotheralternative&quot;&gt;&lt;/a&gt;Another alternative&lt;/h5&gt;
&lt;p&gt;If there&apos;s a closed set of forms that generate classes that one might reasonably be interested in having in a build result (outside of use cases for pervasive AOT), then why not have a simple option that only those forms utilize?  &lt;tt&gt;gen-class&lt;/tt&gt; and &lt;tt&gt;gen-interface&lt;/tt&gt; already do this, but reusing the all-or-nothing &lt;tt&gt;&amp;#42;compile-files&amp;#42;&lt;/tt&gt; binding; if they keyed off of a binding that implied a diminished scope (e.g. &lt;tt&gt;&amp;#42;compile-interop-forms&amp;#42;&lt;/tt&gt; &#8211; which would be &lt;tt&gt;true&lt;/tt&gt; if &lt;tt&gt;&amp;#42;compile-files&amp;#42;&lt;/tt&gt; were &lt;tt&gt;true&lt;/tt&gt;), then they&apos;d do exactly what we wanted.  Extending this approach to &lt;tt&gt;deftype&lt;/tt&gt; (and therefore &lt;tt&gt;defrecord&lt;/tt&gt;) &lt;em&gt;should&lt;/em&gt; be straightforward.&lt;/p&gt;

&lt;p&gt;An implementation of this would probably be somewhat more complicated than S. Sierra&apos;s patch, though not as complex as my original stab at the problem (i.e. no &lt;tt&gt;&amp;#42;load-level&amp;#42;&lt;/tt&gt;).  On the plus side:&lt;/p&gt;

&lt;p&gt;1. No additional configuration for users or implementation work for build tool authors, aside from the addition of the boolean diminished-scope AOT option&lt;br/&gt;
2. Class file generation would remain opaque from a build process standpoint&lt;br/&gt;
3. Future/other class-generating forms (there are a few people futzing with ASM independently, etc) can make local decisions about whether or not to participate in interop-centric classfile generation.  This might be particularly helpful if a given form emits multiple classes, making the determination of a classname-based filter fn less straightforward.&lt;/p&gt;

&lt;p&gt;I can see wanting to further restrict AOT to specific classnames in certain circumstances, in which case the above and S. Sierra&apos;s patch might be complimentary.&lt;/p&gt;</comment>
                    <comment id="26037" author="stuart.sierra" created="Thu, 16 Dec 2010 11:49:12 -0600"  >&lt;p&gt;I like the idea of &lt;tt&gt;&amp;#42;compile-interop-forms&amp;#42;&lt;/tt&gt;.  But is it always possible to determine what an &quot;interop form&quot; is?  I &lt;em&gt;think&lt;/em&gt; it is, I&apos;m just not sure.&lt;/p&gt;</comment>
                    <comment id="26915" author="arohner" created="Sun, 9 Oct 2011 12:50:17 -0500"  >&lt;p&gt;I&apos;m also in favor of compile-interop-forms. As far as determining, how about sticking metadata on the var?&lt;/p&gt;

&lt;p&gt;(defmacro ^{:interop-form true} deftype ...)&lt;/p&gt;</comment>
                    <comment id="27077" author="stuart.sierra" created="Fri, 21 Oct 2011 08:38:31 -0500"  >&lt;p&gt;Summary and design discussion on wiki at &lt;a href=&quot;http://dev.clojure.org/display/design/Transitive+AOT+Compilation&quot;&gt;http://dev.clojure.org/display/design/Transitive+AOT+Compilation&lt;/a&gt;&lt;/p&gt;</comment>
                    <comment id="27367" author="stuart.sierra" created="Tue, 29 Nov 2011 18:54:01 -0600"  >&lt;p&gt;New attachment &lt;tt&gt;compile-interop-1.patch&lt;/tt&gt; has new approach: Add a third possible value for &lt;tt&gt;&amp;#42;compile-files&amp;#42;&lt;/tt&gt;. True and false keep their original meanings, but &lt;tt&gt;:interop&lt;/tt&gt; causes &lt;b&gt;only&lt;/b&gt; interop-related forms to be written out as .class files. &quot;Interop forms&quot; are gen-class, gen-interface, deftype, defrecord, defprotocol, and definterface.&lt;/p&gt;

&lt;p&gt;Pros:&lt;/p&gt;

&lt;ul&gt;
	&lt;li&gt;doesn&apos;t change existing behavior&lt;/li&gt;
	&lt;li&gt;handles common case for non-transitive AOT (interop)&lt;/li&gt;
	&lt;li&gt;minimal changes to the compiler&lt;/li&gt;
&lt;/ul&gt;


&lt;p&gt;Cons:&lt;/p&gt;

&lt;ul&gt;
	&lt;li&gt;not flexible&lt;/li&gt;
&lt;/ul&gt;
</comment>
                    <comment id="27385" author="stuart.sierra" created="Fri, 2 Dec 2011 08:12:21 -0600"  >&lt;p&gt;Just realized my patch doesn&apos;t solve the transitive compilation problem. If library A loads library B, then compiling interop forms in A will also emit interop .class files in B.&lt;/p&gt;</comment>
                    <comment id="30340" author="pmoriarty" created="Tue, 1 Jan 2013 03:55:41 -0600"  >&lt;p&gt;It&apos;s disappointing to see an important issue like this still unresolved after 2.5 years. This is a real pain for us. We have a large closed source project where shipping source is not an option. This forces us to manage the AOT&apos;ing of dependencies due to the hard dependency on protocol interfaces introduced by transitive AOT compilation (see &lt;a href=&quot;https://groups.google.com/forum/?fromgroups=#!topic/clojure-dev/r3A1JOIiwVU&quot;&gt;https://groups.google.com/forum/?fromgroups=#!topic/clojure-dev/r3A1JOIiwVU&lt;/a&gt;).&lt;/p&gt;</comment>
                    <comment id="30346" author="jafingerhut" created="Tue, 1 Jan 2013 16:27:20 -0600"  >&lt;p&gt;Paul, do you have a suggestion for which of the approaches described in comments here, or on the wiki page &lt;a href=&quot;http://dev.clojure.org/display/design/Transitive+AOT+Compilation&quot;&gt;http://dev.clojure.org/display/design/Transitive+AOT+Compilation&lt;/a&gt; would be preferable solution for you?  Or perhaps even a patch that implements your preferred approach?&lt;/p&gt;</comment>
                    <comment id="30371" author="hlewisship" created="Fri, 4 Jan 2013 16:18:11 -0600"  >&lt;p&gt;Andy,&lt;/p&gt;

&lt;p&gt;I&apos;m now consulting with Paudi&apos;s organization, so I think I can speak for him (I&apos;m now the default buildmeister).&lt;/p&gt;

&lt;p&gt;I like Stuart&apos;s :interop idea, but that is somewhat orthogonal to our needs.&lt;/p&gt;

&lt;p&gt;I return to what I would like; compilation would compile specific namespaces; dependencies of those namespaces would not be compiled.&lt;/p&gt;

&lt;p&gt;To be honest, I&apos;m still a little hung up on the interop forms: especially defprotocol and friends; from a cursory glance, it appears that todays AOT compilation will compile the protocol into a Java class, then compile the namespace that references the protocol with the assumption that the protocol&apos;s Java class is available.  When we use build rules to only package our namespace&apos;s class files into the output JAR, the code fails with a NoClassDefFoundError because the protocol really needs to be recompiled, at runtime compilation, into an in-memory Java class.&lt;/p&gt;

&lt;p&gt;Obviously, supporting this correctly will be a challenge; the compiled bytecode for our namespace would ideally:&lt;br/&gt;
1) check to see if the Java class already exists and use it if so&lt;br/&gt;
2) load the necessary namespaces so as to force the creation of the Java class&lt;/p&gt;

&lt;p&gt;I can imagine any number of ways to juggle things to make this work, so I won&apos;t suggest a specific implementation.&lt;/p&gt;

&lt;p&gt;In the meantime, our workaround is to create a &quot;stub&quot; module as part of our build; it simply requires in the necessary namespaces (for example, org.clojure:core.cache); this forces an AOT compile of the dependencies and we have a special rule to package such dependencies in the stub module&apos;s output JAR.  This may not be a scalable problem, and it is expensive to identify what 3rd party dependencies require this treatment.&lt;/p&gt;</comment>
                    <comment id="31152" author="stu" created="Fri, 24 May 2013 13:25:25 -0500"  >&lt;p&gt;I am marking this incomplete because there does not yet seem to be plurality, much less consensus or unanimity, on approach.&lt;/p&gt;

&lt;p&gt;Personally I am in favor of a solution based on a predicate that gets handed the class name and compiled bits, and then can choose whether to write the class. Pretty close to Stuart Sierra&apos;s compile-write-classes.  Might be possible to flow more information than classname to the predicate.&lt;/p&gt;
</comment>
                </comments>
                    <attachments>
                    <attachment id="10035" name="0322-limit-aot-resolved.patch" size="11559" author="stu" created="Mon, 29 Nov 2010 07:18:41 -0600" />
                    <attachment id="10024" name="CLJ-322.diff" size="11478" author="cemerick" created="Fri, 19 Nov 2010 21:28:37 -0600" />
                    <attachment id="10723" name="compile-interop-1.patch" size="1443" author="stuart.sierra" created="Tue, 29 Nov 2011 18:54:01 -0600" />
                    <attachment id="10050" name="write-classes-1.diff.gz" size="1620" author="stuart.sierra" created="Fri, 10 Dec 2010 15:34:31 -0600" />
                </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>cemerick</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>Fri, 24 May 2013 13:21:28 -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>
                    <comment id="31151" author="jafingerhut" created="Fri, 24 May 2013 13:21:28 -0500"  >&lt;p&gt;I am not sure, but this ticket may be related to &lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-1171&quot; title=&quot;Compiler macro for clojure.core/instance? disregards lexical shadows on class names&quot;&gt;CLJ-1171&lt;/a&gt;.  At least, there the issue was a global name &lt;b&gt;not&lt;/b&gt; being shadowed by a local name bound with let.  That seems similar to this issue.&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-669] clojure.java.io/do-copy: use java.nio  for Files</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-669</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;NIO Channels reduce CPU/Disk load when copying Files (by using&lt;br/&gt;
syscalls like sendfile internally on Linux/Solaris).&lt;/p&gt;

&lt;p&gt;CPU-Load goes from 100% to 0% on my system when copying large files, because no userspace-copying is involved:&lt;/p&gt;

&lt;p&gt;Patch: &lt;a href=&quot;http://github.com/juergenhoetzel/clojure/commit/2b5ab103cbcfe6c49236ac6966c032d3c922233d&quot;&gt;http://github.com/juergenhoetzel/clojure/commit/2b5ab103cbcfe6c49236ac6966c032d3c922233d&lt;/a&gt;&lt;/p&gt;</description>
                <environment></environment>
            <key id="14271">CLJ-669</key>
            <summary>clojure.java.io/do-copy: use java.nio  for Files</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 16:03:16 -0500</created>
                <updated>Fri, 24 May 2013 12:45:25 -0500</updated>
                                    <version>Release 1.3</version>
                                <fixVersion>Release 1.6</fixVersion>
                                        <due></due>
                    <votes>0</votes>
                        <watches>2</watches>
                        <comments>
                    <comment id="25965" author="juergenhoetzel" created="Sat, 27 Nov 2010 05:05:14 -0600"  >&lt;p&gt;Patch instead of linking to github&lt;/p&gt;</comment>
                    <comment id="31149" author="jafingerhut" created="Fri, 24 May 2013 12:45:25 -0500"  >&lt;p&gt;Patch clj-669-use-java.nio-in-do-copy-for-files-patch-v2.txt dated May 24 2013 is identical to patch 0001-use-java.nio-in-do-copy-method-for-Files.patch dated Nov 27 2010 except it applies cleanly to latest master.  The older patch conflicts with a recent commit for &lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-1072&quot; title=&quot;Replace old metadata reader macro syntax&quot;&gt;&lt;del&gt;CLJ-1072&lt;/del&gt;&lt;/a&gt; that updates the obsolete #^ syntax for metadata.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="10032" name="0001-use-java.nio-in-do-copy-method-for-Files.patch" size="1158" author="juergenhoetzel" created="Sat, 27 Nov 2010 05:05:14 -0600" />
                    <attachment id="12005" name="clj-669-use-java.nio-in-do-copy-for-files-patch-v2.txt" size="1155" author="jafingerhut" created="Fri, 24 May 2013 12:45: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-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>Fri, 24 May 2013 12:31:42 -0500</updated>
                                                                            <due></due>
                    <votes>1</votes>
                        <watches>0</watches>
                        <comments>
                    <comment id="31147" author="jafingerhut" created="Fri, 24 May 2013 12:31:42 -0500"  >&lt;p&gt;Patch clj-1107-throw-on-get-for-unsupported-types-patch-v2.txt dated May 24 2013 is identical to 0001-&lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-1107&quot; title=&quot;&amp;#39;get&amp;#39; should throw exception on non-Associative argument&quot;&gt;CLJ-1107&lt;/a&gt;-Throw-exception-for-get-called-on-unsupport.patch dated Nov 13 2012, except it applies cleanly to latest master.  A recent commit for &lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-1099&quot; title=&quot;better error message when passing non-seq to seq&quot;&gt;&lt;del&gt;CLJ-1099&lt;/del&gt;&lt;/a&gt; changed many IllegalArgumentException occurrences to Throwable in the tests, which is the only thing changed in this updated patch.&lt;/p&gt;</comment>
                </comments>
                    <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" />
                    <attachment id="12004" name="clj-1107-throw-on-get-for-unsupported-types-patch-v2.txt" size="3090" author="jafingerhut" created="Fri, 24 May 2013 12:31: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="10002">Code and Test</customfieldvalue>

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

<item>
            <title>[CLJ-850] Hinting the arg vector of a primitive-taking fn with a non-primitive type results in AbstractMethodError when invoked</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-850</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;Summary: The &lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-850&quot; title=&quot;Hinting the arg vector of a primitive-taking fn with a non-primitive type results in AbstractMethodError when invoked&quot;&gt;CLJ-850&lt;/a&gt;-conform-to-invokePrim.diff patch is constructed per Rich&apos;s feedback, and appears good to me &lt;span class=&quot;error&quot;&gt;&amp;#91;Stu&amp;#93;&lt;/span&gt;.&lt;/p&gt;

&lt;p&gt;See the following examples:&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; (defn f1 ^String [^String s] s)
#&apos;user/f1
user=&amp;gt; (f1 &quot;foo&quot;)
&quot;foo&quot;
user=&amp;gt; (defn f2 ^long [^String s ^long i] i)
#&apos;user/f2
user=&amp;gt; (f2 &quot;foo&quot; 1)
1
user=&amp;gt; (defn f3 ^String [^String s ^long i] s)                                       
#&apos;user/f3
user=&amp;gt; (f3 &quot;foo&quot; 1)
AbstractMethodError user$f3.invokePrim(Ljava/lang/Object;J)Ljava/lang/Object;  user/eval8 (NO_SOURCE_FILE:6)
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;</description>
                <environment></environment>
            <key id="14677">CLJ-850</key>
            <summary>Hinting the arg vector of a primitive-taking fn with a non-primitive type results in AbstractMethodError when invoked</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="stu">Stuart Halloway</assignee>
                                <reporter username="ataggart">Alexander Taggart</reporter>
                        <labels>
                    </labels>
                <created>Sun, 9 Oct 2011 15:10:53 -0500</created>
                <updated>Fri, 24 May 2013 12:12:20 -0500</updated>
                                    <version>Release 1.3</version>
                                <fixVersion>Release 1.6</fixVersion>
                                        <due></due>
                    <votes>2</votes>
                        <watches>3</watches>
                        <comments>
                    <comment id="26989" author="bsmith.occs@gmail.com" created="Sat, 15 Oct 2011 11:54:52 -0500"  >&lt;p&gt;&lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-850&quot; title=&quot;Hinting the arg vector of a primitive-taking fn with a non-primitive type results in AbstractMethodError when invoked&quot;&gt;CLJ-850&lt;/a&gt;-test.patch added.&lt;/p&gt;</comment>
                    <comment id="27001" author="bsmith.occs@gmail.com" created="Sun, 16 Oct 2011 07:32:43 -0500"  >&lt;p&gt;&lt;del&gt;When the compiler tries to generates the call to the correct overload of invokePrim, it&apos;s failing to take the return type into account. I should be calling &lt;tt&gt;invokePrim(Ljava/lang/Object;J)J;&lt;/tt&gt;.&lt;/del&gt;&lt;/p&gt;

&lt;p&gt;XXX this is where I got myself confused. The &lt;tt&gt;invokePrim&lt;/tt&gt; overload it&apos;s trying to invoke is the &lt;b&gt;correct&lt;/b&gt; one. But, that apparently is no the one that&apos;s being generated. Sorry for the noise.&lt;/p&gt;</comment>
                    <comment id="27002" author="bsmith.occs@gmail.com" created="Sun, 16 Oct 2011 10:17:49 -0500"  >&lt;p&gt;&lt;del&gt;Here&apos;s what I think I&apos;m seeing:&lt;/del&gt;&lt;/p&gt;

&lt;p&gt;&lt;del&gt;&lt;tt&gt;HostExpr.Parse.parse()&lt;/tt&gt; loses track of the return type, in the final else branch where method calls are handled.  This is because &lt;tt&gt;tagOf(form)&lt;/tt&gt;, where form is something like: &lt;tt&gt;(. foo invokePrim 1)&lt;/tt&gt; returns nil. (The form itself doesn&apos;t have a &lt;tt&gt;:tag&lt;/tt&gt;, but I believe &lt;tt&gt;foo&lt;/tt&gt; does, though that&apos;s the name of the appropriate &lt;tt&gt;invokePrim&lt;/tt&gt; interface (i.e. &lt;tt&gt;IFn$OLL&lt;/tt&gt;).&lt;/del&gt;&lt;/p&gt;

&lt;p&gt;&lt;del&gt;&lt;tt&gt;new InstanceMethodExpr(...)&lt;/tt&gt; then gets constructed with &lt;tt&gt;tag==null&lt;/tt&gt;, at which point we&apos;ve already lost sine InstanceMethodExpr can&apos;t correctly consider overloading on the result type if it doesn&apos;t know what it is.&lt;/del&gt;&lt;/p&gt;

&lt;p&gt;&lt;del&gt;It&apos;s not yet clear to me how I can get InstanceMethodExpr to consider the return type, if it knew it...&lt;/del&gt;&lt;/p&gt;





</comment>
                    <comment id="27015" author="bsmith.occs@gmail.com" created="Tue, 18 Oct 2011 00:29:22 -0500"  >
&lt;p&gt;There are two things going on here. I&apos;m not sure which is the error.&lt;/p&gt;

&lt;p&gt;It looks like the return type of the generated invokePrim method is too specific. It&apos;s generated as returning String, though the IFn$LO interface specifies returning Object.&lt;/p&gt;

&lt;p&gt;The caller attempts to call invokePrim returning Object, which is what the interface IFn$LO specifies, but this doesn&apos;t work because methodSL doesn&apos;t actually implement that method. Instead it implements an overload returning String.&lt;/p&gt;

&lt;ol&gt;
	&lt;li&gt;methodSL.invokePrim is declared as &lt;tt&gt;(long)-&amp;gt;String&lt;/tt&gt;&lt;/li&gt;
	&lt;li&gt;methodSL.invoke does invokeinterface with the correct return type WRT methodSL, but the wrong return type WRT the IFn$LO interface.&lt;/li&gt;
	&lt;li&gt;callSL.invoke does invokeinterface with the wrong return type WRT methodSL, but the correct return type WRT IFn$LO. (This is the failure we observe in the clj-850 unit test.)&lt;/li&gt;
&lt;/ol&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 methodSL  ^String [^long i] (str i))
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&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;&amp;lt;&amp;lt;1&amp;gt;&amp;gt; public final java.lang.String invokePrim(long);  &amp;lt;&amp;lt;1&amp;gt;&amp;gt;
      Code:
       0:   getstatic   #25; 
            //Field const__0:Lclojure/lang/Var;
       3:   invokevirtual   #34; 
            //Method clojure/lang/Var.getRawRoot:()Ljava/lang/Object;
       6:   checkcast   #36; 
            //class clojure/lang/IFn
       9:   lload_1
       10:  invokestatic    #42; 
            //Method clojure/lang/Numbers.num:(J)Ljava/lang/Number;
       13:  invokeinterface #46,  2; 
            //InterfaceMethod clojure/lang/IFn.invoke:(Ljava/lang/Object;)Ljava/lang/Object;
       18:  checkcast   #48; 
            //class java/lang/String
       21:  areturn
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&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;      public java.lang.Object invoke(java.lang.Object);
      Code:
       0:   aload_0
       1:   aload_1
       2:   checkcast   #54; 
            //class java/lang/Number
       5:   invokestatic    #58; 
            //Method clojure/lang/RT.longCast:(Ljava/lang/Object;)J
&amp;lt;&amp;lt;2&amp;gt;&amp;gt;  8:   invokeinterface #60,  3; 
            //InterfaceMethod clojure/lang/IFn$LO.invokePrim:(J)Ljava/lang/String;
       13:  areturn
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&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 callSL ^String [] (methodSL 42))
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&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;    public java.lang.Object invoke();
      Code:
       0:   getstatic   #25; 
            //Field const__0:Lclojure/lang/Var;
       3:   invokevirtual   #43; 
            //Method clojure/lang/Var.getRawRoot:()Ljava/lang/Object;
       6:   checkcast   #45; 
            //class clojure/lang/IFn$LO
       9:   ldc2_w  #26; 
            //long 42l
&amp;lt;&amp;lt;3&amp;gt;&amp;gt;  12:  invokeinterface #49,  3; 
            //InterfaceMethod clojure/lang/IFn$LO.invokePrim:(J)Ljava/lang/Object;
       17:  areturn
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;</comment>
                    <comment id="27016" author="bsmith.occs@gmail.com" created="Tue, 18 Oct 2011 01:40:59 -0500"  >&lt;p&gt;Given &lt;tt&gt;P&lt;/tt&gt; is some primitive type, &lt;tt&gt;O&lt;/tt&gt; is type Object, and &lt;tt&gt;R&lt;/tt&gt; some subclass of Object: &lt;/p&gt;

&lt;p&gt;When Clojure generates a &lt;tt&gt;R invokePrim(P x)&lt;/tt&gt;, it also generates a &lt;tt&gt;Object invoke(Object x)&lt;/tt&gt;, which delegates to &lt;tt&gt;R invokePrim(P x)&lt;/tt&gt;. &lt;/p&gt;

&lt;p&gt;&lt;tt&gt;R invokePrim(P x)&lt;/tt&gt; &lt;em&gt;overloads&lt;/em&gt;, but does not &lt;em&gt;override&lt;/em&gt; the method of the corresponding &lt;tt&gt;Fn$PO&lt;/tt&gt; interface. &lt;/p&gt;

&lt;p&gt;If Clojure were to generate an additional &lt;tt&gt;O invokePrim(P x)&lt;/tt&gt; which delegates to &lt;tt&gt;R invokePrim(P x)&lt;/tt&gt;, it would satisfy the requirements of the &lt;tt&gt;Fn$PO&lt;/tt&gt; interface, and should fix this issue.&lt;/p&gt;</comment>
                    <comment id="27018" author="bsmith.occs@gmail.com" created="Tue, 18 Oct 2011 14:54:41 -0500"  >&lt;p&gt;&lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-850&quot; title=&quot;Hinting the arg vector of a primitive-taking fn with a non-primitive type results in AbstractMethodError when invoked&quot;&gt;CLJ-850&lt;/a&gt;.patch fixes the issue.&lt;/p&gt;

&lt;p&gt;I consider this patch to be pretty hackish and hope that there&apos;s a cleaner way of addressing &lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-850&quot; title=&quot;Hinting the arg vector of a primitive-taking fn with a non-primitive type results in AbstractMethodError when invoked&quot;&gt;CLJ-850&lt;/a&gt;. This is the first time I&apos;ve tried to understand (much less change) the Clojure compiler, so don&apos;t expect genius.&lt;/p&gt;</comment>
                    <comment id="27020" author="bsmith.occs@gmail.com" created="Wed, 19 Oct 2011 05:06:03 -0500"  >&lt;p&gt;The patch lies slightly:&lt;/p&gt;

&lt;blockquote&gt;
&lt;p&gt;Clojure needs to generate an additional &lt;tt&gt;O invokePrim(P x)&lt;/tt&gt; method to&lt;br/&gt;
satisfy the interface. This also delegates to &lt;tt&gt;R invokePrim(P x)&lt;/tt&gt;.&lt;/p&gt;&lt;/blockquote&gt;

&lt;p&gt;It turns out that what I&apos;m actually doing is generating a &lt;tt&gt;R invokePrim(P x)&lt;/tt&gt; which is a copy of &lt;tt&gt;O invokePrim(P x)&lt;/tt&gt;, instead of delgating to &lt;tt&gt;O invokePrim(P x)&lt;/tt&gt;. This works, but the resulting class file would be smaller if the patch actually did what it says it does.&lt;/p&gt;</comment>
                    <comment id="27882" author="jafingerhut" created="Tue, 28 Feb 2012 00:49:32 -0600"  >&lt;p&gt;clj-850-type-hinted-fn-abstractmethoderror-patch2.txt is identical to Ben&apos;s two patches combined into one, with the small modification that the new tests are added to metadata.clj instead of creating a new test file.  The patch applies cleanly to latest master as of Feb 27, 2012.  One of the new tests does fail without the change to the compiler, and succeeds with it.  I can&apos;t vouch for the correctness of the change myself, not knowing enough about the compiler internals to judge.&lt;/p&gt;</comment>
                    <comment id="27999" author="jafingerhut" created="Fri, 23 Mar 2012 19:50:25 -0500"  >&lt;p&gt;Same comments as made on Feb 27, 2012, except the patch clj-850-type-hinted-fn-abstractmethoderror-patch3.txt applies cleanly to latest master as of Mar 23, 2012.  Updated because previous patch (now removed) no longer applied cleanly.  git patches often fail to apply if context lines near changes are modified.&lt;/p&gt;</comment>
                    <comment id="28135" author="richhickey" created="Fri, 13 Apr 2012 09:35:51 -0500"  >&lt;p&gt;We don&apos;t support sigs taking prims and returning anything other than prim or Object. Overloading on return value only is a bad idea (and forbidden in Java). The return type of the generated method should be Object, and the String return hint should be used only as a hint.&lt;/p&gt;</comment>
                    <comment id="29887" author="jafingerhut" created="Thu, 1 Nov 2012 19:22:38 -0500"  >&lt;p&gt;clj-850-type-hinted-fn-abstractmethoderror-patch4.txt dated Nov 1 2012 is same as Ben Smith-Mannschott&apos;s &lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-850&quot; title=&quot;Hinting the arg vector of a primitive-taking fn with a non-primitive type results in AbstractMethodError when invoked&quot;&gt;CLJ-850&lt;/a&gt;.patch and &lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-850&quot; title=&quot;Hinting the arg vector of a primitive-taking fn with a non-primitive type results in AbstractMethodError when invoked&quot;&gt;CLJ-850&lt;/a&gt;-test.patch, except it has been combined into one patch and does not create a new test source file.&lt;/p&gt;</comment>
                    <comment id="30196" author="mikera" created="Sun, 9 Dec 2012 15:42:29 -0600"  >&lt;p&gt;+10 for solving this issue: it keeps biting me in 1.4 and wouuld love to see in 1.5&lt;/p&gt;

&lt;p&gt;I&apos;m not familiar with the Clojure compiler internals, but looking at the approach, shouldn&apos;t we produce a primitive method with a different name (since Java doesn&apos;t support overloading on return types as Rich correctly points out). Also I think there should be 4 methods:&lt;/p&gt;

&lt;p&gt;    R invokePrimExact(P x) - the actual method, used when compiler can infer&lt;br/&gt;
    R invokePrimExact(O x) - delegates, used when compiler can&apos;t infer type of x&lt;br/&gt;
    Object invokePrim(P x) - primitive method, conforms to IFn$PO interface, delegates&lt;br/&gt;
    Object invoke(Object x) - general method, delegates&lt;/p&gt;

&lt;p&gt;I think this solves all the important cases?&lt;/p&gt;</comment>
                    <comment id="30266" author="richhickey" created="Wed, 19 Dec 2012 08:03:40 -0600"  >&lt;p&gt;Still no patch incorporating my feedback, afaict. Pushing to next release.&lt;/p&gt;</comment>
                    <comment id="30269" author="gshayban" created="Wed, 19 Dec 2012 15:41:42 -0600"  >&lt;p&gt;Does this new patch address the issue and concerns?  (This incorporates Ben&apos;s tests from the previous patch, wasn&apos;t sure how to attribute him on that hunk)  &lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-850&quot; title=&quot;Hinting the arg vector of a primitive-taking fn with a non-primitive type results in AbstractMethodError when invoked&quot;&gt;CLJ-850&lt;/a&gt;-conform-to-invokePrim.diff&lt;/p&gt;</comment>
                    <comment id="30287" author="jafingerhut" created="Fri, 21 Dec 2012 22:53:27 -0600"  >&lt;p&gt;Presumptuously changing state from Incomplete back to Vetted after Ghadi Shayban added the patch &lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-850&quot; title=&quot;Hinting the arg vector of a primitive-taking fn with a non-primitive type results in AbstractMethodError when invoked&quot;&gt;CLJ-850&lt;/a&gt;-conform-to-invokePrim.diff dated Dec 19 2012 after the status was changed to Incomplete.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="11769" name="CLJ-850-conform-to-invokePrim.diff" size="2336" author="gshayban" created="Wed, 19 Dec 2012 15:41:42 -0600" />
                    <attachment id="10411" name="CLJ-850.patch" size="2531" author="bsmith.occs@gmail.com" created="Tue, 18 Oct 2011 14:54:41 -0500" />
                    <attachment id="10400" name="CLJ-850-test.patch" size="2482" author="bsmith.occs@gmail.com" created="Sat, 15 Oct 2011 11:54:52 -0500" />
                    <attachment id="11656" name="clj-850-type-hinted-fn-abstractmethoderror-patch4.txt" size="3769" author="jafingerhut" created="Thu, 1 Nov 2012 19:22:38 -0500" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_10002" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Approval</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10004">Screened</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-1193] bigint, biginteger throw on double values outside of long range</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1193</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;This works fine:&lt;/p&gt;

&lt;p&gt;    user&amp;gt; (bigint (* 0.99 Long/MAX_VALUE))&lt;br/&gt;
    9131138316486227968N&lt;/p&gt;

&lt;p&gt;but this and any other Float or Double values outside the range of a&lt;br/&gt;
long throw an exception:&lt;/p&gt;

&lt;p&gt;    user&amp;gt; (bigint (* 1.01 Long/MAX_VALUE))&lt;br/&gt;
    IllegalArgumentException Value out of range for long: 9.315605757223324E18  clojure.lang.RT.longCast (RT.java:1178)&lt;/p&gt;

&lt;p&gt;Similarly for biginteger&lt;/p&gt;</description>
                <environment></environment>
            <key id="16131">CLJ-1193</key>
            <summary>bigint, biginteger throw on double values outside of long range</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, 7 Apr 2013 16:35:13 -0500</created>
                <updated>Fri, 24 May 2013 11:46:12 -0500</updated>
                                                    <fixVersion>Release 1.6</fixVersion>
                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                        <comments>
                    <comment id="30902" author="jafingerhut" created="Sun, 7 Apr 2013 16:38:48 -0500"  >&lt;p&gt;Patch clj-1197-make-bigint-work-on-all-doubles-v1.txt dated Apr 7 2013 changes bigint and biginteger so that they return the correct value for all float and double values, and no longer throw an exception.&lt;/p&gt;</comment>
                    <comment id="31100" author="cldwalker" created="Fri, 17 May 2013 10:52:24 -0500"  >&lt;p&gt;Looks good. Tests pass and the failing example now converts correctly&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="11948" name="clj-1197-make-bigint-work-on-all-doubles-v1.txt" size="2499" author="jafingerhut" created="Sun, 7 Apr 2013 16:38:48 -0500" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_10002" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Approval</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10004">Screened</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-1171] Compiler macro for clojure.core/instance? disregards lexical shadows on class names</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1171</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;h1&gt;&lt;a name=&quot;Summary&quot;&gt;&lt;/a&gt;Summary&lt;/h1&gt;
&lt;p&gt;The compiler tries to emit jvm native &lt;b&gt;instanceof&lt;/b&gt; expressions for direct &lt;b&gt;clojure.core/instance?&lt;/b&gt; calls.&lt;br/&gt;
For that, it tries to resolve its first argument as a class name. However, it disregards lexical bindings when doing that.&lt;br/&gt;
This is incongruent to the default implementation in core.clj&lt;/p&gt;

&lt;h2&gt;&lt;a name=&quot;Patches&quot;&gt;&lt;/a&gt;Patches&lt;/h2&gt;

&lt;p&gt;&lt;span class=&quot;error&quot;&gt;&amp;#91;Stu&amp;#93;&lt;/span&gt; All three patches should be applied IMO.&lt;/p&gt;

&lt;ul&gt;
	&lt;li&gt;0002 makes &lt;tt&gt;instance?&lt;/tt&gt; respect lexical bindings&lt;/li&gt;
	&lt;li&gt;0003 makes &lt;tt&gt;instance?&lt;/tt&gt;&apos;s compiled form check arity, consistent with higher-order behavior&lt;/li&gt;
	&lt;li&gt;0001 has a minimal test for both 0002 and 0003.&lt;/li&gt;
&lt;/ul&gt;


&lt;h1&gt;&lt;a name=&quot;Data&quot;&gt;&lt;/a&gt;Data&lt;/h1&gt;

&lt;h2&gt;&lt;a name=&quot;Testcase&quot;&gt;&lt;/a&gt;Test case&lt;/h2&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; (let [&lt;span class=&quot;code-object&quot;&gt;Long&lt;/span&gt; &lt;span class=&quot;code-object&quot;&gt;String&lt;/span&gt;] (instance? &lt;span class=&quot;code-object&quot;&gt;Long&lt;/span&gt; &lt;span class=&quot;code-quote&quot;&gt;&quot;abc&quot;&lt;/span&gt;))
&lt;span class=&quot;code-keyword&quot;&gt;false&lt;/span&gt;
;; expected &lt;span class=&quot;code-keyword&quot;&gt;true&lt;/span&gt; as in
user=&amp;gt; (let [&lt;span class=&quot;code-object&quot;&gt;Long&lt;/span&gt; &lt;span class=&quot;code-object&quot;&gt;String&lt;/span&gt;] (apply instance? [&lt;span class=&quot;code-object&quot;&gt;Long&lt;/span&gt; &lt;span class=&quot;code-quote&quot;&gt;&quot;abc&quot;&lt;/span&gt;]))
&lt;span class=&quot;code-keyword&quot;&gt;true&lt;/span&gt;&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;h2&gt;&lt;a name=&quot;Culpritmethod&quot;&gt;&lt;/a&gt;Culprit method&lt;/h2&gt;
&lt;p&gt;&lt;a href=&quot;https://github.com/clojure/clojure/blob/4ccb10edbe66eae81336a4c0972050d9759b0bf7/src/jvm/clojure/lang/Compiler.java#L3578&quot;&gt;https://github.com/clojure/clojure/blob/4ccb10edbe66eae81336a4c0972050d9759b0bf7/src/jvm/clojure/lang/Compiler.java#L3578&lt;/a&gt;&lt;/p&gt;

&lt;h2&gt;&lt;a name=&quot;ListDiscussion&quot;&gt;&lt;/a&gt;List Discussion&lt;/h2&gt;
&lt;p&gt;&lt;a href=&quot;https://groups.google.com/d/topic/clojure/mf25OlFRpa8/discussion&quot;&gt;https://groups.google.com/d/topic/clojure/mf25OlFRpa8/discussion&lt;/a&gt;&lt;/p&gt;

&lt;h1&gt;&lt;a name=&quot;Tangent&quot;&gt;&lt;/a&gt;Tangent&lt;/h1&gt;
&lt;p&gt;This was discovered because the same compiler macro also omits the arity check implicit in the default definition. This could also conveniently be fixed when touching that method:&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; (instance? &lt;span class=&quot;code-object&quot;&gt;String&lt;/span&gt;)
&lt;span class=&quot;code-keyword&quot;&gt;false&lt;/span&gt;
;; expected
user=&amp;gt; (apply instance? [&lt;span class=&quot;code-object&quot;&gt;String&lt;/span&gt;])
ArityException Wrong number of args (1) passed to: core$instance-QMARK-  clojure.lang.AFn.throwArity (AFn.java:437)&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;blockquote&gt;
&lt;p&gt;&lt;b&gt;EDIT&lt;/b&gt; elaborated on ticket title and description; added tangent&lt;/p&gt;&lt;/blockquote&gt;</description>
                <environment></environment>
            <key id="16030">CLJ-1171</key>
            <summary>Compiler macro for clojure.core/instance? disregards lexical shadows on class names</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="stu">Stuart Halloway</assignee>
                                <reporter username="bendlas">Herwig Hochleitner</reporter>
                        <labels>
                    </labels>
                <created>Wed, 27 Feb 2013 13:21:16 -0600</created>
                <updated>Fri, 24 May 2013 11:29:14 -0500</updated>
                                                    <fixVersion>Release 1.6</fixVersion>
                                        <due></due>
                    <votes>0</votes>
                        <watches>1</watches>
                        <comments>
                    <comment id="30668" author="bendlas" created="Wed, 27 Feb 2013 20:11:30 -0600"  >&lt;p&gt;Attached patches test and fix issue + tangent&lt;/p&gt;</comment>
                    <comment id="30698" author="bendlas" created="Mon, 4 Mar 2013 15:51:36 -0600"  >&lt;p&gt;Note: Patch 0003 just adds the arity check, hence is optional, but if it&apos;s omitted from the patchset, the corresponding test from patch 0001 will fail.&lt;/p&gt;</comment>
                    <comment id="30843" author="stu" created="Fri, 29 Mar 2013 07:31:45 -0500"  >&lt;p&gt;Summarizing the decisions in these patches:&lt;/p&gt;

&lt;ul&gt;
	&lt;li&gt;&lt;tt&gt;instance?&lt;/tt&gt; and &lt;tt&gt;apply instance?&lt;/tt&gt; should be consistent&lt;/li&gt;
	&lt;li&gt;they should check arity  (matching &lt;tt&gt;apply instance?&lt;/tt&gt; existing behavior)&lt;/li&gt;
	&lt;li&gt;they should allow lexical shadowing of the class argument (matching &lt;tt&gt;apply instance?&lt;/tt&gt; existing behavior)&lt;/li&gt;
&lt;/ul&gt;


&lt;p&gt;It is possible (although unlikely) that existing code relies on the current eccentric behavior of &lt;tt&gt;instance?&lt;/tt&gt;.  I think it would be fair to categorize programs relying on this behavior as buggy, but that is easy for me to say. &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>
                    <attachment id="11877" name="0001-CLJ-1171-Tests-for-clojure.core-instance-compiler-ma.patch" size="919" author="bendlas" created="Wed, 27 Feb 2013 20:11:30 -0600" />
                    <attachment id="11878" name="0002-CLJ-1171-Obey-lexical-scope-for-class-argument-in-in.patch" size="1248" author="bendlas" created="Wed, 27 Feb 2013 20:11:30 -0600" />
                    <attachment id="11879" name="0003-CLJ-1171-Check-arity-in-instance-compiler-macro.patch" size="970" author="bendlas" created="Wed, 27 Feb 2013 20:11:30 -0600" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_10002" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Approval</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10004">Screened</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-1161] sources jar has bad versions.properties resource</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1161</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;Summary: patch leaves version.properties file out of sources JAR, where it causes problems for tools.&lt;/p&gt;

&lt;p&gt;The &quot;sources&quot; jar (at least since Clojure 1.4 and including 1.5 RC) has a bad version.properties file in it. The resource clojure/version.properties is literally:&lt;/p&gt;

&lt;p&gt;version=${version}&lt;/p&gt;

&lt;p&gt;The regular Clojure jar has the correct version string in that resource.&lt;/p&gt;

&lt;p&gt;I came across a problem when I was experimenting with the sources jar (as used by IDEs).  I naively added the sources jar to my classpath, and Clojure died on start up.  The bad clojure/versions.properties file was found first, which led to a parse error as the clojure version was being set.&lt;/p&gt;</description>
                <environment></environment>
            <key id="16001">CLJ-1161</key>
            <summary>sources jar has bad versions.properties resource</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="stu">Stuart Halloway</assignee>
                                <reporter username="steveminer@gmail.com">Steve Miner</reporter>
                        <labels>
                        <label>patch</label>
                    </labels>
                <created>Mon, 11 Feb 2013 10:03:01 -0600</created>
                <updated>Fri, 24 May 2013 11:13:59 -0500</updated>
                                    <version>Release 1.4</version>
                <version>Release 1.5</version>
                                <fixVersion>Release 1.5</fixVersion>
                <fixVersion>Release 1.6</fixVersion>
                                        <due></due>
                    <votes>0</votes>
                        <watches>1</watches>
                        <comments>
                    <comment id="30577" author="steveminer@gmail.com" created="Mon, 11 Feb 2013 10:04:27 -0600"  >&lt;p&gt;Notes from the dev mailing list:&lt;/p&gt;

&lt;p&gt;The &quot;sources&quot; JAR is generated by another Maven plugin, configured here:&lt;br/&gt;
&lt;a href=&quot;https://github.com/clojure/clojure/blob/clojure-1.5.0-RC15/pom.xml#L169-L181&quot;&gt;https://github.com/clojure/clojure/blob/clojure-1.5.0-RC15/pom.xml#L169-L181&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;The simplest solution might be to just exclude the file from the sources jar. It looks like maven-source-plugin has an excludes option which would do the trick:&lt;/p&gt;

&lt;p&gt;&lt;a href=&quot;http://maven.apache.org/plugins/maven-source-plugin/jar-mojo.html#excludes&quot;&gt;http://maven.apache.org/plugins/maven-source-plugin/jar-mojo.html#excludes&lt;/a&gt;&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="11861" name="0001-CLJ-1161-Remove-version.properties-from-sources-JAR.patch" size="1099" author="stuart.sierra" created="Sat, 16 Feb 2013 15:19:33 -0600" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_10002" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Approval</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10004">Screened</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-1175] NPE in clojure.lang.Delay/deref</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1175</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;Summary: Delays get into a corrupt state if an exception thrown, allowing deref to behave differently on back-to-back calls.  Patch causes Delay to rethrow the original exception, includes tests.&lt;/p&gt;

&lt;p&gt;If a Delay wraps a function which throws an exception, then forcing that delay multiple times causes behavior which is, to me at least, surprising and unexpected: the first time it is forced, the expected exception is thrown; but after that it will behave as if all locals the expression refers to are nil. This can manifest in multiple ways, depending on the expression being delayed:&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;;; calling a local as a function causes an NPE inside clojure.lang.Delay
(let [f #(/ 1 0) d (delay (f))]
  [(&lt;span class=&quot;code-keyword&quot;&gt;try&lt;/span&gt; (force d) 
        (&lt;span class=&quot;code-keyword&quot;&gt;catch&lt;/span&gt; Exception e e))
   (&lt;span class=&quot;code-keyword&quot;&gt;try&lt;/span&gt; (force d)
        (&lt;span class=&quot;code-keyword&quot;&gt;catch&lt;/span&gt; Exception e e))])
[#&amp;lt;ArithmeticException java.lang.ArithmeticException: Divide by zero&amp;gt; 
 #&amp;lt;NullPointerException java.lang.NullPointerException&amp;gt;]&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;;; &lt;span class=&quot;code-keyword&quot;&gt;if&lt;/span&gt; nil is a valid value, &lt;span class=&quot;code-keyword&quot;&gt;this&lt;/span&gt; can cause subsequent forces to &lt;span class=&quot;code-quote&quot;&gt;&quot;succeed&quot;&lt;/span&gt;
;; even though the first fails as it should
(let [x (java.util.Date.) d (delay (seq x))]
  [(&lt;span class=&quot;code-keyword&quot;&gt;try&lt;/span&gt; (force d) 
        (&lt;span class=&quot;code-keyword&quot;&gt;catch&lt;/span&gt; Exception e e))
   (&lt;span class=&quot;code-keyword&quot;&gt;try&lt;/span&gt; (force d)
        (&lt;span class=&quot;code-keyword&quot;&gt;catch&lt;/span&gt; Exception e e))])
[#&amp;lt;IllegalArgumentException java.lang.IllegalArgumentException: Don&apos;t know how to create ISeq from: java.util.Date&amp;gt; 
 nil]&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;The reason for this is that clojure.core/delay creates a ^:once function, promising to call it only once, so that the compiler can do locals-clearing on its lexical closure. However, when an exception is thrown the Delay object is left thinking it has never called the function, so when it is forced again it calls the function again, breaking its promise to the compiler and causing the function to run after its locals have been cleared.&lt;/p&gt;

&lt;p&gt;In fact, once we realize that locals-clearing is involved, we can make the delay behave differently the first N times it is forced, instead of only the first time, by constructing an expression which throws an exception before using all of its locals:&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;(let [x (java.util.Date.) 
            y (&lt;span class=&quot;code-object&quot;&gt;Long&lt;/span&gt;. 1)
            d (delay (let [y (seq y)]
                       (cons (seq x) y)))]
  [(&lt;span class=&quot;code-keyword&quot;&gt;try&lt;/span&gt; (force d) 
        (&lt;span class=&quot;code-keyword&quot;&gt;catch&lt;/span&gt; Exception e e))
   (&lt;span class=&quot;code-keyword&quot;&gt;try&lt;/span&gt; (force d)
        (&lt;span class=&quot;code-keyword&quot;&gt;catch&lt;/span&gt; Exception e e))
   (&lt;span class=&quot;code-keyword&quot;&gt;try&lt;/span&gt; (force d)
        (&lt;span class=&quot;code-keyword&quot;&gt;catch&lt;/span&gt; Exception e e))])
[#&amp;lt;IllegalArgumentException java.lang.IllegalArgumentException: Don&apos;t know how to create ISeq from: java.lang.&lt;span class=&quot;code-object&quot;&gt;Long&lt;/span&gt;&amp;gt; 
 #&amp;lt;IllegalArgumentException java.lang.IllegalArgumentException: Don&apos;t know how to create ISeq from: java.util.Date&amp;gt;
 (nil)]&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;I&apos;m not sure what the right fix for this issue is: perhaps the best choice is even to leave it alone, and just document that delay&apos;s behavior is undefined if the expression throws an exception. However, I propose making the Delay remember the first exception that was thrown, and rethrow it on subsequent force attempts. This makes sense, in a way: the &quot;result&quot; of the expression was this exception &lt;b&gt;e&lt;/b&gt; being thrown, and so this should happen every time. It might be preferable to have the Delay retry the expression until it succeeds, but I don&apos;t believe this is possible without abandoning locals-clearing, which would cause perfectly-valid delays to now run out of memory, holding onto no-longer-needed locals just in case the expression needs to retry at some later date.&lt;/p&gt;</description>
                <environment></environment>
            <key id="16057">CLJ-1175</key>
            <summary>NPE in clojure.lang.Delay/deref</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="stu">Stuart Halloway</assignee>
                                <reporter username="amalloy">Alan Malloy</reporter>
                        <labels>
                    </labels>
                <created>Wed, 6 Mar 2013 15:06:15 -0600</created>
                <updated>Fri, 24 May 2013 11:02:21 -0500</updated>
                                                    <fixVersion>Release 1.6</fixVersion>
                                        <due></due>
                    <votes>3</votes>
                        <watches>1</watches>
                                <attachments>
                    <attachment id="11894" name="delayed-exceptions.patch" size="2019" author="amalloy" created="Wed, 6 Mar 2013 15:06:15 -0600" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_10002" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Approval</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10004">Screened</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-1176] clojure.repl/source fails when *read-eval* bound to :unknown</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1176</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;clojure.repl/source is broken in Clojure 1.5.0 when &amp;#42;read-eval&amp;#42; is bound to :unknown, since source-fn reads without binding.&lt;/p&gt;

&lt;p&gt;Reproduce:&lt;/p&gt;

&lt;ol&gt;
	&lt;li&gt;Either set &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;:jvm-opts [&quot;-Dclojure.read.eval=unknown&quot;]&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt; in Leiningen or eval at REPL: &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;(alter-var-root #&apos;*read-eval* (constantly :unknown))&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;&lt;/li&gt;
	&lt;li&gt;&lt;tt&gt;(use &apos;clojure.repl)&lt;/tt&gt;&lt;/li&gt;
	&lt;li&gt;&lt;tt&gt;(source drop-last)&lt;/tt&gt;&lt;/li&gt;
&lt;/ol&gt;


&lt;p&gt;Expected:&lt;/p&gt;

&lt;p&gt;Source of drop-last.&lt;/p&gt;

&lt;p&gt;Actual:&lt;/p&gt;

&lt;p&gt;RuntimeException Reading disallowed - &amp;#42;read-eval&amp;#42; bound to :unknown&lt;/p&gt;</description>
                <environment></environment>
            <key id="16058">CLJ-1176</key>
            <summary>clojure.repl/source fails when *read-eval* bound to :unknown</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="timmc">Tim McCormack</reporter>
                        <labels>
                    </labels>
                <created>Wed, 6 Mar 2013 15:26:45 -0600</created>
                <updated>Fri, 24 May 2013 09:42:41 -0500</updated>
                                    <version>Release 1.5</version>
                                <fixVersion>Release 1.6</fixVersion>
                                        <due></due>
                    <votes>0</votes>
                        <watches>1</watches>
                        <comments>
                    <comment id="30705" author="timmc" created="Wed, 6 Mar 2013 16:04:03 -0600"  >&lt;p&gt;The attached patch just binds &amp;#42;read-eval&amp;#42; to true inside source-fn.&lt;/p&gt;</comment>
                    <comment id="30840" author="stu" created="Fri, 29 Mar 2013 06:24:27 -0500"  >&lt;p&gt;Note: Allowing this implies that you trust the data on your classpath.  If there are reasons somebody might not, we should reject this patch and people will have to be explicit when calling source.&lt;/p&gt;</comment>
                    <comment id="30841" author="timmc" created="Fri, 29 Mar 2013 06:37:27 -0500"  >&lt;p&gt;Ugh, that&apos;s a fair point when it comes to sandboxing. I&apos;ll check with the owners of clojurebot and lazybot.&lt;/p&gt;</comment>
                    <comment id="31051" author="timmc" created="Sat, 4 May 2013 22:40:43 -0500"  >&lt;p&gt;I haven&apos;t come up with any scenarios where this is problematic, and I haven&apos;t heard anything back from the bot owners. As for sandboxing, clojure.repl can easily be excluded.&lt;/p&gt;</comment>
                    <comment id="31140" author="cldwalker" created="Fri, 24 May 2013 09:42:41 -0500"  >&lt;p&gt;Looks good&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="11895" name="0001-CLJ-1176-Bind-read-eval-true-in-clojure.repl-source-.patch" size="928" author="timmc" created="Wed, 6 Mar 2013 16:04:03 -0600" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_10002" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Approval</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10004">Screened</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-1187] Clojure loses quoted metadata on empty literals</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1187</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;user=&amp;gt; (meta &apos;^:foo [])&lt;br/&gt;
nil&lt;/p&gt;

&lt;p&gt;while&lt;br/&gt;
user=&amp;gt; (meta &apos;^:foo &lt;span class=&quot;error&quot;&gt;&amp;#91;1&amp;#93;&lt;/span&gt;)&lt;br/&gt;
{:foo true}&lt;/p&gt;

&lt;p&gt;This bug propagates to ^:const vars:&lt;br/&gt;
user=&amp;gt; (def ^:const foo ^:foo [])&lt;br/&gt;
#&apos;user/foo&lt;br/&gt;
user=&amp;gt; (meta foo)&lt;br/&gt;
nil&lt;br/&gt;
user=&amp;gt; (meta @#&apos;foo)&lt;br/&gt;
{:foo true}&lt;/p&gt;</description>
                <environment></environment>
            <key id="16102">CLJ-1187</key>
            <summary>Clojure loses quoted metadata on empty literals</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="bronsa">Nicola Mometto</reporter>
                        <labels>
                    </labels>
                <created>Fri, 22 Mar 2013 13:47:34 -0500</created>
                <updated>Fri, 24 May 2013 09:14:44 -0500</updated>
                                    <version>Release 1.5</version>
                <version>Release 1.6</version>
                                <fixVersion>Release 1.6</fixVersion>
                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                        <comments>
                    <comment id="30804" author="bronsa" created="Fri, 22 Mar 2013 14:12:20 -0500"  >&lt;p&gt;After patch:&lt;/p&gt;

&lt;p&gt;user=&amp;gt; (meta &apos;^:foo [])&lt;br/&gt;
{:foo true}&lt;br/&gt;
user=&amp;gt; (meta &apos;^:foo &lt;span class=&quot;error&quot;&gt;&amp;#91;:a&amp;#93;&lt;/span&gt;)&lt;br/&gt;
{:foo true}&lt;br/&gt;
user=&amp;gt; (def ^:const foo ^:foo [])&lt;br/&gt;
#&apos;user/foo&lt;br/&gt;
user=&amp;gt; (meta foo)&lt;br/&gt;
{:foo true}&lt;/p&gt;
</comment>
                    <comment id="30838" author="stu" created="Fri, 29 Mar 2013 06:13:16 -0500"  >&lt;p&gt;I believe the title should read &quot;Clojure loses quoted metdata on empty literals&quot;.&lt;/p&gt;</comment>
                    <comment id="30839" author="stu" created="Fri, 29 Mar 2013 06:16:15 -0500"  >&lt;p&gt;At first glance, the implementation looks wrong in that it blocks non-IObjs ever getting to EmptyExpr. Probably all persistent collections are IObjs, but would not want to bake this in.&lt;/p&gt;</comment>
                    <comment id="30842" author="bronsa" created="Fri, 29 Mar 2013 07:00:19 -0500"  >&lt;p&gt;You&apos;re right, I&apos;ve updated my patch, it should work as expected now&lt;/p&gt;</comment>
                    <comment id="30877" author="jafingerhut" created="Thu, 4 Apr 2013 21:44:12 -0500"  >&lt;p&gt;Nicola: Your updated patch 001-&lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-1187&quot; title=&quot;Clojure loses quoted metadata on empty literals&quot;&gt;CLJ-1187&lt;/a&gt;.patch dated Mar 29, 2013 gives syntax errors when I try to compile it.&lt;/p&gt;</comment>
                    <comment id="30878" author="bronsa" created="Fri, 5 Apr 2013 09:06:59 -0500"  >&lt;p&gt;Oh, the irony, I messed up some parentheses writing java.&lt;/p&gt;

&lt;p&gt;Sorry for it, here&apos;s the correct patch, it applies on upstream/master.&lt;/p&gt;</comment>
                    <comment id="31139" author="cldwalker" created="Fri, 24 May 2013 09:14:44 -0500"  >&lt;p&gt;Looks good&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="11943" name="001-CLJ-1187.patch" size="2114" author="bronsa" created="Fri, 5 Apr 2013 09:06:59 -0500" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_10002" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Approval</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10004">Screened</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-944] compiler makes different concrete maps then the reader</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-944</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;I (Stu) agree with Nicola&apos;s assessment in the comments: the single real problem here is that the compiler&apos;s MapExpr parser emits maps differently from other map-makers, e.g. RT&apos;s factory functions. &lt;/p&gt;

&lt;p&gt;Patch clj944-plus-tests does three things:&lt;/p&gt;

&lt;ul&gt;
	&lt;li&gt;has the compiler emit map types consistent with the reader (like the previous &quot;0002&quot; patch)&lt;/li&gt;
	&lt;li&gt;adds tests&lt;/li&gt;
	&lt;li&gt;removes broken tests&lt;/li&gt;
&lt;/ul&gt;


&lt;p&gt;Original report follows:&lt;/p&gt;

&lt;p&gt;Hi guys, I am getting the following exception:&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;(.containsKey {:one 1} :one)
;=&amp;gt; ClassCastException clojure.lang.PersistentArrayMap cannot be &lt;span class=&quot;code-keyword&quot;&gt;cast&lt;/span&gt; to clojure.lang.PersistentHashMap&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt; 

&lt;p&gt;The map is a clojure.lang.PersistentArrayMap, which obviously has a containsKey method (&lt;a href=&quot;https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/PersistentArrayMap.java#L95&quot;&gt;https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/PersistentArrayMap.java#L95&lt;/a&gt;). &lt;/p&gt;

&lt;p&gt;Casting it works fine though:&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;(.containsKey ^clojure.lang.PersistentArrayMap {:one 1} :one)
;=&amp;gt; &lt;span class=&quot;code-keyword&quot;&gt;true&lt;/span&gt;&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt; 

&lt;p&gt;The mailing list suggest that the compiler injects an incorrect cast to clojure.lang.PersistentHashMap. In this case it should probably be cast to a clojure.lang.Associative, the highest common interface having the .containsKey method.&lt;/p&gt;

&lt;p&gt;The problem is not present in Clojure 1.2.1.&lt;/p&gt;</description>
                <environment>Clojure 1.3 om Mac OS 10.7, Clojure 1.5.0 alpha1 on Linux x86_64 (OpenJDK 1.7.0 b147)</environment>
            <key id="15259">CLJ-944</key>
            <summary>compiler makes different concrete maps then the reader</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="stoyle">Alf Kristian St&#248;yle</reporter>
                        <labels>
                    </labels>
                <created>Sun, 4 Mar 2012 02:45:09 -0600</created>
                <updated>Fri, 24 May 2013 09:03:46 -0500</updated>
                                    <version>Release 1.3</version>
                <version>Release 1.4</version>
                <version>Release 1.5</version>
                                <fixVersion>Release 1.5</fixVersion>
                <fixVersion>Release 1.6</fixVersion>
                                        <due></due>
                    <votes>2</votes>
                        <watches>3</watches>
                        <comments>
                    <comment id="29873" author="bronsa" created="Tue, 30 Oct 2012 17:02:10 -0500"  >&lt;p&gt;The attached patch fixes the issue, by emitting IPersistentMap instead of Persistent{Hash|Array}Map as class type for maps literals&lt;/p&gt;</comment>
                    <comment id="29885" author="bronsa" created="Thu, 1 Nov 2012 15:48:45 -0500"  >&lt;p&gt;I uploaded another patch fixing the same problem in a different way.&lt;br/&gt;
While 0001-Fix-for-&lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-944&quot; title=&quot;compiler makes different concrete maps then the reader&quot;&gt;CLJ-944&lt;/a&gt;.patch makes clojure.lang.Complier.ConstantExpr#getJavaClass return clojure.lang.IPersistentMap for both clojure.lang.PersistentHashMap and clojure.lang.PersistentArrayMap, 0002-Fix-for-&lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-944&quot; title=&quot;compiler makes different concrete maps then the reader&quot;&gt;CLJ-944&lt;/a&gt;.patch makes clojure.lang.Compiler.MapExpr#parse return a PersistentArrayMap if the length is &amp;lt;= HASHTABLE_THRESHOLD, instead of always returning a PersistentHashMap.&lt;/p&gt;

&lt;p&gt;This approach is more consistent, making the type of the compiler&apos;s internal representation of a map literal equal to the one of the reader.&lt;/p&gt;

&lt;p&gt;Note that this second approach while being more consistent, breaks some tests that assume some operations on maps (specifically `seq` and `print`) to be order dependent, and written with the hash-map return order implementation in mind.&lt;/p&gt;

&lt;p&gt;That should not be the case and if the second patch is preferred over the first one, I&apos;ll gladly fix those tests.&lt;/p&gt;</comment>
                    <comment id="30678" author="stu" created="Fri, 1 Mar 2013 12:09:44 -0600"  >&lt;p&gt;Approach #2, relying on consistent choice of concrete map class by size throughout, feels quite fragile.&lt;/p&gt;

&lt;p&gt;Approach #1 seems to abuse the method name getJavaClass(), now having it return &quot;get the base type I would need for cast&quot;.&lt;/p&gt;

&lt;p&gt;Maybe there needs to be a different thing entirely?&lt;/p&gt;</comment>
                    <comment id="30684" author="bronsa" created="Fri, 1 Mar 2013 14:17:09 -0600"  >&lt;p&gt;Patch #2 should get merged (IMHO) regardless of the fragility of its approach to fixing this ticket&apos;s bug, since it fixes another bug:&lt;/p&gt;

&lt;p&gt;prior to the patch:&lt;/p&gt;

&lt;p&gt;user=&amp;gt; (class {:a 1})&lt;br/&gt;
clojure.lang.PersistentArrayMap&lt;br/&gt;
user=&amp;gt; (def a {:a 1})&lt;br/&gt;
#&apos;user/a&lt;br/&gt;
user=&amp;gt; (class a)&lt;br/&gt;
clojure.lang.PersistentHashMap&lt;/p&gt;

&lt;p&gt;after the patch:&lt;/p&gt;

&lt;p&gt;user=&amp;gt; (class {:a 1})&lt;br/&gt;
clojure.lang.PersistentArrayMap&lt;br/&gt;
user=&amp;gt; (def a {:a 1})&lt;br/&gt;
#&apos;user/a&lt;br/&gt;
user=&amp;gt; (class a)&lt;br/&gt;
clojure.lang.PersistentArrayMap&lt;/p&gt;

&lt;p&gt;This should also lead to some &lt;b&gt;minor&lt;/b&gt; performance enhancement since prior to this moment, every map def&apos;ed would be a HashMap instead of an ArrayMap&lt;/p&gt;

&lt;p&gt;So, I think patch #2 should be applied if not for this ticket&apos;s bug, at least for the reason stated above.&lt;br/&gt;
If somebody has any proposal for making this patch more solid regarding this ticket&apos;s bug, any help is welcome&lt;/p&gt;</comment>
                    <comment id="30949" author="richhickey" created="Sat, 13 Apr 2013 09:41:58 -0500"  >&lt;p&gt;This should not have passed screening. There are two issues, should be separate. I have no idea what has been screened nor what will be applied should it be approved. There&apos;s contention in the discussion but no resolution.&lt;/p&gt;</comment>
                    <comment id="30950" author="bronsa" created="Sat, 13 Apr 2013 12:06:35 -0500"  >&lt;p&gt;I don&apos;t think that there are two issues here.&lt;br/&gt;
The issue is only one: the compiler doesn&apos;t emit maps in a way consistent with what the reader returns and with how the compiler itself uses maps.&lt;br/&gt;
The symptoms are two: some interop calls fail, and def&apos;ed vars with a literal map as value never use a PersistentArrayMap.&lt;/p&gt;

&lt;p&gt;The underlying cause of those two symtoms is fixed by the patch 002 that i submitted (incorporated in Stu&apos;s clj944-plus-tests patch.&lt;/p&gt;

&lt;p&gt;Stuart said that this approach feels fragile but the bug is caused by the fact that everywhere else clojure returns a PersistentArrayMap when the element count is &amp;lt;= than the PersistentHashMap threshold, and when emitting maps, it doesn&apos;t.&lt;/p&gt;

&lt;p&gt;Making clojure emit maps consistently with how clojure does internally everywhere else looks to me like the only solution, and I don&apos;t really see how making clojure consistent is a fragile approach.&lt;/p&gt;

&lt;p&gt;But again, if somebody can suggest a better solution to this problem, I&apos;ll gladly submit another patch.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="11644" name="0001-Fix-for-CLJ-944.patch" size="879" author="bronsa" created="Tue, 30 Oct 2012 17:02:10 -0500" />
                    <attachment id="11655" name="0002-Fix-for-CLJ-944.patch" size="1094" author="bronsa" created="Thu, 1 Nov 2012 15:48:45 -0500" />
                    <attachment id="11955" name="clj944-plus-tests.patch" size="4827" author="stu" created="Fri, 12 Apr 2013 15:57:36 -0500" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_10002" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Approval</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10004">Screened</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-1121] -&gt; and -&gt;&gt; have unexpected behavior when combined with unusual macros</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1121</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;My intuitive understanding of the classic threading macros is that the meaning of forms like &lt;tt&gt;(-&amp;gt; a b c)&lt;/tt&gt; can be understood syntactically independent of the meaning of the symbols involved or the fact that the two threading macros are defined recursively. However the recursive definition breaks that expectation. After&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;(macroexpand-1 (macroexpand-1 &apos;(-&amp;gt; a b c)))

=&amp;gt; (c (-&amp;gt; a b))
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;&lt;tt&gt;c&lt;/tt&gt; is now in control if it is a macro, and is now seeing the argument &lt;tt&gt;(-&amp;gt; a b)&lt;/tt&gt; rather than &lt;tt&gt;(b a)&lt;/tt&gt; as would be the case if we had written &lt;tt&gt;(c (b a))&lt;/tt&gt; originally.&lt;/p&gt;

&lt;p&gt;Admittedly I do not know of a realistic example where this is an important distinction (I noticed this when playing with a rather perverse use of &lt;tt&gt;-&amp;gt;&amp;gt;&lt;/tt&gt; with macros from korma), but at the very least it means that the behavior of the threading macros isn&apos;t quite as easy to accurately explain as I thought it was.&lt;/p&gt;</description>
                <environment></environment>
            <key id="15875">CLJ-1121</key>
            <summary>-&gt; and -&gt;&gt; have unexpected behavior when combined with unusual macros</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="stu">Stuart Halloway</assignee>
                                <reporter username="gfredericks">Gary Fredericks</reporter>
                        <labels>
                    </labels>
                <created>Thu, 6 Dec 2012 20:28:37 -0600</created>
                <updated>Fri, 24 May 2013 08:48:42 -0500</updated>
                                    <version>Release 1.5</version>
                                <fixVersion>Release 1.6</fixVersion>
                                        <due></due>
                    <votes>4</votes>
                        <watches>5</watches>
                        <comments>
                    <comment id="30183" author="gfredericks" created="Fri, 7 Dec 2012 09:19:46 -0600"  >&lt;p&gt;I just realized that my patch also implements &lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-1086&quot; title=&quot;Support arity-1 for -&amp;gt;&amp;gt;&quot;&gt;CLJ-1086&lt;/a&gt;.&lt;/p&gt;</comment>
                    <comment id="30290" author="stu" created="Sat, 22 Dec 2012 09:48:55 -0600"  >&lt;p&gt;Would be nice if tests also demonstrated that metadata is preserved correctly.&lt;/p&gt;</comment>
                    <comment id="30329" author="gfredericks" created="Wed, 26 Dec 2012 20:16:45 -0600"  >&lt;p&gt;New patch in response to stuarthalloway feedback.&lt;/p&gt;</comment>
                    <comment id="30414" author="timmc" created="Wed, 9 Jan 2013 18:47:26 -0600"  >&lt;p&gt;This patch also prevents an infinite loop in the macroexpander when fed the following expression:&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;(-&amp;gt;&amp;gt; a b (-&amp;gt;&amp;gt; c d))&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;Edit: Far simpler example.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="11751" name="0001-CLJ-1121-Reimplement-and-without-recursion.patch" size="2680" author="gfredericks" created="Thu, 6 Dec 2012 20:33:40 -0600" />
                    <attachment id="11780" name="CLJ-1121-v002.patch" size="4843" author="gfredericks" created="Wed, 26 Dec 2012 20:16:45 -0600" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_10002" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Approval</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10004">Screened</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-1122] Add contributing.md file to github repository (shows clear message on issues/pull request create form)</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1122</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;This adds a clear message when someone wants to create a pull request/issue and invites the user to read the contribution guidelines: see &lt;a href=&quot;https://github.com/blog/1184-contributing-guidelines&quot;&gt;https://github.com/blog/1184-contributing-guidelines&lt;/a&gt;. &lt;/p&gt;

&lt;p&gt;The same thing could be done for all the clojure/* repositories.&lt;/p&gt;

&lt;p&gt;The content of the file is just a markdown version of &lt;a href=&quot;http://clojure.org/contributing&quot;&gt;http://clojure.org/contributing&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;Preview here: &lt;a href=&quot;https://github.com/mpenet/clojure/blob/aef170ca5eca1b71a2eb1ef320223d1277df0e5e/CONTRIBUTING.md&quot;&gt;https://github.com/mpenet/clojure/blob/aef170ca5eca1b71a2eb1ef320223d1277df0e5e/CONTRIBUTING.md&lt;/a&gt;&lt;/p&gt;</description>
                <environment></environment>
            <key id="15877">CLJ-1122</key>
            <summary>Add contributing.md file to github repository (shows clear message on issues/pull request create form)</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="mpenet">Max Penet</reporter>
                        <labels>
                    </labels>
                <created>Sun, 9 Dec 2012 14:14:57 -0600</created>
                <updated>Fri, 24 May 2013 08:24:38 -0500</updated>
                                                    <fixVersion>Release 1.6</fixVersion>
                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                        <comments>
                    <comment id="30349" author="stu" created="Wed, 2 Jan 2013 06:31:18 -0600"  >&lt;p&gt;Please change this to link to the definitive prose, so we don&apos;t have to maintain that in two places.&lt;/p&gt;</comment>
                    <comment id="30350" author="mpenet" created="Wed, 2 Jan 2013 06:51:49 -0600"  >&lt;p&gt;Feel free to correct the wording, I used something simple.&lt;/p&gt;</comment>
                    <comment id="31098" author="cldwalker" created="Fri, 17 May 2013 09:04:03 -0500"  >&lt;p&gt;Stu, he linked to clojure.org as you requested so I&apos;m moving this along.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="11754" name="contributing.patch" size="3555" author="mpenet" created="Sun, 9 Dec 2012 14:14:57 -0600" />
                    <attachment id="11787" name="contributing-v2.patch" size="563" author="mpenet" created="Wed, 2 Jan 2013 06:52:38 -0600" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_10002" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Approval</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10004">Screened</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-783] clojure.inspector/inspect-tree doesn&apos;t work on sets --patch in the description by Jason Wolfe</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-783</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;As reported by Jason Wolfe on March 19, 2009 in the clojure group:&lt;/p&gt;

&lt;p&gt;clojure.inspector/inspect-tree doesn&apos;t work on sets; patch attached&lt;br/&gt;
&lt;a href=&quot;http://groups.google.com/group/clojure/browse_thread/thread/97bcad115fcfaf5a/95e61c423c61cfa8?lnk=gst&amp;amp;q=inspector+set#95e61c423c61cfa8&quot;&gt;http://groups.google.com/group/clojure/browse_thread/thread/97bcad115fcfaf5a/95e61c423c61cfa8?lnk=gst&amp;amp;q=inspector+set#95e61c423c61cfa8&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;I was debugging with inspect-tree and noticed that it errors when it &lt;br/&gt;
encounters a set (it thinks it&apos;s not atomic, but then nth produces an &lt;br/&gt;
UnsupportedOperationException). &lt;/p&gt;

&lt;p&gt;I made a small patch (below) that makes inspect-tree work on &lt;br/&gt;
java.util.Sets, and also anything else that implements &lt;br/&gt;
clojure.lang.Seqable.  If this is of interest, please let me know and &lt;br/&gt;
I can create an issue. &lt;/p&gt;


&lt;p&gt;Cheers, &lt;br/&gt;
Jason &lt;/p&gt;


&lt;p&gt;Index: src/clj/clojure/inspector.clj &lt;br/&gt;
=================================================================== &lt;br/&gt;
&amp;#8212; src/clj/clojure/inspector.clj       (revision 1335) &lt;br/&gt;
+++ src/clj/clojure/inspector.clj       (working copy) &lt;br/&gt;
@@ -20,8 +20,10 @@ &lt;br/&gt;
 (defn collection-tag &lt;span class=&quot;error&quot;&gt;&amp;#91;x&amp;#93;&lt;/span&gt; &lt;br/&gt;
   (cond &lt;br/&gt;
    (instance? java.util.Map$Entry x) :entry &lt;/p&gt;
&lt;ul class=&quot;alternate&quot; type=&quot;square&quot;&gt;
	&lt;li&gt;(instance? java.util.Map x) :map&lt;br/&gt;
+   (instance? java.util.Map x) :seqable &lt;br/&gt;
+   (instance? java.util.Set x) :seqable &lt;br/&gt;
    (sequential? x) :seq &lt;br/&gt;
+   (instance? clojure.lang.Seqable x) :seqable &lt;br/&gt;
    :else :atom)) &lt;/li&gt;
&lt;/ul&gt;



&lt;p&gt; (defmulti is-leaf collection-tag) &lt;br/&gt;
@@ -42,11 +44,15 @@ &lt;br/&gt;
 (defmethod get-child-count :entry &lt;span class=&quot;error&quot;&gt;&amp;#91;e&amp;#93;&lt;/span&gt; &lt;br/&gt;
   (count (val e))) &lt;/p&gt;


&lt;p&gt;-(defmethod is-leaf :map &lt;span class=&quot;error&quot;&gt;&amp;#91;m&amp;#93;&lt;/span&gt; &lt;br/&gt;
+(defmethod is-leaf :seqable &lt;span class=&quot;error&quot;&gt;&amp;#91;parent&amp;#93;&lt;/span&gt; &lt;br/&gt;
   false) &lt;br/&gt;
-(defmethod get-child :map &lt;span class=&quot;error&quot;&gt;&amp;#91;m index&amp;#93;&lt;/span&gt; &lt;/p&gt;
&lt;ul class=&quot;alternate&quot; type=&quot;square&quot;&gt;
	&lt;li&gt;(nth (seq m) index))&lt;br/&gt;
+(defmethod get-child :seqable &lt;span class=&quot;error&quot;&gt;&amp;#91;parent index&amp;#93;&lt;/span&gt; &lt;br/&gt;
+  (nth (seq parent) index)) &lt;br/&gt;
+(defmethod get-child-count :seqable &lt;span class=&quot;error&quot;&gt;&amp;#91;parent&amp;#93;&lt;/span&gt; &lt;br/&gt;
+  (count (seq parent))) &lt;/li&gt;
&lt;/ul&gt;



&lt;p&gt; (defn tree-model &lt;span class=&quot;error&quot;&gt;&amp;#91;data&amp;#93;&lt;/span&gt; &lt;br/&gt;
   (proxy &lt;span class=&quot;error&quot;&gt;&amp;#91;TreeModel&amp;#93;&lt;/span&gt; [] &lt;br/&gt;
     (getRoot [] data) &lt;/p&gt;</description>
                <environment>Any</environment>
            <key id="14409">CLJ-783</key>
            <summary>clojure.inspector/inspect-tree doesn&apos;t work on sets --patch in the description by Jason Wolfe</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="6" iconUrl="http://dev.clojure.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Completed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="ablancas">Armando Blancas</reporter>
                        <labels>
                    </labels>
                <created>Thu, 28 Apr 2011 11:29:27 -0500</created>
                <updated>Fri, 24 May 2013 07:55:10 -0500</updated>
                    <resolved>Fri, 24 May 2013 07:55:10 -0500</resolved>
                                            <fixVersion>Release 1.6</fixVersion>
                                        <due></due>
                    <votes>1</votes>
                        <watches>1</watches>
                        <comments>
                    <comment id="27718" author="jafingerhut" created="Tue, 14 Feb 2012 12:54:05 -0600"  >&lt;p&gt;Created a properly formatted patch, attached, for Jason&apos;s enhancement.  I tested it with&lt;/p&gt;

&lt;p&gt;(inspect-tree (:members (clojure.reflect/reflect java.lang.Math)))&lt;/p&gt;

&lt;p&gt;and it worked, whereas it had many errors without Jason&apos;s changes.&lt;/p&gt;</comment>
                    <comment id="27831" author="jafingerhut" created="Thu, 23 Feb 2012 23:58:31 -0600"  >&lt;p&gt;Jason Wolfe has signed a CA.  Patch applies cleanly with latest master as of Feb 14, 2012.  No errors, warnings, or test failures with the patch applied.  No doc strings need updating.&lt;/p&gt;</comment>
                    <comment id="29929" author="stuart.sierra" created="Fri, 9 Nov 2012 16:12:45 -0600"  >&lt;p&gt;Screened.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="10909" name="clj-783-patch.txt" size="1294" author="jafingerhut" created="Tue, 14 Feb 2012 12:54:05 -0600" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_10002" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Approval</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10007">Ok</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-896] Make browse-url aware of xdg-open</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-896</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;clojure.java.browse/browse-url tests to see if it&apos;s running on Mac OS to fall back to &quot;/usr/bin/open&quot; in order&lt;br/&gt;
to open a URI. On most other systems it&apos;ll just falls through to open-url-in-swing instead. The attached patch&lt;br/&gt;
tests to see if freedesktop.org&apos;s &quot;xdg-open&quot; is present in the users path. This way browse-url will launch the&lt;br/&gt;
program associated with the URI, in my case chromium.&lt;/p&gt;</description>
                <environment>All platforms that provide xdg-open (as part of freedesktop.org) benefit from this. Fix was tested on OpenBSD.</environment>
            <key id="15069">CLJ-896</key>
            <summary>Make browse-url aware of xdg-open</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="6" iconUrl="http://dev.clojure.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Completed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="jasperla">Jasper Lievisse Adriaanse</reporter>
                        <labels>
                    </labels>
                <created>Tue, 13 Dec 2011 17:29:14 -0600</created>
                <updated>Fri, 24 May 2013 07:55:10 -0500</updated>
                    <resolved>Fri, 24 May 2013 07:55:10 -0500</resolved>
                                            <fixVersion>Release 1.6</fixVersion>
                                        <due></due>
                    <votes>3</votes>
                        <watches>1</watches>
                        <comments>
                    <comment id="27885" author="jafingerhut" created="Tue, 28 Feb 2012 18:19:08 -0600"  >&lt;p&gt;&lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-920&quot; title=&quot;Adds support for FreeDesktop&amp;#39;s xdg-open in clojure.java.browse/browse-url.&quot;&gt;&lt;del&gt;CLJ-920&lt;/del&gt;&lt;/a&gt;, if not identical, at least bears a significant resemblance to this ticket.  It would be good to see if the patch for one of them fixes both issues.&lt;/p&gt;</comment>
                    <comment id="27889" author="jafingerhut" created="Wed, 29 Feb 2012 13:18:04 -0600"  >&lt;p&gt;clj-896-browse-url-uses-xdg-open-patch2.txt is based more on the patch attached to &lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-920&quot; title=&quot;Adds support for FreeDesktop&amp;#39;s xdg-open in clojure.java.browse/browse-url.&quot;&gt;&lt;del&gt;CLJ-920&lt;/del&gt;&lt;/a&gt; by Jeremy Heiler than on the earlier patch attached to this ticket.  He and I have signed CAs.&lt;/p&gt;

&lt;p&gt;I think this patch improves on both of the previous patches for &lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-896&quot; title=&quot;Make browse-url aware of xdg-open&quot;&gt;&lt;del&gt;CLJ-896&lt;/del&gt;&lt;/a&gt; and &lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-920&quot; title=&quot;Adds support for FreeDesktop&amp;#39;s xdg-open in clojure.java.browse/browse-url.&quot;&gt;&lt;del&gt;CLJ-920&lt;/del&gt;&lt;/a&gt;.  In particular, Jeremy&apos;s worked fine, but it caused a long slowdown in the running of tests when building Clojure.  This one does not.&lt;/p&gt;

&lt;p&gt;Tested on:&lt;/p&gt;

&lt;p&gt;Mac OS X 10.6.8&lt;br/&gt;
Windows XP SP3, both in cmd.exe and a Cygwin bash shell&lt;br/&gt;
Ubuntu 10.04 LTS&lt;/p&gt;

&lt;p&gt;It would be great if someone could test it on a BSD system.  The only possible issue I can think of is whether the output of the &quot;which&quot; command is different there than on the Linux system I tested.&lt;/p&gt;

&lt;p&gt;If someone wants to make a patch that doesn&apos;t use &quot;which&quot;, but instead checks the PATH, I&apos;d recommend they also test on Windows in cmd.exe to make sure it works correctly there.&lt;/p&gt;</comment>
                    <comment id="29922" author="stuart.sierra" created="Fri, 9 Nov 2012 09:04:35 -0600"  >&lt;p&gt;Screened. Verified on Mac OS X.&lt;/p&gt;</comment>
                    <comment id="29925" author="jasperla" created="Fri, 9 Nov 2012 09:41:07 -0600"  >&lt;p&gt;And I&apos;ve tested it on OpenBSD.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="10745" name="0001-teach-browse-url-about-xdg-open.patch" size="1948" author="jasperla" created="Tue, 13 Dec 2011 17:29:14 -0600" />
                    <attachment id="10974" name="clj-896-browse-url-uses-xdg-open-patch2.txt" size="3184" author="jafingerhut" created="Wed, 29 Feb 2012 13:18:04 -0600" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_10002" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Approval</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10007">Ok</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-863] interleave should accept 1 or 0 arguments</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-863</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;interleave should handle 0 and 1 arguments in the same way that concat does (i.e., 0 args --&amp;gt; empty seq, 1 args --&amp;gt; identity).&lt;/p&gt;</description>
                <environment></environment>
            <key id="14807">CLJ-863</key>
            <summary>interleave should accept 1 or 0 arguments</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="6" iconUrl="http://dev.clojure.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Completed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="joegallo">Joe Gallo</reporter>
                        <labels>
                    </labels>
                <created>Mon, 24 Oct 2011 14:50:34 -0500</created>
                <updated>Fri, 24 May 2013 07:55:10 -0500</updated>
                    <resolved>Fri, 24 May 2013 07:55:10 -0500</resolved>
                            <version>Release 1.3</version>
                                <fixVersion>Release 1.6</fixVersion>
                                        <due></due>
                    <votes>5</votes>
                        <watches>1</watches>
                        <comments>
                    <comment id="28814" author="richhickey" created="Fri, 15 Jun 2012 09:31:29 -0500"  >&lt;p&gt;(lazy-seq nil) should be ()&lt;/p&gt;</comment>
                    <comment id="28817" author="joegallo" created="Fri, 15 Jun 2012 10:13:06 -0500"  >&lt;p&gt;Hey Rich, if you&apos;re talking about the first line of the diff:&lt;/p&gt;

&lt;p&gt;+  ([] (lazy-seq nil))&lt;/p&gt;

&lt;p&gt;Then that&apos;s the implementation, not the tests &amp;#8211; given an empty vector of arguments, return (lazy-seq nil), which I just copied from the existing definition of concat.&lt;/p&gt;

&lt;p&gt;Cheers,&lt;br/&gt;
Joe&lt;/p&gt;</comment>
                    <comment id="29591" author="mdzaebel" created="Wed, 3 Oct 2012 13:19:59 -0500"  >&lt;p&gt;(defn interleave &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;amp; s&amp;#93;&lt;/span&gt; (apply mapcat list s))&lt;/p&gt;</comment>
                    <comment id="29592" author="m0smith" created="Wed, 3 Oct 2012 20:47:53 -0500"  >&lt;p&gt;Marc&apos;s definition doesn&apos;t work for no arguments.  Maybe:&lt;/p&gt;

&lt;p&gt;(defn interleave &lt;br/&gt;
    ([] ()) &lt;br/&gt;
    (&lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;amp; s&amp;#93;&lt;/span&gt; (apply mapcat list s)))&lt;/p&gt;</comment>
                    <comment id="29608" author="mdzaebel" created="Fri, 5 Oct 2012 13:07:13 -0500"  >&lt;p&gt;Yes, but my solution is too slow, as it uses &quot;apply&quot;.&lt;/p&gt;</comment>
                    <comment id="30343" author="jafingerhut" created="Tue, 1 Jan 2013 11:54:06 -0600"  >&lt;p&gt;Patch clj-863-make-interleave-handle-odd-args-like-concat-patch-v1.txt dated Jan 1 2013 is identical to Joe Gallo&apos;s 0001-make-interleave-handle-odd-arugments-in-the-same-man.patch patch dated Oct 24 2011, except it returns () instead of (lazy-seq nil) as per Rich&apos;s comment.  If concat should also return () instead of (lazy-seq nil), perhaps another ticket should be created to fix that.  Also presumptuously changing ticket state from Incomplete back to Vetted, since the reason it was marked Incomplete should now be addressed, and it was Screened before.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="10496" name="0001-make-interleave-handle-odd-arugments-in-the-same-man.patch" size="1247" author="joegallo" created="Mon, 24 Oct 2011 14:50:36 -0500" />
                    <attachment id="11785" name="clj-863-make-interleave-handle-odd-args-like-concat-patch-v1.txt" size="1235" author="jafingerhut" created="Tue, 1 Jan 2013 11:54:06 -0600" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_10002" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Approval</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10007">Ok</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-1072] Replace old metadata reader macro syntax</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1072</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;5 files still have old metadata reader syntax hash-caret instead of just caret:&lt;/p&gt;

&lt;p&gt;src/clj/clojure/core.clj&lt;br/&gt;
src/clj/clojure/gvec.clj&lt;br/&gt;
src/clj/clojure/java/browse_ui.clj&lt;br/&gt;
src/clj/clojure/java/io.clj&lt;br/&gt;
src/clj/clojure/repl.clj&lt;/p&gt;</description>
                <environment></environment>
            <key id="15709">CLJ-1072</key>
            <summary>Replace old metadata reader macro syntax</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="6" iconUrl="http://dev.clojure.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Completed</resolution>
                                <assignee username="stuart.sierra">Stuart Sierra</assignee>
                                <reporter username="samaaron">Sam Aaron</reporter>
                        <labels>
                    </labels>
                <created>Fri, 21 Sep 2012 05:30:17 -0500</created>
                <updated>Fri, 24 May 2013 07:55:10 -0500</updated>
                    <resolved>Fri, 24 May 2013 07:55:10 -0500</resolved>
                            <version>Release 1.4</version>
                                <fixVersion>Release 1.6</fixVersion>
                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                        <comments>
                    <comment id="29511" author="stuart.sierra" created="Fri, 21 Sep 2012 07:56:24 -0500"  >&lt;p&gt;Modified this ticket to cover all remaining cases of old metadata syntax. Added patch.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="11515" name="0001-CLJ-1072-Replace-old-metadata-reader-macro-syntax.patch" size="8627" author="stuart.sierra" created="Fri, 21 Sep 2012 07:56:24 -0500" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_10002" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Approval</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10007">Ok</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-908] Functions with metadata print poorly</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-908</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;1.3 removed the metadata slot on most functions, and made &lt;tt&gt;.withMeta&lt;/tt&gt; return a new wrapping function that provides metadata. This changes the way functions with metadata print: instead of &lt;tt&gt;#&amp;lt;user$eval595$fn_&lt;em&gt;596 user$eval595$fn&lt;/em&gt;_596@3d48ff04&amp;gt;&lt;/tt&gt; we now see &lt;tt&gt;#&amp;lt; clojure.lang.AFunction$1@581de498&amp;gt;&lt;/tt&gt;. I might argue that we should &quot;lie&quot; and print the class of the original wrapped function since it&apos;s more useful than AFunction$1, but that&apos;s debatable. The two things I propose changing are: &lt;/p&gt;

&lt;ol&gt;
	&lt;li&gt;When &lt;tt&gt;&amp;#42;print-meta&amp;#42;&lt;/tt&gt; is true, we should print the metadata map for functions. That nothing prints implies there is no metadata, which can make it difficult to track down bugs related to metadata on functions.&lt;/li&gt;
	&lt;li&gt;Remove the errant space at the front of the printed representation of functions with meta, changing &lt;tt&gt;#&amp;lt; clojure.lang.AFunction$1@581de498&amp;gt;&lt;/tt&gt; to &lt;tt&gt;#&amp;lt;clojure.lang.AFunction$1@581de498&amp;gt;&lt;/tt&gt;. The cause of this issue is that &lt;tt&gt;.getSimpleName&lt;/tt&gt; on an object with an anonymous class returns &lt;tt&gt;&quot;&quot;&lt;/tt&gt;, and we print that followed by a space and its &lt;tt&gt;.toString&lt;/tt&gt;. My fix is to omit the extra space if the class has no simple name; this would cause instances of other anonymous (non-function) classes to print more nicely as well.&lt;/li&gt;
&lt;/ol&gt;


&lt;p&gt;If it would be desirable to print the class of the original &quot;wrapped&quot; function, then I can easily add another patch for that.&lt;/p&gt;</description>
                <environment></environment>
            <key id="15108">CLJ-908</key>
            <summary>Functions with metadata print poorly</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="6" iconUrl="http://dev.clojure.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Completed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="amalloy">Alan Malloy</reporter>
                        <labels>
                    </labels>
                <created>Tue, 10 Jan 2012 17:15:47 -0600</created>
                <updated>Fri, 24 May 2013 07:55:08 -0500</updated>
                    <resolved>Fri, 24 May 2013 07:55:08 -0500</resolved>
                            <version>Release 1.3</version>
                <version>Release 1.4</version>
                                <fixVersion>Release 1.6</fixVersion>
                                        <due></due>
                    <votes>0</votes>
                        <watches>3</watches>
                        <comments>
                    <comment id="28538" author="jafingerhut" created="Sat, 19 May 2012 03:30:55 -0500"  >&lt;p&gt;clj-908-Print-metadata-and-anonymous-classes-better-patch2.txt dated May 19, 2012 only has context line changes from the previous one, 0001-Print-metadata-and-anonymous-classes-better.patch dated Jan 10, 2012.  The previous one no longer applies cleanly to the latest master, while the new one does.&lt;/p&gt;</comment>
                    <comment id="29923" author="stuart.sierra" created="Fri, 9 Nov 2012 09:21:52 -0600"  >&lt;p&gt;Screened.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="10765" name="0001-Print-metadata-and-anonymous-classes-better.patch" size="935" author="amalloy" created="Tue, 10 Jan 2012 17:15:47 -0600" />
                    <attachment id="11234" name="clj-908-Print-metadata-and-anonymous-classes-better-patch2.txt" size="922" author="jafingerhut" created="Sat, 19 May 2012 03:30:55 -0500" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_10002" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Approval</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10007">Ok</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-1099] better error message when passing non-seq to seq</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1099</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;Design discussion &lt;a href=&quot;http://dev.clojure.org/display/design/Better+Error+Messages&quot;&gt;here&lt;/a&gt;.&lt;/p&gt;

&lt;p&gt;This patch improves Clojure&apos;s error message for a single common error: passing a non-seq where a seq is neede. More importantly, it is intended as a prototype for other similar improvements in the future.&lt;/p&gt;

&lt;p&gt;Error message 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;(cons 1 2)
=&amp;gt; IllegalArgumentException Don&apos;t know how to create ISeq from: java.lang.Long
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;Error message after:&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; (cons 1 2)
ExceptionInfo Don&apos;t know how to create ISeq from: java.lang.Long
user=&amp;gt; (ex-data *e)
{:instance 2}
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;</description>
                <environment></environment>
            <key id="15809">CLJ-1099</key>
            <summary>better error message when passing non-seq to seq</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="6" iconUrl="http://dev.clojure.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Completed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="stu">Stuart Halloway</reporter>
                        <labels>
                    </labels>
                <created>Thu, 1 Nov 2012 10:03:14 -0500</created>
                <updated>Fri, 24 May 2013 07:55:08 -0500</updated>
                    <resolved>Fri, 24 May 2013 07:55:08 -0500</resolved>
                                            <fixVersion>Release 1.6</fixVersion>
                                        <due></due>
                    <votes>0</votes>
                        <watches>1</watches>
                        <comments>
                    <comment id="29932" author="michaelklishin" created="Mon, 12 Nov 2012 10:34:49 -0600"  >&lt;p&gt;Wouldn&apos;t it be better to make it read &quot;Don&apos;t know how to create ISeq from: 2 (java.lang.Long)&quot;? How many beginners will figure&lt;br/&gt;
out ex-data exists and how to use it?&lt;/p&gt;</comment>
                    <comment id="30946" author="stu" created="Fri, 12 Apr 2013 11:36:35 -0500"  >&lt;p&gt;Hi Michael,&lt;/p&gt;

&lt;p&gt;ex-info messages should not, in general, pr-str things into their bodies.  This raises the question of print-length and print-level in a place where the user doesn&apos;t have good control, while the whole point of ex-info is to be in the data business, not the string business. Users can control printing from ex-data any way they like.&lt;/p&gt;

&lt;p&gt;There are two possible ways to make beginners aware of ex-data: Tell them about it in one (or a few places) in docs, or in an infinite number of places saying &quot;This would have been useful here, but we didn&apos;t use it because you might not know about it.&quot;  I prefer the former.&lt;/p&gt;

&lt;p&gt;That said, I think it would be great to increase the visibility of ex-info and ex-data early on in documentation for beginners, and to make sure that things like exception printing in logs are flexible enough not to lose the benefits of ex-info.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="11653" name="better-error-message-for-seq.patch" size="4724" author="stu" created="Thu, 1 Nov 2012 10:03:14 -0500" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_10002" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Approval</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10007">Ok</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-1101] *default-data-reader-fn* should be set!-able in REPL</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1101</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;In &lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-927&quot; title=&quot;default tagged literal reader&quot;&gt;&lt;del&gt;CLJ-927&lt;/del&gt;&lt;/a&gt;, Nicola Mometto pointed out that &amp;#42;default-data-reader-fn* should be set!-able.  The fix needs to be added to clojure.main/with-bindings.&lt;/p&gt;</description>
                <environment></environment>
            <key id="15813">CLJ-1101</key>
            <summary>*default-data-reader-fn* should be set!-able in REPL</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="6" iconUrl="http://dev.clojure.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Completed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="steveminer@gmail.com">Steve Miner</reporter>
                        <labels>
                    </labels>
                <created>Sat, 3 Nov 2012 09:28:36 -0500</created>
                <updated>Fri, 24 May 2013 07:55:08 -0500</updated>
                    <resolved>Fri, 24 May 2013 07:55:08 -0500</resolved>
                            <version>Release 1.5</version>
                                <fixVersion>Release 1.6</fixVersion>
                                        <due></due>
                    <votes>0</votes>
                        <watches>1</watches>
                        <comments>
                    <comment id="29898" author="steveminer@gmail.com" created="Sat, 3 Nov 2012 09:32:36 -0500"  >&lt;p&gt;Add &amp;#42;default-data-reader-fn* to the special bindings in main.clj so that it is set!-able in the REPL&lt;/p&gt;</comment>
                    <comment id="30155" author="steveminer@gmail.com" created="Mon, 3 Dec 2012 10:07:37 -0600"  >&lt;p&gt;This is a one-liner that makes &amp;#42;default-data-reader-fn* convenient to use in the REPL, similar to how &amp;#42;data-readers* works.  I&apos;d like to have this fix in Clojure 1.5.&lt;/p&gt;</comment>
                    <comment id="30750" author="steveminer@gmail.com" created="Tue, 12 Mar 2013 20:10:02 -0500"  >&lt;p&gt;work-around for 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;(alter-&lt;span class=&quot;code-keyword&quot;&gt;var&lt;/span&gt;-root #&apos;clojure.core/*&lt;span class=&quot;code-keyword&quot;&gt;default&lt;/span&gt;-data-reader-fn* (constantly my-&lt;span class=&quot;code-keyword&quot;&gt;default&lt;/span&gt;-reader))&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="11659" name="CLJ-1101-make-default-data-reader-fn-set-able-in-REPL.patch" size="850" author="steveminer@gmail.com" created="Sat, 3 Nov 2012 09:32:36 -0500" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_10002" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Approval</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10007">Ok</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-1143] Minor correction to doc string of ns macro</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1143</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;The doc string of ns says &quot;If :refer-clojure is not used, a default (refer &apos;clojure) is used.&quot;  &apos;clojure should be replaced with &apos;clojure.core&lt;/p&gt;

&lt;p&gt;Clojure group thread: &lt;a href=&quot;https://groups.google.com/forum/?fromgroups=#!topic/clojure/rDjZodxOMh8&quot;&gt;https://groups.google.com/forum/?fromgroups=#!topic/clojure/rDjZodxOMh8&lt;/a&gt;&lt;/p&gt;</description>
                <environment></environment>
            <key id="15954">CLJ-1143</key>
            <summary>Minor correction to doc string of ns macro</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="6" iconUrl="http://dev.clojure.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Completed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="jafingerhut">Andy Fingerhut</reporter>
                        <labels>
                    </labels>
                <created>Thu, 10 Jan 2013 13:32:17 -0600</created>
                <updated>Fri, 24 May 2013 07:55:08 -0500</updated>
                    <resolved>Fri, 24 May 2013 07:55:08 -0500</resolved>
                            <version>Release 1.6</version>
                                <fixVersion>Release 1.6</fixVersion>
                                        <due></due>
                    <votes>0</votes>
                        <watches>1</watches>
                        <comments>
                    <comment id="30416" author="jafingerhut" created="Thu, 10 Jan 2013 13:34:23 -0600"  >&lt;p&gt;clj-1143-ns-doc-string-correction-v1.txt dated Jan 10 2013 replaces (refer &apos;clojure) with (refer &apos;clojure.core) in the doc string of the ns macro.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="11800" name="clj-1143-ns-doc-string-correction-v1.txt" size="918" author="jafingerhut" created="Thu, 10 Jan 2013 13:34:23 -0600" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_10002" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Approval</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10007">Ok</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-1164] typos in instant.clj</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1164</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;There are a few typographical mistakes in instant.clj.&lt;/p&gt;</description>
                <environment></environment>
            <key id="16010">CLJ-1164</key>
            <summary>typos in instant.clj</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="6" iconUrl="http://dev.clojure.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Completed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="steveminer@gmail.com">Steve Miner</reporter>
                        <labels>
                    </labels>
                <created>Thu, 14 Feb 2013 11:59:36 -0600</created>
                <updated>Fri, 24 May 2013 07:55:08 -0500</updated>
                    <resolved>Fri, 24 May 2013 07:55:08 -0500</resolved>
                            <version>Release 1.4</version>
                <version>Release 1.5</version>
                                <fixVersion>Release 1.6</fixVersion>
                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                        <comments>
                    <comment id="30598" author="steveminer@gmail.com" created="Thu, 14 Feb 2013 12:01:17 -0600"  >&lt;p&gt;Fixes a couple of typos.  No code changes.&lt;/p&gt;</comment>
                    <comment id="31078" author="cldwalker" created="Fri, 10 May 2013 11:25:20 -0500"  >&lt;p&gt;For anyone wondering about the UTC change see &lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-928&quot; title=&quot;instant literal for Date and Timestamp should print in UTC&quot;&gt;&lt;del&gt;CLJ-928&lt;/del&gt;&lt;/a&gt;&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="11858" name="CLJ-1164-typos-instant.patch" size="1618" author="steveminer@gmail.com" created="Thu, 14 Feb 2013 12:01:17 -0600" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_10002" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Approval</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10007">Ok</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-1018] range&apos;s behavior is inconsistent</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1018</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;Problem statement: The current behavior of range is inconsistent. (range 0 9 0) has always produced (). (range 0 9 -1) has always produced (). (range 9 0 1) has always produced (). However, (range 9 0 0) produces (9 9 9 9 ...), and (range 0 0 0) produces &apos;(0 0 0 0 ...)&lt;/p&gt;

&lt;p&gt;Proposal: Make the behavior of range consistent when using a step of 0 to make it produce an empty list.&lt;/p&gt;

&lt;p&gt;Please see attached code and patch.&lt;/p&gt;</description>
                <environment></environment>
            <key id="15557">CLJ-1018</key>
            <summary>range&apos;s behavior is inconsistent</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="6" iconUrl="http://dev.clojure.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Completed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="devn">Devin Walters</reporter>
                        <labels>
                        <label>patch</label>
                        <label>range</label>
                    </labels>
                <created>Fri, 29 Jun 2012 16:25:03 -0500</created>
                <updated>Fri, 24 May 2013 07:34:58 -0500</updated>
                    <resolved>Fri, 24 May 2013 07:34:58 -0500</resolved>
                            <version>Release 1.1</version>
                <version>Release 1.2</version>
                <version>Release 1.3</version>
                <version>Release 1.4</version>
                <version>Release 1.5</version>
                                <fixVersion>Release 1.5</fixVersion>
                <fixVersion>Release 1.6</fixVersion>
                                        <due></due>
                    <votes>0</votes>
                        <watches>2</watches>
                        <comments>
                    <comment id="28925" author="mikera" created="Sun, 1 Jul 2012 04:08:00 -0500"  >&lt;p&gt;Agree it is good to fix the inconsistency, but I think an infinite sequence of zeros is the correct result, as implied by the current docstring definition.&lt;/p&gt;

&lt;p&gt;It&apos;s also mathematically cleanest: range should produce an arithmetic progression until the end value is equalled or exceeded.&lt;/p&gt;

&lt;p&gt;Empty lists only seem to make sense as a return value when start &amp;gt;= end.&lt;/p&gt;</comment>
                    <comment id="28928" author="devn" created="Sun, 1 Jul 2012 12:36:08 -0500"  >&lt;p&gt;Hi Mike,&lt;/p&gt;

&lt;p&gt;Could you explain how you think the docstring definition implies this behavior? Maybe I&apos;m missing something, but I was surprised. For instance, in the case of (range 3 9 0), if start were truly inclusive as the docstring says, the result would be (3), not ().&lt;/p&gt;

&lt;p&gt;You mentioned that you think the infinite sequence of 0&apos;s is consistent and in keeping with the definition of range. I&apos;m not sure I agree. (0,0] is an empty set of length zero, and [0,0) is an empty set of length zero.&lt;/p&gt;

&lt;p&gt;You state that empty list only makes sense for start &amp;gt;= end, except this is not the current behavior. Could you help me understand what you believe the appropriate behavior would be in each of the following three cases? (range 0 10 0), (range 10 0 0), and (range 0 0 0)?&lt;/p&gt;

&lt;p&gt;A few options to consider:&lt;br/&gt;
1) Fix the docstring to reflect the actual behavior of range.&lt;br/&gt;
2) Handle the case of (range 9 3 0) =&amp;gt; (9 9 9 ...) to make it consistent with the behavior of (range 3 9 0) =&amp;gt; ()&lt;br/&gt;
3) Stop allowing a step of zero altogether.&lt;/p&gt;

&lt;p&gt;Editing to Add (Note: I don&apos;t think the way someone else did something is always the right way, just wanted to do some digging on how other people have handled this in the past):&lt;br/&gt;
&lt;a href=&quot;http://docs.python.org/library/functions.html#range&quot;&gt;http://docs.python.org/library/functions.html#range&lt;/a&gt; (0 step returns ValueError)&lt;br/&gt;
&lt;a href=&quot;http://www2.tcl.tk/10797&quot;&gt;http://www2.tcl.tk/10797&lt;/a&gt; (range returns empty list for a zero step)&lt;br/&gt;
&lt;a href=&quot;http://www.scala-lang.org/api/2.7.7/scala/Range.html&quot;&gt;http://www.scala-lang.org/api/2.7.7/scala/Range.html&lt;/a&gt; (zero step is not allowed)&lt;/p&gt;</comment>
                    <comment id="28956" author="jimpil" created="Thu, 5 Jul 2012 16:13:22 -0500"  >&lt;p&gt;It does make sense NOT to allow a step of zero (at least to me)... I wasn&apos;t going to say anything about this but if other popular languages do not allow 0, then I guess it makes more sense than I originally gave myself credit for... However, if we want to be mathematically correct then the answer would be to return an infinte seq with the start value like below. After all, what  is a step of 0? does it  make any difference how many steps you take if with every step you cover 0 distance? obviously not...you start from x and you stay at x forever...we do have repeat for this sort of thing though... &lt;/p&gt;

&lt;p&gt;(take 5 (range 3 9 0)) =&amp;gt; (3 3 3 3 3)&lt;/p&gt;

&lt;p&gt;+1 for not allowing 0 step&lt;/p&gt;</comment>
                    <comment id="28958" author="mikera" created="Sun, 8 Jul 2012 08:49:11 -0500"  >&lt;p&gt;@Devin quite simple: a lazy sequence of nums starting from x with step 0.0 until it reaches an end value of y (where y &amp;gt; x) is an infinite sequence of x.&lt;/p&gt;

&lt;p&gt;Consider the case where start is 0 and end is infinity (the default), you would expect sequences to go as follows:&lt;/p&gt;

&lt;p&gt;step +2 : 0  2  4  6  8....&lt;br/&gt;
step +1 : 0  1  2  3  4....&lt;br/&gt;
step +0 : 0  0  0  0  0....&lt;/p&gt;

&lt;p&gt;It would be inconsistent to make 0 a special case, all of these are valid arithmetic progressions. And all of these are consistent with the current docstring.&lt;/p&gt;

&lt;p&gt;If you make 0 a special case, then people will need to write special case code to handle it. Consider the code to create a multiplication table for example:&lt;/p&gt;

&lt;p&gt;(for &lt;span class=&quot;error&quot;&gt;&amp;#91;x (range 10)&amp;#93;&lt;/span&gt;&lt;br/&gt;
     (take 10 (range 0 Long/MAX_VALUE x)))&lt;/p&gt;

&lt;p&gt;This works fine if you produce an infinite sequence of zeros for step 0, but fails if you create an empty list as a special case for step 0.&lt;/p&gt;

&lt;p&gt;As a related issue, I&apos;d personally also favour negative step sizes also producing an infinite sequence. If we don&apos;t want to allow this though, then at least the docstring should be changed to say &quot;a lazy seq of non-decreasing nums&quot; and a negative step should throw an error.&lt;/p&gt;</comment>
                    <comment id="28959" author="devn" created="Mon, 9 Jul 2012 19:09:16 -0500"  >&lt;p&gt;Carrying over a message from the clojure-dev list by Stuart Sierra:&lt;/p&gt;

&lt;ul class=&quot;alternate&quot; type=&quot;square&quot;&gt;
	&lt;li&gt;I called the ticket a defect. Does that seem reasonable?&lt;/li&gt;
&lt;/ul&gt;


&lt;p&gt;yes&lt;/p&gt;

&lt;ul class=&quot;alternate&quot; type=&quot;square&quot;&gt;
	&lt;li&gt;Does anyone actually use the 0 step behavior in their programs?&lt;/li&gt;
&lt;/ul&gt;


&lt;p&gt;not if they have any sense&lt;/p&gt;

&lt;ul class=&quot;alternate&quot; type=&quot;square&quot;&gt;
	&lt;li&gt;Has anyone been bitten by this in the past?&lt;/li&gt;
&lt;/ul&gt;


&lt;p&gt;not me&lt;/p&gt;

&lt;ul class=&quot;alternate&quot; type=&quot;square&quot;&gt;
	&lt;li&gt;Is this behavior intentional for some historical reason I don&apos;t know about or understand?&lt;/li&gt;
&lt;/ul&gt;


&lt;p&gt;I doubt it.&lt;/p&gt;

&lt;ul class=&quot;alternate&quot; type=&quot;square&quot;&gt;
	&lt;li&gt;Has this been brought up before? I couldn&apos;t find any reference to it via Google.&lt;/li&gt;
&lt;/ul&gt;


&lt;p&gt;Not that I know of.&lt;/p&gt;

&lt;ul class=&quot;alternate&quot; type=&quot;square&quot;&gt;
	&lt;li&gt;Are there performance implications to my patch?&lt;/li&gt;
&lt;/ul&gt;


&lt;p&gt;I doubt it. Lazy seqs are not ideal for high-performance code anyway.&lt;/p&gt;

&lt;ul class=&quot;alternate&quot; type=&quot;square&quot;&gt;
	&lt;li&gt;Am I addressing a symptom rather than the problem?&lt;/li&gt;
&lt;/ul&gt;


&lt;p&gt;I think the &lt;b&gt;problem&lt;/b&gt; is that the result of `range` with a step of 0 was never specified. Don&apos;t assume that the tests are specifications. Many of the tests in Clojure were written by over-eager volunteers who defined the tests based on whatever the behavior happened to be. The only specification from the language designer is the docstring. By my reading, that means that `range` with a step of 0 should return an infinite seq of the start value, unless the start and end values are equal.&lt;/p&gt;

&lt;p&gt;-S&lt;/p&gt;</comment>
                    <comment id="28960" author="devn" created="Mon, 9 Jul 2012 19:10:24 -0500"  >&lt;p&gt;Carrying over a message by Michal Marczyk:&lt;/p&gt;

&lt;p&gt;With a negative step, the comparison is reversed, so that e.g.&lt;/p&gt;

&lt;p&gt;(range 3 0 -1)&lt;/p&gt;

&lt;p&gt;evaluates to&lt;/p&gt;

&lt;p&gt;(3 2 1)&lt;/p&gt;

&lt;p&gt;I think this is the useful behaviour; the docstring should perhaps be&lt;br/&gt;
adjusted to match it.&lt;/p&gt;

&lt;p&gt;Agreed on zero step.&lt;/p&gt;

&lt;p&gt;Cheers,&lt;br/&gt;
Micha&#322;&lt;/p&gt;</comment>
                    <comment id="29014" author="devn" created="Fri, 20 Jul 2012 17:10:19 -0500"  >&lt;p&gt;Adding a new patch after hearing comments. This patch makes (range 9 3 0) =&amp;gt; (9 9 9 9 ...), (range 3 9 0) =&amp;gt; (3 3 3 3 ...), and () will be returned when (= start end). Also updated the docstring.&lt;/p&gt;</comment>
                    <comment id="30065" author="halgari" created="Tue, 27 Nov 2012 15:01:11 -0600"  >&lt;p&gt;Marking as vetted&lt;/p&gt;</comment>
                    <comment id="30066" author="halgari" created="Tue, 27 Nov 2012 15:04:24 -0600"  >&lt;p&gt;Patch applies cleanly. We&apos;ve discussed this issue to death (for as simple as it is). I think it&apos;s time to mark it as screened. &lt;/p&gt;</comment>
                    <comment id="30067" author="halgari" created="Tue, 27 Nov 2012 15:06:27 -0600"  >&lt;p&gt;For some reason I&apos;m not allowed to edit the attachments list. When you apply the patch, please apply inconsistent_range_fix.diff as that is the most recent version of the fix. &lt;/p&gt;</comment>
                    <comment id="30194" author="richhickey" created="Sun, 9 Dec 2012 06:44:10 -0600"  >&lt;p&gt;As someone who has to read these tickets, I&apos;d really appreciate it if you could keep the description up to date and accurate, with examples of the current and intended behavior and the strategy to be used in fixing. I can&apos;t follow every thread to see what the latest thinking is, especially on a patch like this where the original mission was changed.&lt;/p&gt;

&lt;p&gt;Thanks&lt;/p&gt;</comment>
                    <comment id="30207" author="devn" created="Mon, 10 Dec 2012 15:53:31 -0600"  >&lt;p&gt;@Tim: I&apos;ve removed the other attachments.&lt;/p&gt;

&lt;p&gt;@Rich: Understood. I will update the description this evening.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="11393" name="inconsistent_range_fix.diff" size="1944" author="devn" created="Fri, 20 Jul 2012 17:10:19 -0500" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_10002" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Approval</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10007">Ok</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-1210] error message for (clojure.java.io/reader nil) &#8212; consistency for use with io/resource</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1210</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;This seems to a common idiom:&lt;/p&gt;

&lt;p&gt;    (clojure.java.io/reader (clojure.java.io/resource &quot;myfile&quot;))&lt;/p&gt;


&lt;p&gt;When a file is available these are the behaviors:&lt;/p&gt;

&lt;p&gt;    =&amp;gt; (clojure.java.io/reader &quot;resources/myfile&quot;)&lt;br/&gt;
    #&amp;lt;BufferedReader java.io.BufferedReader@1f291df0&amp;gt;&lt;/p&gt;

&lt;p&gt;    =&amp;gt; (clojure.java.io/resource &quot;myfile&quot;)&lt;br/&gt;
    #&amp;lt;URL &lt;a href=&quot;file:/project/resources/myfile&quot;&gt;file:/project/resources/myfile&lt;/a&gt;&amp;gt;&lt;/p&gt;

&lt;p&gt;    =&amp;gt; (clojure.java.io/reader (clojure.java.io/resource &quot;myfile&quot;))&lt;br/&gt;
    #&amp;lt;BufferedReader java.io.BufferedReader@1db04f7c&amp;gt;&lt;/p&gt;


&lt;p&gt;If the file (resource) is unavailable:&lt;/p&gt;

&lt;p&gt;    =&amp;gt; (clojure.java.io/reader &quot;resources/nofile&quot;)&lt;br/&gt;
    FileNotFoundException resources/nofile (No such file or directory)  java.io.FileInputStream.open (FileInputStream.java:-2)&lt;/p&gt;

&lt;p&gt;    =&amp;gt; (clojure.java.io/resource &quot;nofile&quot;)&lt;br/&gt;
    nil&lt;/p&gt;

&lt;p&gt;    =&amp;gt; (clojure.java.io/reader (clojure.java.io/resource &quot;nofile&quot;))&lt;br/&gt;
    IllegalArgumentException No implementation of method: :make-reader of protocol: #&apos;clojure.java.io/IOFactory found for class: nil  clojure.core/-cache-protocol-fn (core_deftype.clj:541)&lt;/p&gt;


&lt;p&gt;The main enhancement request is to have a better error message from `(clojure.java.io/reader nil)`. I&apos;m not sure if io/resource should return something like &apos;resource &quot;nofile&quot; not found&apos; or if io/reader could add a more helpful suggestion.&lt;/p&gt;</description>
                <environment></environment>
            <key id="16199">CLJ-1210</key>
            <summary>error message for (clojure.java.io/reader nil) &#8212; consistency for use with io/resource</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>
                    </labels>
                <created>Thu, 23 May 2013 17:59:08 -0500</created>
                <updated>Thu, 23 May 2013 17:59:08 -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-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>Thu, 23 May 2013 17:56:23 -0500</updated>
                                    <version>Release 1.5</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>1</watches>
                        <comments>
                    <comment id="31136" author="jafingerhut" created="Thu, 23 May 2013 17:56:23 -0500"  >&lt;p&gt;Related clojure-dev message: &lt;a href=&quot;https://groups.google.com/forum/?fromgroups#!topic/clojure-dev/fLJWh9A3OuA&quot;&gt;https://groups.google.com/forum/?fromgroups#!topic/clojure-dev/fLJWh9A3OuA&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;and enhancement proposal wiki page: &lt;a href=&quot;http://dev.clojure.org/display/design/Representing+EDN&quot;&gt;http://dev.clojure.org/display/design/Representing+EDN&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-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="5" iconUrl="http://dev.clojure.org/jira/images/icons/status_resolved.gif">Resolved</status>
                    <resolution id="1">Completed</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>Mon, 20 May 2013 16:24:12 -0500</updated>
                    <resolved>Mon, 20 May 2013 16:18:25 -0500</resolved>
                            <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>
                    <comment id="31121" author="tomfaulhaber" created="Mon, 20 May 2013 16:18:25 -0500"  >&lt;p&gt;This is fixed with gh-pages commit 919143e (autodoc doesn&apos;t follow the regular Clojure release path since it&apos;s a website built off the source checkins).&lt;/p&gt;</comment>
                    <comment id="31122" author="tomfaulhaber" created="Mon, 20 May 2013 16:24:12 -0500"  >&lt;p&gt;Gabriel, Thanks for the offer. I fixed this one, but may take you up on it if more come up. &lt;/p&gt;

&lt;p&gt;There is currently no wiki page about the autodoc process but it&apos;s an excellent suggestion. I&apos;ll put it on my list to write something up. In the meantime source on the autodoc program itself is at &lt;a href=&quot;https://github.com/tomfaulhaber/autodoc&quot;&gt;https://github.com/tomfaulhaber/autodoc&lt;/a&gt; and a description of how it works is at &lt;a href=&quot;http://tomfaulhaber.github.io/autodoc&quot;&gt;http://tomfaulhaber.github.io/autodoc&lt;/a&gt;. Two caveats: (1) autodoc is currently undergoing a bunch of work (thus this bug fix) in preparation for a new release and (2) the documentation doesn&apos;t talk much about how it&apos;s used for documenting Clojure itself.&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-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-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-1173] One-arg protocol functions whose name begins in a dash generates a call to a wrong field in the emitted code</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1173</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;(defprotocol P (-foo [&lt;span class=&quot;code-keyword&quot;&gt;this&lt;/span&gt;]))&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;This code generates a reflective call to a non-existing &lt;tt&gt;foo&lt;/tt&gt; field instead of the correct &lt;tt&gt;-foo&lt;/tt&gt; method.&lt;/p&gt;

&lt;p&gt;I was told by Christophe Grand that changing the &lt;a href=&quot;https://github.com/clojure/clojure/blob/master/src/clj/clojure/core_deftype.clj#L557&quot;&gt;line 557 in core_deftype.clj&lt;/a&gt; from:&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;(. ~(with-meta target {:tag on-&lt;span class=&quot;code-keyword&quot;&gt;interface&lt;/span&gt;}) ~(or on-method method) ~@(&lt;span class=&quot;code-keyword&quot;&gt;rest&lt;/span&gt; gargs))&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;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;(. ~(with-meta target {:tag on-&lt;span class=&quot;code-keyword&quot;&gt;interface&lt;/span&gt;}) (~(or on-method method) ~@(&lt;span class=&quot;code-keyword&quot;&gt;rest&lt;/span&gt; gargs)))&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;is a quick fix. However I don&apos;t know too much about the compilation specifics of &lt;tt&gt;.&lt;/tt&gt; to judge whether this is the correct fix.&lt;/p&gt;

&lt;p&gt;Issue reproduction:&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;Clojure
user=&amp;gt; (set! *warn-on-reflection* &lt;span class=&quot;code-keyword&quot;&gt;true&lt;/span&gt;)
&lt;span class=&quot;code-keyword&quot;&gt;true&lt;/span&gt;
user=&amp;gt; (defprotocol P (-foo [&lt;span class=&quot;code-keyword&quot;&gt;this&lt;/span&gt;]))
P
Reflection warning, REPL:4 - reference to field foo can&apos;t be resolved.&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;</description>
                <environment>Clojure 1.4</environment>
            <key id="16035">CLJ-1173</key>
            <summary>One-arg protocol functions whose name begins in a dash generates a call to a wrong field in the emitted code</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="6" iconUrl="http://dev.clojure.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="3">Duplicate</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="mbrandmeyer">Meikel Brandmeyer</reporter>
                        <labels>
                    </labels>
                <created>Fri, 1 Mar 2013 04:48:28 -0600</created>
                <updated>Fri, 17 May 2013 13:36:40 -0500</updated>
                    <resolved>Fri, 17 May 2013 13:36:40 -0500</resolved>
                            <version>Release 1.4</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                        <comments>
                    <comment id="31101" author="cldwalker" created="Fri, 17 May 2013 13:36:40 -0500"  >&lt;p&gt;&lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-1202&quot; title=&quot;protocol fns with dashes may get compiled into property access when used higher order&quot;&gt;CLJ-1202&lt;/a&gt; addresses this exact issue with the same fix and includes tests&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-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-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>

<item>
            <title>[CLJ-1202] protocol fns with dashes may get compiled into property access when used higher order</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1202</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; (defprotocol Foo (-foo [x]))
Foo
user=&amp;gt; (deftype Bar [] Foo (-foo [_] :baz))
user.Bar
user=&amp;gt; (map -foo [(Bar.)])
IllegalArgumentException No matching field found: foo &lt;span class=&quot;code-keyword&quot;&gt;for&lt;/span&gt; class user.Bar  
clojure.lang.Reflector.getInstanceField (Reflector.java:271)&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;I would have expected to see (:baz). The full stack is:&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;IllegalArgumentException No matching field found: foo &lt;span class=&quot;code-keyword&quot;&gt;for&lt;/span&gt; class user.Bar
	clojure.lang.Reflector.getInstanceField (Reflector.java:271)
	clojure.lang.Reflector.invokeNoArgInstanceMember (Reflector.java:300)
	user/eval79/fn--80/G--71--82 (NO_SOURCE_FILE:11)
	user/eval79/fn--80/G--70--85 (NO_SOURCE_FILE:11)
	clojure.core/map/fn--4207 (core.clj:2485)
	clojure.lang.LazySeq.sval (LazySeq.java:42)
	clojure.lang.LazySeq.seq (LazySeq.java:60)
	clojure.lang.RT.seq (RT.java:484)
	clojure.core/seq (core.clj:133)
	clojure.core/print-sequential (core_print.clj:46)
	clojure.core/fn--5406 (core_print.clj:143)
	clojure.lang.MultiFn.invoke (MultiFn.java:231)
nil&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;I suspect this is somehow related to the property access changes to make Clojure/ClojureScript compatible. I was in fact prepping core.logic for a unified code base and was adopting the ClojureScript protocol naming convention when I encountered this issue.&lt;/p&gt;

&lt;p&gt;&lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-872&quot; title=&quot;Add support for property lookup&quot;&gt;&lt;del&gt;CLJ-872&lt;/del&gt;&lt;/a&gt; added dash property support to Clojure.&lt;/p&gt;</description>
                <environment></environment>
            <key id="16147">CLJ-1202</key>
            <summary>protocol fns with dashes may get compiled into property access when used higher order</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="dnolen">David Nolen</reporter>
                        <labels>
                    </labels>
                <created>Tue, 16 Apr 2013 20:48:27 -0500</created>
                <updated>Fri, 10 May 2013 15:19:29 -0500</updated>
                                    <version>Release 1.5</version>
                                <fixVersion>Release 1.6</fixVersion>
                                        <due></due>
                    <votes>0</votes>
                        <watches>3</watches>
                        <comments>
                    <comment id="30970" author="amalloy" created="Thu, 18 Apr 2013 19:18:35 -0500"  >&lt;p&gt;Attached patch fixes the issue, and adds regression test for it.&lt;/p&gt;</comment>
                    <comment id="31080" author="cldwalker" created="Fri, 10 May 2013 15:19:29 -0500"  >&lt;p&gt;Verified patch works&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="11962" name="CLJ-1202.patch" size="1759" author="amalloy" created="Thu, 18 Apr 2013 19:18:35 -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-866] Provide a clojure.test function to run a single test case with fixtures</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-866</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;At present, clojure.test test cases are functions and can be invoked directly.  However, in the case that the test relies on fixtures, this does not work.  Please provide a function that can run a single test case with all fixtures applied.&lt;/p&gt;</description>
                <environment></environment>
            <key id="14902">CLJ-866</key>
            <summary>Provide a clojure.test function to run a single test case with fixtures</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="anthonygrimes">Anthony Grimes</assignee>
                                <reporter username="hugoduncan">Hugo Duncan</reporter>
                        <labels>
                    </labels>
                <created>Thu, 27 Oct 2011 08:57:55 -0500</created>
                <updated>Sat, 4 May 2013 09:36:20 -0500</updated>
                                                    <fixVersion>Release 1.6</fixVersion>
                                        <due></due>
                    <votes>8</votes>
                        <watches>5</watches>
                        <comments>
                    <comment id="29767" author="anthonygrimes" created="Mon, 22 Oct 2012 18:17:38 -0500"  >&lt;p&gt;I just added clj-866-test-vars.patch (22/Oct/12 6:09PM).&lt;/p&gt;

&lt;p&gt;I had to implement this hackishly in Leiningen a few days ago, so I&apos;m very excited to get this functionality in clojure.test itself.&lt;/p&gt;

&lt;p&gt;This patch adds a test-vars function that solves this problem (and is more general). You can test as many vars as you want with it, with fixtures. It works by grouping vars passed by their namespace and then running them all with appropriate fixtures applied. Being able to run a single test isn&apos;t the problem here, being able to run &lt;b&gt;only specific tests&lt;/b&gt; is. If we wrote a function to run one test with fixtures but we actually needed to run several, just not &lt;b&gt;all&lt;/b&gt; tests, we&apos;d end up having to run once-fixtures more than once which is wasteful. I think test-vars is a good solution that solves both this problem and the one I just mentioned.&lt;/p&gt;</comment>
                    <comment id="31049" author="alexmiller" created="Sat, 4 May 2013 09:36:20 -0500"  >&lt;p&gt;This is highly useful. Could you add a test to the patch?&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="11602" name="clj-866-test-vars.patch" size="1977" author="anthonygrimes" created="Mon, 22 Oct 2012 18:09:31 -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-766] Implicit casting behaviour of into-array differs from &lt;primitive&gt;-array</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-766</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;Current patch: byte-short-array-ctors.diff&lt;/p&gt;

&lt;p&gt;The behavior of &lt;tt&gt;byte-array&lt;/tt&gt; and &lt;tt&gt;short-array&lt;/tt&gt; is inconsistent with the other &lt;tt&gt;&amp;lt;type&amp;gt;-array&lt;/tt&gt; functions and with the &lt;tt&gt;into-array&lt;/tt&gt; function when invoked with types other than byte or short. All of the other cases upcast to Number, then extract the primitive value, allowing this operation to succeed (assuming the value is in range). &lt;tt&gt;byte-array&lt;/tt&gt; and &lt;tt&gt;short-array&lt;/tt&gt; throw a ClassCastException.&lt;/p&gt;

&lt;p&gt;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;base64v3a=&amp;gt; (into-array Byte/TYPE [1 2 3 4])  ;; int to byte ok
#&amp;lt;byte[] [B@5ee04fd&amp;gt;
base64v3a=&amp;gt; (byte-array [1 2 3 4])  ;; int to byte NOT ok!! 
ClassCastException java.lang.Long cannot be cast to java.lang.Byte
  clojure.lang.Numbers.byte_array (Numbers.java:1418)
base64v3a=&amp;gt; (long-array [1 2 3 4])  ;; int to long ok
#&amp;lt;long[] [J@3f9f4d1d&amp;gt;
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;&lt;tt&gt;into-array&lt;/tt&gt; (via &lt;tt&gt;RT.seqToTypedArray&lt;/tt&gt;) and the other &lt;tt&gt;&amp;lt;type&amp;gt;-array&lt;/tt&gt; functions all upcast to Number (via Numbers.&amp;lt;type&amp;gt;_array}}), then obtain the proper primitive value. &lt;tt&gt;Numbers.byte-array&lt;/tt&gt; and &lt;tt&gt;Numbers.short-array&lt;/tt&gt; do casts directly to Byte and Short (yielding the ClassCastException).&lt;/p&gt;

&lt;p&gt;The attached patch makes the Byte and Short cases match the other types and the &lt;tt&gt;into-array&lt;/tt&gt; behavior. Tests are included. The submitter is a contributor.&lt;/p&gt;</description>
                <environment></environment>
            <key id="14390">CLJ-766</key>
            <summary>Implicit casting behaviour of into-array differs from &lt;primitive&gt;-array</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="toxi">Karsten Schmidt</assignee>
                                <reporter username="ataggart">Alexander Taggart</reporter>
                        <labels>
                    </labels>
                <created>Fri, 1 Apr 2011 18:45:53 -0500</created>
                <updated>Fri, 3 May 2013 20:46:29 -0500</updated>
                                    <version>Release 1.3</version>
                                <fixVersion>Release 1.6</fixVersion>
                                        <due></due>
                    <votes>3</votes>
                        <watches>6</watches>
                        <comments>
                    <comment id="26342" author="ataggart" created="Sat, 2 Apr 2011 14:04:31 -0500"  >&lt;p&gt;See &lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-678&quot; title=&quot;into-array should work with all primitive types&quot;&gt;&lt;del&gt;CLJ-678&lt;/del&gt;&lt;/a&gt;.&lt;/p&gt;</comment>
                    <comment id="28631" author="jafingerhut" created="Mon, 28 May 2012 18:45:30 -0500"  >&lt;p&gt;Some more details from Alexandar Taggart: This is not a duplicate of &lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-678&quot; title=&quot;into-array should work with all primitive types&quot;&gt;&lt;del&gt;CLJ-678&lt;/del&gt;&lt;/a&gt;.  &lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-766&quot; title=&quot;Implicit casting behaviour of into-array differs from &amp;lt;primitive&amp;gt;-array&quot;&gt;CLJ-766&lt;/a&gt; was created precisely due to the fact the the behavior of *-array is not consistent with the post-678 version of into-array.&lt;/p&gt;</comment>
                    <comment id="30688" author="toxi" created="Sat, 2 Mar 2013 17:11:43 -0600"  >&lt;p&gt;I&apos;d like to bump up this issue, since it&apos;d be great if all the (xxx-array) factory functions have the same expected behavior (i.e. not throw an exception, especially not if the values are in range). The attached patch is changing the behaviour for byte-array &amp;amp; short-array to the same pattern used as for int/long/float/double and therefore will not throw an exception for valid (even if overflown) numbers. You can find more discussion in this thread on:&lt;/p&gt;

&lt;p&gt;&lt;a href=&quot;https://groups.google.com/forum/?hl=en&amp;amp;fromgroups=#!topic/clojure/KyQrbph-zqo&quot;&gt;https://groups.google.com/forum/?hl=en&amp;amp;fromgroups=#!topic/clojure/KyQrbph-zqo&lt;/a&gt;&lt;/p&gt;</comment>
                    <comment id="30689" author="jafingerhut" created="Sun, 3 Mar 2013 08:11:29 -0600"  >&lt;p&gt;Voting on a ticket (click the &quot;Vote&quot; link under the &quot;People&quot; heading while viewing the ticket on JIRA) may help draw attention to it, too.&lt;/p&gt;</comment>
                    <comment id="30695" author="jafingerhut" created="Mon, 4 Mar 2013 13:08:11 -0600"  >&lt;p&gt;Karsten, patches should be in the format created by the &quot;git format-patch&quot; command as described in the instructions under the heading &quot;Development&quot; on 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;</comment>
                    <comment id="30696" author="toxi" created="Mon, 4 Mar 2013 14:05:51 -0600"  >&lt;p&gt;Sorry Andy, I used Atlassian SourceTree to create the patch and assumed it&apos;s in standard git format... I&apos;ve removed the old one and attach a (hopefully) properly formatted one. Apologies, contributing-beginners-luck!&lt;/p&gt;</comment>
                    <comment id="30850" author="stu" created="Sat, 30 Mar 2013 08:52:01 -0500"  >&lt;p&gt;While investigating this, I noticed that long-array coerces across type, e.g.&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;(seq (long-array [1.0]))
=&amp;gt; (1)
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;Is this what we want? I don&apos;t think so.&lt;/p&gt;</comment>
                    <comment id="30851" author="stu" created="Sat, 30 Mar 2013 08:53:59 -0500"  >&lt;p&gt;I agree that all the numeric array constructors should work the same way, but I am not sue we should adopt long-array&apos;s approach, which allows coercion from float to integer types.&lt;/p&gt;</comment>
                    <comment id="31047" author="alexmiller" created="Fri, 3 May 2013 20:31:24 -0500"  >&lt;p&gt;I think the patch approach is valid. However, the patch does not cover the same problem in the 2-arity version of byte_array and short_array (when a size is supplied). Please update the patch to include a fix in the 2-arity version of byte_array and short_array and tests for the same. Ex: (byte-array 1 &lt;span class=&quot;error&quot;&gt;&amp;#91;1&amp;#93;&lt;/span&gt;).  &lt;/p&gt;

&lt;p&gt;Also, there is a whitespace issue in the patch - please just use spaces! &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;/Users/alex/work/code/clojure/.git/rebase-apply/patch:24: space before tab in indent.
	    	ret[i] = ((Number)s.first()).byteValue();
warning: 1 line adds whitespace errors.
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;Re Stuart&apos;s comments, I don&apos;t think that&apos;s in the scope of this ticket or solution. &lt;/p&gt;</comment>
                    <comment id="31048" author="alexmiller" created="Fri, 3 May 2013 20:32:42 -0500"  >&lt;p&gt;Sending back to Karsten for the requested patch updates.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="11890" name="byte-short-array-ctors.diff" size="1873" author="toxi" created="Mon, 4 Mar 2013 14:05:51 -0600" />
                </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>
                                                                                        </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>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-428] subseq, rsubseq enhancements to support priority maps?</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-428</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;See dev thread at &lt;a href=&quot;http://groups.google.com/group/clojure-dev/browse_thread/thread/fdb000cae4f66a95&quot;&gt;http://groups.google.com/group/clojure-dev/browse_thread/thread/fdb000cae4f66a95&lt;/a&gt;.&lt;/p&gt;

&lt;p&gt;Note: subseq currently returns () instead of nil in some situations. If the rest of this idea dies we might still want to fix that.&lt;/p&gt;</description>
                <environment></environment>
            <key id="13825">CLJ-428</key>
            <summary>subseq, rsubseq enhancements to support priority maps?</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, 20 Aug 2010 08:01:00 -0500</created>
                <updated>Wed, 1 May 2013 02:44:36 -0500</updated>
                                    <version>Approved Backlog</version>
                                <fixVersion>Approved Backlog</fixVersion>
                                        <due></due>
                    <votes>2</votes>
                        <watches>3</watches>
                        <comments>
                    <comment id="24210" author="importer" created="Tue, 24 Aug 2010 10:10:00 -0500"  >&lt;p&gt;Converted from &lt;a href=&quot;http://www.assembla.com/spaces/clojure/tickets/428&quot;&gt;http://www.assembla.com/spaces/clojure/tickets/428&lt;/a&gt;&lt;/p&gt;</comment>
                    <comment id="31010" author="jafingerhut" created="Sun, 28 Apr 2013 02:14:18 -0500"  >&lt;p&gt;Patch clj-428-change-Sorted-seqFrom-to-take-inclusive-patch-v1.txt dated Apr 28 2013 was written by Mark Engelberg in July 2010, and was attached to a message he sent to the dev thread linked in the description.  The approach he takes is described by him in that thread, copied here:&lt;/p&gt;

&lt;p&gt;----------------------------------------&lt;br/&gt;
Meanwhile, to initiate discussion on how to modify subseq, I&apos;ve attached a proposed patch.  This patch works by modifying the seqFrom method of the Sorted interface to take an additional &quot;inclusive&quot; parameter (i.e., &amp;lt;= and &amp;gt;= are inclusive, &amp;lt; and &amp;gt; are not).&lt;/p&gt;

&lt;p&gt;In this patch, I do not address one issue I raised before, which is whether subseq implies by its name that it should return a seq rather than a sequence (in other words nil rather than ()).  If seq behavior is desired, it would be necessary to wrap a call to seq around the calls to take-while.  But for now, I&apos;m just making the behavior match the current behavior.&lt;/p&gt;

&lt;p&gt;Although I think this is the cleanest way to address the extensibility issue with subseq, the change to seqFrom will break anyone who currently is overriding that method.  I didn&apos;t see any such classes in clojure.contrib, so I don&apos;t think it&apos;s an issue, but if this is a concern, my other idea is to fix the problem entirely within subseq by changing the calls to next into calls to drop-while.  I have coded this to confirm that it works, and can provide that alternative patch if desired.&lt;br/&gt;
----------------------------------------&lt;/p&gt;

&lt;p&gt;I can also supply a patch that uses drop-while in clojure.core/subseq and rsubseq if such an approach is preferred to the one in this patch.&lt;/p&gt;</comment>
                    <comment id="31014" author="jafingerhut" created="Sun, 28 Apr 2013 12:12:47 -0500"  >&lt;p&gt;clj-428-change-Sorted-seqFrom-to-take-inclusive-patch-v2.txt dated Apr 28 2013 is same as clj-428-change-Sorted-seqFrom-to-take-inclusive-patch-v1.txt (soon to be deleted), except it adds tests for subseq and rsubseq, and corrects a bug in that patch.  The approach is the same as described above for that patch.&lt;/p&gt;</comment>
                    <comment id="31036" author="jafingerhut" created="Wed, 1 May 2013 02:44:20 -0500"  >&lt;p&gt;Patch clj-428-change-Sorted-seqFrom-to-take-inclusive-patch-v3.txt dated May 1 2013 is the same as clj-428-change-Sorted-seqFrom-to-take-inclusive-patch-v1.txt, still with the bug fix mentioned for -v2, but with some unnecessary changes removed from the patch.  The comments for -v1.txt on the approach still apply.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="11977" name="clj-428-change-Sorted-seqFrom-to-take-inclusive-patch-v3.txt" size="5901" author="jafingerhut" created="Wed, 1 May 2013 02:44: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="10001">Code</customfieldvalue>

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

<item>
            <title>[CLJ-1203] Fallback to hash-based comparison for non-Comparables in Util.compare()</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1203</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;I oftentimes use sorted collections, and my comparator functions usually look like that:&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;(fn [a b]
  (let [x (compare-according-to-my-use-case a b)]
    (if (zero? x)
       (compare a b)
       x)))
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;That is, I define the sorting order depending on the requirements of my use-case, and if that doesn&apos;t suffice to make a distinction, I simply fall back to the standard `compare` function in order to get a stable ordering anyhow. I think that&apos;s a widely used idiom, e.g., also used in &quot;Clojure Programming&quot; (for example page 109).&lt;/p&gt;

&lt;p&gt;The problem with this approach is that several data structures don&apos;t implement Comparable, and thus aren&apos;t applicable to `compare` (you&apos;ll get a ClassCastException).  Examples are maps, records, deftypes, and sequences.&lt;/p&gt;

&lt;p&gt;The patch I&apos;m going to attach extends `Util.compare()` with a fallback clause that performs a `hasheq()`-based comparison.  This results in a meaningless but at least stable sorting order which suffices for use-cases like the one  shown above.&lt;/p&gt;</description>
                <environment></environment>
            <key id="16148">CLJ-1203</key>
            <summary>Fallback to hash-based comparison for non-Comparables in Util.compare()</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="6" iconUrl="http://dev.clojure.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="2">Declined</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="tsdh">Tassilo Horn</reporter>
                        <labels>
                        <label>enhancement</label>
                        <label>patch</label>
                    </labels>
                <created>Wed, 17 Apr 2013 02:42:29 -0500</created>
                <updated>Mon, 29 Apr 2013 02:30:08 -0500</updated>
                    <resolved>Mon, 29 Apr 2013 02:30:08 -0500</resolved>
                                                                    <due></due>
                    <votes>0</votes>
                        <watches>3</watches>
                        <comments>
                    <comment id="30974" author="jafingerhut" created="Thu, 18 Apr 2013 21:01:21 -0500"  >&lt;p&gt;Patch 0001-Add-hasheq-based-fallback-to-Util.compare.patch dated Apr 17 2013 applies cleanly to latest master, but causes several unit tests in data_structures.clj to fail.  These are the kinds of things you would expect to fail with the change made in the patch, because the failing tests expect an exception to be thrown when comparing objects that don&apos;t implement Comparable, and with this patch&apos;s changes they no longer do.  If this patch&apos;s change is desired, those tests should probably be removed.&lt;/p&gt;</comment>
                    <comment id="30975" author="tsdh" created="Fri, 19 Apr 2013 02:34:51 -0500"  >&lt;p&gt;Thanks Andy, I can&apos;t believe I&apos;ve forgotten to re-run the tests. &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;

&lt;p&gt;Anyway, I&apos;m attaching a new version of the patch that deletes the few sorted-set and sorted-set-by invocations that check that an exception is thrown when creating sorted sets containing non-Comparables.&lt;/p&gt;</comment>
                    <comment id="30976" author="tsdh" created="Fri, 19 Apr 2013 02:35:28 -0500"  >&lt;p&gt;New version of the patch.&lt;/p&gt;</comment>
                    <comment id="31003" author="jafingerhut" created="Fri, 26 Apr 2013 14:47:49 -0500"  >&lt;p&gt;Tassilo, you say that one of your use cases is sorted collections.  Note that any compare function that returns 0 for two values will cause sorted sets and maps to treat the two compared values as equal, and at most one of them will get into the ordered set/map, the second treated as a duplicate, even though the values are not equal.  See &lt;a href=&quot;https://github.com/jafingerhut/thalia/blob/master/doc/other-topics/comparators.md#comparators-for-sorted-sets-and-maps-are-easy-to-get-wrong&quot;&gt;https://github.com/jafingerhut/thalia/blob/master/doc/other-topics/comparators.md#comparators-for-sorted-sets-and-maps-are-easy-to-get-wrong&lt;/a&gt; for an example (not based on your modified compare, but on a comparator that returns 0 for non-equal items).&lt;/p&gt;

&lt;p&gt;With your proposed change to compare, this occurrence would become very dependent upon the hash function used.  Probably quite rare, but it would crop up from time to time, and could potentially be very difficult to detect and track down the source.&lt;/p&gt;</comment>
                    <comment id="31019" author="tsdh" created="Mon, 29 Apr 2013 02:29:56 -0500"  >&lt;p&gt;Hi Andy, you are right.  It&apos;s possible to add an explicit equals()-check in cases the hashcodes are the same, but I think there&apos;s nothing you can do in the hashcodes-equal-but-objects-are-not case.  That is, there&apos;s no way to ensure the rule sgn(compare(x, y)) == -sgn(compare(y, x)), the transitivity rule, and the compare(x, y)==0 ==&amp;gt; sgn(compare(x, z))==sgn(compare(y, z)) for all z rule.&lt;/p&gt;

&lt;p&gt;I&apos;m closing that ticket.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="11965" name="0001-Add-hasheq-based-fallback-to-Util.compare.patch" size="3032" author="tsdh" created="Fri, 19 Apr 2013 02:35: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="10001">Code</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>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-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-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-889] Specifically allow &apos;.&apos; inside keywords</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-889</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;The documentation for keywords (on page &lt;a href=&quot;http://clojure.org/reader&quot;&gt;http://clojure.org/reader&lt;/a&gt;) specifically states that &apos;.&apos; is not allowed as part of a keyword name; however &apos;.&apos; is specifically useful.  For example, several web frameworks for Clojure use keywords to represent HTML elements, using CSS selector syntax (i.e., :div.important is equivalent to &amp;lt;div class=&apos;important&apos;&amp;gt;).&lt;/p&gt;

&lt;p&gt;In any case, the use of &apos;.&apos; is not checked by the reader and it is generally useful.&lt;/p&gt;

&lt;p&gt;I would like to see &apos;.&apos; officially allowed (in the documentation).  Further, I&apos;d like to see additional details about which punctuation characters are allowed (my own web framework uses &apos;&amp;amp;&apos;, &apos;?&apos; and &apos;&amp;gt;&apos; inside keywords for various purposes ... again, current reader implementation does not forbid this, but if a future reader will reject it, I&apos;d like to know now).&lt;/p&gt;</description>
                <environment></environment>
            <key id="15043">CLJ-889</key>
            <summary>Specifically allow &apos;.&apos; inside keywords</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>keywords</label>
                        <label>reader</label>
                    </labels>
                <created>Thu, 1 Dec 2011 11:09:04 -0600</created>
                <updated>Mon, 15 Apr 2013 05:56:25 -0500</updated>
                                                    <fixVersion>Reviewed Backlog</fixVersion>
                                        <due></due>
                    <votes>0</votes>
                        <watches>3</watches>
                        <comments>
                    <comment id="27427" author="hlewisship" created="Thu, 8 Dec 2011 15:37:26 -0600"  >&lt;p&gt;To clarify, Hiccup and Cascade both use keywords containing &apos;#&apos; and &apos;.&apos;  Cascade goes further, using &apos;&amp;amp;&apos; (to represent HTML entities), &apos;&amp;gt;&apos;, and (possibly in the future) &apos;?&apos;.&lt;/p&gt;</comment>
                    <comment id="29735" author="devn" created="Sat, 20 Oct 2012 18:46:53 -0500"  >&lt;p&gt;I think the EDN spec mitigates some of the concern, but as of yet the official clojure.org reader documentation does not reflect the language used in the description of EDN. Where does EDN stand right now? Can the description being used on the github page be pulled over to clojure.org?&lt;/p&gt;

&lt;p&gt;References:&lt;/p&gt;
&lt;ul class=&quot;alternate&quot; type=&quot;square&quot;&gt;
	&lt;li&gt;&lt;a href=&quot;https://github.com/edn-format/edn#keywords&quot;&gt;https://github.com/edn-format/edn#keywords&lt;/a&gt;&lt;/li&gt;
	&lt;li&gt;&lt;a href=&quot;http://clojure.org/reader#The&quot;&gt;http://clojure.org/reader#The&lt;/a&gt; Reader--extensible data notation (edn)&lt;/li&gt;
&lt;/ul&gt;
</comment>
                    <comment id="30962" author="hlewisship" created="Mon, 15 Apr 2013 05:56:25 -0500"  >&lt;p&gt;Unfortunately, the EDN specification does not mention &apos;&amp;gt;&apos;.&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-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-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-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-1188] Public Java API</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1188</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;Problem: Java consumers need an API into Clojure that does not drag in a ton of concrete implementation detail.&lt;/p&gt;

&lt;p&gt;Solution: Very small API class that allows looking up Vars (returning IFn), and reading data (as edn).  Uses Clojure logic where possible, e.g. Var.intern.&lt;/p&gt;

&lt;p&gt;Current patch: &lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-1188&quot; title=&quot;Public Java API&quot;&gt;&lt;del&gt;CLJ-1188&lt;/del&gt;&lt;/a&gt;-via-var-intern.patch&lt;/p&gt;

&lt;p&gt;Also considered:&lt;/p&gt;

&lt;ul&gt;
	&lt;li&gt;wrapper class (inconvenient for users, wrappers anathema in Clojure)&lt;/li&gt;
	&lt;li&gt;common superinterface for IFn and Deref (unnecessary, might bloat vtable)&lt;/li&gt;
&lt;/ul&gt;


&lt;p&gt;See also &lt;a href=&quot;http://dev.clojure.org/display/design/Improvements+to+interop+from+Java&quot;&gt;http://dev.clojure.org/display/design/Improvements+to+interop+from+Java&lt;/a&gt;&lt;/p&gt;</description>
                <environment></environment>
            <key id="16116">CLJ-1188</key>
            <summary>Public Java API</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="5" iconUrl="http://dev.clojure.org/jira/images/icons/status_resolved.gif">Resolved</status>
                    <resolution id="1">Completed</resolution>
                                <assignee username="stu">Stuart Halloway</assignee>
                                <reporter username="stu">Stuart Halloway</reporter>
                        <labels>
                    </labels>
                <created>Sat, 30 Mar 2013 08:37:15 -0500</created>
                <updated>Fri, 12 Apr 2013 13:51:46 -0500</updated>
                    <resolved>Fri, 12 Apr 2013 13:51:46 -0500</resolved>
                                            <fixVersion>Release 1.6</fixVersion>
                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                        <comments>
                    <comment id="30856" author="hiredman" created="Tue, 2 Apr 2013 11:34:02 -0500"  >&lt;p&gt;the attached patch would turn&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;...
public static Var ENQUEUE = RT.var(&quot;greenmail.smtp&quot;,&quot;enqueue&quot;);
...
ENQUEUE.fn().invoke(userManager, state.getMessage());
...
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;in to something like&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;...
public static VRef ENQUEUE = API.vref(&quot;greenmail.smtp/enqueue&quot;);
...
ENQUEUE.fn().invoke(userManager, state.getMessage());
...
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;what is the value of VRefs over using Vars directly?&lt;/p&gt;</comment>
                    <comment id="30859" author="hiredman" created="Tue, 2 Apr 2013 17:56:38 -0500"  >&lt;p&gt;using this from a java api, it looks like if the namespace the var is in is not loaded when you go to create a VRef it will return null, generally my java code that calls clojure looks something like&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;public static Var FOO = RT.var(&quot;namespace&quot;, &quot;name&quot;);
public static NAMESPACE = Symbol.intern(&quot;namespace&quot;);
public static Var REQUIRE = RT.var(&quot;clojure&quot;, &quot;require&quot;);

static {
  REQUIRE.invoke(NAMESPACE);
}
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;can you tell me without checking the java/jvm spec if FOO is null? does the static init block run before or after static fields are init&apos;ed? returning null just seems like a bad idea.&lt;/p&gt;</comment>
                    <comment id="30864" author="stu" created="Wed, 3 Apr 2013 06:53:24 -0500"  >&lt;p&gt;Per discussion on the ticket and with Rich, the wrapper-free approach (Apr 3 patch) is preferred.&lt;/p&gt;</comment>
                    <comment id="30865" author="stu" created="Wed, 3 Apr 2013 07:03:50 -0500"  >&lt;p&gt;Hi Kevin,&lt;/p&gt;

&lt;p&gt;The purpose of not returning Vars is outlined in the &lt;a href=&quot;http://dev.clojure.org/display/design/Improvements+to+interop+from+Java&quot;&gt;design discussion&lt;/a&gt;.  That said, it is possible to return IFn, which does not drag in too much implementation detail (just a javadoc config tweak, see &lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-1190&quot; title=&quot;Javadoc for public Java API&quot;&gt;CLJ-1190&lt;/a&gt;).  Today&apos;s patch returns IFn, which addresses the wrapper ickiness demonstrated by your code examples.&lt;/p&gt;

&lt;p&gt;Java static initializers run in lexical order, and I trust Java programmers to know Java. &lt;/p&gt;

&lt;p&gt;I can think of several options other than returning null when a var is not available, and they are all complecting, inconsistent with Clojure, or both.&lt;/p&gt;</comment>
                    <comment id="30866" author="hiredman" created="Wed, 3 Apr 2013 12:08:31 -0500"  >&lt;p&gt;Hey,&lt;/p&gt;

&lt;p&gt;Always returning the var is very consistent with clojure, it is what RT.var does. It is what the var lookups emitted by the compiler do. RT.var is most likely the point through which most java that calls clojure goes at the moment.&lt;/p&gt;

&lt;p&gt;As to &quot;hiding&quot; vars, how about creating a clojure.lang.ILink interface with both deref() and fn(), have Var implement it. The previous discussion I see linked all seems to presume hiding Var without discussion of why it should be hidden. What I see Rich saying is:&lt;/p&gt;

&lt;blockquote&gt;
&lt;p&gt;So RT.var is the right idea. It would be nice to hide the Var class,  &lt;br/&gt;
but unfortunately we can&apos;t make ClojureAPI.var() return both IFn and  &lt;br/&gt;
IDeref without inventing a common subinterface. There are other  &lt;br/&gt;
similar details.&lt;/p&gt;&lt;/blockquote&gt;

&lt;p&gt;and&lt;/p&gt;

&lt;blockquote&gt;
&lt;p&gt;We will need an interface unifying IDeref and IFn for the return type  &lt;br/&gt;
of API.var()&lt;/p&gt;&lt;/blockquote&gt;

&lt;p&gt;It seems like Rich is suggesting that ILink or whatever should also bring in IFn, but I wonder if having a fn() that does the cast for you is an acceptable alternative to that.&lt;/p&gt;</comment>
                    <comment id="30938" author="richhickey" created="Fri, 12 Apr 2013 08:24:42 -0500"  >&lt;p&gt;The API should be called var, not fn, and should return IFn. Also, I really want the logic of RT.var (i.e. Var.intern) to be used, not this new logic. Please find another way to handle the string/symbol support.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="11932" name="CLJ-1188.patch" size="7178" author="stu" created="Sat, 30 Mar 2013 08:40:34 -0500" />
                    <attachment id="11954" name="CLJ-1188-via-var-intern.patch" size="7486" author="stu" created="Fri, 12 Apr 2013 11:51:59 -0500" />
                    <attachment id="11939" name="CLJ-1188-wrapper-free.patch" size="6010" author="stu" created="Wed, 3 Apr 2013 06:53:24 -0500" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_10002" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Approval</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10007">Ok</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-196] *file* returns &quot;NO_SOURCE_PATH&quot;, but the doc says it should be nil</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-196</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;According to &lt;a href=&quot;http://clojure.org/api&quot;&gt;http://clojure.org/api&lt;/a&gt;, &amp;#42;file* should return nil in the repl, but it returns &quot;NO_SOURCE_PATH&quot;.&lt;/p&gt;

&lt;p&gt;This has been true for a long time. Latest patch changes only the docstring of &amp;#42;file* to accurately reflect current behavior.&lt;/p&gt;</description>
                <environment></environment>
            <key id="13593">CLJ-196</key>
            <summary>*file* returns &quot;NO_SOURCE_PATH&quot;, but the doc says it should be nil</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="3" iconUrl="http://dev.clojure.org/jira/images/icons/status_inprogress.gif">In Progress</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="aredington">Alexander Redington</reporter>
                        <labels>
                    </labels>
                <created>Sat, 10 Oct 2009 04:34:00 -0500</created>
                <updated>Fri, 12 Apr 2013 10:05:40 -0500</updated>
                                    <version>Approved Backlog</version>
                                <fixVersion>Release 1.6</fixVersion>
                                        <due></due>
                    <votes>2</votes>
                        <watches>2</watches>
                        <comments>
                    <comment id="23213" author="importer" created="Tue, 24 Aug 2010 04:47:00 -0500"  >&lt;p&gt;Converted from &lt;a href=&quot;http://www.assembla.com/spaces/clojure/tickets/196&quot;&gt;http://www.assembla.com/spaces/clojure/tickets/196&lt;/a&gt;&lt;/p&gt;</comment>
                    <comment id="26070" author="trptcolin" created="Fri, 31 Dec 2010 14:41:51 -0600"  >&lt;p&gt;I think this is a pretty trivial docstring fix - &quot;NO_SOURCE_PATH&quot; has been the default value of &lt;b&gt;file&lt;/b&gt; since 3dd4c1cf18ea8456b5b4aec607cd54ecfdd85eea (April 2009).&lt;/p&gt;</comment>
                    <comment id="27858" author="jafingerhut" created="Fri, 24 Feb 2012 16:36:56 -0600"  >&lt;p&gt;Colin&apos;s patch still applies cleanly to latest master as of Feb 24, 2012.&lt;/p&gt;</comment>
                    <comment id="27989" author="stuart.sierra" created="Fri, 23 Mar 2012 08:32:42 -0500"  >&lt;p&gt;Docstring only. Screened. &lt;/p&gt;</comment>
                    <comment id="29263" author="stuart.sierra" created="Fri, 24 Aug 2012 08:44:01 -0500"  >&lt;p&gt;Rescreened. Still applies on latest master.&lt;/p&gt;</comment>
                    <comment id="29707" author="richhickey" created="Fri, 19 Oct 2012 17:47:35 -0500"  >&lt;p&gt;I&apos;d rather promise nothing than promise this forever.&lt;/p&gt;</comment>
                    <comment id="29714" author="trptcolin" created="Fri, 19 Oct 2012 19:15:01 -0500"  >&lt;p&gt;The second patch avoids promising the return value. For clarity, it does mention the lack of guarantee instead of omitting any mention.&lt;/p&gt;</comment>
                    <comment id="30070" author="redinger" created="Tue, 27 Nov 2012 17:33:19 -0600"  >&lt;p&gt;Patch applies cleanly and makes documentation more correct.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="10063" name="0001-Fix-docstring-for-file-refs-196.patch" size="767" author="trptcolin" created="Fri, 31 Dec 2010 14:41:51 -0600" />
                    <attachment id="11582" name="0002-Don-t-promise-the-value-of-file-in-the-REPL.patch" size="786" author="trptcolin" created="Fri, 19 Oct 2012 19:15:01 -0500" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_10002" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Approval</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10007">Ok</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-124] GC  Issue 120: Determine mechanism for controlling automatic shutdown of Agents, with a default policy and mechanism for changing that policy as needed</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-124</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;Reported by cemer...@snowtide.com, Jun 01, 2009

There has been intermittent chatter over the past months from a couple of
people on the group (e.g.
http:&lt;span class=&quot;code-comment&quot;&gt;//groups.google.com/group/clojure/browse_thread/thread/409054e3542adc1f)
&lt;/span&gt;and in #clojure about some clojure scripts hanging, either &lt;span class=&quot;code-keyword&quot;&gt;for&lt;/span&gt; a constant
time (usually reported as a minute or so with no CPU util) or seemingly
forever (or until someone kills the process).

I just hit a similar situation in our compilation process, which invokes
clojure.lang.Compile from ant.  The build process &lt;span class=&quot;code-keyword&quot;&gt;for&lt;/span&gt; &lt;span class=&quot;code-keyword&quot;&gt;this&lt;/span&gt; particular
project had taken 15 second or so, but after adding a couple of pmap calls,
that build time jumped to ~1:15, with roughly zero CPU utilization over the
course of that last minute.

Adding a call to Agent.shutdown() in the &lt;span class=&quot;code-keyword&quot;&gt;finally&lt;/span&gt; block in
clojure.lang.Compile/main resolved the problem; a patch including &lt;span class=&quot;code-keyword&quot;&gt;this&lt;/span&gt;
change is attached.  I wouldn&apos;t suspect anyone would have any issues with
such a change.

-----
In general, it doesn&apos;t seem like everyone should keep tripping over &lt;span class=&quot;code-keyword&quot;&gt;this&lt;/span&gt;
problem in different directions.  It&apos;s a very difficult thing to debug &lt;span class=&quot;code-keyword&quot;&gt;if&lt;/span&gt;
you&apos;re not attuned to how clojure&apos;s concurrency primitives work under the
hood, and I would bet that newer users would be particularly affected.

After discussion in #clojure, rhickey suggested adding a
*auto-shutdown-agents* &lt;span class=&quot;code-keyword&quot;&gt;var&lt;/span&gt;, which:

- &lt;span class=&quot;code-keyword&quot;&gt;if&lt;/span&gt; &lt;span class=&quot;code-keyword&quot;&gt;true&lt;/span&gt; when exiting one of the main entry points (clojure.main, or the
legacy script/repl entry points), Agent.shutdown() would be called,
allowing &lt;span class=&quot;code-keyword&quot;&gt;for&lt;/span&gt; the clean exit of the application

- would be bound by &lt;span class=&quot;code-keyword&quot;&gt;default&lt;/span&gt; to &lt;span class=&quot;code-keyword&quot;&gt;true&lt;/span&gt;

- could be easily set to &lt;span class=&quot;code-keyword&quot;&gt;false&lt;/span&gt; &lt;span class=&quot;code-keyword&quot;&gt;for&lt;/span&gt; anyone with an advanced use-&lt;span class=&quot;code-keyword&quot;&gt;case&lt;/span&gt; that
requires agents to remain active after the main thread of the application
exits.

This would obviously not help anyone initializing clojure from a different
entry point, but &lt;span class=&quot;code-keyword&quot;&gt;this&lt;/span&gt; may represent the best compromise between
least-surprise and maximal functionality &lt;span class=&quot;code-keyword&quot;&gt;for&lt;/span&gt; advanced users.

------

In addition to the above, it perhaps might be worthwhile to change the
keepalive values used to create the Threadpools used by c.l.Actor&apos;s
Executors.  Currently, Actor uses a &lt;span class=&quot;code-keyword&quot;&gt;default&lt;/span&gt; thread pool executor, which
results in a 60s keepalive.  Lowering &lt;span class=&quot;code-keyword&quot;&gt;this&lt;/span&gt; to something much smaller (1s?
5s?) would additionally minimize the impact of Agent&apos;s threadpools on Java
applications that embed clojure directly (and would therefore not benefit
from *auto-shutdown-agents* as currently conceived, leading to puzzling
&apos;hanging&apos; behaviour).  I&apos;m not in a position to determine what impact &lt;span class=&quot;code-keyword&quot;&gt;this&lt;/span&gt;
would have on performance due to thread churn, but it would at least
minimize what would be perceived as undesirable behaviour by users that are
less familiar with the implementation details of Agent and code that
depends on it.

Comment 1  by cemer...@snowtide.com, Jun 01, 2009

Just FYI, I&apos;d be happy to provide patches &lt;span class=&quot;code-keyword&quot;&gt;for&lt;/span&gt; either of the suggestions mentioned
above...&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;</description>
                <environment></environment>
            <key id="13521">CLJ-124</key>
            <summary>GC  Issue 120: Determine mechanism for controlling automatic shutdown of Agents, with a default policy and mechanism for changing that policy as needed</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="cemerick">Chas Emerick</assignee>
                                <reporter username="cemerick">Chas Emerick</reporter>
                        <labels>
                    </labels>
                <created>Wed, 17 Jun 2009 23:24:00 -0500</created>
                <updated>Fri, 12 Apr 2013 09:52:24 -0500</updated>
                                                    <fixVersion>Release 1.6</fixVersion>
                                        <due></due>
                    <votes>3</votes>
                        <watches>5</watches>
                        <comments>
                    <comment id="22862" author="importer" created="Tue, 24 Aug 2010 00:45:00 -0500"  >&lt;p&gt;Converted from &lt;a href=&quot;http://www.assembla.com/spaces/clojure/tickets/124&quot;&gt;http://www.assembla.com/spaces/clojure/tickets/124&lt;/a&gt;&lt;br/&gt;
Attachments:&lt;br/&gt;
compile-agent-shutdown.patch - &lt;a href=&quot;https://www.assembla.com/spaces/clojure/documents/a56S2ow4ur3O2PeJe5afGb/download/a56S2ow4ur3O2PeJe5afGb&quot;&gt;https://www.assembla.com/spaces/clojure/documents/a56S2ow4ur3O2PeJe5afGb/download/a56S2ow4ur3O2PeJe5afGb&lt;/a&gt;&lt;br/&gt;
124-compilation.diff - &lt;a href=&quot;https://www.assembla.com/spaces/clojure/documents/aqn0IGxZSr3RUGeJe5aVNr/download/aqn0IGxZSr3RUGeJe5aVNr&quot;&gt;https://www.assembla.com/spaces/clojure/documents/aqn0IGxZSr3RUGeJe5aVNr/download/aqn0IGxZSr3RUGeJe5aVNr&lt;/a&gt;&lt;/p&gt;</comment>
                    <comment id="22863" author="importer" created="Tue, 24 Aug 2010 00:45:00 -0500"  >&lt;p&gt;oranenj said: [&lt;a href=&quot;file:a56S2ow4ur3O2PeJe5afGb&quot;&gt;file:a56S2ow4ur3O2PeJe5afGb&lt;/a&gt;]&lt;/p&gt;</comment>
                    <comment id="22864" author="importer" created="Tue, 24 Aug 2010 00:45:00 -0500"  >&lt;p&gt;richhickey said: Updating tickets (#8, #19, #30, #31, #126, #17, #42, #47, #50, #61, #64, #69, #71, #77, #79, #84, #87, #89, #96, #99, #103, #107, #112, #113, #114, #115, #118, #119, #121, #122, #124)&lt;/p&gt;</comment>
                    <comment id="22865" author="importer" created="Tue, 24 Aug 2010 00:45:00 -0500"  >&lt;p&gt;cemerick said: (In [&lt;span class=&quot;error&quot;&gt;&amp;#91;r:fa3d24973fc415b35ae6ec8d84b61ace76bd4133&amp;#93;&lt;/span&gt;]) Add a call to Agent.shutdown() at the end of clojure.lang.Compile/main Refs #124&lt;/p&gt;

&lt;p&gt;Signed-off-by: Chouser &amp;lt;chouser@n01se.net&amp;gt;&lt;/p&gt;

&lt;p&gt;Branch: master&lt;/p&gt;</comment>
                    <comment id="22866" author="importer" created="Tue, 24 Aug 2010 00:45:00 -0500"  >&lt;p&gt;chouser@n01se.net said: I&apos;m closing this ticket to because the attached patch solves a specific problem.  I agree that the idea of an &lt;b&gt;auto-shutdown-agents&lt;/b&gt; var sounds like a positive compromise.  If Rich wants a ticket to track that issue, I think it&apos;d be best to open a new ticket (and perhaps mention this one there) rather than use this ticket to track further changes.&lt;/p&gt;</comment>
                    <comment id="22867" author="importer" created="Tue, 24 Aug 2010 00:45:00 -0500"  >&lt;p&gt;scgilardi said: With both Java 5 and Java 6 on Mac OS X 10.5 Leopard I&apos;m getting an error when compiling with this change present.&lt;/p&gt;

&lt;p&gt;Java 1.5.0_19&lt;br/&gt;
Java 1.6.0_13&lt;/p&gt;

&lt;p&gt;For example, when building clojure using &quot;ant&quot; from within my clone of the clojure repo:&lt;/p&gt;

&lt;p&gt;&lt;span class=&quot;error&quot;&gt;&amp;#91;java&amp;#93;&lt;/span&gt; java.security.AccessControlException: access denied (java.lang.RuntimePermission modifyThread)&lt;br/&gt;
     &lt;span class=&quot;error&quot;&gt;&amp;#91;java&amp;#93;&lt;/span&gt;  at java.security.AccessControlContext.checkPermission(AccessControlContext.java:264)&lt;br/&gt;
     &lt;span class=&quot;error&quot;&gt;&amp;#91;java&amp;#93;&lt;/span&gt;  at java.security.AccessController.checkPermission(AccessController.java:427)&lt;br/&gt;
     &lt;span class=&quot;error&quot;&gt;&amp;#91;java&amp;#93;&lt;/span&gt;  at java.util.concurrent.ThreadPoolExecutor.shutdown(ThreadPoolExecutor.java:894)&lt;br/&gt;
     &lt;span class=&quot;error&quot;&gt;&amp;#91;java&amp;#93;&lt;/span&gt;  at clojure.lang.Agent.shutdown(Agent.java:34)&lt;br/&gt;
     &lt;span class=&quot;error&quot;&gt;&amp;#91;java&amp;#93;&lt;/span&gt;  at clojure.lang.Compile.main(Compile.java:71)&lt;/p&gt;

&lt;p&gt;I reproduced this on two Mac OS X 10.5 machines. I&apos;m not aware of having any enhanced security policies along these lines on my machines. The compile goes fine for me with Java 1.6.0_0 on an Ubuntu box.&lt;/p&gt;</comment>
                    <comment id="22868" author="importer" created="Tue, 24 Aug 2010 00:45:00 -0500"  >&lt;p&gt;chouser@n01se.net said: I had only tested it on my ubuntu box &amp;#8211; looks like that was openjdk 1.6.0_0.  I&apos;ll test again with sun-java5 and sun-java6.&lt;/p&gt;</comment>
                    <comment id="22869" author="importer" created="Tue, 24 Aug 2010 00:45:00 -0500"  >&lt;p&gt;chouser@n01se.net said: 1.6.0_13 worked fine for me on ubuntu, but 1.5.0_18 generated an the exception Steve pasted.  Any suggestions?  Should this patch be backed out until someone has a fix?&lt;/p&gt;</comment>
                    <comment id="22870" author="importer" created="Tue, 24 Aug 2010 00:45:00 -0500"  >&lt;p&gt;achimpassen said: [&lt;a href=&quot;file:aqn0IGxZSr3RUGeJe5aVNr&quot;&gt;file:aqn0IGxZSr3RUGeJe5aVNr&lt;/a&gt;]&lt;/p&gt;</comment>
                    <comment id="22871" author="importer" created="Tue, 24 Aug 2010 00:45:00 -0500"  >&lt;p&gt;chouser@n01se.net said: With Achim&apos;s patch, clojure compiles for me on ubuntu using java 1.5.0_18 from sun, and still works on 1.6.0_13 sun and 1.6.0_0 openjdk.  I don&apos;t know anything about ant or the security error, but this is looking good to me.&lt;/p&gt;</comment>
                    <comment id="22872" author="importer" created="Tue, 24 Aug 2010 00:45:00 -0500"  >&lt;p&gt;achimpassen said: It works for me on 1.6.0_13 and 1.5.0_19 (32 and 64 bit) on OS X 10.5.7.&lt;/p&gt;</comment>
                    <comment id="22873" author="importer" created="Tue, 24 Aug 2010 00:45:00 -0500"  >&lt;p&gt;chouser@n01se.net said: (In [&lt;span class=&quot;error&quot;&gt;&amp;#91;r:895b39dabc17b3fd766fdbac3b0757edb0d4b60d&amp;#93;&lt;/span&gt;]) Rev fa3d2497 causes compile to fail on some VMs &amp;#8211; back it out. Refs #124&lt;/p&gt;

&lt;p&gt;Branch: master&lt;/p&gt;</comment>
                    <comment id="22874" author="importer" created="Tue, 24 Aug 2010 00:45:00 -0500"  >&lt;p&gt;mikehinchey said: I got the same compile error on both 1.5.0_11 and 1.6.0_14 on Windows.  Achim&apos;s patch fixes both.&lt;/p&gt;

&lt;p&gt;See the note for &quot;permissions&quot; on &lt;a href=&quot;http://ant.apache.org/manual/CoreTasks/java.html&quot;&gt;http://ant.apache.org/manual/CoreTasks/java.html&lt;/a&gt; .  I assume ThreadPoolExecutor.shutdown is the problem, it would shutdown the main Ant thread, so Ant disallows that.  Forking avoids the permissions limitation.&lt;/p&gt;

&lt;p&gt;In addition, since the build error still resulted in &quot;BUILD SUCCESSFUL&quot;, I think failonerror=&quot;true&quot; should also be added to the java call so the build would totally fail for such an error.&lt;/p&gt;</comment>
                    <comment id="22875" author="importer" created="Tue, 24 Aug 2010 00:45:00 -0500"  >&lt;p&gt;chouser@n01se.net said: I don&apos;t know if the &amp;lt;java fork=true&amp;gt; patch is a good idea or not, or if there&apos;s a better way to solve the original problem.&lt;/p&gt;

&lt;p&gt;Chas, I&apos;m kicking back to you, but I guess if you don&apos;t want it you can reassign to &quot;nobody&quot;.&lt;/p&gt;</comment>
                    <comment id="22876" author="importer" created="Tue, 24 Aug 2010 00:45:00 -0500"  >&lt;p&gt;richhickey said: Updating tickets (#8, #42, #113, #2, #20, #94, #96, #104, #119, #124, #127, #149, #162)&lt;/p&gt;</comment>
                    <comment id="22877" author="importer" created="Tue, 24 Aug 2010 00:45:00 -0500"  >&lt;p&gt;shoover said: I&apos;d like to suggest an alternate approach. There are already well-defined and intuitive ways to block on agents and futures. Why not deprecate shutdown-agents and force users to call await and deref if they really want to block? In the pmap situation one would have to evaluate the pmap form.&lt;/p&gt;

&lt;p&gt;The System.exit problem goes away if you configure the threadpools to use daemon threads (call new ThreadPoolExecutor and pass a thread factory that creates threads and sets daemon to true). That way the user has an explicit means of blocking and System.exit won&apos;t hang.&lt;/p&gt;</comment>
                    <comment id="22878" author="importer" created="Tue, 24 Aug 2010 00:45:00 -0500"  >&lt;p&gt;alexdmiller said: I blogged about these issues at:&lt;br/&gt;
&lt;a href=&quot;http://tech.puredanger.com/2010/06/08/clojure-agent-thread-pools/&quot;&gt;http://tech.puredanger.com/2010/06/08/clojure-agent-thread-pools/&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;I think that:&lt;/p&gt;

&lt;ul&gt;
	&lt;li&gt;agent thread pool threads should be named (see ticket &lt;a href=&quot;https://www.assembla.com/spaces/clojure/tickets/378-set-thread-names-on-agent-thread-pools&quot;&gt;#378&lt;/a&gt;)&lt;/li&gt;
	&lt;li&gt;agent thread pools must be daemon threads by default&lt;/li&gt;
	&lt;li&gt;having ways to specify an customized executor pool for an agent send/send-off is essential to customize threading behavior&lt;/li&gt;
	&lt;li&gt;(shutdown-agents) should be either deprecated or made less dangerous&lt;/li&gt;
&lt;/ul&gt;
</comment>
                    <comment id="26565" author="ataggart" created="Mon, 11 Jul 2011 21:33:24 -0500"  >&lt;p&gt;Rich, what is the intention behind using non-daemon threads in the agent pools?&lt;/p&gt;

&lt;p&gt;If it is because daemon threads could terminate before their work is complete, would it be acceptable to &lt;a href=&quot;http://download.oracle.com/javase/1.5.0/docs/api/java/lang/Runtime.html#addShutdownHook(java.lang.Thread)&quot;&gt;add a shutdown hook&lt;/a&gt; to ensure against such premature termination?  Such a shutdown hook could call &lt;tt&gt;Agent.shutdown()&lt;/tt&gt;, then &lt;a href=&quot;http://download.oracle.com/javase/1.5.0/docs/api/java/util/concurrent/ExecutorService.html#awaitTermination(long, java.util.concurrent.TimeUnit)&quot;&gt;&lt;tt&gt;awaitTermination()&lt;/tt&gt;&lt;/a&gt; on the pools.&lt;/p&gt;</comment>
                    <comment id="30069" author="redinger" created="Tue, 27 Nov 2012 15:47:20 -0600"  >&lt;p&gt;Moving this ticket out of approval &quot;OK&quot; status, and dropping the priority. These were Assembla import defaults.&lt;/p&gt;

&lt;p&gt;Also, Chas gets to be the Reporter now.&lt;/p&gt;</comment>
                    <comment id="30072" author="cemerick" created="Tue, 27 Nov 2012 17:56:24 -0600"  >&lt;p&gt;Heh, blast from the past.&lt;/p&gt;

&lt;p&gt;The comment import appears to have set their timestamps to the date of the import, so the conversation is pretty hard to follow, and obviously doesn&apos;t benefit from the intervening years of experience.  In addition, there have been plenty of changes to agents, including some &lt;a href=&quot;https://github.com/clojure/clojure/commit/f5f4faf&quot;&gt;recent enhancements&lt;/a&gt; that address some of the pain points that Alex Miller mentioned above.&lt;/p&gt;

&lt;p&gt;I propose closing this as &apos;invalid&apos; or whatever, and opening one or more new issues to track whatever issues still persist (presumably based on fresh ML discussion, etc).&lt;/p&gt;</comment>
                    <comment id="30073" author="jafingerhut" created="Tue, 27 Nov 2012 18:11:09 -0600"  >&lt;p&gt;Rereading the original description of this ticket, without reading all of the comments that follow, that description is still right on target for the behavior of latest Clojure master today.&lt;/p&gt;

&lt;p&gt;People send messages to the Clojure Google group every couple of months hitting this issue, and one even filed &lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-959&quot; title=&quot;after call to clojure.java.shell/sh, jvm won&amp;#39;t exit&quot;&gt;CLJ-959&lt;/a&gt; because of hitting it.  I have updated the examples on ClojureDocs.org for future, and also for pmap and clojure.java.shell/sh which use future in their implementations, to warn people about this and explain that they should call (shutdown-agents), but making it unnecessary to call shutdown-agents would be even better, at least as the default behavior.  It sounds fine to me to provide a way for experts on thread behavior to change that default behavior if they need to.&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>
                                                                                                        <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-420] Some compiler exceptions erroneously using REPL line numbers.</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-420</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;Certain kinds of errors in loaded source files are coming back tagged with the correct source file, but what seems to be the REPL line number.  &lt;/p&gt;

&lt;p&gt;&lt;a href=&quot;http://groups.google.com/group/clojure/browse_frm/thread/beb36e7228eabd69/a7ef16dcc45834bc?hl=en#a7ef16dcc45834bc&quot;&gt;http://groups.google.com/group/clojure/browse_frm/thread/beb36e7228eabd69/a7ef16dcc45834bc?hl=en#a7ef16dcc45834bc&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;jawolfe@&lt;span class=&quot;error&quot;&gt;&amp;#91;~/Projects/testproj&amp;#93;&lt;/span&gt;: cat &amp;gt; src/test.clj&lt;/p&gt;

&lt;p&gt;bla&lt;br/&gt;
jawolfe@&lt;span class=&quot;error&quot;&gt;&amp;#91;~/Projects/testproj&amp;#93;&lt;/span&gt;: cat &amp;gt; src/test2.clj&lt;/p&gt;

&lt;p&gt;(bla)&lt;br/&gt;
jawolfe@&lt;span class=&quot;error&quot;&gt;&amp;#91;~/Projects/testproj&amp;#93;&lt;/span&gt;: lein repl&lt;br/&gt;
user=&amp;gt; (require &apos;test)&lt;br/&gt;
java.lang.Exception: Unable to resolve symbol: bla in this context&lt;br/&gt;
(test.clj:1)&lt;br/&gt;
user=&amp;gt; (require &apos;test)a&lt;br/&gt;
java.lang.Exception: Unable to resolve symbol: bla in this context&lt;br/&gt;
(test.clj:2)&lt;br/&gt;
user=&amp;gt; (require &apos;test)&lt;br/&gt;
java.lang.Exception: Unable to resolve symbol: bla in this context&lt;br/&gt;
(test.clj:3)&lt;br/&gt;
user=&amp;gt; (require &apos;test2)&lt;br/&gt;
java.lang.Exception: Unable to resolve symbol: bla in this context&lt;br/&gt;
(test2.clj:2)&lt;br/&gt;
user=&amp;gt; (require &apos;test2)&lt;br/&gt;
java.lang.Exception: Unable to resolve symbol: bla in this context&lt;br/&gt;
(test2.clj:2)&lt;br/&gt;
user=&amp;gt; (require &apos;test2)&lt;br/&gt;
java.lang.Exception: Unable to resolve symbol: bla in this context&lt;br/&gt;
(test2.clj:2)&lt;br/&gt;
user=&amp;gt; (require &apos;test)&lt;br/&gt;
java.lang.Exception: Unable to resolve symbol: bla in this context&lt;br/&gt;
(test.clj:7)&lt;br/&gt;
user=&amp;gt;&lt;/p&gt;</description>
                <environment></environment>
            <key id="13817">CLJ-420</key>
            <summary>Some compiler exceptions erroneously using REPL line 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="aredington">Alexander Redington</reporter>
                        <labels>
                    </labels>
                <created>Sun, 8 Aug 2010 04:46:00 -0500</created>
                <updated>Fri, 12 Apr 2013 09:42:02 -0500</updated>
                                    <version>Approved Backlog</version>
                                <fixVersion>Release 1.6</fixVersion>
                                        <due></due>
                    <votes>0</votes>
                        <watches>1</watches>
                        <comments>
                    <comment id="24177" author="importer" created="Tue, 28 Sep 2010 21:59:00 -0500"  >&lt;p&gt;Converted from &lt;a href=&quot;http://www.assembla.com/spaces/clojure/tickets/420&quot;&gt;http://www.assembla.com/spaces/clojure/tickets/420&lt;/a&gt;&lt;/p&gt;</comment>
                    <comment id="24178" author="importer" created="Tue, 28 Sep 2010 21:59:00 -0500"  >&lt;p&gt;stu said: Updating tickets (#427, #426, #421, #420, #397)&lt;/p&gt;</comment>
                    <comment id="24179" author="importer" created="Tue, 28 Sep 2010 21:59:00 -0500"  >&lt;p&gt;stu said: Updating tickets (#429, #437, #397, #420)&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-1058] StackOverflowError on exception in reducef for PersistentHashMap fold</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1058</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;If reducef throws an exception, the PHM fold code can descend into an infinite loop, causing a stack overflow which masks the problem. This situation is commented &quot;aargh&quot; in PersistentHashMap.java line 444 (as of 412a51d).&lt;/p&gt;

&lt;p&gt;To reproduce:&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; (require &apos;[clojure.core.reducers :as r])
nil
user&amp;gt; (r/fold (fn ([]) ([ret k v] (+ 3 &lt;span class=&quot;code-quote&quot;&gt;&quot;foo&quot;&lt;/span&gt;) ret)) (into {} (map (juxt identity identity) (range 10000))))
;; boom&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;This results in a stack like: &lt;a href=&quot;https://raw.github.com/gist/3bab917287a7fd635a84/f38bfe3e270556e467f3fc02062af7ea10781390/gistfile1.txt&quot;&gt;https://raw.github.com/gist/3bab917287a7fd635a84/f38bfe3e270556e467f3fc02062af7ea10781390/gistfile1.txt&lt;/a&gt;&lt;/p&gt;</description>
                <environment>Clojure 1.5.0-alpha4, Sun Java 1.6.0_35, with [org.codehaus.jsr166-mirror/jsr166y &amp;quot;1.7.0&amp;quot;]</environment>
            <key id="15668">CLJ-1058</key>
            <summary>StackOverflowError on exception in reducef for PersistentHashMap fold</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="tomoj">Tom Jack</reporter>
                        <labels>
                    </labels>
                <created>Sun, 2 Sep 2012 17:20:02 -0500</created>
                <updated>Fri, 12 Apr 2013 09:42:02 -0500</updated>
                                    <version>Release 1.5</version>
                                <fixVersion>Release 1.6</fixVersion>
                                        <due></due>
                    <votes>0</votes>
                        <watches>1</watches>
                        <comments>
                    <comment id="30124" author="halgari" created="Fri, 30 Nov 2012 15:40:59 -0600"  >&lt;p&gt;Verified as a bug. &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-701] Compiler loses &apos;loop&apos;s return type in some cases</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-701</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;(set! *warn-on-reflection* &lt;span class=&quot;code-keyword&quot;&gt;true&lt;/span&gt;)
(fn [] (loop [b 0] (recur (loop [a 1] a))))&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;Generates the following warnings:&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;recur arg for primitive local: b is not matching primitive, had: Object, needed: long
Auto-boxing loop arg: b
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;This is interesting for several reasons.  For one, if the arg to &lt;tt&gt;recur&lt;/tt&gt; is a &lt;tt&gt;let&lt;/tt&gt; form, there is no 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;(fn [] (loop [b 0] (recur (let [a 1] a))))&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;Also, the compiler appears to understand the return type of &lt;tt&gt;loop&lt;/tt&gt; forms just fine:&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;(use &apos;[clojure.contrib.repl-utils :only [expression-info]])
(expression-info &apos;(loop [a 1] a))
;=&amp;gt; {:class &lt;span class=&quot;code-object&quot;&gt;long&lt;/span&gt;, :primitive? &lt;span class=&quot;code-keyword&quot;&gt;true&lt;/span&gt;}&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;The problem can of course be worked around using an explicit cast on the &lt;tt&gt;loop&lt;/tt&gt; form:&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;(fn [] (loop [b 0] (recur (&lt;span class=&quot;code-object&quot;&gt;long&lt;/span&gt; (loop [a 1] a)))))&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;Reported by leafw in IRC: &lt;a href=&quot;http://clojure-log.n01se.net/date/2011-01-03.html#10:31&quot;&gt;http://clojure-log.n01se.net/date/2011-01-03.html#10:31&lt;/a&gt;&lt;/p&gt;</description>
                <environment>Clojure commit 9052ca1854b7b6202dba21fe2a45183a4534c501, version 1.3.0-master-SNAPSHOT</environment>
            <key id="14310">CLJ-701</key>
            <summary>Compiler loses &apos;loop&apos;s return type in some cases</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="chouser@n01se.net">Chouser</reporter>
                        <labels>
                    </labels>
                <created>Mon, 3 Jan 2011 10:56:07 -0600</created>
                <updated>Fri, 12 Apr 2013 09:42:00 -0500</updated>
                                    <version>Approved Backlog</version>
                                <fixVersion>Release 1.6</fixVersion>
                                        <due></due>
                    <votes>0</votes>
                        <watches>2</watches>
                        <comments>
                    <comment id="26081" author="a_strange_guy" created="Mon, 3 Jan 2011 16:36:27 -0600"  >&lt;p&gt;The problem is that a &apos;loop form gets converted into an anonymous fn that gets called immediately, when the loop is in a expression context (eg. its return value is needed, but not as the return value of a method/fn).&lt;/p&gt;

&lt;p&gt;so&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;(fn [] (loop [b 0] (recur (loop [a 1] a))))
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt; 
&lt;p&gt;gets converted into&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;(fn [] (loop [b 0] (recur ((fn [] (loop [a 1] a))))))
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;see the code in the compiler:&lt;br/&gt;
&lt;a href=&quot;http://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/Compiler.java#L5572&quot;&gt;http://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/Compiler.java#L5572&lt;/a&gt;&lt;/p&gt;


&lt;p&gt;this conversion already bites you if you have mutable fields in a deftype and want to &apos;set! them in a loop&lt;/p&gt;

&lt;p&gt;&lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-274&quot;&gt;http://dev.clojure.org/jira/browse/CLJ-274&lt;/a&gt;&lt;/p&gt;</comment>
                    <comment id="30009" author="cgrand" created="Fri, 23 Nov 2012 02:28:14 -0600"  >&lt;p&gt;loops in expression context are lifted into fns because else Hotspot doesn&apos;t optimize them.&lt;br/&gt;
This causes several problems:&lt;/p&gt;
&lt;ul&gt;
	&lt;li&gt;type inference doesn&apos;t propagate outside of the loop&lt;span class=&quot;error&quot;&gt;&amp;#91;1&amp;#93;&lt;/span&gt;&lt;/li&gt;
	&lt;li&gt;the return value is never a primitive&lt;/li&gt;
	&lt;li&gt;mutable fields are inaccessible&lt;/li&gt;
	&lt;li&gt;surprise allocation of one closure objects each time the loop is entered.&lt;/li&gt;
&lt;/ul&gt;


&lt;p&gt;Adressing all those problems isn&apos;t easy. &lt;br/&gt;
One can compute the type of the loop and emit a type hint but it works only with reference types. To make it works with primitive, primitie fns aren&apos;t enough since they return only long/double: you have to add explicit casts.&lt;br/&gt;
So solving the first two points can be done in a rather lccal way.&lt;br/&gt;
The two other points require more impacting changes, the goal would be to emit a method rather than a fn. So it means at the very least changing ObjExpr and adding a new subclassof  ObjMethod.&lt;/p&gt;

&lt;p&gt;&lt;span class=&quot;error&quot;&gt;&amp;#91;1&amp;#93;&lt;/span&gt; beware of &lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-1111&quot; title=&quot;Loops returning primtives are boxed even in return position&quot;&gt;&lt;del&gt;CLJ-1111&lt;/del&gt;&lt;/a&gt; when testing. &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-1105] defrecord classes implement IPersistentCollection but not .empty, clojure.walk assumes collections support empty</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1105</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;Using clojure.walk functions fails surprisingly for data containing records defined with defrecord:&lt;/p&gt;

&lt;p&gt;user=&amp;gt; (defrecord Foo &lt;span class=&quot;error&quot;&gt;&amp;#91;x&amp;#93;&lt;/span&gt;)&lt;br/&gt;
user.Foo&lt;br/&gt;
user=&amp;gt; (def f (Foo. :x))&lt;br/&gt;
#&apos;user/f&lt;br/&gt;
user=&amp;gt; (use &apos;clojure.walk)&lt;br/&gt;
nil&lt;br/&gt;
user=&amp;gt; (postwalk identity {:foo f})&lt;br/&gt;
UnsupportedOperationException Can&apos;t create empty: user.Foo  user.Foo (NO_SOURCE_FILE:1)&lt;/p&gt;

&lt;p&gt;This seems to be because clojure.walk/walk guards a call to (empty form) with a (coll? form) check. The check succeeds because records implement IPersistentCollection, but (empty form) throws an exception. This looks to me like a bug in clojure.walk (it should check records separately and either treat them as atomic or implement a way of walking through them) but perhaps it is a sign of some unclarity in the contract of collections.&lt;/p&gt;</description>
                <environment></environment>
            <key id="15817">CLJ-1105</key>
            <summary>defrecord classes implement IPersistentCollection but not .empty, clojure.walk assumes collections support empty</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="jks">Jouni K. Sepp&#228;nen</reporter>
                        <labels>
                    </labels>
                <created>Thu, 8 Nov 2012 08:20:52 -0600</created>
                <updated>Fri, 12 Apr 2013 09:42:00 -0500</updated>
                                    <version>Release 1.4</version>
                                <fixVersion>Release 1.6</fixVersion>
                                        <due></due>
                    <votes>1</votes>
                        <watches>4</watches>
                        <comments>
                    <comment id="29912" author="bronsa" created="Thu, 8 Nov 2012 14:35:42 -0600"  >&lt;p&gt;maybe clojure should follow clojurescript&apos;s footsteps and move empty out of IPersistentCollection and create an&lt;br/&gt;
interface IEmptyableCollection extends IPersistentCollection {
  IEmptyableCollection empty();
}&lt;/p&gt;</comment>
                    <comment id="30029" author="stu" created="Sun, 25 Nov 2012 18:39:22 -0600"  >&lt;p&gt;Can whoever claims this please consider walk&apos;s behavior in the face of all different collection types? I think it also fails with Java collections. &lt;/p&gt;

&lt;p&gt;Also, the collection partitioning code in clojure.data may be of use.&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-1154] Compile.java closes out preventing java from reporting exceptions</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1154</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;I was trying to compile a project that has some native dependencies.  I am using clojure-maven-plugin version 1.3.13 with Maven 2.0.  I forgot to set java.library.path properly so that the native library could be found, and only got an error of&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;[INFO] ------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------
[INFO] Clojure failed.
[INFO] ------------------------------------------------------------------------
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;I traced this down to Compile.java, where it is flushing and closing &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;out&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt; in the finally block.  The JVM uses out to write out a stack trace for any uncaught exceptions.  When out is closed it is unable to write out the stack trace for the UnsatisfiedLinkError that was being thrown.  This made it very difficult to debug what was happening.&lt;/p&gt;</description>
                <environment></environment>
            <key id="15983">CLJ-1154</key>
            <summary>Compile.java closes out preventing java from reporting exceptions</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="revans2">Robert (Bobby) Evans</reporter>
                        <labels>
                    </labels>
                <created>Thu, 31 Jan 2013 13:04:08 -0600</created>
                <updated>Fri, 12 Apr 2013 09:31:03 -0500</updated>
                                    <version>Release 1.4</version>
                                <fixVersion>Release 1.5</fixVersion>
                <fixVersion>Release 1.6</fixVersion>
                                        <due></due>
                    <votes>1</votes>
                        <watches>1</watches>
                        <comments>
                    <comment id="30677" author="stu" created="Fri, 1 Mar 2013 10:45:51 -0600"  >&lt;p&gt;I have encountered this problem as well.  Did not verify the explanation, but sounds reasonable.&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-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-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-1179] distinct? does not accept zero arguments</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1179</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;&lt;tt&gt;distinct?&lt;/tt&gt; cannot be invoked with zero arguments. When using the pattern &lt;tt&gt;(apply distinct? x)&lt;/tt&gt;, this is bothersome as you have to check whether x is empty or not. It is also logical that &lt;tt&gt;distinct?&lt;/tt&gt; should return &lt;tt&gt;true&lt;/tt&gt; if no arguments are given, since there are no duplicates.&lt;/p&gt;

&lt;h3&gt;&lt;a name=&quot;What%28smallsetof%29stepswillreproducetheproblem%3F&quot;&gt;&lt;/a&gt;What (small set of) steps will reproduce the problem?&lt;/h3&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 distinct? [])
ArityException Wrong number of args (0) passed to: core$distinct-QMARK-  clojure.lang.AFn.throwArity (AFn.java:437)
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;h3&gt;&lt;a name=&quot;Whatistheexpectedoutput%3FWhatdoyouseeinstead%3F&quot;&gt;&lt;/a&gt;What is the expected output? What do you see instead?&lt;/h3&gt;
&lt;p&gt;I would expect &lt;tt&gt;distinct?&lt;/tt&gt; to return true whenever given zero arguments.&lt;/p&gt;

&lt;h3&gt;&lt;a name=&quot;Whatversionareyouusing%3F&quot;&gt;&lt;/a&gt;What version are you using?&lt;/h3&gt;
&lt;p&gt;This was tested under Clojure 1.4 and Clojure 1.5.&lt;/p&gt;</description>
                <environment></environment>
            <key id="16068">CLJ-1179</key>
            <summary>distinct? does not accept zero arguments</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="6" iconUrl="http://dev.clojure.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="2">Declined</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="hypirion">Jean Niklas L&apos;orange</reporter>
                        <labels>
                        <label>bug</label>
                    </labels>
                <created>Sat, 9 Mar 2013 05:46:03 -0600</created>
                <updated>Fri, 12 Apr 2013 09:12:55 -0500</updated>
                    <resolved>Fri, 12 Apr 2013 09:12:55 -0500</resolved>
                            <version>Release 1.4</version>
                <version>Release 1.5</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>1</watches>
                        <comments>
                    <comment id="30719" author="hypirion" created="Sat, 9 Mar 2013 06:08:41 -0600"  >&lt;p&gt;Attached the straightforward patch which solves this issue.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="11902" name="clj-1179-distinct-zero-arguments.txt" size="603" author="hypirion" created="Sat, 9 Mar 2013 06:08:41 -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="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-1005] Use transient map in zipmap</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1005</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;The attached patch changes zipmap to use a transient map internally. The definition is also moved so that it resides below that of #&apos;transient. The original definition is commented out (like that of #&apos;into).&lt;/p&gt;</description>
                <environment></environment>
            <key id="15491">CLJ-1005</key>
            <summary>Use transient map in zipmap</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="aaron">Aaron Bedra</assignee>
                                <reporter username="michalmarczyk">Micha&#322; Marczyk</reporter>
                        <labels>
                    </labels>
                <created>Wed, 30 May 2012 02:55:43 -0500</created>
                <updated>Thu, 11 Apr 2013 18:19:28 -0500</updated>
                                    <version>Release 1.6</version>
                                <fixVersion>Release 1.6</fixVersion>
                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                        <comments>
                    <comment id="29156" author="aaron" created="Tue, 14 Aug 2012 21:24:43 -0500"  >&lt;p&gt;Why is the old implementation left and commented out? If we are going to move to a new implementation, the old one should be removed.&lt;/p&gt;</comment>
                    <comment id="29164" author="michalmarczyk" created="Wed, 15 Aug 2012 04:17:00 -0500"  >&lt;p&gt;As mentioned in the ticket description, the previously attached patch follows the pattern of into whose non-transient-enabled definition is left in core.clj with a #_ in front &amp;#8211; I wasn&apos;t sure if that&apos;s something desirable in all cases.&lt;/p&gt;

&lt;p&gt;Here&apos;s a new patch with the old impl removed.&lt;/p&gt;</comment>
                    <comment id="29170" author="jafingerhut" created="Wed, 15 Aug 2012 10:37:04 -0500"  >&lt;p&gt;Thanks for the updated patch, Michal.  Sorry to raise such a minor issue, but would you mind using a different name for the updated patch?  I know JIRA can handle multiple attached files with the same name, but my prescreening code isn&apos;t quite that talented yet, and it can lead to confusion when discussing patches.&lt;/p&gt;</comment>
                    <comment id="29171" author="michalmarczyk" created="Wed, 15 Aug 2012 10:42:40 -0500"  >&lt;p&gt;Thanks for the heads-up, Andy! I&apos;ve reattached the new patch under a new name.&lt;/p&gt;</comment>
                    <comment id="29197" author="jafingerhut" created="Thu, 16 Aug 2012 20:24:44 -0500"  >&lt;p&gt;Presumptuously changing Approval from Incomplete back to None after the Michal&apos;s updated patch was added, addressing the reason the ticket was marked incomplete.&lt;/p&gt;</comment>
                    <comment id="30930" author="aaron" created="Thu, 11 Apr 2013 17:32:24 -0500"  >&lt;p&gt;The patch looks good and applies cleanly. Are there additional tests that we should run to verify that this is providing the improvement we think it is. Also, is there a discussion somewhere that started this ticket? There isn&apos;t a lot of context here.&lt;/p&gt;</comment>
                    <comment id="30932" author="michalmarczyk" created="Thu, 11 Apr 2013 18:19:28 -0500"  >&lt;p&gt;Hi Aaron,&lt;/p&gt;

&lt;p&gt;Thanks for looking into this!&lt;/p&gt;

&lt;p&gt;From what I&apos;ve been able to observe, this change hugely improves &lt;tt&gt;zipmap&lt;/tt&gt; times for large maps. For small maps, there is a small improvement. Here are two basic Criterium benchmarks (&lt;tt&gt;transient-zipmap&lt;/tt&gt; defined at the REPL as in the patch):&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;;;; large map
user=&amp;gt; (def xs (range 16384))
#&apos;user/xs
user=&amp;gt; (last xs)
16383
user=&amp;gt; (c/bench (zipmap xs xs))
Evaluation count : 13920 in 60 samples of 232 calls.
             Execution time mean : 4.329635 ms
    Execution time std-deviation : 77.791989 us
   Execution time lower quantile : 4.215050 ms ( 2.5%)
   Execution time upper quantile : 4.494120 ms (97.5%)
nil
user=&amp;gt; (c/bench (transient-zipmap xs xs))
Evaluation count : 21180 in 60 samples of 353 calls.
             Execution time mean : 2.818339 ms
    Execution time std-deviation : 110.751493 us
   Execution time lower quantile : 2.618971 ms ( 2.5%)
   Execution time upper quantile : 3.025812 ms (97.5%)

Found 2 outliers in 60 samples (3.3333 %)
	low-severe	 2 (3.3333 %)
 Variance from outliers : 25.4675 % Variance is moderately inflated by outliers
nil

;;; small map
user=&amp;gt; (def ys (range 16))
#&apos;user/ys
user=&amp;gt; (last ys)
15
user=&amp;gt; (c/bench (zipmap ys ys))
Evaluation count : 16639020 in 60 samples of 277317 calls.
             Execution time mean : 3.803683 us
    Execution time std-deviation : 88.431220 ns
   Execution time lower quantile : 3.638146 us ( 2.5%)
   Execution time upper quantile : 3.935160 us (97.5%)
nil
user=&amp;gt; (c/bench (transient-zipmap ys ys))
Evaluation count : 18536880 in 60 samples of 308948 calls.
             Execution time mean : 3.412992 us
    Execution time std-deviation : 81.338284 ns
   Execution time lower quantile : 3.303888 us ( 2.5%)
   Execution time upper quantile : 3.545549 us (97.5%)
nil
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;Clearly the semantics are preserved provided transients satisfy their contract.&lt;/p&gt;

&lt;p&gt;I think I might not have started a ggroup thread for this, sorry.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="11432" name="0001-Use-transient-map-in-zipmap.2.patch" size="1722" author="michalmarczyk" created="Wed, 15 Aug 2012 10:40:53 -0500" />
                    <attachment id="11269" name="0001-Use-transient-map-in-zipmap.patch" size="1281" author="michalmarczyk" created="Wed, 30 May 2012 02:55:43 -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-935] clojure.string/trim uses different defn of whitespace as triml, trimr</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-935</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;clojure.string/triml and trimr use Character/isWhitespace to determine whether a character is whitespace, but trim uses some other definition of white space character.  For example:&lt;/p&gt;

&lt;p&gt;user=&amp;gt; (use &apos;clojure.string)&lt;br/&gt;
nil&lt;br/&gt;
user=&amp;gt; (def s &quot;  \u2002  foo&quot;)&lt;br/&gt;
#&apos;user/s&lt;br/&gt;
user=&amp;gt; (trim s)&lt;br/&gt;
&quot;?  foo&quot;&lt;br/&gt;
user=&amp;gt; (triml s)&lt;br/&gt;
&quot;foo&quot;&lt;/p&gt;

&lt;p&gt;The attached patch changes trim to use Character/isWhitespace.  I suppose other possibilities are to change triml and trimr to use trim&apos;s notion of whitespace, whatever that is, or to just leave these functions inconsistent with each other.  It does seem that it would be a nice property that (trim s) is equal to (triml (trimr s)) for all strings.&lt;/p&gt;

&lt;p&gt;The patch also changes triml to only call .length on s once.&lt;/p&gt;</description>
                <environment></environment>
            <key id="15237">CLJ-935</key>
            <summary>clojure.string/trim uses different defn of whitespace as triml, trimr</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="aaron">Aaron Bedra</assignee>
                                <reporter username="jafingerhut">Andy Fingerhut</reporter>
                        <labels>
                    </labels>
                <created>Tue, 21 Feb 2012 13:29:54 -0600</created>
                <updated>Thu, 11 Apr 2013 17:36:32 -0500</updated>
                                    <version>Release 1.6</version>
                                <fixVersion>Release 1.6</fixVersion>
                                        <due></due>
                    <votes>0</votes>
                        <watches>2</watches>
                        <comments>
                    <comment id="28741" author="stu" created="Fri, 8 Jun 2012 10:22:17 -0500"  >&lt;p&gt;Question for Rich: do we want to be consistent across the different trim fns (per this patch) or consistent with Java, which uses one definition of whitespace in Character/isWhitespace, and a different definition in String/trim?&lt;/p&gt;</comment>
                    <comment id="28742" author="stu" created="Fri, 8 Jun 2012 10:22:59 -0500"  >&lt;p&gt;Question for Andy: why the (int ...) forms, when Clojure only works with primitive longs?&lt;/p&gt;</comment>
                    <comment id="28743" author="jafingerhut" created="Fri, 8 Jun 2012 10:33:54 -0500"  >&lt;p&gt;Answer for Stuart: Looks like I was preserving the (int ...) form that was in triml before, perhaps somewhat mindlessly.  Depending on Rich&apos;s answer, I can update the patch if desired.&lt;/p&gt;</comment>
                    <comment id="30931" author="aaron" created="Thu, 11 Apr 2013 17:34:32 -0500"  >&lt;p&gt;Bump on the discussion. This ticket seems blocked until we make a decision.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="10937" name="fix-trim-fns-different-whitespace-patch.txt" size="2731" author="jafingerhut" created="Tue, 21 Feb 2012 13:29: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-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-1196] eval of defrecord instance with no fields produces {}, not itself</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1196</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;user&amp;gt; (defrecord Foo [])&lt;br/&gt;
user.Foo&lt;br/&gt;
user&amp;gt; (Foo.)&lt;br/&gt;
#user.Foo{}&lt;br/&gt;
user&amp;gt; (eval (Foo.))&lt;br/&gt;
{}&lt;/p&gt;

&lt;p&gt;user&amp;gt; (defrecord Foo &lt;span class=&quot;error&quot;&gt;&amp;#91;a b&amp;#93;&lt;/span&gt;)&lt;br/&gt;
user.Foo&lt;br/&gt;
user&amp;gt; (eval (Foo. 1 2))&lt;br/&gt;
#user.Foo{:a 1, :b 2}&lt;/p&gt;

&lt;p&gt;As you can see, evaluating the record with no fields loses the type information.  This came up in code that uses records to describe argument schema information for functions in a macro, with no direct use of &apos;eval&apos;.  It is unexpected because of the inconsistency between empty and non-empty defrecords, and because the Clojure docs say &apos;Any object other than those discussed above will evaluate to itself.&apos;  &lt;/p&gt;

&lt;p&gt;&lt;a href=&quot;http://clojure.org/evaluation&quot;&gt;http://clojure.org/evaluation&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;I&apos;m happy to elaborate on the use case if there are questions.&lt;/p&gt;
</description>
                <environment>Mac OS X Clojure 1.5.1</environment>
            <key id="16135">CLJ-1196</key>
            <summary>eval of defrecord instance with no fields produces {}, not itself</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="6" iconUrl="http://dev.clojure.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="3">Duplicate</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="jawolfe">Jason Wolfe</reporter>
                        <labels>
                    </labels>
                <created>Wed, 10 Apr 2013 01:55:04 -0500</created>
                <updated>Wed, 10 Apr 2013 11:42:33 -0500</updated>
                    <resolved>Wed, 10 Apr 2013 11:42:33 -0500</resolved>
                            <version>Release 1.5</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>1</watches>
                        <comments>
                    <comment id="30921" author="bronsa" created="Wed, 10 Apr 2013 05:11:17 -0500"  >&lt;p&gt;I think this is a duplicate of &lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-1093&quot;&gt;http://dev.clojure.org/jira/browse/CLJ-1093&lt;/a&gt;&lt;/p&gt;</comment>
                    <comment id="30923" author="jawolfe" created="Wed, 10 Apr 2013 10:51:29 -0500"  >&lt;p&gt;You are right, sorry for the duplication.  I searched for empty record in JIRA and somehow missed that ticket.&lt;/p&gt;</comment>
                    <comment id="30924" author="jafingerhut" created="Wed, 10 Apr 2013 11:42:33 -0500"  >&lt;p&gt;Close as duplicate of &lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-1093&quot; title=&quot;Empty record literals gets incorrectly evaluated to array-maps&quot;&gt;CLJ-1093&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-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-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-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-1194] Typo in core.reducers</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1194</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;As far as I can say, there is a typo in core.reducers (and therefore core.reducers/monoid is unusable in 1.5.1):&lt;/p&gt;

&lt;p&gt;&lt;a href=&quot;https://github.com/clojure/clojure/blob/master/src/clj/clojure/core/reducers.clj#L321&quot;&gt;https://github.com/clojure/clojure/blob/master/src/clj/clojure/core/reducers.clj#L321&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;(fn m &amp;lt;-- &lt;span class=&quot;code-keyword&quot;&gt;this&lt;/span&gt;
    ([] (ctor))
    ([a b] (op a b))))&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;Should I submit a patch to fix this?&lt;/p&gt;</description>
                <environment></environment>
            <key id="16133">CLJ-1194</key>
            <summary>Typo in core.reducers</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="6" iconUrl="http://dev.clojure.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="2">Declined</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="si14">Dmitry Groshev</reporter>
                        <labels>
                    </labels>
                <created>Mon, 8 Apr 2013 14:54:56 -0500</created>
                <updated>Tue, 9 Apr 2013 04:49:58 -0500</updated>
                    <resolved>Tue, 9 Apr 2013 04:49:58 -0500</resolved>
                            <version>Release 1.5</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                        <comments>
                    <comment id="30908" author="gshayban" created="Mon, 8 Apr 2013 15:09:36 -0500"  >&lt;p&gt;I guess you didn&apos;t try to actually &lt;b&gt;use&lt;/b&gt; the function to see if it is actually broken...&lt;/p&gt;

&lt;p&gt;m is not a argument vector, those are below in the function clauses.&lt;/p&gt;</comment>
                    <comment id="30909" author="si14" created="Mon, 8 Apr 2013 15:26:24 -0500"  >&lt;p&gt;I did, but as it turns out the error was somewhere else and I can&apos;t reproduce it within a &quot;clean&quot; environment. Sorry for this hasty ticket.&lt;/p&gt;</comment>
                    <comment id="30914" author="jafingerhut" created="Mon, 8 Apr 2013 23:31:29 -0500"  >&lt;p&gt;Dmitry, do you think it is OK to close this ticket as declined, meaning no change will be made in response to it?  I can do that for you, if you wish.&lt;/p&gt;</comment>
                    <comment id="30917" author="si14" created="Tue, 9 Apr 2013 04:49:49 -0500"  >&lt;p&gt;Andy, I&apos;ll close it myself if you don&apos;t mind. I would done it earlier, but didn&apos;t have sufficient rights in JIRA.&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-937] cl-format prints ratio arguments with bad format for E, F, G directives</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-937</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;user=&amp;gt; (use &apos;clojure.pprint)&lt;br/&gt;
nil&lt;br/&gt;
user=&amp;gt; (cl-format false &quot;~e&quot; 4/5)&lt;br/&gt;
&quot;4./5E+2&quot;&lt;br/&gt;
user=&amp;gt; (cl-format false &quot;~f&quot; 4/5)&lt;br/&gt;
&quot;4/5.0&quot;&lt;br/&gt;
user=&amp;gt; (cl-format false &quot;~g&quot; 4/5)&lt;br/&gt;
&quot;4/5.    &quot;&lt;/p&gt;

&lt;p&gt;Patch changes cl-format so that when E, F, or G directive is used, the corresponding arg is coerced from a clojure.lang.Ratio to a double before formatting.&lt;/p&gt;</description>
                <environment></environment>
            <key id="15241">CLJ-937</key>
            <summary>cl-format prints ratio arguments with bad format for E, F, G directives</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>Tue, 21 Feb 2012 20:38:14 -0600</created>
                <updated>Mon, 8 Apr 2013 12:02:21 -0500</updated>
                                    <version>Release 1.3</version>
                <version>Release 1.4</version>
                                <fixVersion>Release 1.6</fixVersion>
                                        <due></due>
                    <votes>0</votes>
                        <watches>1</watches>
                        <comments>
                    <comment id="28054" author="tomfaulhaber" created="Thu, 29 Mar 2012 20:48:58 -0500"  >&lt;p&gt;I have reviewed this patch and recommend that it be applied.&lt;/p&gt;

&lt;p&gt;(This one has actually been on my to do list for about 4 years. Thanks, Andy!)&lt;/p&gt;</comment>
                    <comment id="30907" author="jafingerhut" created="Mon, 8 Apr 2013 12:02:21 -0500"  >&lt;p&gt;Patch clj-937-cl-format-coerces-ratios-patch2.txt dated Apr 8 2013 supersedes the previous patch cl-format-efg-coerce-ratios-to-doubes-patch1.txt dated Feb 21 2013.&lt;/p&gt;

&lt;p&gt;The newer patch works with ratios that cannot be represented as a double, using BigDecimal in those cases.  The older patch would print garbage from the string &quot;Infinity&quot; if the ratios were larger than Double/MAX_VALUE, or 0 if the ratio was between 0 and Double/MIN_VALUE.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="10938" name="cl-format-efg-coerce-ratios-to-doubes-patch1.txt" size="3810" author="jafingerhut" created="Tue, 21 Feb 2012 20:38:14 -0600" />
                    <attachment id="11949" name="clj-937-cl-format-coerces-ratios-patch2.txt" size="7892" author="jafingerhut" created="Mon, 8 Apr 2013 12:02:21 -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-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-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-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-1190] Javadoc for public Java API</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1190</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;We should publish javadoc for &lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-1188&quot;&gt;http://dev.clojure.org/jira/browse/CLJ-1188&lt;/a&gt;.&lt;/p&gt;

&lt;ul&gt;
	&lt;li&gt;make sure to publish on the the public API classes and interfaces&lt;/li&gt;
	&lt;li&gt;if IFn remains part of public interface, find javadoc control knob to disable including the nested interfaces dealing with primitives&lt;/li&gt;
	&lt;li&gt;automate publishing the docs somewhere (javadoc.clojure.org?)&lt;/li&gt;
&lt;/ul&gt;


&lt;p&gt;This ticket should wait until &lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-1188&quot; title=&quot;Public Java API&quot;&gt;&lt;del&gt;CLJ-1188&lt;/del&gt;&lt;/a&gt; is ok&apos;ed.&lt;/p&gt;</description>
                <environment></environment>
            <key id="16124">CLJ-1190</key>
            <summary>Javadoc for public Java API</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, 3 Apr 2013 06:51:13 -0500</created>
                <updated>Wed, 3 Apr 2013 06:51:13 -0500</updated>
                                                    <fixVersion>Release 1.6</fixVersion>
                                        <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-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-1166] Range function accumulates minor errors when called on floating-point numbers</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1166</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;Due to range&apos;s incremental computation minor errors introduced by floating point arithmetic accumulate, becoming more noticeable in long ranges and causing unexpected behaviour.&lt;/p&gt;

&lt;p&gt;Compare the output of the following:&lt;/p&gt;

&lt;p&gt;=&amp;gt; (range 0.0 10.0 0.1)&lt;br/&gt;
(0.0 0.1 0.2 0.30000000000000004 0.4 0.5 0.6 0.7 0.7999999999999999 0.8999999999999999 0.9999999999999999 1.0999999999999999 1.2 1.3 1.4000000000000001 1.5000000000000002 1.6000000000000003 1.7000000000000004 1.8000000000000005 1.9000000000000006 2.0000000000000004 2.1000000000000005 2.2000000000000006 2.3000000000000007 2.400000000000001 2.500000000000001 2.600000000000001 2.700000000000001 2.800000000000001 2.9000000000000012 3.0000000000000013 3.1000000000000014 3.2000000000000015 3.3000000000000016 3.4000000000000017 3.5000000000000018 3.600000000000002 3.700000000000002 3.800000000000002 3.900000000000002 4.000000000000002 4.100000000000001 4.200000000000001 4.300000000000001 4.4 4.5 4.6 4.699999999999999 4.799999999999999 4.899999999999999 4.999999999999998 5.099999999999998 5.1999999999999975 5.299999999999997 5.399999999999997 5.4999999999999964 5.599999999999996 5.699999999999996 5.799999999999995 5.899999999999995 5.999999999999995 6.099999999999994 6.199999999999994 6.299999999999994 6.399999999999993 6.499999999999993 6.5999999999999925 6.699999999999992 6.799999999999992 6.8999999999999915 6.999999999999991 7.099999999999991 7.19999999999999 7.29999999999999 7.39999999999999 7.499999999999989 7.599999999999989 7.699999999999989 7.799999999999988 7.899999999999988 7.999999999999988 8.099999999999987 8.199999999999987 8.299999999999986 8.399999999999986 8.499999999999986 8.599999999999985 8.699999999999985 8.799999999999985 8.899999999999984 8.999999999999984 9.099999999999984 9.199999999999983 9.299999999999983 9.399999999999983 9.499999999999982 9.599999999999982 9.699999999999982 9.799999999999981 9.89999999999998 9.99999999999998)&lt;/p&gt;

&lt;p&gt;=&amp;gt; (defn range&apos; &lt;span class=&quot;error&quot;&gt;&amp;#91;start end step&amp;#93;&lt;/span&gt; (map #(+ start (* % step)) (range 0 (/ (- end start) step) 1)))&lt;br/&gt;
=&amp;gt; (range&apos; 0.0 10.0 0.1)&lt;br/&gt;
(0.0 0.1 0.2 0.30000000000000004 0.4 0.5 0.6000000000000001 0.7000000000000001 0.8 0.9 1.0 1.1 1.2000000000000002 1.3 1.4000000000000001 1.5 1.6 1.7000000000000002 1.8 1.9000000000000001 2.0 2.1 2.2 2.3000000000000003 2.4000000000000004 2.5 2.6 2.7 2.8000000000000003 2.9000000000000004 3.0 3.1 3.2 3.3000000000000003 3.4000000000000004 3.5 3.6 3.7 3.8000000000000003 3.9000000000000004 4.0 4.1000000000000005 4.2 4.3 4.4 4.5 4.6000000000000005 4.7 4.800000000000001 4.9 5.0 5.1000000000000005 5.2 5.300000000000001 5.4 5.5 5.6000000000000005 5.7 5.800000000000001 5.9 6.0 6.1000000000000005 6.2 6.300000000000001 6.4 6.5 6.6000000000000005 6.7 6.800000000000001 6.9 7.0 7.1000000000000005 7.2 7.300000000000001 7.4 7.5 7.6000000000000005 7.7 7.800000000000001 7.9 8.0 8.1 8.200000000000001 8.3 8.4 8.5 8.6 8.700000000000001 8.8 8.9 9.0 9.1 9.200000000000001 9.3 9.4 9.5 9.600000000000001 9.700000000000001 9.8 9.9)&lt;/p&gt;</description>
                <environment></environment>
            <key id="16019">CLJ-1166</key>
            <summary>Range function accumulates minor errors when called on floating-point numbers</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="6" iconUrl="http://dev.clojure.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="2">Declined</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="sfnelson">Stephen Nelson</reporter>
                        <labels>
                    </labels>
                <created>Tue, 19 Feb 2013 15:04:14 -0600</created>
                <updated>Fri, 29 Mar 2013 17:10:49 -0500</updated>
                    <resolved>Fri, 1 Mar 2013 10:08:43 -0600</resolved>
                            <version>Release 1.5</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                        <comments>
                    <comment id="30619" author="sfnelson" created="Tue, 19 Feb 2013 15:06:48 -0600"  >&lt;p&gt;=&amp;gt; (last (range 0.0 10000000.0 0.1))&lt;br/&gt;
9999999.98112945&lt;br/&gt;
=&amp;gt; (last (range&apos; 0.0 10000000.0 0.1))&lt;br/&gt;
9999999.9&lt;/p&gt;</comment>
                    <comment id="30674" author="stu" created="Fri, 1 Mar 2013 10:08:35 -0600"  >&lt;p&gt;Range is incremental by design, and that is how floats work.  Something with the desired behavior would need to be a different fn with a different name.&lt;/p&gt;</comment>
                    <comment id="30691" author="sfnelson" created="Sun, 3 Mar 2013 14:38:21 -0600"  >&lt;p&gt;&quot;Returns a lazy seq of nums from start (inclusive) to end (exclusive), by step&quot;&lt;/p&gt;

&lt;p&gt;What specifically about that wording specifically suggests that the implementation will use naive increment-and-recurse behaviour? My reading is that the function will return a lazy sequence of numbers from start to end separated by step, not separated by &apos;almost step&apos;.&lt;/p&gt;

&lt;p&gt;This implementation leads to unexpected behaviour with bounds:&lt;/p&gt;

&lt;p&gt;=&amp;gt; (count (range 0 100 1))&lt;br/&gt;
100&lt;br/&gt;
=&amp;gt; (count (range 0 10 0.1))&lt;br/&gt;
101&lt;/p&gt;

&lt;p&gt;&lt;a href=&quot;http://www.ima.umn.edu/~arnold/455.f96/disasters.html&quot;&gt;http://www.ima.umn.edu/~arnold/455.f96/disasters.html&lt;/a&gt;&lt;/p&gt;</comment>
                    <comment id="30845" author="timothypratley" created="Fri, 29 Mar 2013 17:09:50 -0500"  >&lt;p&gt;range could avoid this issue cleanly by converting floats to bigdecimals (let me know if you think this is a good idea?)&lt;/p&gt;

&lt;p&gt;I ran into this problem recently, and have to say it was pretty ugly. This is how I avoided the issue:&lt;/p&gt;

&lt;p&gt;(defn rangef&lt;br/&gt;
  &quot;Returns a sequence of n numbers from start to end inclusive.&quot;&lt;br/&gt;
  &lt;span class=&quot;error&quot;&gt;&amp;#91;start end n&amp;#93;&lt;/span&gt;&lt;br/&gt;
  (for &lt;span class=&quot;error&quot;&gt;&amp;#91;i (range 0 n)&amp;#93;&lt;/span&gt;&lt;br/&gt;
    (+ start (* i (/ (- end start) (dec n))))))&lt;/p&gt;

&lt;p&gt;Hope that helps any disillusioned float users out there, or just pass in BigDecimals to range instead of floats... I would go so far as to say using floats with range as it stands is almost always going to end in tears (or worse as Stephen describes &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="30846" author="timothypratley" created="Fri, 29 Mar 2013 17:10:49 -0500"  >&lt;p&gt;&lt;span class=&quot;error&quot;&gt;&amp;#91;and just to be clear if it is considered an error, it would be nice if range explicitly forbade it&amp;#93;&lt;/span&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-1155] Suppress tracebacks from clojure.core</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1155</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;It would be really nice if we could hide the Java traceback from the compiler when it&apos;s not relevant. When there&apos;s no Java interop, it&apos;s not useful. I can&apos;t see any case where we want the tracebacks from the compiler referencing clojure.core.&lt;/p&gt;

&lt;p&gt;Here&apos;s how a syntax error traceback looks at the moment on trunk:&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;$ more dodgy-map.clj
(defn dodgy-map []
  {:1 :2 :3})
$ java -cp target/clojure-1.5.0-master-SNAPSHOT.jar clojure.main dodgy-map.clj
Exception in thread &quot;main&quot; java.lang.RuntimeException: Map literal must contain an even number of forms, compiling:(/home/wilfred/src/clojure/dodgy-map.clj:2:13)
	at clojure.lang.Compiler.load(Compiler.java:7070)
	at clojure.lang.Compiler.loadFile(Compiler.java:7020)
	at clojure.main$load_script.invoke(main.clj:286)
	at clojure.main$script_opt.invoke(main.clj:348)
	at clojure.main$main$fn__6682.invoke(main.clj:432)
	at clojure.main$main.doInvoke(main.clj:429)
	at clojure.lang.RestFn.invoke(RestFn.java:408)
	at clojure.lang.Var.invoke(Var.java:415)
	at clojure.lang.AFn.applyToHelper(AFn.java:161)
	at clojure.lang.Var.applyTo(Var.java:532)
	at clojure.main.main(main.java:37)
Caused by: java.lang.RuntimeException: Map literal must contain an even number of forms
	at clojure.lang.Util.runtimeException(Util.java:219)
	at clojure.lang.LispReader$MapReader.invoke(LispReader.java:1090)
	at clojure.lang.LispReader.readDelimitedList(LispReader.java:1145)
	at clojure.lang.LispReader$ListReader.invoke(LispReader.java:979)
	at clojure.lang.LispReader.read(LispReader.java:182)
	at clojure.lang.Compiler.load(Compiler.java:7058)
	... 10 more
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;With my patch, this is simplified to:&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 -cp target/clojure-1.5.0-master-SNAPSHOT.jar clojure.main dodgy-map.clj
java.lang.RuntimeException: Map literal must contain an even number of forms, compiling:(/home/wilfred/src/clojure/dodgy-map.clj:2:13)
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;Another example: here&apos;s how name errors appear on trunk:&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;$ more i-dont-exist.clj
(defn no-such-variable []
  i-dont-exist)
$ java -cp target/clojure-1.5.0-master-SNAPSHOT.jar clojure.main i-dont-exist.clj
Exception in thread &quot;main&quot; java.lang.RuntimeException: Unable to resolve symbol: i-dont-exist in this context, compiling:(/home/wilfred/src/clojure/i-dont-exist.clj:1:1)
	at clojure.lang.Compiler.analyze(Compiler.java:6380)
	at clojure.lang.Compiler.analyze(Compiler.java:6322)
	at clojure.lang.Compiler$BodyExpr$Parser.parse(Compiler.java:5708)
	at clojure.lang.Compiler$FnMethod.parse(Compiler.java:5139)
	at clojure.lang.Compiler$FnExpr.parse(Compiler.java:3751)
	at clojure.lang.Compiler.analyzeSeq(Compiler.java:6558)
	at clojure.lang.Compiler.analyze(Compiler.java:6361)
	at clojure.lang.Compiler.analyzeSeq(Compiler.java:6548)
	at clojure.lang.Compiler.analyze(Compiler.java:6361)
	at clojure.lang.Compiler.access$100(Compiler.java:37)
	at clojure.lang.Compiler$DefExpr$Parser.parse(Compiler.java:529)
	at clojure.lang.Compiler.analyzeSeq(Compiler.java:6560)
	at clojure.lang.Compiler.analyze(Compiler.java:6361)
	at clojure.lang.Compiler.analyze(Compiler.java:6322)
	at clojure.lang.Compiler.eval(Compiler.java:6623)
	at clojure.lang.Compiler.load(Compiler.java:7063)
	at clojure.lang.Compiler.loadFile(Compiler.java:7020)
	at clojure.main$load_script.invoke(main.clj:286)
	at clojure.main$script_opt.invoke(main.clj:348)
	at clojure.main$main$fn__6682.invoke(main.clj:432)
	at clojure.main$main.doInvoke(main.clj:429)
	at clojure.lang.RestFn.invoke(RestFn.java:408)
	at clojure.lang.Var.invoke(Var.java:415)
	at clojure.lang.AFn.applyToHelper(AFn.java:161)
	at clojure.lang.Var.applyTo(Var.java:532)
	at clojure.main.main(main.java:37)
Caused by: java.lang.RuntimeException: Unable to resolve symbol: i-dont-exist in this context
	at clojure.lang.Util.runtimeException(Util.java:219)
	at clojure.lang.Compiler.resolveIn(Compiler.java:6874)
	at clojure.lang.Compiler.resolve(Compiler.java:6818)
	at clojure.lang.Compiler.analyzeSymbol(Compiler.java:6779)
	at clojure.lang.Compiler.analyze(Compiler.java:6343)
	... 25 more
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;With patch:&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 -cp target/clojure-1.5.0-master-SNAPSHOT.jar clojure.main i-dont-exist.clj
java.lang.RuntimeException: Unable to resolve symbol: i-dont-exist in this context, compiling:(/home/wilfred/src/clojure/i-dont-exist.clj:1:1)
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;I&apos;m not familiar with the compiler internals, but I&apos;ve attached a tentative patch. Undoubtedly it isn&apos;t perfect. For one, it would be nicer to say &apos;Syntax error&apos; rather than &apos;java.lang.RuntimeException&apos;. All the tests pass with this change.&lt;/p&gt;

&lt;p&gt;Relevant mailing list discussion: &lt;a href=&quot;https://groups.google.com/forum/?fromgroups=#!searchin/clojure/wilfred/clojure/M5NlEW7HJ_c/joUY6mo6Rd8J&quot;&gt;https://groups.google.com/forum/?fromgroups=#!searchin/clojure/wilfred/clojure/M5NlEW7HJ_c/joUY6mo6Rd8J&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;Please let me know what you think. This would make my life easier when developing.&lt;/p&gt;</description>
                <environment></environment>
            <key id="15984">CLJ-1155</key>
            <summary>Suppress tracebacks from clojure.core</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="6" iconUrl="http://dev.clojure.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="2">Declined</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="wilfred">Wilfred Hughes</reporter>
                        <labels>
                        <label>enhancement</label>
                    </labels>
                <created>Fri, 1 Feb 2013 17:44:16 -0600</created>
                <updated>Fri, 29 Mar 2013 06:06:12 -0500</updated>
                    <resolved>Fri, 29 Mar 2013 06:06:12 -0500</resolved>
                                                                    <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                        <comments>
                    <comment id="30837" author="stu" created="Fri, 29 Mar 2013 06:06:12 -0500"  >&lt;p&gt;It is easy for tools that consume Clojure to hide stack traces for those who do not want to see them.  If Clojure itself eats stack traces, it is impossible for those of us who &lt;b&gt;do&lt;/b&gt; want to see them to get them back.&lt;/p&gt;

&lt;p&gt;Please do this kind of work in tool (if at all) and make it optional for users.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="11827" name="suppress_tracebacks.patch" size="1016" author="wilfred" created="Fri, 1 Feb 2013 17:44:16 -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-1178] Requiring the same ns doesn&apos;t throw an exception</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1178</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;The compiler will happily allow requiring the same ns twice. I can&apos;t see any reason you&apos;d intentionally do 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 program
  (:require [program.a :as a]
            [program.a :as b])&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;This caused some confusion for a while as to why b wasn&apos;t producing the expected functionality. Just a simple mistake that I think can be caught at compile time.&lt;/p&gt;</description>
                <environment></environment>
            <key id="16063">CLJ-1178</key>
            <summary>Requiring the same ns doesn&apos;t throw an exception</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="6" iconUrl="http://dev.clojure.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="2">Declined</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="michael-drogalis">Michael Drogalis</reporter>
                        <labels>
                    </labels>
                <created>Thu, 7 Mar 2013 18:18:46 -0600</created>
                <updated>Fri, 29 Mar 2013 05:57:12 -0500</updated>
                    <resolved>Fri, 29 Mar 2013 05:57:12 -0500</resolved>
                                                                    <due></due>
                    <votes>0</votes>
                        <watches>1</watches>
                        <comments>
                    <comment id="30836" author="stu" created="Fri, 29 Mar 2013 05:57:12 -0500"  >&lt;p&gt;The example shows valid Clojure code.&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="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>
                                                                                                            </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-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-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-250] debug builds</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-250</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;This ticket includes two patches: &lt;/p&gt;

&lt;ol&gt;
	&lt;li&gt;a patch to set  &lt;tt&gt;&lt;b&gt;assert&lt;/b&gt;&lt;/tt&gt; when clojure.lang.RT loads, based on the presence of system property clojure.debug&lt;/li&gt;
	&lt;li&gt;expand error messages in assert to include &lt;tt&gt;local-bindings&amp;lt;/code&amp;gt; (a new macro which wraps the implicit &amp;lt;code&amp;gt;&amp;amp;env&lt;/tt&gt;)&lt;/li&gt;
&lt;/ol&gt;


&lt;p&gt;Things to consider before approving these patches:&lt;/p&gt;

&lt;ol&gt;
	&lt;li&gt;should there be an easy Clojure-level way to query if debug is enabled? (checking assert isn&apos;t the same, as debug should eventually drive other features)&lt;/li&gt;
	&lt;li&gt;assertions will now be off by default &amp;#8211; this is a change!&lt;/li&gt;
	&lt;li&gt;is the addition of the name &lt;tt&gt;local-bindings&lt;/tt&gt; to clojure.core cool?&lt;/li&gt;
&lt;/ol&gt;
</description>
                <environment></environment>
            <key id="13647">CLJ-250</key>
            <summary>debug builds</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, 27 Jan 2010 17:40:00 -0600</created>
                <updated>Thu, 14 Mar 2013 13:28:51 -0500</updated>
                                    <version>Release 1.2</version>
                                <fixVersion>Approved Backlog</fixVersion>
                                        <due></due>
                    <votes>0</votes>
                        <watches>2</watches>
                        <comments>
                    <comment id="23417" author="importer" created="Tue, 24 Aug 2010 06:05:00 -0500"  >&lt;p&gt;Converted from &lt;a href=&quot;http://www.assembla.com/spaces/clojure/tickets/250&quot;&gt;http://www.assembla.com/spaces/clojure/tickets/250&lt;/a&gt;&lt;br/&gt;
Attachments:&lt;br/&gt;
add-clojure-debug-flag.patch - &lt;a href=&quot;https://www.assembla.com/spaces/clojure/documents/aUWn50c64r35E-eJe5aVNr/download/aUWn50c64r35E-eJe5aVNr&quot;&gt;https://www.assembla.com/spaces/clojure/documents/aUWn50c64r35E-eJe5aVNr/download/aUWn50c64r35E-eJe5aVNr&lt;/a&gt;&lt;br/&gt;
assert-report-locals.patch - &lt;a href=&quot;https://www.assembla.com/spaces/clojure/documents/aUWqLSc64r35E-eJe5aVNr/download/aUWqLSc64r35E-eJe5aVNr&quot;&gt;https://www.assembla.com/spaces/clojure/documents/aUWqLSc64r35E-eJe5aVNr/download/aUWqLSc64r35E-eJe5aVNr&lt;/a&gt;&lt;/p&gt;</comment>
                    <comment id="26008" author="stu" created="Tue, 7 Dec 2010 20:23:13 -0600"  >&lt;p&gt;Ignore the old patches. Considering the following implementation, please review and then move ticket to waiting on Stu:&lt;/p&gt;

&lt;ol&gt;
	&lt;li&gt;RT will check system property &lt;tt&gt;&quot;clojure.debug&quot;&lt;/tt&gt;, default to false&lt;/li&gt;
	&lt;li&gt;property will set the root binding for the current &lt;tt&gt;&amp;#42;assert&amp;#42;&lt;/tt&gt;, plus a new &lt;tt&gt;&amp;#42;debug&amp;#42;&lt;/tt&gt; flag. (Debug builds can and will drive other things than just asserts.)&lt;/li&gt;
	&lt;li&gt;does Compile.java need to push &lt;tt&gt;&amp;#42;assert&amp;#42;&lt;/tt&gt; or &lt;tt&gt;&amp;#42;debug&amp;#42;&lt;/tt&gt; as thread local bindings, or can they be root-bound only when compiling clojure?&lt;/li&gt;
	&lt;li&gt;will add &lt;tt&gt;&amp;#42;debug&amp;#42;&lt;/tt&gt; binding to &lt;tt&gt;clojure.main/with-bindings&lt;/tt&gt;. Anywhere else?&lt;/li&gt;
	&lt;li&gt;build.xml should not have to change &amp;#8211; system properties will flow through (and build.xml may not be around much longer anyway)&lt;/li&gt;
	&lt;li&gt;once we agree on the approach, I will ping maven plugin and lein owners so that they flow the setting through&lt;/li&gt;
	&lt;li&gt;better assertion messages will be a separate ticket&lt;/li&gt;
	&lt;li&gt;what is the interaction between &amp;#42;debug&amp;#42; and &amp;#42;unchecked-math&amp;#42;? Change checks to &lt;tt&gt;(and &amp;#42;unchecked-math&amp;#42; (not &amp;#42;debug&amp;#42;))&lt;/tt&gt;}?&lt;/li&gt;
&lt;/ol&gt;
</comment>
                    <comment id="26012" author="richhickey" created="Wed, 8 Dec 2010 11:00:04 -0600"  >&lt;p&gt;#3 - root bound only&lt;br/&gt;
#4 - should &lt;b&gt;not&lt;/b&gt; be in with-bindings for same reason as #3 - we don&apos;t want people to set! &amp;#42;debug&amp;#42; nor &amp;#42;assert&amp;#42;&lt;br/&gt;
#8 - yes, wrapping that in a helper fn&lt;/p&gt;

&lt;p&gt;#6 - my biggest reservation is that this isn&apos;t yet informed by maven best practices&lt;/p&gt;</comment>
                    <comment id="26013" author="stuart.sierra" created="Wed, 8 Dec 2010 14:09:49 -0600"  >&lt;p&gt;System properties can be passed through Maven, so I do not anticipate this being a problem.&lt;/p&gt;

&lt;p&gt;However, I would prefer &lt;tt&gt;&amp;#42;assert&amp;#42;&lt;/tt&gt; to remain true by default.&lt;/p&gt;</comment>
                    <comment id="26015" author="cemerick" created="Thu, 9 Dec 2010 07:19:33 -0600"  >&lt;p&gt;SS is correct about this approach not posing any issue for Maven.  In addition, the build could easily be set up to always emit two jars, one &quot;normal&quot;, one &quot;debug&quot;.&lt;/p&gt;

&lt;p&gt;I&apos;d suggest that, while &lt;tt&gt;clojure.debug&lt;/tt&gt; might have broad effect, additional properties should be available to provide fine-grained control over each of the additional &quot;debug&quot;-related parameterizations that might become available in the future.&lt;/p&gt;

&lt;hr /&gt;

&lt;p&gt;I&apos;d like to raise a couple of potentially tangential concerns (after now thinking about assertions for a bit in the above context), some or all of which may simply be a result of my lack of understanding in various areas.&lt;/p&gt;

&lt;p&gt;Looking at where &lt;tt&gt;assert&lt;/tt&gt; is used in &lt;tt&gt;core.clj&lt;/tt&gt; (only two places AFAICT: validating arguments to &lt;tt&gt;derive&lt;/tt&gt; and checking pre- and post-conditions in &lt;tt&gt;fn&lt;/tt&gt;), it would seem unwise to make it &lt;tt&gt;false&lt;/tt&gt; by default.  i.e. non-&lt;tt&gt;Named&lt;/tt&gt; values would be able to get into hierarchies, and pre- and post-conditions would simply be ignored.&lt;/p&gt;

&lt;p&gt;It&apos;s my understanding that assertions (talking here of the JVM construct, from which Clojure reuses &lt;tt&gt;AssertionError&lt;/tt&gt;) should not be used to validate arguments to public API functions, or used to validate any aspect of a function&apos;s normal operation (i.e. &lt;a href=&quot;http://download.oracle.com/javase/1.4.2/docs/guide/lang/assert.html#usage&quot;&gt;&quot;where not to use assertions&quot;&lt;/a&gt;).  That would imply that &lt;tt&gt;derive&lt;/tt&gt; should throw &lt;tt&gt;IllegalArugmentException&lt;/tt&gt; when necessary, and fn pre- and post-conditions should perhaps throw &lt;tt&gt;IllegalStateException&lt;/tt&gt; &amp;#8211; or, in any case, something other than &lt;tt&gt;AssertionError&lt;/tt&gt; via &lt;tt&gt;assert&lt;/tt&gt;.  This would match up far better with most functions in core using &lt;tt&gt;assert-args&lt;/tt&gt; rather than &lt;tt&gt;assert&lt;/tt&gt;, the former throwing &lt;tt&gt;IllegalArgumentException&lt;/tt&gt; rather than &lt;tt&gt;AssertionError&lt;/tt&gt;.&lt;/p&gt;

&lt;p&gt;That leads me to the question: is &lt;tt&gt;assert&lt;/tt&gt; (and &lt;tt&gt;&amp;#42;assert&amp;#42;&lt;/tt&gt;) intended to be a Clojure construct, or a quasi-interop form?&lt;/p&gt;

&lt;p&gt;If the former, then it can roughly have whatever semantics we want, but then it seems like it should not be throwing &lt;tt&gt;AssertionError&lt;/tt&gt;.&lt;/p&gt;

&lt;p&gt;If the latter, then &lt;tt&gt;AssertionError&lt;/tt&gt; is appropriate on the JVM, but then we need to take care that assertions can be enabled and disabled at runtime (without having to switch around different builds of Clojure), ideally using the host-defined switches (e.g. &lt;tt&gt;-ea&lt;/tt&gt; and friends) and likely not anything like &lt;tt&gt;&amp;#42;assert&amp;#42;&lt;/tt&gt;. I don&apos;t know if this is possible or practical at this point (I presume this would require nontrivial compiler changes).&lt;/p&gt;

&lt;hr /&gt;

&lt;p&gt;Hopefully the above is not water under the bridge at this point.  Thank you in advance for your forbearance. &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;</comment>
                    <comment id="26016" author="richhickey" created="Thu, 9 Dec 2010 08:08:07 -0600"  >&lt;p&gt;Thanks for the useful input Chas. Nothing is concluded yet. I think we should step back and look at the objective here, before moving forward with a solution. Being a dynamic language, there are many things we might want to validate about our programs, where the cost of checking is something we are unwilling to pay in production.&lt;/p&gt;

&lt;p&gt;Being a macro, assert has the nice property that, should &amp;#42;assert&amp;#42; not be true during compilation, it generates nil, no conditional test at all. Thus right now it is more like static conditional compilation.&lt;/p&gt;

&lt;p&gt;Java assert does have runtime toggle-ability, via &amp;#45;ea as you say. I haven&apos;t looked at the bytecode generated for Java asserts, but it might be possible for Clojure assert to do something similar, if the runtime overhead is negligible. It is quite likely that HotSpot has special code for eliding the assertion bytecode given a single check of some flag. I&apos;m just not sure that flag is &lt;a href=&quot;http://download.oracle.com/javase/1.5.0/docs/api/java/lang/Class.html#desiredAssertionStatus()&quot;&gt;Class.desiredAssertionStatus&lt;/a&gt;.&lt;/p&gt;

&lt;p&gt;Whether this turns into changes in assert or pre/post conditions, best practices etc is orthogonal and derived. Currently we don&apos;t have a facility to run without the checks. We need to choose between making them disappear during compilation (debug build) or runtime (track &amp;#45;ea) or both. Then we can look at how that is reflected in assert/pre-post and re-examine existing use of both. The &quot;where not to use assertions&quot; doc deals with them categorically, but in not considering their cost, seems unrealistic IMO. &lt;/p&gt;

&lt;p&gt;I&apos;d appreciate it if someone could look into how assert is generated and optimized by Java itself.&lt;/p&gt;</comment>
                    <comment id="26018" author="cemerick" created="Thu, 9 Dec 2010 17:04:52 -0600"  >&lt;p&gt;Bytecode issues continue to be above my pay grade, unfortunately&#8230;&lt;/p&gt;

&lt;p&gt;A few additional thoughts in response that you may or may not be juggling already:&lt;/p&gt;

&lt;p&gt;&lt;tt&gt;assert&lt;/tt&gt; being a macro makes total sense for what it&apos;s doing.  Trouble is, &quot;compile-time&quot; is a tricky concept in Clojure: there&apos;s code-loading-time, AOT-compile-time, and transitively-AOT-compile-time.  Given that, it&apos;s entirely possible for an application deployed to a production environment that contains a patchwork of code or no code produced by &lt;tt&gt;assert&lt;/tt&gt; usages in various libraries and namespaces depending upon when those libs and ns&apos; were loaded, AOT-compiled, or their dependents AOT-compiled, and the value of &lt;tt&gt;&amp;#42;assert&amp;#42;&lt;/tt&gt; at each of those times.  Of course, this is the case for all such macros whose results are dependent upon context-dependent state (I think this was a big issue with &lt;tt&gt;clojure.contrib.logging&lt;/tt&gt;, making it only usable with log4j for a while).&lt;/p&gt;

&lt;p&gt;What&apos;s really attractive about the JVM assertion mechanism is that it can be parameterized for a given runtime on a per-package basis, if desired.  Reimplementing that concept so that &lt;tt&gt;assert&lt;/tt&gt; can be &lt;tt&gt;&amp;#42;ns&amp;#42;&lt;/tt&gt;-sensitive seems like it&apos;d be straightforward, but the compile-time complexity already mentioned remains, and the idea of having two independently-controlled assertion facilities doesn&apos;t sound fun.&lt;/p&gt;

&lt;p&gt;I know nearly nothing about the CLR, but it would appear that it doesn&apos;t provide for anything like runtime-controllable assertions.&lt;/p&gt;</comment>
                    <comment id="26068" author="stu" created="Wed, 29 Dec 2010 15:17:44 -0600"  >&lt;p&gt;The best (dated) evidence I could find says that the compiler sets a special class static final field &lt;tt&gt;$assertionsDisabled&lt;/tt&gt; based on the return of &lt;tt&gt;desiredAssertionStatus&lt;/tt&gt;. HotSpot doesn&apos;t do anything special with this, dead code elimination simply makes it go away. The code indeed compiles this way:&lt;/p&gt;

&lt;p&gt;   11:	getstatic	#6; //Field $assertionsDisabled:Z&lt;br/&gt;
   14:	ifne	33&lt;br/&gt;
   17:	lload_1&lt;br/&gt;
   18:	lconst_0&lt;br/&gt;
   19:	lcmp&lt;br/&gt;
   20:	ifeq	33&lt;br/&gt;
   23:	new	#7; //class java/lang/AssertionError&lt;br/&gt;
   26:	dup&lt;br/&gt;
   27:	ldc	#8; //String X should be zero&lt;br/&gt;
   29:	invokespecial	#9; //Method java/lang/AssertionError.&quot;&amp;lt;init&amp;gt;&quot;:(Ljava/lang/Object;)V&lt;br/&gt;
   32:	athrow&lt;/p&gt;

&lt;p&gt;Even if we were 100% sure that assertion removal was total, I would still vote for a separate Clojure-level switch, for the following reasons:&lt;/p&gt;

&lt;ol&gt;
	&lt;li&gt;I have a real and pressing need to disable some assertions, and I don&apos;t need the Java interop at all. Arguably others will be in the same boat.&lt;/li&gt;
	&lt;li&gt;there will be multiple debugging facilities over time, and having a top-level &lt;b&gt;debug&lt;/b&gt; switch is convenient for Clojure users.&lt;/li&gt;
	&lt;li&gt;Java dis/enabling via command line flags is still possible as a separate feature. We could add this later as a (small) breaking change to our assert, or have a separate java-assert interop form. I am on the fence about which way to go here.&lt;/li&gt;
	&lt;li&gt;I believe it is perfectly fine to throw an &lt;tt&gt;AssertionError&lt;/tt&gt; from a non-Java-assertion-form. We don&apos;t believe in a world of a static exception hierarchy, and an assertion in production is a critical failure no matter what you call it. Even Scala does it &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;http://daily-scala.blogspot.com/2010/03/assert-require-assume.html&quot;&gt;http://daily-scala.blogspot.com/2010/03/assert-require-assume.html&lt;/a&gt;&lt;/li&gt;
&lt;/ol&gt;


&lt;p&gt;Rich: awaiting your blessing to move forward on this.&lt;/p&gt;</comment>
                    <comment id="26100" author="richhickey" created="Fri, 7 Jan 2011 09:42:47 -0600"  >&lt;p&gt;The compiler sets $assertionsDisabled when, in static init code? Is there special support in the classloader for it? Is there a link to the best dated evidence you found?&lt;/p&gt;</comment>
                    <comment id="26101" author="stu" created="Fri, 7 Jan 2011 09:51:27 -0600"  >&lt;ol&gt;
	&lt;li&gt;Yes, in static init code&lt;/li&gt;
	&lt;li&gt;There is no special support in the classloader, per Brian Goetz (private correspondence) last week. But dead code elimination is great: &quot;The run-time cost of disabled assertions should indeed be zero for compiled code&quot;&lt;/li&gt;
&lt;/ol&gt;
</comment>
                    <comment id="26102" author="stu" created="Fri, 7 Jan 2011 09:57:17 -0600"  >&lt;p&gt;Link: Google &quot;java assert shirazi&quot;. (Not posting link because I can&apos;t tell in 10 secs whether it includes my session information.)&lt;/p&gt;</comment>
                    <comment id="30760" author="akiel" created="Thu, 14 Mar 2013 13:28:51 -0500"  >&lt;p&gt;Is there anything new on this issue? I also look for a convenient way to disable assertions in production.&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="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_10003" key="com.atlassian.jira.plugin.system.customfieldtypes:userpicker">
                <customfieldname>Waiting On</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>richhickey</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-713] Upgrade ASM to a more current version</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-713</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;ul&gt;
	&lt;li&gt;Move to the latest ASM (currently 3.3.1)&lt;/li&gt;
	&lt;li&gt;No longer subset-ed&lt;/li&gt;
	&lt;li&gt;Still re-rooted it under clojure.asm&lt;/li&gt;
&lt;/ul&gt;
</description>
                <environment></environment>
            <key id="14322">CLJ-713</key>
            <summary>Upgrade ASM to a more current version</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="aaron">Aaron Bedra</reporter>
                        <labels>
                    </labels>
                <created>Tue, 11 Jan 2011 22:47:00 -0600</created>
                <updated>Mon, 11 Mar 2013 15:43:51 -0500</updated>
                                                    <fixVersion>Approved Backlog</fixVersion>
                                        <due></due>
                    <votes>0</votes>
                        <watches>2</watches>
                        <comments>
                    <comment id="30720" author="gshayban" created="Sun, 10 Mar 2013 06:34:10 -0500"  >&lt;p&gt;Attached is a patch that externalizes and moves the ASM lib to the latest version (4.1), which has support for invokeDynamic if a brave soul wants to emit that instruction.  Heed fogus&apos;s caveats &lt;span class=&quot;error&quot;&gt;&amp;#91;3&amp;#93;&lt;/span&gt;.&lt;/p&gt;

&lt;p&gt;ASM in this patch is not re-rooted, but an external Maven dependency. It does have the disadvantage of possibly conflicting with other dependents of ASM, but this is the same approach is used by other JVM langs.&lt;/p&gt;

&lt;p&gt;Can classloaders mitigate that problem?&lt;/p&gt;

&lt;p&gt;&lt;span class=&quot;error&quot;&gt;&amp;#91;1&amp;#93;&lt;/span&gt; Recent post on clojure-dev, oblivious of &lt;span class=&quot;error&quot;&gt;&amp;#91;2&amp;#93;&lt;/span&gt; &lt;a href=&quot;https://groups.google.com/d/msg/clojure-dev/iX-ZFPk_zyE/Es3mDOdG3bYJ&quot;&gt;https://groups.google.com/d/msg/clojure-dev/iX-ZFPk_zyE/Es3mDOdG3bYJ&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;https://groups.google.com/d/msg/clojure-dev/ahJXBT1vG68/_fEEM6Lc7LcJ&quot;&gt;https://groups.google.com/d/msg/clojure-dev/ahJXBT1vG68/_fEEM6Lc7LcJ&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://blog.fogus.me/2011/10/14/why-clojure-doesnt-need-invokedynamic-but-it-might-be-nice/&quot;&gt;http://blog.fogus.me/2011/10/14/why-clojure-doesnt-need-invokedynamic-but-it-might-be-nice/&lt;/a&gt;&lt;/p&gt;</comment>
                    <comment id="30729" author="gshayban" created="Mon, 11 Mar 2013 10:41:22 -0500"  >&lt;p&gt;Ran some of Andy Fingerhut&apos;s expression microbenchmarks on -master with the patch.  There is no difference between performance compared to 1.5.1.&lt;/p&gt;</comment>
                    <comment id="30733" author="jafingerhut" created="Mon, 11 Mar 2013 15:43:51 -0500"  >&lt;p&gt;Ghadi, out of curiosity, if you do AOT compilation of some Clojure class files, does it produce byte-for-byte identical .class files after your changes vs. before your changes?  If so, that would be pretty high assurance of no problems.  If not, it would be good to understand what changed.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="11903" name="asm-split.txt" size="533589" author="gshayban" created="Sun, 10 Mar 2013 06:34:10 -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-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-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-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-15] GC Issue 11: incremental hashcode calculation for collections</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-15</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;Reported by richhickey, Dec 17, 2008
So hachCode can be &lt;span class=&quot;code-keyword&quot;&gt;final&lt;/span&gt;, more efficient to calc as you go.&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;</description>
                <environment></environment>
            <key id="13412">CLJ-15</key>
            <summary>GC Issue 11: incremental hashcode calculation for collections</summary>
                <type id="4" iconUrl="http://dev.clojure.org/jira/images/icons/improvement.gif">Enhancement</type>
                                        <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="-1">None</reporter>
                        <labels>
                    </labels>
                <created>Wed, 17 Jun 2009 11:55:00 -0500</created>
                <updated>Fri, 8 Mar 2013 06:20:08 -0600</updated>
                                                    <fixVersion>Backlog</fixVersion>
                                        <due></due>
                    <votes>0</votes>
                        <watches>2</watches>
                        <comments>
                    <comment id="22495" author="importer" created="Tue, 24 Aug 2010 03:44:00 -0500"  >&lt;p&gt;Converted from &lt;a href=&quot;http://www.assembla.com/spaces/clojure/tickets/15&quot;&gt;http://www.assembla.com/spaces/clojure/tickets/15&lt;/a&gt;&lt;/p&gt;</comment>
                    <comment id="30715" author="cgrand" created="Fri, 8 Mar 2013 06:20:08 -0600"  >&lt;p&gt;Wouldn&apos;t the naive approach incur realizing lazy sequences when adding them to a list or a vector or as values in a map?&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-1174] Website doc link for 1.4 api docs returns a 404</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1174</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;The API docs for Clojure 1.4 (&lt;a href=&quot;http://clojure.github.com/clojure/branch-clojure-1.4.0/index.html&quot;&gt;http://clojure.github.com/clojure/branch-clojure-1.4.0/index.html&lt;/a&gt;), linked to from &lt;a href=&quot;http://clojure.github.com/clojure/&quot;&gt;http://clojure.github.com/clojure/&lt;/a&gt;, returns a 404.&lt;/p&gt;

&lt;p&gt;I logged it under this category because I can&apos;t see anywhere else to log bugs about clojure.org.&lt;/p&gt;</description>
                <environment>All</environment>
            <key id="16054">CLJ-1174</key>
            <summary>Website doc link for 1.4 api docs returns a 404</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="5" iconUrl="http://dev.clojure.org/jira/images/icons/status_resolved.gif">Resolved</status>
                    <resolution id="1">Completed</resolution>
                                <assignee username="tomfaulhaber">Tom Faulhaber</assignee>
                                <reporter username="edoloughlin">Ed O&apos;Loughlin</reporter>
                        <labels>
                    </labels>
                <created>Tue, 5 Mar 2013 05:50:53 -0600</created>
                <updated>Tue, 5 Mar 2013 20:29:46 -0600</updated>
                    <resolved>Tue, 5 Mar 2013 20:29:46 -0600</resolved>
                            <version>Release 1.4</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                        <comments>
                    <comment id="30704" author="tomfaulhaber" created="Tue, 5 Mar 2013 20:29:46 -0600"  >&lt;p&gt;Fixed. Thanks for pointing this out.&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-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-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-372] possible binding issue in clojure.template?</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-372</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;I came across some strange behavior the other day in clojure.test/are, where the template replacement seems a bit over-eager.  As a simple case:&lt;/p&gt;

&lt;p&gt;(use &apos;clojure.test)&lt;/p&gt;

&lt;p&gt;(are &lt;span class=&quot;error&quot;&gt;&amp;#91;x y&amp;#93;&lt;/span&gt; (= x y)&lt;br/&gt;
  &apos;(4 9 16) (map (fn &lt;span class=&quot;error&quot;&gt;&amp;#91;x&amp;#93;&lt;/span&gt; (* x x)) &apos;(2 3 4)))&lt;/p&gt;

&lt;p&gt;gives &quot;java.lang.Exception: Unsupported binding form: clojure.lang.LazySeq@7bed76a7&quot;, but &lt;/p&gt;

&lt;p&gt;(are &lt;span class=&quot;error&quot;&gt;&amp;#91;x y&amp;#93;&lt;/span&gt; (= x y)&lt;br/&gt;
  &apos;(4 9 16) (map (fn &lt;span class=&quot;error&quot;&gt;&amp;#91;z&amp;#93;&lt;/span&gt; (* z z)) &apos;(2 3 4)))&lt;/p&gt;

&lt;p&gt;is fine.  It seems that all instances of the variable x get replaced, even the ones in other expressions that are doing the replacing. A macroexpand-1 traced it to clojure.template, and if I patch apply-template there to use postwalk-replace rather than prewalk-replace, clojure.test/are works as I had expected.  However, the simple test case I wrote to expose this problem (wrapping deftest around the first example above) fails with what seems to me to be a bizarre error:&lt;/p&gt;

&lt;p&gt;&lt;span class=&quot;error&quot;&gt;&amp;#91;java&amp;#93;&lt;/span&gt; FAIL in (can-test-using-local-bindings) (test_clojure.clj:87)&lt;br/&gt;
&lt;span class=&quot;error&quot;&gt;&amp;#91;java&amp;#93;&lt;/span&gt;  but got :pass&lt;br/&gt;
&lt;span class=&quot;error&quot;&gt;&amp;#91;java&amp;#93;&lt;/span&gt; expected: (= (quote (4 9 16)) (map (fn &lt;span class=&quot;error&quot;&gt;&amp;#91;x&amp;#93;&lt;/span&gt; (* x x)) (quote (2 3 4))))&lt;br/&gt;
&lt;span class=&quot;error&quot;&gt;&amp;#91;java&amp;#93;&lt;/span&gt;   actual: (#&amp;lt;core$&lt;em&gt;EQ&lt;/em&gt; clojure.core$&lt;em&gt;EQ&lt;/em&gt;@a947850&amp;gt; (4 9 16) (4 9 16))&lt;/p&gt;

&lt;p&gt;Can anyone decipher why this fails, or come up with a better solution?&lt;/p&gt;</description>
                <environment></environment>
            <key id="13769">CLJ-372</key>
            <summary>possible binding issue in clojure.template?</summary>
                <type id="1" iconUrl="http://dev.clojure.org/jira/images/icons/bug.gif">Defect</type>
                                        <status id="6" iconUrl="http://dev.clojure.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="2">Declined</resolution>
                                <assignee username="stuart.sierra">Stuart Sierra</assignee>
                                <reporter username="-1">None</reporter>
                        <labels>
                    </labels>
                <created>Thu, 3 Jun 2010 01:17:00 -0500</created>
                <updated>Fri, 1 Mar 2013 12:47:10 -0600</updated>
                    <resolved>Fri, 26 Nov 2010 08:54:42 -0600</resolved>
                                                                    <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                        <comments>
                    <comment id="23995" author="importer" created="Tue, 24 Aug 2010 11:29:00 -0500"  >&lt;p&gt;Converted from &lt;a href=&quot;http://www.assembla.com/spaces/clojure/tickets/372&quot;&gt;http://www.assembla.com/spaces/clojure/tickets/372&lt;/a&gt;&lt;br/&gt;
Attachments:&lt;br/&gt;
template-local-binding.patch - &lt;a href=&quot;https://www.assembla.com/spaces/clojure/documents/bEvfq-BS8r36foeJe5cbLA/download/bEvfq-BS8r36foeJe5cbLA&quot;&gt;https://www.assembla.com/spaces/clojure/documents/bEvfq-BS8r36foeJe5cbLA/download/bEvfq-BS8r36foeJe5cbLA&lt;/a&gt;&lt;/p&gt;</comment>
                    <comment id="23996" author="importer" created="Tue, 24 Aug 2010 11:29:00 -0500"  >&lt;p&gt;stuart.sierra said: Reason for the bizarre error is the awkwardness of using clojure.test to test itself.  clojure.test-clojure.test uses an alternate reporting function that looks at the doc string of the assertion.&lt;/p&gt;

&lt;p&gt;This can be fixed by placing the can-test-use-local-bindings test in a different namespace.&lt;/p&gt;</comment>
                    <comment id="23997" author="importer" created="Tue, 24 Aug 2010 11:29:00 -0500"  >&lt;p&gt;stuart.sierra said: I can&apos;t reproduce the error.  This works for me:&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; (are [x y] (= x y) &apos;(4 9 16) (map (fn [x] (* x x)) &apos;(2 3 4)))
&lt;span class=&quot;code-keyword&quot;&gt;true&lt;/span&gt;&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;</comment>
                    <comment id="25957" author="stuart.sierra" created="Fri, 26 Nov 2010 08:54:43 -0600"  >&lt;p&gt;Could not reproduce the reported error.&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="10004">Screened</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-695] pprint does not respect *print-length*</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-695</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;pprint does not respect &lt;tt&gt;&lt;b&gt;print-length&lt;/b&gt;&lt;/tt&gt; &amp;#8211; instead it prints ellipses for every element one length is passed (and prints forever on infinite collections).&lt;/p&gt;</description>
                <environment></environment>
            <key id="14304">CLJ-695</key>
            <summary>pprint does not respect *print-length*</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="6" iconUrl="http://dev.clojure.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Completed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="stu">Stuart Halloway</reporter>
                        <labels>
                    </labels>
                <created>Sat, 18 Dec 2010 15:11:14 -0600</created>
                <updated>Fri, 1 Mar 2013 12:47:10 -0600</updated>
                    <resolved>Fri, 31 Dec 2010 15:53:23 -0600</resolved>
                                            <fixVersion>Release 1.3</fixVersion>
                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                        <comments>
                    <comment id="26058" author="stu" created="Sat, 18 Dec 2010 15:14:28 -0600"  >&lt;p&gt;The attached patch is part of a possible fix. Issues to run down:&lt;/p&gt;

&lt;ul&gt;
	&lt;li&gt;where and how is the return value of &lt;tt&gt;write-out&lt;/tt&gt; used. (The changes I make eliminate this dependency in favor of a direct check of the dynamic variables.&lt;/li&gt;
	&lt;li&gt;how to make sets work? they are in a different code path than the others&lt;/li&gt;
&lt;/ul&gt;
</comment>
                    <comment id="26059" author="tomfaulhaber" created="Tue, 21 Dec 2010 02:36:20 -0600"  >&lt;p&gt;Hmm, looks like I broke some logic when I hand unrolled the original cl-format based dispatch to get better performance for lists, vectors, and maps. (Really I shouldn&apos;t have to do this, but I need to make cl-format itself generate code rather than threaded functions which are slow and tend to blow your stack. Haven&apos;t gotten around to that yet, though so the hand-coded versions are stop-gaps.)&lt;/p&gt;

&lt;p&gt;I&apos;m not digging the patch too much, though, for 3 reasons:&lt;/p&gt;

&lt;p&gt;1) It breaks sets and arrays, which work in master.&lt;br/&gt;
2) It pushes the logic for &lt;b&gt;print-length&lt;/b&gt; printing into the dispatch functions (redundantly since there&apos;s still logic in write-out). Since these are customizable, it places that load on whoever customizes it.&lt;br/&gt;
3) It adds redundant logic in write-out which is the called for every object that the pretty printer deals with.&lt;/p&gt;

&lt;p&gt;I&apos;ll try to take a stab at a patch that fits a little better with what I&apos;m trying to do in the next couple of days.&lt;/p&gt;</comment>
                    <comment id="26060" author="tomfaulhaber" created="Wed, 22 Dec 2010 03:13:01 -0600"  >&lt;p&gt;This fixes the the issue with hand-rolled dispatch functions and provides a macro to help other users do it correctly as well.&lt;/p&gt;</comment>
                    <comment id="26061" author="stu" created="Wed, 22 Dec 2010 21:03:14 -0600"  >&lt;p&gt;Second patch is good. This is more important because apparently the IDE REPLs use pprint by default.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="10059" name="0695-partial-fix.patch" size="4042" author="stu" created="Sat, 18 Dec 2010 15:14:28 -0600" />
                    <attachment id="10061" name="pprint-print-length-fix.diff" size="7884" author="tomfaulhaber" created="Wed, 22 Dec 2010 03:13:01 -0600" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_10002" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Approval</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10007">Ok</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-697] Compiler doesn&apos;t push a binding for *unchecked-math*</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-697</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;Compile.java in Clojure doesn&apos;t push a binding for &lt;b&gt;unchecked-math&lt;/b&gt;, so compilation of code with statements like (set! &lt;b&gt;unchecked-math&lt;/b&gt; true) fails with:&lt;/p&gt;

&lt;p&gt;Can&apos;t change/establish root binding of: &lt;b&gt;unchecked-math&lt;/b&gt; with set&lt;/p&gt;

&lt;p&gt;This problem doesn&apos;t happen with the REPL because with-bindings in clojure.main sets up an &lt;b&gt;unchecked-math&lt;/b&gt; binding.&lt;/p&gt;</description>
                <environment></environment>
            <key id="14306">CLJ-697</key>
            <summary>Compiler doesn&apos;t push a binding for *unchecked-math*</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="6" iconUrl="http://dev.clojure.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Completed</resolution>
                                <assignee username="alan@thinkrelevance.com">Alan Dipert</assignee>
                                <reporter username="alan@thinkrelevance.com">Alan Dipert</reporter>
                        <labels>
                    </labels>
                <created>Tue, 21 Dec 2010 16:20:19 -0600</created>
                <updated>Fri, 1 Mar 2013 12:47:10 -0600</updated>
                    <resolved>Wed, 5 Jan 2011 06:49:34 -0600</resolved>
                                            <fixVersion>Release 1.3</fixVersion>
                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                <attachments>
                    <attachment id="10060" name="697_unchecked_math.diff" size="1788" author="alan@thinkrelevance.com" created="Tue, 21 Dec 2010 16:21:55 -0600" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_10002" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Approval</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10007">Ok</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>stu</customfieldvalue>
                </customfieldvalues>
            </customfield>
                            </customfields>
    </item>

<item>
            <title>[CLJ-682] cl-format: ~w throws an exception when not wrapped in a pretty-writer</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-682</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;(cl-format nil &quot;hello: &lt;sub&gt;w&lt;/sub&gt;%&quot; &apos;(a b c)) &lt;/p&gt;

&lt;p&gt;throws an exception because ~w is (kind of ironically) not marked :pretty in the cl-format definition.&lt;/p&gt;</description>
                <environment></environment>
            <key id="14290">CLJ-682</key>
            <summary>cl-format: ~w throws an exception when not wrapped in a pretty-writer</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="6" iconUrl="http://dev.clojure.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Completed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="tomfaulhaber">Tom Faulhaber</reporter>
                        <labels>
                    </labels>
                <created>Sat, 27 Nov 2010 14:23:41 -0600</created>
                <updated>Fri, 1 Mar 2013 12:47:10 -0600</updated>
                    <resolved>Fri, 31 Dec 2010 15:53:23 -0600</resolved>
                            <version>Release 1.2</version>
                                <fixVersion>Release 1.3</fixVersion>
                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                        <comments>
                    <comment id="26065" author="tomfaulhaber" created="Wed, 29 Dec 2010 01:34:41 -0600"  >&lt;p&gt;This one-line patch resolves the issue.&lt;/p&gt;</comment>
                    <comment id="26066" author="tomfaulhaber" created="Wed, 29 Dec 2010 01:35:48 -0600"  >&lt;p&gt;OK, this is ready to be applied to master.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="10062" name="clj-682-patch.diff" size="875" author="tomfaulhaber" created="Wed, 29 Dec 2010 01:34:41 -0600" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_10002" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Approval</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10007">Ok</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-712] JIRA email and contact info</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-712</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;From Daniel: &lt;br/&gt;
I have come across a small issue with some of the e-mails sent from&lt;br/&gt;
JIRA.  The &apos;from&apos; address used in some of the e-mails it sends is&lt;br/&gt;
currently set to &apos;jira@dev.clojure.com&apos;.  However, the domain&lt;br/&gt;
&apos;dev.clojure.com&apos; does not resolve via DNS.  As a result, some mail&lt;br/&gt;
systems reject these mails as the domain is not found.  Presumably, the&lt;br/&gt;
domain should be &apos;dev.clojure.org&apos;.&lt;/p&gt;

&lt;p&gt;I am not sure to whom to direct this issue, as JIRA&apos;s &apos;Contact&lt;br/&gt;
Administrators&apos; page does not list anyone.  I hope that you can resolve&lt;br/&gt;
this issue so as to keep this from affecting anyone else.&lt;/p&gt;

&lt;p&gt;Please fix both problems (email and contact admins).&lt;/p&gt;</description>
                <environment></environment>
            <key id="14321">CLJ-712</key>
            <summary>JIRA email and contact info</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="6" iconUrl="http://dev.clojure.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Completed</resolution>
                                <assignee username="aaron">Aaron Bedra</assignee>
                                <reporter username="dsg">Daniel Solano G&#243;mez</reporter>
                        <labels>
                    </labels>
                <created>Mon, 10 Jan 2011 13:41:39 -0600</created>
                <updated>Fri, 1 Mar 2013 12:47:10 -0600</updated>
                    <resolved>Tue, 22 Feb 2011 19:25:22 -0600</resolved>
                                                                    <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                        <comments>
                    <comment id="26130" author="aaron" created="Fri, 14 Jan 2011 13:42:31 -0600"  >&lt;p&gt;The contact page now has a list of administrators and the email address has been updated to dev.clojure.org as the sending domain&lt;/p&gt;</comment>
                    <comment id="26158" author="dsg" created="Sat, 22 Jan 2011 22:34:41 -0600"  >&lt;p&gt;I just did a bit of testing by sending myself some password reset mails (as I had done originally).  Unfortunately, the problem remains.&lt;/p&gt;

&lt;p&gt;To be more specific, the mails sent from JIRA related to issue status updates seem to work fine.  It is the password reset mails that are not working.  Unfortunately, I do not know enough about JIRA to provide any other clues as to what is misconfigured.&lt;/p&gt;</comment>
                    <comment id="26178" author="aaron" created="Wed, 26 Jan 2011 07:29:46 -0600"  >&lt;p&gt;Grrrrrr.  Thanks for pointing that out.  I didn&apos;t realize that you had to change it in more than one place.  I&apos;ll get this taken care of as well.&lt;/p&gt;</comment>
                    <comment id="26184" author="aaron" created="Fri, 28 Jan 2011 09:34:06 -0600"  >&lt;p&gt;Ok I have updated and confirmed that the email address for user account creation (and from anything system releated) is now coming from dev.clojure.org.&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="10007">Ok</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_10003" key="com.atlassian.jira.plugin.system.customfieldtypes:userpicker">
                <customfieldname>Waiting On</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>stu</customfieldvalue>
                </customfieldvalues>
            </customfield>
                            </customfields>
    </item>

<item>
            <title>[CLJ-738] &lt;= is incorrect when args include Double/NaN</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-738</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;user&amp;gt; (&amp;lt;= 10 Double/NaN 1)&lt;br/&gt;
true&lt;/p&gt;

&lt;p&gt;(on both 1.2 and 1.3 alpha 5).  &lt;/p&gt;</description>
                <environment>Mac OS X, Java 6</environment>
            <key id="14352">CLJ-738</key>
            <summary>&lt;= is incorrect when args include Double/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="6" iconUrl="http://dev.clojure.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Completed</resolution>
                                <assignee username="lvanderhart">Luke VanderHart</assignee>
                                <reporter username="jawolfe">Jason Wolfe</reporter>
                        <labels>
                    </labels>
                <created>Mon, 14 Feb 2011 19:07:09 -0600</created>
                <updated>Fri, 1 Mar 2013 12:47:10 -0600</updated>
                    <resolved>Fri, 26 Aug 2011 11:35:55 -0500</resolved>
                            <version>Release 1.3</version>
                                <fixVersion>Release 1.3</fixVersion>
                                        <due></due>
                    <votes>1</votes>
                        <watches>4</watches>
                        <comments>
                    <comment id="26217" author="jawolfe" created="Mon, 14 Feb 2011 19:18:05 -0600"  >&lt;p&gt;The source of the issue seems to be incorrect treatment of boxed NaN:&lt;/p&gt;

&lt;p&gt;user&amp;gt; (&amp;lt;= 1000 (Double. Double/NaN))&lt;br/&gt;
true&lt;br/&gt;
user&amp;gt; (&amp;lt;= 1000 (double Double/NaN))&lt;br/&gt;
false&lt;/p&gt;</comment>
                    <comment id="26251" author="ataggart" created="Mon, 28 Feb 2011 23:14:30 -0600"  >&lt;p&gt;Primitive comparisons use java&apos;s primitive operators directly, which always return false for NaN, even when testing equality between two NaNs.&lt;/p&gt;

&lt;p&gt;In clojure, Number comparisons are all logical variations around calls to Numbers.Ops.lt(Number, Number).  So a call to &lt;tt&gt;(&amp;lt;= x y)&lt;/tt&gt; is actually a call to &lt;tt&gt;(not (&amp;lt; y x))&lt;/tt&gt;, which eventually uses the primitive &lt;tt&gt;&amp;lt;&lt;/tt&gt; operator.  Alas that logical premise doesn&apos;t hold when dealing with NaN:&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; (&amp;lt;= 1 Double/NaN)
false
user=&amp;gt; (not (&amp;lt; Double/NaN 1))
true
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;So the bug is not that boxed NaN is treated incorrectly, but rather:&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; (&amp;lt;= 1000 (Double. Double/NaN)) ; becomes !(NaN &amp;lt; 1000) 
true
user&amp;gt; (&amp;lt;= 1000 (double Double/NaN))  ; becomes (1000 &amp;lt;= NaN)
false
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;
&lt;p&gt;In the original example, since there are more than two args, the primitive looking args were boxed:&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; (&amp;lt;= 10 Double/NaN 1) ; equivalent to logical-and of the following
true
user=&amp;gt; (&amp;lt;= 10 (Double. Double/NaN))  ; becomes !(NaN &amp;lt; 10)
true
user=&amp;gt; (&amp;lt;= (Double. Double/NaN) 1)   ; becomes !(1 &amp;lt; NaN)
true
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;Note however that java object comparisons for NaNs behave differently: NaN is the largest Double, and NaNs equal each other (see the &lt;a href=&quot;http://download.oracle.com/javase/6/docs/api/java/lang/Double.html#compareTo(java.lang.Double)&quot;&gt;javadoc&lt;/a&gt;).&lt;/p&gt;

&lt;p&gt;If we make object NaN comparisons always return false, we would need to add the rest of the comparison methods to &lt;tt&gt;Numbers.Ops&lt;/tt&gt;.  Yet doing so could also make collection sorting algorithms behave oddly, deviating from sorting written in java. Besides, &lt;tt&gt;(= NaN NaN) =&amp;gt; false&lt;/tt&gt; is annoying.&lt;/p&gt;

&lt;p&gt;Clojure already throws out the notion of error-free dividing by zero (which for doubles would otherwise result in NaN or Infinity, depending on the dividend).  Perhaps we could similarly error on NaNs passed to clojure numeric ops.  They seem to be more trouble than they&apos;re worth.  That said, people smarter than me thought they were useful.&lt;/p&gt;

&lt;p&gt;Then there&apos;s that -0.0 nonsense...&lt;/p&gt;</comment>
                    <comment id="26314" author="jks" created="Sat, 19 Mar 2011 15:02:14 -0500"  >&lt;p&gt;On current master, &lt;tt&gt;(&amp;lt;= x y)&lt;/tt&gt; seems to be special-cased by the compiler, but when &lt;tt&gt;&amp;lt;=&lt;/tt&gt; is called dynamically, the bug is still there:&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; (&amp;lt;= 1 Float/NaN)
false
user=&amp;gt; (let [op &amp;lt;=] (op 1 Float/NaN))
true
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;
&lt;p&gt;Since &lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-354&quot; title=&quot;&amp;lt;= and &amp;gt;= comparisons against NaN return true&quot;&gt;&lt;del&gt;CLJ-354&lt;/del&gt;&lt;/a&gt; got marked &quot;Completed&quot;, perhaps there was an attempt to fix this.&lt;/p&gt;</comment>
                    <comment id="26317" author="ataggart" created="Sat, 19 Mar 2011 18:45:55 -0500"  >&lt;p&gt;Using &lt;tt&gt;let&lt;/tt&gt; forces calling &lt;tt&gt;&amp;lt;=&lt;/tt&gt; as a function rather than inlining &lt;tt&gt;Numbers/lte&lt;/tt&gt;, which means the args are treated as objects not primitives, thus the different behaviour as I discussed earlier.&lt;/p&gt;</comment>
                    <comment id="26537" author="aaron" created="Tue, 28 Jun 2011 18:28:31 -0500"  >&lt;p&gt;Rich, what should the behavior be?&lt;/p&gt;</comment>
                    <comment id="26543" author="jks" created="Wed, 29 Jun 2011 01:22:26 -0500"  >&lt;p&gt;My suggestion for the behavior is to follow Java (Java Language Specification &#167;15.20.1) and IEEE 754. The java.sun.com site seems to be down right now, but here&apos;s a Google cache link:&lt;/p&gt;

&lt;p&gt;&lt;a href=&quot;http://webcache.googleusercontent.com/search?q=cache:http://java.sun.com/docs/books/jls/third_edition/html/expressions.html#15.20.1&quot;&gt;http://webcache.googleusercontent.com/search?q=cache:http://java.sun.com/docs/books/jls/third_edition/html/expressions.html#15.20.1&lt;/a&gt;&lt;/p&gt;</comment>
                    <comment id="26671" author="richhickey" created="Fri, 29 Jul 2011 07:48:02 -0500"  >&lt;p&gt;It should work the same as primitive double in all cases&lt;/p&gt;</comment>
                    <comment id="26736" author="lvanderhart" created="Fri, 26 Aug 2011 11:33:15 -0500"  >&lt;p&gt;Added patches. The problem was that our logic for lte/gte depended on the fact that lte is equivalent to !gt. &lt;/p&gt;

&lt;p&gt;However, in Java, this assumption is invalid - any comparison involving NaN always yields false.&lt;/p&gt;

&lt;p&gt;The fix was to adding lte and gte methods to Numbers.Ops directly, rather than implementing everything in terms of lt. This was the only fix I could see that didn&apos;t incur the cost of runtime checks for NaN.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="10321" name="738.diff" size="3932" author="lvanderhart" created="Fri, 26 Aug 2011 11:33:15 -0500" />
                    <attachment id="10322" name="738-tests.diff" size="2720" author="lvanderhart" created="Fri, 26 Aug 2011 11:33: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-856] Building Clojure (git head) on JDK7 fails</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-856</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;lnostdal@blackbox:~/programming/clojure$ ant&lt;br/&gt;
Buildfile: /home/lnostdal/programming/clojure/build.xml&lt;/p&gt;

&lt;p&gt;clean:&lt;br/&gt;
   &lt;span class=&quot;error&quot;&gt;&amp;#91;delete&amp;#93;&lt;/span&gt; Deleting directory /home/lnostdal/programming/clojure/target&lt;br/&gt;
   &lt;span class=&quot;error&quot;&gt;&amp;#91;delete&amp;#93;&lt;/span&gt; Deleting /home/lnostdal/programming/clojure/clojure-1.4.0-master-SNAPSHOT.jar&lt;br/&gt;
   &lt;span class=&quot;error&quot;&gt;&amp;#91;delete&amp;#93;&lt;/span&gt; Deleting /home/lnostdal/programming/clojure/clojure.jar&lt;/p&gt;

&lt;p&gt;init:&lt;br/&gt;
    &lt;span class=&quot;error&quot;&gt;&amp;#91;mkdir&amp;#93;&lt;/span&gt; Created dir: /home/lnostdal/programming/clojure/target/classes&lt;br/&gt;
    &lt;span class=&quot;error&quot;&gt;&amp;#91;mkdir&amp;#93;&lt;/span&gt; Created dir: /home/lnostdal/programming/clojure/target/classes/clojure&lt;/p&gt;

&lt;p&gt;compile-java:&lt;br/&gt;
    &lt;span class=&quot;error&quot;&gt;&amp;#91;javac&amp;#93;&lt;/span&gt; /home/lnostdal/programming/clojure/build.xml:39: warning: &apos;includeantruntime&apos; was not set, defaulting to build.sysclasspath=last; set to false for repeatable builds&lt;br/&gt;
    &lt;span class=&quot;error&quot;&gt;&amp;#91;javac&amp;#93;&lt;/span&gt; Compiling 144 source files to /home/lnostdal/programming/clojure/target/classes&lt;br/&gt;
    &lt;span class=&quot;error&quot;&gt;&amp;#91;javac&amp;#93;&lt;/span&gt; javac: target release 1.5 conflicts with default source release 1.7&lt;/p&gt;

&lt;p&gt;BUILD FAILED&lt;br/&gt;
/home/lnostdal/programming/clojure/build.xml:39: Compile failed; see the compiler error output for details.&lt;/p&gt;

&lt;p&gt;Total time: 0 seconds&lt;/p&gt;



&lt;p&gt;lnostdal@blackbox:~/programming/clojure$ emacs -nw build.xml &lt;br/&gt;
lnostdal@blackbox:~/programming/clojure$ git diff&lt;br/&gt;
diff --git a/build.xml b/build.xml&lt;br/&gt;
index a693e6d..c05adf8 100644&lt;br/&gt;
&amp;#8212; a/build.xml&lt;br/&gt;
+++ b/build.xml&lt;br/&gt;
@@ -36,7 +36,7 @@&lt;br/&gt;
   &amp;lt;target name=&quot;compile-java&quot; depends=&quot;init&quot;&lt;br/&gt;
           description=&quot;Compile Java sources.&quot;&amp;gt;&lt;br/&gt;
     &amp;lt;javac srcdir=&quot;${jsrc}&quot; destdir=&quot;${build}&quot; includeJavaRuntime=&quot;yes&quot;&lt;/p&gt;
&lt;ul class=&quot;alternate&quot; type=&quot;square&quot;&gt;
	&lt;li&gt;debug=&quot;true&quot; target=&quot;1.5&quot;/&amp;gt;&lt;br/&gt;
+           debug=&quot;true&quot;/&amp;gt;&lt;br/&gt;
   &amp;lt;/target&amp;gt;&lt;/li&gt;
&lt;/ul&gt;


&lt;p&gt;   &amp;lt;target name=&quot;compile-clojure&quot;&lt;/p&gt;



&lt;p&gt;lnostdal@blackbox:~/programming/clojure$ ant&lt;br/&gt;
...&lt;br/&gt;
...&lt;/p&gt;

&lt;p&gt;..and it builds OK. I don&apos;t understand the Java tools very well, but I decided to try removing &quot;target&quot; based on what I found here: &lt;a href=&quot;http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6856165&quot;&gt;http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6856165&lt;/a&gt;&lt;/p&gt;</description>
                <environment>linux, &amp;quot;1.7.0_02-ea&amp;quot;, x86-64</environment>
            <key id="14693">CLJ-856</key>
            <summary>Building Clojure (git head) on JDK7 fails</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="6" iconUrl="http://dev.clojure.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Completed</resolution>
                                <assignee username="stuart.sierra">Stuart Sierra</assignee>
                                <reporter username="lnostdal">Lars Rune N&#248;stdal</reporter>
                        <labels>
                    </labels>
                <created>Wed, 12 Oct 2011 00:31:14 -0500</created>
                <updated>Fri, 1 Mar 2013 12:47:10 -0600</updated>
                    <resolved>Fri, 27 Jan 2012 09:40:20 -0600</resolved>
                                                                    <due></due>
                    <votes>1</votes>
                        <watches>1</watches>
                        <comments>
                    <comment id="27088" author="stu" created="Tue, 25 Oct 2011 18:03:06 -0500"  >&lt;p&gt;Based on the Sun bug link above, it seems to me we need to add the source=&quot;1.5&quot; flag if we want to be able to build on 1.7&lt;/p&gt;</comment>
                    <comment id="27489" author="tsdh" created="Fri, 23 Dec 2011 03:54:18 -0600"  >&lt;p&gt;Exactly, Stuart.  Here is a patch.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="10752" name="0002-Set-source-level-explicitly-to-1.5-to-make-clojure-c.patch" size="1242" author="tsdh" created="Fri, 23 Dec 2011 03:54:18 -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-998] doc string for replace-first mentions non-existent replace-all</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-998</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;The doc string for clojure.string/replace-first says see also replace-all, which does not exist.  The actual function is simply &apos;replace&apos;.&lt;/p&gt;</description>
                <environment></environment>
            <key id="15455">CLJ-998</key>
            <summary>doc string for replace-first mentions non-existent replace-all</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="6" iconUrl="http://dev.clojure.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="3">Duplicate</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="steveminer@gmail.com">Steve Miner</reporter>
                        <labels>
                        <label>documentation</label>
                    </labels>
                <created>Fri, 18 May 2012 11:34:39 -0500</created>
                <updated>Fri, 1 Mar 2013 12:47:10 -0600</updated>
                    <resolved>Fri, 18 May 2012 11:43:06 -0500</resolved>
                            <version>Release 1.3</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>1</watches>
                        <comments>
                    <comment id="28523" author="jafingerhut" created="Fri, 18 May 2012 11:42:21 -0500"  >&lt;p&gt;&lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-870&quot; title=&quot;clojure.string/replace behaves unexpectedly when \ or $ are part of the result string&quot;&gt;&lt;del&gt;CLJ-870&lt;/del&gt;&lt;/a&gt; patch file &lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-753&quot; title=&quot;clojure.string/replace-first returns nil with replacement fn when regex doesn&amp;#39;t match&quot;&gt;&lt;del&gt;CLJ-753&lt;/del&gt;&lt;/a&gt;-870-905-combined-fix3.patch dated Feb 28, 2012 fixes this issue, some other doc string issues, and fixes to the code.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="11228" name="0001-fix-doc-string-for-replace-first.patch" size="725" author="steveminer@gmail.com" created="Fri, 18 May 2012 11:34: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-1038] Docstring for deliver doesn&apos;t match behavior</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1038</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;The docstring for deliver doesn&apos;t match the actual behavior. It says an exception gets thrown on multiple delivers, but that&apos;s no longer the case, as of 1.3 (hat tip to clgv on irc).&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; (doc deliver)
-------------------------
clojure.core/deliver
([promise val])
  Alpha - subject to change.
  Delivers the supplied value to the promise, releasing any pending
  derefs. A subsequent call to deliver on a promise will &lt;span class=&quot;code-keyword&quot;&gt;throw&lt;/span&gt; an exception.
nil&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;(let [p (promise)] 
  (deliver p &lt;span class=&quot;code-quote&quot;&gt;&quot;hi&quot;&lt;/span&gt;) 
  (deliver p &lt;span class=&quot;code-quote&quot;&gt;&quot;bye&quot;&lt;/span&gt;) 
  @p)
;=&amp;gt; &lt;span class=&quot;code-quote&quot;&gt;&quot;hi&quot;&lt;/span&gt;&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;This patch updates the docstring to reflect actual behavior: &quot;will throw an exception.&quot; -&amp;gt; &quot;will have no effect.&quot;&lt;/p&gt;</description>
                <environment></environment>
            <key id="15615">CLJ-1038</key>
            <summary>Docstring for deliver doesn&apos;t match behavior</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="6" iconUrl="http://dev.clojure.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Completed</resolution>
                                <assignee username="trptcolin">Colin Jones</assignee>
                                <reporter username="trptcolin">Colin Jones</reporter>
                        <labels>
                        <label>documentation</label>
                    </labels>
                <created>Tue, 7 Aug 2012 16:47:29 -0500</created>
                <updated>Fri, 1 Mar 2013 12:47:10 -0600</updated>
                    <resolved>Fri, 24 Aug 2012 07:41:47 -0500</resolved>
                            <version>Release 1.3</version>
                <version>Release 1.4</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>1</watches>
                        <comments>
                    <comment id="29107" author="stu" created="Fri, 10 Aug 2012 13:48:57 -0500"  >&lt;p&gt;Both patches are correct. Colin&apos;s patch documents the side effect, my variant also commits to the return values. Take your pick.&lt;/p&gt;</comment>
                    <comment id="29110" author="richhickey" created="Fri, 10 Aug 2012 15:09:35 -0500"  >&lt;p&gt;Don&apos;t doc return&lt;/p&gt;</comment>
                    <comment id="29259" author="stuart.sierra" created="Fri, 24 Aug 2012 07:41:47 -0500"  >&lt;p&gt;&lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-1038&quot; title=&quot;Docstring for deliver doesn&amp;#39;t match behavior&quot;&gt;&lt;del&gt;CLJ-1038&lt;/del&gt;&lt;/a&gt; Update docstring for deliver&apos;s actual behavior (patch applied Aug 15, 2012) &lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="11413" name="0001-Update-docstring-for-deliver-s-actual-behavior.patch" size="847" author="trptcolin" created="Tue, 7 Aug 2012 16:47:29 -0500" />
                    <attachment id="11419" name="correct-deliver-docstring.patch" size="945" author="stu" created="Fri, 10 Aug 2012 13:48:57 -0500" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_10002" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Approval</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10007">Ok</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-689] Audit and update all user permissions on the hudson machine</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-689</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;Currently, the small handful of users are all hudson administrators.  With Stuart Sierra&apos;s pending changes to the build process, the hudson box will be doing all releases of Clojure.  This means that only a few people should be able to run the -alpha, -beta, and stable releases.  &lt;/p&gt;</description>
                <environment></environment>
            <key id="14298">CLJ-689</key>
            <summary>Audit and update all user permissions on the hudson machine</summary>
                <type id="3" iconUrl="http://dev.clojure.org/jira/images/icons/task.gif">Task</type>
                                <priority id="2" iconUrl="http://dev.clojure.org/jira/images/icons/priority_critical.gif">Critical</priority>
                    <status id="6" iconUrl="http://dev.clojure.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Completed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="aaron">Aaron Bedra</reporter>
                        <labels>
                    </labels>
                <created>Sun, 12 Dec 2010 19:14:55 -0600</created>
                <updated>Fri, 1 Mar 2013 12:47:08 -0600</updated>
                    <resolved>Tue, 22 Feb 2011 17:07:57 -0600</resolved>
                            <version>Release 1.3</version>
                                <fixVersion>Release 1.3</fixVersion>
                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                        <comments>
                    <comment id="26076" author="stu" created="Fri, 31 Dec 2010 16:05:55 -0600"  >&lt;p&gt;For some reason this was incorrectly marked as OK. When the work is complete, please mark as Screened with a note showing Rich where to go to verify.&lt;/p&gt;</comment>
                    <comment id="26080" author="aaron" created="Mon, 3 Jan 2011 07:31:08 -0600"  >&lt;p&gt;Bah! That shouldn&apos;t have happened.  I got a 500 from JIRA after trying to update the ticket and figured I would visit it when I had more time.  Looks like it ended up being set the wrong way.  Anyways, the permissions have been updated and are in need of a review.&lt;/p&gt;</comment>
                    <comment id="26089" author="stu" created="Wed, 5 Jan 2011 06:50:57 -0600"  >&lt;p&gt;Please grab someone in the office and walk them through what you have done (documenting it here) so we can mark this complete.&lt;/p&gt;</comment>
                    <comment id="26195" author="stuart.sierra" created="Fri, 28 Jan 2011 14:09:42 -0600"  >&lt;p&gt;Audit completed; results and recommendations communicated privately.&lt;/p&gt;</comment>
                    <comment id="26202" author="stuart.sierra" created="Fri, 28 Jan 2011 15:52:52 -0600"  >&lt;p&gt;Verified Aaron&apos;s fixes.&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="10007">Ok</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-149] pop does not preserve meta-data</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-149</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;As discussed with chouser on irc.&lt;/p&gt;

&lt;p&gt;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;=&amp;gt; (meta (conj (with-meta &apos;(1 2 3) {:my :meta}) 4))
{:my :meta}
=&amp;gt; (meta (pop (with-meta &apos;(1 2 3) {:my :meta}))) 
nil&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;Both calls should yield the same result.&lt;/p&gt;

&lt;p&gt;This occurs in 1.0.0 as well as trunk.  &lt;/p&gt;

&lt;p&gt;This might be part of a larger issue with when meta-data should be preserved (e.g., &lt;tt&gt;butlast&lt;/tt&gt;).&lt;/p&gt;</description>
                <environment></environment>
            <key id="13546">CLJ-149</key>
            <summary>pop does not preserve meta-data</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="6" iconUrl="http://dev.clojure.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="2">Declined</resolution>
                                <assignee username="aaron">Aaron Bedra</assignee>
                                <reporter username="importer">Assembla Importer</reporter>
                        <labels>
                    </labels>
                <created>Fri, 10 Jul 2009 15:41:00 -0500</created>
                <updated>Fri, 1 Mar 2013 12:47:08 -0600</updated>
                    <resolved>Sat, 19 Mar 2011 10:09:39 -0500</resolved>
                                            <fixVersion>Release 1.3</fixVersion>
                                        <due></due>
                    <votes>0</votes>
                        <watches>1</watches>
                        <comments>
                    <comment id="22992" author="importer" created="Sun, 3 Oct 2010 16:08:00 -0500"  >&lt;p&gt;Converted from &lt;a href=&quot;http://www.assembla.com/spaces/clojure/tickets/149&quot;&gt;http://www.assembla.com/spaces/clojure/tickets/149&lt;/a&gt;&lt;/p&gt;</comment>
                    <comment id="22993" author="importer" created="Sun, 3 Oct 2010 16:08:00 -0500"  >&lt;p&gt;chouser@n01se.net said: Alex, sorry if my various statements mislead you.  What you described may be a bug, but I don&apos;t know that for sure.  Rich would have to rule on what the desired behavior is there.&lt;/p&gt;

&lt;p&gt;However, I&apos;m pretty sure that the metadata is getting lost here incorrectly:&lt;/p&gt;

&lt;p&gt;&amp;lt;pre&amp;gt;&lt;br/&gt;
  (let [v (with-meta &lt;span class=&quot;error&quot;&gt;&amp;#91;1 2 3&amp;#93;&lt;/span&gt; {:my :meta})]&lt;br/&gt;
    (map meta &lt;span class=&quot;error&quot;&gt;&amp;#91;(conj v 4) (pop v)&amp;#93;&lt;/span&gt;))&lt;/p&gt;

&lt;p&gt;  returns: (nil nil)&lt;br/&gt;
&amp;lt;/pre&amp;gt;&lt;/p&gt;

&lt;p&gt;Because if you start with a PersistentVector instead of a LazilyPersistentVector, the metadata is preserved:&lt;/p&gt;

&lt;p&gt;&amp;lt;pre&amp;gt;&lt;br/&gt;
  (let [v (with-meta (pop &lt;span class=&quot;error&quot;&gt;&amp;#91;1 2 3&amp;#93;&lt;/span&gt;) {:my :meta})]&lt;br/&gt;
    (map meta &lt;span class=&quot;error&quot;&gt;&amp;#91;(conj v 4) (pop v)&amp;#93;&lt;/span&gt;))&lt;/p&gt;

&lt;p&gt;  returns: ({:my :meta} {:my :meta})&lt;br/&gt;
&amp;lt;/pre&amp;gt;&lt;/p&gt;

&lt;p&gt;The problem seems to be that metadata is lost when the LazilyPersistentVector is converted to a PersistentVector.  I&apos;ll attach a patch to address this.&lt;/p&gt;</comment>
                    <comment id="22994" author="importer" created="Sun, 3 Oct 2010 16:08:00 -0500"  >&lt;p&gt;chouser@n01se.net said: [&lt;a href=&quot;file:dBRCkCBBar3QrKeJe5aVNr&quot;&gt;file:dBRCkCBBar3QrKeJe5aVNr&lt;/a&gt;]: Move metadata from LazilyPersistentVectors to PersistentVectors when the latter are created.&lt;/p&gt;</comment>
                    <comment id="22995" author="importer" created="Sun, 3 Oct 2010 16:08:00 -0500"  >&lt;p&gt;richhickey said: That diff doesn&apos;t seem to be the right one&lt;/p&gt;</comment>
                    <comment id="22996" author="importer" created="Sun, 3 Oct 2010 16:08:00 -0500"  >&lt;p&gt;chouser@n01se.net said: Bother.  I think I deleted my local copy of the correct patch after attaching the incorrect one here.&lt;/p&gt;

&lt;p&gt;It just added .withMeta(meta()) in LazilyPersistentVector&apos;s v() method, plus some related unit tests.  I&apos;ll recreate it when I get a chance.&lt;/p&gt;</comment>
                    <comment id="22997" author="importer" created="Sun, 3 Oct 2010 16:08:00 -0500"  >&lt;p&gt;richhickey said: Updating tickets (#8, #42, #113, #2, #20, #94, #96, #104, #119, #124, #127, #149, #162)&lt;/p&gt;</comment>
                    <comment id="25933" author="aredington" created="Fri, 12 Nov 2010 10:15:22 -0600"  >&lt;p&gt;Reported behavior is still observed in the latest development sources.&lt;/p&gt;</comment>
                    <comment id="26253" author="ataggart" created="Tue, 1 Mar 2011 01:45:06 -0600"  >&lt;p&gt;PersistentList.pop() will now create a new head of the forthcoming list if it doesn&apos;t share the same metadata instance.&lt;/p&gt;</comment>
                    <comment id="26267" author="stu" created="Fri, 4 Mar 2011 15:27:45 -0600"  >&lt;p&gt;This works as advertised, but I am unclear on what &lt;b&gt;should&lt;/b&gt; happen. Given&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;(a b)&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;where both the conses have metadata, what rule specifies which metadata should be left after &lt;tt&gt;pop&lt;/tt&gt;? If there is a rule, we should document it, and I bet there are other breakages.&lt;/p&gt;</comment>
                    <comment id="26296" author="richhickey" created="Thu, 10 Mar 2011 11:32:07 -0600"  >&lt;p&gt;This is a non-problem (but the vector one Chouser found is a real problem). Lists are not going to create new heads to convey metadata on pop. Lists really are chains of things, not encapsulations of chains of things. The metadata of the second link is what it was, and shouldn&apos;t be lost by pop, i.e. pop should not construct a new list as it goes.&lt;/p&gt;</comment>
                    <comment id="26298" author="ataggart" created="Thu, 10 Mar 2011 12:50:55 -0600"  >&lt;p&gt;Very well. Note that the failure example chouser gave no longer occurs:&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; (let [v (with-meta [1 2 3] {:my :meta})]
         (map meta [(conj v 4) (pop v)]))
({:my :meta} {:my :meta})
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&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="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-191] enhance stacktrace: causes like java, syntax like clojure</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-191</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;Various enhancements I&apos;d like to make:&lt;br/&gt;
Copy the feature of java stacktrace to print &quot;... 25 more&quot; instead of duplicating stack lines.&lt;br/&gt;
Print java class.method in clojure format: class/method. &lt;/p&gt;

&lt;p&gt;Discussion: &lt;a href=&quot;http://groups.google.com/group/clojure-dev/browse_thread/thread/d03dd16acbe3aa14&quot;&gt;http://groups.google.com/group/clojure-dev/browse_thread/thread/d03dd16acbe3aa14&lt;/a&gt;&lt;/p&gt;</description>
                <environment></environment>
            <key id="13588">CLJ-191</key>
            <summary>enhance stacktrace: causes like java, syntax like clojure</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="6" iconUrl="http://dev.clojure.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="2">Declined</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="importer">Assembla Importer</reporter>
                        <labels>
                    </labels>
                <created>Mon, 14 Sep 2009 03:25:00 -0500</created>
                <updated>Fri, 1 Mar 2013 12:47:08 -0600</updated>
                    <resolved>Fri, 31 Dec 2010 15:55:31 -0600</resolved>
                                            <fixVersion>Release 1.3</fixVersion>
                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                        <comments>
                    <comment id="23189" author="importer" created="Wed, 1 Sep 2010 09:39:00 -0500"  >&lt;p&gt;Converted from &lt;a href=&quot;http://www.assembla.com/spaces/clojure/tickets/191&quot;&gt;http://www.assembla.com/spaces/clojure/tickets/191&lt;/a&gt;&lt;br/&gt;
Attachments:&lt;br/&gt;
clojure-191-stacktrace.patch - &lt;a href=&quot;https://www.assembla.com/spaces/clojure/documents/dz8x6oOqar3PnLeJe5afGb/download/dz8x6oOqar3PnLeJe5afGb&quot;&gt;https://www.assembla.com/spaces/clojure/documents/dz8x6oOqar3PnLeJe5afGb/download/dz8x6oOqar3PnLeJe5afGb&lt;/a&gt;&lt;/p&gt;</comment>
                    <comment id="23190" author="importer" created="Wed, 1 Sep 2010 09:39:00 -0500"  >&lt;p&gt;mikehinchey said: [&lt;a href=&quot;file:dz8x6oOqar3PnLeJe5afGb&quot;&gt;file:dz8x6oOqar3PnLeJe5afGb&lt;/a&gt;]: enhance stacktrace&lt;/p&gt;</comment>
                    <comment id="23191" author="importer" created="Wed, 1 Sep 2010 09:39:00 -0500"  >&lt;p&gt;mikehinchey said: Printing causes, abridge duplicated stack lines with ... (same as java printStackTrace does).&lt;br/&gt;
Improve matching and reformatting of stack lines of clj code.&lt;br/&gt;
(e) takes an optional argument. (e) prints all causes.&lt;br/&gt;
Created unit tests for stacktrace (succeeds in repl and ant).&lt;/p&gt;</comment>
                    <comment id="23192" author="importer" created="Wed, 1 Sep 2010 09:39:00 -0500"  >&lt;p&gt;richhickey said: I&apos;m not sure this is the patch, but I&apos;d like to get improved stack traces on the agenda again. See also &lt;a href=&quot;http://github.com/mmcgrana/clj-stacktrace&quot;&gt;http://github.com/mmcgrana/clj-stacktrace&lt;/a&gt; and other ideas.&lt;/p&gt;</comment>
                    <comment id="23193" author="importer" created="Wed, 1 Sep 2010 09:39:00 -0500"  >&lt;p&gt;richhickey said: Some work has been done in master, little feedback at present&lt;/p&gt;</comment>
                    <comment id="26021" author="aaron" created="Fri, 10 Dec 2010 10:10:57 -0600"  >&lt;p&gt;Further discussion on this ticket is at &lt;a href=&quot;http://dev.clojure.org/display/design/Stacktraces&quot;&gt;http://dev.clojure.org/display/design/Stacktraces&lt;/a&gt; and should be the basis for any future discussion and eventual design sign off.&lt;/p&gt;</comment>
                    <comment id="26074" author="stu" created="Fri, 31 Dec 2010 15:55:31 -0600"  >&lt;p&gt;This will be subsumed under the changes being proposed at &lt;a href=&quot;http://dev.clojure.org/display/design/Error+Handling&quot;&gt;http://dev.clojure.org/display/design/Error+Handling&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-784] Update min/max functions to take advantage of primitive math</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-784</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;Currently, the &lt;tt&gt;min&lt;/tt&gt; and &lt;tt&gt;max&lt;/tt&gt; functions are quite slow, since they don&apos;t take advantage of new primitive math.&lt;/p&gt;

&lt;p&gt;Implement them in the same manner in which other primitive math functions are implemented for efficiency.&lt;/p&gt;</description>
                <environment></environment>
            <key id="14410">CLJ-784</key>
            <summary>Update min/max functions to take advantage of primitive math</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="6" iconUrl="http://dev.clojure.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Completed</resolution>
                                <assignee username="lvanderhart">Luke VanderHart</assignee>
                                <reporter username="lvanderhart">Luke VanderHart</reporter>
                        <labels>
                    </labels>
                <created>Fri, 29 Apr 2011 10:20:41 -0500</created>
                <updated>Fri, 1 Mar 2013 12:47:08 -0600</updated>
                    <resolved>Thu, 26 May 2011 20:17:29 -0500</resolved>
                            <version>Release 1.3</version>
                                <fixVersion>Release 1.3</fixVersion>
                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                        <comments>
                    <comment id="26408" author="lvanderhart" created="Fri, 29 Apr 2011 15:17:10 -0500"  >&lt;p&gt;This patch creates inline versions of min and max, combined with overloaded implementations in c.l.Numbers. It is over an order of magnitude faster using a test like this one (from 19 seconds to 1.2 seconds on my machine):&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;(time (loop [a 0 b 10 c 5]
            (&lt;span class=&quot;code-keyword&quot;&gt;if&lt;/span&gt; (&amp;lt; a 1000000000)
                (recur (inc a) (min b c) (max c b)))))&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;There are two patches. One is contagious, but returns primitives for (long, double) input. The other is not contagious and returns primitives only for (long,long) and (double,double) args, but is still substantially faster than the original version.&lt;/p&gt;</comment>
                    <comment id="26421" author="stu" created="Fri, 6 May 2011 10:11:58 -0500"  >&lt;p&gt;The May 6 &quot;take 3&quot; patch eliminates a few contagions that were hiding in the earlier patch, and is hopefully good to go.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="10217" name="0784-min-max-take-3.patch" size="3596" author="stu" created="Fri, 6 May 2011 10:11:57 -0500" />
                    <attachment id="10211" name="fast_min_max_no_contagion.patch" size="6029" author="lvanderhart" created="Fri, 29 Apr 2011 15:17:10 -0500" />
                    <attachment id="10210" name="fast_min_max.patch" size="3712" author="lvanderhart" created="Fri, 29 Apr 2011 15:17:09 -0500" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_10002" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Approval</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10007">Ok</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-871] instant literal</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-871</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;See &lt;a href=&quot;http://dev.clojure.org/pages/viewpage.action?pageId=950382&quot;&gt;http://dev.clojure.org/pages/viewpage.action?pageId=950382&lt;/a&gt; for design discussion.&lt;/p&gt;</description>
                <environment></environment>
            <key id="14915">CLJ-871</key>
            <summary>instant literal</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="6" iconUrl="http://dev.clojure.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Completed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="stu">Stuart Halloway</reporter>
                        <labels>
                    </labels>
                <created>Fri, 4 Nov 2011 12:48:37 -0500</created>
                <updated>Fri, 1 Mar 2013 12:47:08 -0600</updated>
                    <resolved>Fri, 3 Feb 2012 09:05:21 -0600</resolved>
                                            <fixVersion>Release 1.4</fixVersion>
                                        <due></due>
                    <votes>0</votes>
                        <watches>1</watches>
                        <comments>
                    <comment id="27195" author="stu" created="Fri, 4 Nov 2011 12:59:21 -0500"  >&lt;p&gt;I have tested patch locally with no Joda, 1.6.2 Joda, and 2.0 Joda. All work as intended in simple invocations.&lt;/p&gt;

&lt;p&gt;Seeking feedback on &lt;/p&gt;

&lt;ul&gt;
	&lt;li&gt;UTC at the door. Goal is to stay out of localization business. Is that a good goal, and is that the right way to achieve it?&lt;/li&gt;
	&lt;li&gt;idiom for dynamically loading code based on whether Joda on classpath&lt;/li&gt;
	&lt;li&gt;idiom for conveying maven classpath into the ant part of the build. People using ant will have to configure path locally to include Joda.&lt;/li&gt;
&lt;/ul&gt;
</comment>
                    <comment id="27196" author="hiredman" created="Fri, 4 Nov 2011 13:37:31 -0500"  >&lt;p&gt;using a bindable var for a read time setting is kind of a drag stuff like:&lt;/p&gt;

&lt;p&gt;(binding &lt;span class=&quot;error&quot;&gt;&amp;#91;*instant-reader* some-other-instant-reader&amp;#93;&lt;/span&gt;&lt;br/&gt;
  #@2011-11-04T14:42Z)&lt;/p&gt;

&lt;p&gt;will not have the desired effect, so then what are the use cases for the bindable var? should the repl bind it? should the compiler?&lt;/p&gt;</comment>
                    <comment id="27198" author="hiredman" created="Fri, 4 Nov 2011 18:47:23 -0500"  >&lt;p&gt;dates should always be read and printed as UTC&lt;/p&gt;</comment>
                    <comment id="27199" author="abrooks" created="Sat, 5 Nov 2011 09:55:26 -0500"  >&lt;p&gt;It seems like it would be nice to have time-delta literals as well. My usage cases deal more often with time-deltas applied as intervals or offsets in time. I presume the current scheme doesn&apos;t allow for that but could be adjusted. Is that outside of the scope of this discussion?&lt;/p&gt;</comment>
                    <comment id="27200" author="richhickey" created="Sun, 6 Nov 2011 10:31:33 -0600"  >&lt;p&gt;&amp;gt; UTC at the door.&lt;/p&gt;

&lt;p&gt;No. Offsets are not localization, just arithmetic.&lt;/p&gt;

&lt;p&gt;&amp;gt;idiom for dynamically loading code based on whether Joda on classpath&lt;/p&gt;

&lt;p&gt;We&apos;ll need more explicit mechanisms for determining the programmatic representation. Dynamic Joda is just to avoid Joda as hard implementation dep.&lt;/p&gt;

&lt;p&gt;&amp;gt; People using ant will have to configure path locally to include Joda.&lt;/p&gt;

&lt;p&gt;People using ant = me.&lt;/p&gt;</comment>
                    <comment id="27281" author="bsmith.occs@gmail.com" created="Sat, 12 Nov 2011 15:10:30 -0600"  >&lt;p&gt;This patch implements instant literals of the form &lt;tt&gt;#@yyyy-mm-ddThh:mm:ss.fff+hh:mm&lt;/tt&gt; using only classes available in the JRE.&lt;/p&gt;

&lt;p&gt;clojure.instant provides instant-readers producing instances of three different JDK classes. These functions accept a string representing a timestamp See (doc clojure.instant/parse-timestamp) for details. &lt;/p&gt;

&lt;ul class=&quot;alternate&quot; type=&quot;square&quot;&gt;
	&lt;li&gt;read-instant-date (java.util.Date)&lt;/li&gt;
	&lt;li&gt;read-instant-calendar (java.util.Calendar)&lt;/li&gt;
	&lt;li&gt;read-instant-timestamp (java.sql.Timestamp)&lt;/li&gt;
&lt;/ul&gt;


&lt;p&gt;By default &amp;#42;instant-reader&amp;#42; is bound to read-instant-date.&lt;/p&gt;

&lt;p&gt;print-method and print-dup are provided for all three types.&lt;/p&gt;

&lt;p&gt;Rough bits include:&lt;/p&gt;

&lt;p&gt;I&apos;m not yet certain about the exact public interface of clojure.instant. It&apos;s clear that read-instant-&amp;#42; need to be visible. It also seems likely that parse-timestamp and validated could usefully support alternate implementations for &amp;#42;instant-reader&amp;#42;.&lt;/p&gt;

&lt;p&gt;fixup-offset and fixup-nanos are ugly warts necessitated by Java&apos;s pathetic built-in support for dates and times (possibly exacerbated by my own misunderstandings of the same).&lt;/p&gt;

&lt;p&gt;Unit tests are very basic. For example, I&apos;m not testing validated except in the good case where everything is valid.&lt;/p&gt;

&lt;p&gt;See also &lt;a href=&quot;https://github.com/bpsm/clojure/commit/753f991151847df53d624f7c09b7113cd2321793&quot;&gt;https://github.com/bpsm/clojure/commit/753f991151847df53d624f7c09b7113cd2321793&lt;/a&gt;&lt;/p&gt;

&lt;hr /&gt;

&lt;p&gt;I&apos;ve made a few trivial fixes to doc strings, visible &lt;a href=&quot;https://github.com/bpsm/clojure/commits/CLJ-871.1&quot;&gt;on my github branch&lt;/a&gt;. Those changes will be included when  I re-roll the patch it to incorporate any feedback.&lt;/p&gt;</comment>
                    <comment id="27285" author="stuart.sierra" created="Sun, 13 Nov 2011 18:53:03 -0600"  >&lt;p&gt;&lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-871&quot; title=&quot;instant literal&quot;&gt;&lt;del&gt;CLJ-871&lt;/del&gt;&lt;/a&gt;-data-readers-1.patch&lt;/p&gt;

&lt;p&gt;An alternative approach. The dynamic Var &lt;tt&gt;&amp;#42;data-readers&amp;#42;&lt;/tt&gt; maps keywords to reader functions, triggered by reader syntax &lt;tt&gt;#:keyword&lt;/tt&gt;. Default &lt;tt&gt;#:instant&lt;/tt&gt; reader takes a vector like &lt;tt&gt;&lt;span class=&quot;error&quot;&gt;&amp;#91;year month day hrs min sec ms&amp;#93;&lt;/span&gt;&lt;/tt&gt;, all components optional.&lt;/p&gt;

&lt;p&gt;Pros: No string parsing. Extensible.&lt;/p&gt;

&lt;p&gt;Cons: Clojure 1.2 used the &lt;tt&gt;#:&lt;/tt&gt; syntax to print records.&lt;/p&gt;</comment>
                    <comment id="27596" author="fogus" created="Sat, 21 Jan 2012 09:11:54 -0600"  >&lt;p&gt;Oddly, I made another case for this.  My bad.  Attached is the updated patch based off of Ben&apos;s work.  This patch is merged into the tagged literal feature as implemented in v1.4-alpha4.  I also fixed a fence-post error and very minor doc problems.  The parser currently defaults to constructing j.u.Date instances of the following 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;date-year   = 4DIGIT
date-month      = 2DIGIT  ; 01-12
date-mday       = 2DIGIT  ; 01-28, 01-29, 01-30, 01-31 based on
                         ; month/year
time-hour       = 2DIGIT  ; 00-23
time-minute     = 2DIGIT  ; 00-59
time-second     = 2DIGIT  ; 00-58, 00-59, 00-60 based on leap second
                         ; rules
time-secfrac    = &apos;.&apos; 1*DIGIT
time-numoffset  = (&apos;+&apos; / &apos;-&apos;) time-hour &apos;:&apos; time-minute
time-offset     = &apos;Z&apos; / time-numoffset

time-part            = time-hour [ &apos;:&apos; time-minute [ &apos;:&apos; time-second [time-secfrac] [time-offset] ] ]

timestamp       = date-year [ &apos;-&apos; date-month [ &apos;-&apos; date-mday [ &apos;T&apos; time-part ] ] ]
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;Or in other words, &lt;a href=&quot;http://tools.ietf.org/html/rfc3339&quot;&gt;RFC 3339 &lt;/a&gt;.&lt;/p&gt;
</comment>
                    <comment id="27624" author="stuart.sierra" created="Fri, 27 Jan 2012 08:46:46 -0600"  >&lt;p&gt;2 problems:&lt;/p&gt;

&lt;p&gt;1. You can&apos;t specify an alternate &lt;tt&gt;inst&lt;/tt&gt; reader in data_readers.clj. Doing so causes an opaque error when Clojure starts. This is a flaw in &lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-890&quot; title=&quot;Tagged literals in reader&quot;&gt;&lt;del&gt;CLJ-890&lt;/del&gt;&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;2. &lt;tt&gt;&amp;#42;data-readers&amp;#42;&lt;/tt&gt; is intended to be a map of symbols to Vars, not symbols to functions. This doesn&apos;t really matter.&lt;/p&gt;</comment>
                    <comment id="27625" author="stuart.sierra" created="Fri, 27 Jan 2012 09:24:03 -0600"  >&lt;p&gt;New patch &lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-871&quot; title=&quot;instant literal&quot;&gt;&lt;del&gt;CLJ-871&lt;/del&gt;&lt;/a&gt;-with-defaults.patch.&lt;/p&gt;

&lt;p&gt;Fixes problems described in previous comment by adding &lt;tt&gt;default-data-readers&lt;/tt&gt; which can be overridden by &lt;tt&gt;&amp;#42;data-readers&amp;#42;&lt;/tt&gt;. Also adds documentation for &lt;tt&gt;&amp;#42;data-readers&amp;#42;&lt;/tt&gt;.&lt;/p&gt;</comment>
                    <comment id="27640" author="steveminer@gmail.com" created="Wed, 1 Feb 2012 14:25:26 -0600"  >&lt;p&gt;divisible? and indivisible? should be normal functions, not macros.  They&apos;re used only in leap-year? &amp;#8211; it would be pretty simple to use zero? and mod? directly there.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="10597" name="0871-instant-reader.patch" size="9421" author="stu" created="Fri, 4 Nov 2011 12:59:21 -0500" />
                    <attachment id="10702" name="CLJ-871-data-readers-1.patch" size="8345" author="stuart.sierra" created="Sun, 13 Nov 2011 18:53:03 -0600" />
                    <attachment id="10698" name="CLJ-871-jre-only.diff" size="17481" author="bsmith.occs@gmail.com" created="Sat, 12 Nov 2011 15:10:30 -0600" />
                    <attachment id="10790" name="CLJ-871-with-defaults.patch" size="24472" author="stuart.sierra" created="Fri, 27 Jan 2012 09:24:03 -0600" />
                    <attachment id="10783" name="CLJ-915-instant-literals.diff" size="19377" author="fogus" created="Sat, 21 Jan 2012 09:11:54 -0600" />
                </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>
                                                                                    <customfield id="customfield_10003" key="com.atlassian.jira.plugin.system.customfieldtypes:userpicker">
                <customfieldname>Waiting On</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>stuart.sierra</customfieldvalue>
                </customfieldvalues>
            </customfield>
                            </customfields>
    </item>

<item>
            <title>[CLJ-907] records do not enforce type hints</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-907</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;Specify a record with a field as say ^String, but the constructor won&apos;t throw if you pass in a non-String.&lt;/p&gt;</description>
                <environment></environment>
            <key id="15102">CLJ-907</key>
            <summary>records do not enforce type hints</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="6" iconUrl="http://dev.clojure.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="2">Declined</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="chip">Chip Salzenberg</reporter>
                        <labels>
                    </labels>
                <created>Sun, 8 Jan 2012 01:25:39 -0600</created>
                <updated>Fri, 1 Mar 2013 12:47:08 -0600</updated>
                    <resolved>Tue, 27 Nov 2012 13:52:24 -0600</resolved>
                            <version>Release 1.2</version>
                <version>Release 1.3</version>
                                                        <due></due>
                    <votes>1</votes>
                        <watches>0</watches>
                        <comments>
                    <comment id="27523" author="amalloy" created="Tue, 10 Jan 2012 16:59:53 -0600"  >&lt;p&gt;I doubt there&apos;s any desire to change this. Records only support typehints to enable performant storage of primitive types like ints, not to provide static typing in general. An Object is stored the same way as a String, so there&apos;s no need to pay attention to that typehint.&lt;/p&gt;

&lt;p&gt;Functions behave the same way: ((fn &lt;span class=&quot;error&quot;&gt;&amp;#91;^String x&amp;#93;&lt;/span&gt; x) :test) works just fine. Only if you use a member method of the hinted type (such as .substring in this example) is an exception thrown then the compiler casts to String in order to call the method.&lt;/p&gt;</comment>
                    <comment id="27524" author="chip" created="Tue, 10 Jan 2012 17:08:54 -0600"  >&lt;p&gt;I don&apos;t understand how you get from &quot;this is how it is&quot; to &quot;this is how it is meant to be.&quot;  The compiler can do a better job if the underlying field is properly typed: Type errors can be caught sooner, and cast operations can be omitted on use.  This is a worthy enhancement.&lt;/p&gt;</comment>
                    <comment id="30059" author="halgari" created="Tue, 27 Nov 2012 13:52:00 -0600"  >&lt;p&gt;Alan is correct, the reason type hints exist is to reduce reflection and to allow for the unboxing of primitives. String is not a primitive and therefore type-hinting it only reduces the amount of reflection performed. &lt;/p&gt;

&lt;p&gt;It has always been Rich&apos;s policy that any type systems used in Clojure should not throw compile time errors, but instead should only enhance the performance of existing code. (see the implementation of Typed Clojure for more info on this). &lt;/p&gt;

&lt;p&gt;Closing this issue, as it is by design.  &lt;/p&gt;

</comment>
                    <comment id="30060" author="halgari" created="Tue, 27 Nov 2012 13:52:24 -0600"  >&lt;p&gt;By design. &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="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>
                                                                                                            </customfields>
    </item>

<item>
            <title>[CLJ-930] cljs.core// does not work in ClojureScript</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-930</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;clojure.core// is hard coded into the reader as a special case. cljs.core// should similarly be hard coded&lt;/p&gt;</description>
                <environment></environment>
            <key id="15212">CLJ-930</key>
            <summary>cljs.core// does not work in ClojureScript</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="6" iconUrl="http://dev.clojure.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="3">Duplicate</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="dnolen">David Nolen</reporter>
                        <labels>
                    </labels>
                <created>Wed, 8 Feb 2012 08:06:38 -0600</created>
                <updated>Fri, 1 Mar 2013 12:47:08 -0600</updated>
                    <resolved>Wed, 29 Feb 2012 13:25:03 -0600</resolved>
                            <version>Release 1.4</version>
                                <fixVersion>Release 1.4</fixVersion>
                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                        <comments>
                    <comment id="27864" author="jafingerhut" created="Fri, 24 Feb 2012 20:02:18 -0600"  >&lt;p&gt;David, the patch for &lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-873&quot; title=&quot;Allow the function / to be referred to in namespaces other than clojure.core&quot;&gt;CLJ-873&lt;/a&gt; seems to be more general than this, i.e. it allows the symbol / to be used in any namespace, not only in clojure.core and cljs.core.&lt;/p&gt;</comment>
                    <comment id="27891" author="jafingerhut" created="Wed, 29 Feb 2012 13:25:03 -0600"  >&lt;p&gt;I checked with David Nolen, and he agrees that the patch for &lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-873&quot; title=&quot;Allow the function / to be referred to in namespaces other than clojure.core&quot;&gt;CLJ-873&lt;/a&gt; fixes not only this issue, but also enables the symbol / to be used in any namespace.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="10897" name="cljs_slash.patch" size="1426" author="dnolen" created="Wed, 8 Feb 2012 08:06: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-1006] Quotient on bigdec may produce wrong result</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1006</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;Hi,&lt;/p&gt;

&lt;p&gt;As discussed on the mailing list in the message &quot;When arithmetic on a computer bite back&quot; (01/jun)&lt;/p&gt;

&lt;p&gt;There may be bug in the way quotient is implemented for bigdec.&lt;/p&gt;

&lt;p&gt;user&amp;gt; (quot 1.4411518807585587E17 2)   ;; correct with doubles&lt;br/&gt;
7.2057594037927936E16&lt;br/&gt;
user&amp;gt; (quot 1.4411518807585587E+17M 2) ;; wrong with BigDecs&lt;br/&gt;
72057594037927935M &lt;/p&gt;

&lt;p&gt;&amp;#8211;&lt;br/&gt;
Laurent&lt;/p&gt;</description>
                <environment>Linux 3.2.0-24-generic #39-Ubuntu SMP i686 GNU/Linux</environment>
            <key id="15500">CLJ-1006</key>
            <summary>Quotient on bigdec may produce wrong result</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="6" iconUrl="http://dev.clojure.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="2">Declined</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="laurentj">laurent joigny</reporter>
                        <labels>
                        <label>bug</label>
                    </labels>
                <created>Fri, 1 Jun 2012 16:12:34 -0500</created>
                <updated>Fri, 1 Mar 2013 12:47:08 -0600</updated>
                    <resolved>Fri, 9 Nov 2012 08:49:48 -0600</resolved>
                            <version>Release 1.4</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>1</watches>
                        <comments>
                    <comment id="28677" author="laurentj" created="Fri, 1 Jun 2012 17:48:24 -0500"  >&lt;p&gt;I can reproduce the bug when using BigDecimal constructor on String.&lt;br/&gt;
See attached file for a test class.&lt;/p&gt;

&lt;p&gt;More infos :&lt;br/&gt;
java version &quot;1.6.0_24&quot;&lt;br/&gt;
OpenJDK Runtime Environment (IcedTea6 1.11.1) (6b24-1.11.1-4ubuntu3)&lt;br/&gt;
OpenJDK Client VM (build 20.0-b12, mixed mode, sharing)&lt;/p&gt;</comment>
                    <comment id="28678" author="laurentj" created="Fri, 1 Jun 2012 17:49:50 -0500"  >&lt;p&gt;A simple test file, that you can drop in Clojure sources and execute to reproduce the bug on BigDecimal constructor using String as argument.&lt;/p&gt;</comment>
                    <comment id="28687" author="tsdh" created="Sun, 3 Jun 2012 04:30:44 -0500"  >&lt;p&gt;Seems to be a general precision problem.  Note that in&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; (quot 1.4411518807585587E17 2) ;; correct with doubles
7.2057594037927936E16
user&amp;gt; (quot 1.4411518807585587E+17M 2) ;; wrong with BigDecs
72057594037927935M
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;the double result is actually wrong and the bigdec one is correct.  The problem which lead to the wrong conclusion is that in your calculation the input number is already wrong.&lt;/p&gt;

&lt;p&gt;So the moral is: don&apos;t use any floating points (neither doubles nor bigdecs) for computations involving divisibility tests.&lt;/p&gt;

&lt;p&gt;For bigdecs, you can set the math context for making computations throw exceptions if they lose precision, though:&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; (binding [*math-context* (java.math.MathContext. 1 java.math.RoundingMode/UNNECESSARY)]
	       (quot (bigdec (Math/pow 2 58)) 2))
;Division impossible
;  [Thrown class java.lang.ArithmeticException]
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;</comment>
                    <comment id="29920" author="stuart.sierra" created="Fri, 9 Nov 2012 08:49:48 -0600"  >&lt;p&gt;Not a bug. Just floating-point arithmetic.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="11282" name="TestBigDecimalQuotient.java" size="782" author="laurentj" created="Fri, 1 Jun 2012 17:49: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>
                                                                                                            </customfields>
    </item>

<item>
            <title>[CLJ-244] walk support for sorted-by collections</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-244</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;&lt;a href=&quot;http://groups.google.com/group/clojure-dev/browse_thread/thread/51982e4091e3614d&quot;&gt;http://groups.google.com/group/clojure-dev/browse_thread/thread/51982e4091e3614d&lt;/a&gt;&lt;/p&gt;</description>
                <environment></environment>
            <key id="13641">CLJ-244</key>
            <summary>walk support for sorted-by collections</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="6" iconUrl="http://dev.clojure.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Completed</resolution>
                                <assignee username="timothypratley">Timothy Pratley</assignee>
                                <reporter username="importer">Assembla Importer</reporter>
                        <labels>
                    </labels>
                <created>Wed, 13 Jan 2010 01:52:00 -0600</created>
                <updated>Fri, 1 Mar 2013 12:47:08 -0600</updated>
                    <resolved>Wed, 5 Jan 2011 06:49:32 -0600</resolved>
                                            <fixVersion>Release 1.3</fixVersion>
                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                        <comments>
                    <comment id="23395" author="importer" created="Tue, 28 Sep 2010 17:09:00 -0500"  >&lt;p&gt;Converted from &lt;a href=&quot;http://www.assembla.com/spaces/clojure/tickets/244&quot;&gt;http://www.assembla.com/spaces/clojure/tickets/244&lt;/a&gt;&lt;br/&gt;
Attachments:&lt;br/&gt;
sorted_walk.diff - &lt;a href=&quot;https://www.assembla.com/spaces/clojure/documents/b0Y9k2c5Or34IaeJe5afGb/download/b0Y9k2c5Or34IaeJe5afGb&quot;&gt;https://www.assembla.com/spaces/clojure/documents/b0Y9k2c5Or34IaeJe5afGb/download/b0Y9k2c5Or34IaeJe5afGb&lt;/a&gt;&lt;/p&gt;</comment>
                    <comment id="23396" author="importer" created="Tue, 28 Sep 2010 17:09:00 -0500"  >&lt;p&gt;timothypratley said: [&lt;a href=&quot;file:b0Y9k2c5Or34IaeJe5afGb&quot;&gt;file:b0Y9k2c5Or34IaeJe5afGb&lt;/a&gt;]: fix and tests&lt;/p&gt;</comment>
                    <comment id="23397" author="importer" created="Tue, 28 Sep 2010 17:09:00 -0500"  >&lt;p&gt;timothypratley said: Ready&lt;/p&gt;</comment>
                    <comment id="26085" author="stu" created="Tue, 4 Jan 2011 20:18:22 -0600"  >&lt;p&gt;Jan 4 patch updated to work with current master.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="10069" name="0244-sorted-walk-resolved.patch" size="4725" author="stu" created="Tue, 4 Jan 2011 20:18:22 -0600" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_10002" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Approval</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10007">Ok</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-901] implementation of doc macro in core.repl incorrect for special names... add one character to fix</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-901</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;In the implementation of the doc macro in core.repl, the line:&lt;br/&gt;
  (if-let [special-name (&apos;{&amp;amp; fn catch try finally try} name)]&lt;br/&gt;
contains:{&amp;amp; fn catch try finally try}  which is a hashmap.  &lt;/p&gt;

&lt;p&gt;It should be a set, and the line should read:&lt;br/&gt;
  (if-let &lt;a href=&quot;#tok1-block-tok� name)&quot;&gt;special-name (&apos;#{&amp;amp; fn catch try finally try} name)&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;To see the bug at work:&lt;br/&gt;
user&amp;gt; (doc &amp;amp;)&lt;br/&gt;
-------------------------&lt;br/&gt;
clojure.core/fn&lt;br/&gt;
  (fn name? &lt;span class=&quot;error&quot;&gt;&amp;#91;params*&amp;#93;&lt;/span&gt; exprs*)&lt;br/&gt;
  (fn name? (&lt;span class=&quot;error&quot;&gt;&amp;#91;params*&amp;#93;&lt;/span&gt; exprs*) +)&lt;br/&gt;
Special Form&lt;br/&gt;
  params =&amp;gt; positional-params* , or positional-params* &amp;amp; next-param&lt;br/&gt;
  positional-param =&amp;gt; binding-form&lt;br/&gt;
  next-param =&amp;gt; binding-form&lt;br/&gt;
  name =&amp;gt; symbol&lt;/p&gt;

&lt;p&gt;  Defines a function&lt;/p&gt;

&lt;p&gt;  Please see &lt;a href=&quot;http://clojure.org/special_forms#fn&quot;&gt;http://clojure.org/special_forms#fn&lt;/a&gt;&lt;/p&gt;</description>
                <environment></environment>
            <key id="15086">CLJ-901</key>
            <summary>implementation of doc macro in core.repl incorrect for special names... add one character to fix</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="6" iconUrl="http://dev.clojure.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="2">Declined</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="doeklund">Daniel Eklund</reporter>
                        <labels>
                    </labels>
                <created>Fri, 23 Dec 2011 12:59:58 -0600</created>
                <updated>Fri, 1 Mar 2013 12:47:08 -0600</updated>
                    <resolved>Tue, 28 Feb 2012 20:04:20 -0600</resolved>
                            <version>Release 1.3</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                        <comments>
                    <comment id="27731" author="jafingerhut" created="Fri, 17 Feb 2012 00:06:31 -0600"  >&lt;p&gt;Daniel, I&apos;m pretty sure it is intended to be a map, not a set.  The goal is to show the same documentation for try whether you ask for the documentation of try, catch, or finally.  Also, to show the documentation for fn if you ask for the documentation of &amp;amp;, since that symbol is only useful in arg lists in fn (or let).  They could have put multiple entries in special-doc-map and not had that little map inside doc, but that little map avoided the need for such duplication.&lt;/p&gt;</comment>
                    <comment id="27886" author="doeklund" created="Tue, 28 Feb 2012 19:34:41 -0600"  >&lt;p&gt;100% agree.  It was an incorrect report on my part.  Thanks for clearing it up.&lt;/p&gt;</comment>
                    <comment id="27887" author="jafingerhut" created="Tue, 28 Feb 2012 20:04:20 -0600"  >&lt;p&gt;Daniel asked me to change the state of the ticket, since he could not see how to (perhaps insufficient privileges).  Not sure if it should be marked Closed or Resolved, so I&apos;m picking Resolved.&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-1067] Fix error message inconsistencies in Symbol and Keyword</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1067</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;1. There are some ugly and unnecessary &amp;#8211; but harmless &amp;#8211; inconsistencies between Symbol and Keyword:&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;(.run &apos;foo);    =&amp;gt; ArityException Wrong number of args (0) passed to: Symbol  clojure.lang.AFn.throwArity (AFn.java:437)
(.run :foo);    =&amp;gt; UnsupportedOperationException   clojure.lang.Keyword.run (Keyword.java:97)
(.call &apos;foo);   =&amp;gt; ArityException Wrong number of args (0) passed to: Symbol  clojure.lang.AFn.throwArity (AFn.java:437)
(.call :foo);   =&amp;gt; IllegalArgumentException Wrong number of args passed to keyword: :foo  clojure.lang.Keyword.throwArity (Keyword.java:88)
(.invoke &apos;foo); =&amp;gt; ArityException Wrong number of args (0) passed to: Symbol  clojure.lang.AFn.throwArity (AFn.java:437)
(.invoke :foo); =&amp;gt; IllegalArgumentException Wrong number of args passed to keyword: :foo  clojure.lang.Keyword.throwArity (Keyword.java:88)&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;2. Keyword.java contains a lot of code that has already been factored out to AFn.java.&lt;/p&gt;

&lt;p&gt;I propose that Keyword is modified to extend AFn to resolve the above issues.&lt;/p&gt;</description>
                <environment></environment>
            <key id="15694">CLJ-1067</key>
            <summary>Fix error message inconsistencies in Symbol and Keyword</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="6" iconUrl="http://dev.clojure.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="2">Declined</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="qerub">Christoffer Sawicki</reporter>
                        <labels>
                    </labels>
                <created>Fri, 14 Sep 2012 11:38:28 -0500</created>
                <updated>Fri, 1 Mar 2013 12:47:08 -0600</updated>
                    <resolved>Mon, 17 Sep 2012 07:03:26 -0500</resolved>
                                                                    <due></due>
                    <votes>0</votes>
                        <watches>1</watches>
                        <comments>
                    <comment id="29458" author="stu" created="Mon, 17 Sep 2012 07:03:18 -0500"  >&lt;p&gt;At first glance, it appears that there could be some code sharing here. But the attached patch changes the semantics of run, which is a non-starter.&lt;/p&gt;</comment>
                    <comment id="29462" author="qerub" created="Mon, 17 Sep 2012 07:19:38 -0500"  >&lt;p&gt;The only thing that changes is the type of thrown exception.&lt;/p&gt;

&lt;p&gt;Current call tree:&lt;/p&gt;

&lt;p&gt;Keyword.run() -&amp;gt; throw new UnsupportedOperationException()&lt;/p&gt;

&lt;p&gt;Call tree with patch applied:&lt;/p&gt;

&lt;p&gt;Keyword.run() -&amp;gt; AFn.run() -&amp;gt; AFn.invoke() -&amp;gt; AFn.throwArity(0) -&amp;gt; throw new ArityException(...)&lt;/p&gt;

&lt;p&gt;(I.e. Keyword.run() always throws an exception, with and without my patch.)&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="11496" name="Make-Keyword-extend-AFn-just-like-Symbol.patch" size="6322" author="qerub" created="Fri, 14 Sep 2012 11:40:42 -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>
                                                                                                            </customfields>
    </item>

<item>
            <title>[CLJ-895] Collection.toArray implementations do not conform to Java API docs</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-895</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;Per &lt;a href=&quot;http://docs.oracle.com/javase/6/docs/api/index.html?java/util/Collections.html&quot;&gt;http://docs.oracle.com/javase/6/docs/api/index.html?java/util/Collections.html&lt;/a&gt;, Collection.toArray(T []) implements must allocate an array of type T[], not Object[]. This will cause type-casty code to break. Not often a problem in Clojure, but e.g. it makes Clojure defrecords unprintable from the JRuby console.&lt;/p&gt;

&lt;p&gt;There is also a chance to DRY up some common code, as the six places that have this problem should all call an RT helper.&lt;/p&gt;

&lt;p&gt;This also fixes toArray(T[]) for PersistentQueue when the passed array has the same length as the queue.&lt;/p&gt;</description>
                <environment></environment>
            <key id="15063">CLJ-895</key>
            <summary>Collection.toArray implementations do not conform to Java API docs</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="6" iconUrl="http://dev.clojure.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Completed</resolution>
                                <assignee username="stu">Stuart Halloway</assignee>
                                <reporter username="stu">Stuart Halloway</reporter>
                        <labels>
                    </labels>
                <created>Sat, 10 Dec 2011 17:27:36 -0600</created>
                <updated>Fri, 1 Mar 2013 12:47:07 -0600</updated>
                    <resolved>Sun, 19 Feb 2012 20:20:56 -0600</resolved>
                                                                    <due></due>
                    <votes>1</votes>
                        <watches>2</watches>
                        <comments>
                    <comment id="27451" author="stu" created="Sat, 10 Dec 2011 17:35:37 -0600"  >&lt;p&gt;Sorry about the ^M crap in the patch, feel free to humiliate me on twitter with the correct incantation to prettify patch whitespace.&lt;/p&gt;</comment>
                    <comment id="27452" author="cosmin" created="Sat, 10 Dec 2011 22:44:27 -0600"  >&lt;p&gt;I don&apos;t understand the motivation for changing toArray in PersistentList. Calling seqToPassedArray here seems to accomplish the same thing, but the way in which it does that becomes harder to follow (at least for me). I would be tempted to keep the old toArray code in PersistentList.&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;                                                                                                                                                                                              
-       public Object[] toArray(Object[] objects){                                                                                                                                                          
-               if(objects.length &amp;gt; 0)                                                                                                                                                                      
-                       objects[0] = null;                                                                                                                                                                  
-               return objects;                                                                                                                                                                             
+       public Object[] toArray(Object[] a){                                                                                                                                                                
+        return RT.seqToPassedArray(seq(), a);                                                                                                                                                              
        }
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;Also, in the implementation of seqToPassedArray I think the final if condition can be simplified because dest != passed only if len &amp;gt; passed.length. I think this would do.&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;+        if (len &amp;lt; passed.length) {
+            dest[len] = null;
+        }
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;Finally, it probably wouldn&apos;t hurt to throw some braces around the for loop.&lt;/p&gt;</comment>
                    <comment id="27453" author="stu" created="Sun, 11 Dec 2011 06:53:45 -0600"  >&lt;p&gt;Thanks Cosmin. &quot;take-2&quot; patch incorporates your suggestions.&lt;/p&gt;</comment>
                    <comment id="27454" author="cosmin" created="Sun, 11 Dec 2011 22:17:24 -0600"  >&lt;p&gt;I removed the line ending changes from PersistentQueue from the patch so now just the relevant changes should be left.&lt;/p&gt;</comment>
                    <comment id="27455" author="cosmin" created="Mon, 12 Dec 2011 01:56:34 -0600"  >&lt;p&gt;Added tests for the new toArray functionality. Checking for collections shorter, same-length, and longer than the passed array for lists, vectors, hash-sets and queues.&lt;/p&gt;

&lt;p&gt;In the process discovered that the previous implementation of toArray for PersistentQueue was actually broken when the passed array had the same length as the queue because&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;if(a.length &amp;gt;= count())
    a[count()] = null;
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;should have been&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;if(a.length &amp;gt; count())
    a[count()] = null;
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;which was the case for the other implementations. With the new shared implementation of RT.seqToPassedArray this is no longer a problem.&lt;/p&gt;</comment>
                    <comment id="27476" author="stuart.sierra" created="Fri, 16 Dec 2011 09:30:51 -0600"  >&lt;p&gt;Patch 0895-to-array-take-3.patch does not apply on 485b6fc357157458f156bbba49f8e78c10c66c31&lt;/p&gt;</comment>
                    <comment id="27481" author="cosmin" created="Fri, 16 Dec 2011 16:20:34 -0600"  >&lt;p&gt;Odd, it seems to apply cleanly for me onto 485b6fc357157458f156bbba49f8e78c10c66c31 as well as 12f07da889819bc5613546ec223e97ac27c86dbf (current HEAD).&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 reset --hard HEAD
HEAD is now at 485b6fc [maven-release-plugin] prepare for next development iteration
$ git checkout 485b6fc357157458f156bbba49f8e78c10c66c31
HEAD is now at 485b6fc... [maven-release-plugin] prepare for next development iteration
$ patch -p1 &amp;lt; 0895-to-array-take-3.patch 
patching file src/jvm/clojure/lang/APersistentSet.java
patching file src/jvm/clojure/lang/APersistentVector.java
patching file src/jvm/clojure/lang/ASeq.java
patching file src/jvm/clojure/lang/LazySeq.java
patching file src/jvm/clojure/lang/PersistentQueue.java
patching file src/jvm/clojure/lang/RT.java
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;</comment>
                    <comment id="27646" author="cosmin" created="Fri, 3 Feb 2012 18:52:38 -0600"  >&lt;p&gt;One more shot at getting a combined patch for this issue. 0001-&lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-895&quot; title=&quot;Collection.toArray implementations do not conform to Java API docs&quot;&gt;&lt;del&gt;CLJ-895&lt;/del&gt;&lt;/a&gt;.-Use-RT.seqToPassedArray-to-implement-Collec.patch contains the fix as well as the tests and should apply with no problems on top of e27a27d9a6dc3fd0d15f26a5076e2876007e0ae6&lt;/p&gt;</comment>
                    <comment id="27770" author="stu" created="Sun, 19 Feb 2012 18:48:53 -0600"  >&lt;p&gt;the take 4 patch is the same as previous, merely cleaned up to apply on master&lt;/p&gt;</comment>
                    <comment id="27771" author="stu" created="Sun, 19 Feb 2012 19:17:40 -0600"  >&lt;p&gt;Aargh. One last time with correct git usage. Ignore take-4, the take-5 patch applies on master.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="10799" name="0001-CLJ-895.-Use-RT.seqToPassedArray-to-implement-Collec.patch" size="6277" author="cosmin" created="Fri, 3 Feb 2012 18:52:38 -0600" />
                    <attachment id="10928" name="0895-take-4.patch" size="6231" author="stu" created="Sun, 19 Feb 2012 18:48:53 -0600" />
                    <attachment id="10929" name="0895-take-5.patch" size="6225" author="stu" created="Sun, 19 Feb 2012 19:17:40 -0600" />
                    <attachment id="10738" name="0895-to-array.patch" size="7561" author="stu" created="Sat, 10 Dec 2011 17:35:37 -0600" />
                    <attachment id="10739" name="0895-to-array-take-2.patch" size="6868" author="stu" created="Sun, 11 Dec 2011 06:53:45 -0600" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_10002" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Approval</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10007">Ok</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-775] Test clojure.test-clojure.rt fails</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-775</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;When I run the &lt;em&gt;mvn test&lt;/em&gt; command against Clojure built from source, I&lt;br/&gt;
encounter the following error in the test &lt;tt&gt;clojure.test-clojure.rt&lt;/tt&gt;,&lt;br/&gt;
which appears to be due to the &lt;tt&gt;bare-rt-print&lt;/tt&gt; function&apos;s use of the&lt;br/&gt;
var &lt;tt&gt;clojure.core/print-initialized&lt;/tt&gt;:&lt;/p&gt;

&lt;p&gt;{{Testing clojure.test-clojure.rt&lt;/p&gt;

&lt;p&gt;ERROR in (rt-print-prior-to-print-initialize) (Var.java:339)&lt;br/&gt;
expected: (= &quot;#\&quot;foo\&quot;&quot; (bare-rt-print #&quot;foo&quot;))&lt;br/&gt;
  actual: java.lang.IllegalStateException: Can&apos;t dynamically bind non-dynamic var: clojure.core/print-initialized&lt;br/&gt;
 at clojure.lang.Var.pushThreadBindings (Var.java:339)&lt;br/&gt;
    clojure.core$push_thread_bindings.invoke (core.clj:1656)&lt;br/&gt;
    clojure.test_clojure.rt$bare_rt_print$fn__14891.invoke (rt.clj:46)&lt;br/&gt;
    clojure.test_clojure.rt$bare_rt_print.invoke (rt.clj:45)&lt;br/&gt;
    clojure.test_clojure.rt/fn (rt.clj:53)&lt;br/&gt;
    clojure.test$test_var$fn__1762.invoke (test.clj:693)&lt;br/&gt;
    clojure.test$test_var.invoke (test.clj:693)&lt;br/&gt;
    clojure.test$test_all_vars$fn_&lt;em&gt;1766$fn&lt;/em&gt;_1773.invoke (test.clj:709)&lt;br/&gt;
    clojure.test$default_fixture.invoke (test.clj:663)&lt;br/&gt;
    clojure.test$test_all_vars$fn__1766.invoke (test.clj:709)&lt;br/&gt;
    clojure.test$default_fixture.invoke (test.clj:663)&lt;br/&gt;
    clojure.test$test_all_vars.invoke (test.clj:705)&lt;br/&gt;
    clojure.test$test_ns.invoke (test.clj:728)&lt;br/&gt;
    clojure.core$map$fn__2231.invoke (core.clj:2371)&lt;br/&gt;
    clojure.lang.LazySeq.sval (LazySeq.java:42)&lt;br/&gt;
    clojure.lang.LazySeq.seq (LazySeq.java:60)&lt;br/&gt;
    clojure.lang.ChunkedCons.chunkedNext (ChunkedCons.java:59)&lt;br/&gt;
    clojure.core$chunk_next.invoke (core.clj:643)&lt;br/&gt;
    clojure.core$reException in thread &quot;main&quot; java.lang.IllegalStateException: Pop without matching push&lt;br/&gt;
    at clojure.lang.Var.popThreadBindings(Var.java:350)&lt;br/&gt;
    at clojure.core$pop_thread_bindings.invoke(core.clj:1658)&lt;br/&gt;
    at clojure.main$script_opt.invoke(main.clj:338)&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;br/&gt;
duce1.invoke (core.clj:878)&lt;br/&gt;
    clojure.core$reduce1.invoke (core.clj:870)&lt;br/&gt;
    clojure.core$merge_with.doInvoke (core.clj:2588)&lt;br/&gt;
    clojure.lang.RestFn.applyTo (RestFn.java:139)&lt;br/&gt;
    clojure.core$apply.invoke (core.clj:602)&lt;br/&gt;
    clojure.test$run_tests.doInvoke (test.clj:743)&lt;br/&gt;
    clojure.lang.RestFn.applyTo (RestFn.java:137)&lt;br/&gt;
    clojure.core$apply.invoke (core.clj:600)&lt;br/&gt;
    clojure.test_clojure$eval19718.invoke (run_tests.clj:58)&lt;br/&gt;
    clojure.lang.Compiler.eval (Compiler.java:6328)&lt;br/&gt;
    clojure.lang.Compiler.load (Compiler.java:6765)&lt;br/&gt;
    clojure.lang.Compiler.loadFile (Compiler.java:6726)&lt;br/&gt;
    clojure.main$load_script.invoke (main.clj:282)&lt;br/&gt;
    clojure.main$script_opt.invoke (main.clj:342)&lt;br/&gt;
    clojure.main$main.doInvoke (main.clj:426)&lt;br/&gt;
    clojure.lang.RestFn.invoke (RestFn.java:408)&lt;br/&gt;
    clojure.lang.Var.invoke (Var.java:401)&lt;br/&gt;
    clojure.lang.AFn.applyToHelper (AFn.java:161)&lt;br/&gt;
    clojure.lang.Var.applyTo (Var.java:518)&lt;br/&gt;
    clojure.main.main (main.java:37)}}&lt;/p&gt;</description>
                <environment>Windows XP, Cygwin, with Clojure built against the tip of the published &amp;quot;clojure/clojure&amp;quot; repository on GitHub</environment>
            <key id="14401">CLJ-775</key>
            <summary>Test clojure.test-clojure.rt fails</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="6" iconUrl="http://dev.clojure.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Completed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="seh">Steven E. Harris</reporter>
                        <labels>
                    </labels>
                <created>Wed, 20 Apr 2011 17:45:22 -0500</created>
                <updated>Fri, 1 Mar 2013 12:47:06 -0600</updated>
                    <resolved>Fri, 9 Nov 2012 08:31:28 -0600</resolved>
                                                                    <due></due>
                    <votes>0</votes>
                        <watches>2</watches>
                        <comments>
                    <comment id="27842" author="jafingerhut" created="Fri, 24 Feb 2012 13:02:42 -0600"  >&lt;p&gt;With latest Clojure master as of Feb 24, 2012, and with &quot;git checkout 1.3.x&quot; in a Clojure tree, &quot;mvn test&quot; builds and passes all tests for me on a Windows XP system with Cygwin, Java 1.7.0, and Maven 3.0.4.  Similarly on Mac OS X 10.6.8 with Java 1.6.0_29 and Maven 3.0.3.&lt;/p&gt;

&lt;p&gt;This may have been fixed already in 1.3.0, but it would be good for Steven to confirm.&lt;/p&gt;</comment>
                    <comment id="27843" author="jafingerhut" created="Fri, 24 Feb 2012 13:03:22 -0600"  >&lt;p&gt;Sorry, I should have said Windows Vista, but everything else applies.&lt;/p&gt;</comment>
                    <comment id="27844" author="seh" created="Fri, 24 Feb 2012 13:15:51 -0600"  >&lt;p&gt;I&apos;m ecstatic to report that at present, I don&apos;t have access to a computer running Windows with Cygwin, so I can&apos;t help verify the fix at present.&lt;/p&gt;</comment>
                    <comment id="28102" author="jafingerhut" created="Wed, 11 Apr 2012 17:34:20 -0500"  >&lt;p&gt;I have just today experienced this same exception today with the following versions of software:&lt;/p&gt;

&lt;p&gt;$ uname -a&lt;br/&gt;
Linux ubuntu 2.6.38-13-generic #57-Ubuntu SMP Mon Mar 5 18:10:14 UTC 2012 i686 i686 i386 GNU/Linux&lt;br/&gt;
$ java -version&lt;br/&gt;
java version &quot;1.7.0_02&quot;&lt;br/&gt;
Java(TM) SE Runtime Environment (build 1.7.0_02-b13)&lt;br/&gt;
Java HotSpot(TM) Client VM (build 22.0-b10, mixed mode)&lt;br/&gt;
$ ant -version&lt;br/&gt;
Apache Ant version 1.8.1 compiled on October 13 2010&lt;/p&gt;

&lt;p&gt;With latest Clojure master as of Apr 11 2012.&lt;/p&gt;

&lt;p&gt;Note: I saw this problem when I had tar&apos;ed a .tar.gz file of the Clojure source code on one machine with a current date, then untar&apos;ed it on a machine with its clock set a few days earlier.  Thus there were many warnings during compilation about file dates being in the future.  This may have had something to do with the failures, because when I updated the system&apos;s time, the compile and tests passed.&lt;/p&gt;</comment>
                    <comment id="29915" author="stuart.sierra" created="Fri, 9 Nov 2012 08:31:28 -0600"  >&lt;p&gt;It appears that this issue has been resolved. The clojure.core/print-initialized Var is declared dynamic in commit b9b1a094499b69a94bd47fc94c4f082d80239fa9&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-716] Hudson release build failing at git clone step</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-716</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;See &lt;a href=&quot;http://build.clojure.org/job/clojure/237/console&quot;&gt;http://build.clojure.org/job/clojure/237/console&lt;/a&gt; for specifics.&lt;/p&gt;</description>
                <environment></environment>
            <key id="14325">CLJ-716</key>
            <summary>Hudson release build failing at git clone step</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="6" iconUrl="http://dev.clojure.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Completed</resolution>
                                <assignee username="stuart.sierra">Stuart Sierra</assignee>
                                <reporter username="stu">Stuart Halloway</reporter>
                        <labels>
                    </labels>
                <created>Fri, 14 Jan 2011 11:40:37 -0600</created>
                <updated>Fri, 1 Mar 2013 12:47:05 -0600</updated>
                    <resolved>Fri, 14 Jan 2011 16:08:23 -0600</resolved>
                                            <fixVersion>Release 1.3</fixVersion>
                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                        <comments>
                    <comment id="26131" author="stuart.sierra" created="Fri, 14 Jan 2011 14:26:49 -0600"  >&lt;p&gt;Looks like some of the advanced Git options were misconfigured in the Hudson job. Specifically:&lt;/p&gt;

&lt;ul&gt;
	&lt;li&gt;&quot;Checkout/merge to local branch&quot; should be &quot;master&quot;&lt;/li&gt;
	&lt;li&gt;&quot;Merge before build&quot; should be checked
	&lt;ul&gt;
		&lt;li&gt;&quot;Name of repository&quot; should be &quot;origin&quot;&lt;/li&gt;
		&lt;li&gt;&quot;Branch to merge to&quot; should be &quot;master&quot;&lt;/li&gt;
	&lt;/ul&gt;
	&lt;/li&gt;
&lt;/ul&gt;


&lt;p&gt;I&apos;ve changed these settings. Ready to try another release.&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="10007">Ok</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_10003" key="com.atlassian.jira.plugin.system.customfieldtypes:userpicker">
                <customfieldname>Waiting On</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>stu</customfieldvalue>
                </customfieldvalues>
            </customfield>
                            </customfields>
    </item>

<item>
            <title>[CLJ-829] Transient hashmaps mishandle hash collisions</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-829</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;Clojure 1.2.1 and 1.3.0-beta1 both exhibit the following behavior:&lt;/p&gt;

&lt;p&gt;user&amp;gt; (let [m (into {} (for [x (range 100000)] &lt;span class=&quot;error&quot;&gt;&amp;#91;(rand) (rand)&amp;#93;&lt;/span&gt;))]&lt;br/&gt;
        (println (count (distinct (map hash (keys m)))))&lt;br/&gt;
        ((juxt count identity) (persistent!&lt;br/&gt;
                (reduce dissoc! (transient m) (keys m)))))&lt;br/&gt;
99999&lt;br/&gt;
&lt;span class=&quot;error&quot;&gt;&amp;#91;2 {0.42548900739367024 0.8725039567983159}&amp;#93;&lt;/span&gt;&lt;/p&gt;

&lt;p&gt;We create a large transient map with random keys and values, and check to see how many unique hashcodes we get. Then, we iterate over all the keys, dissoc&apos;ing each out of the transient map. The resulting map has one element in it (wrong - it should be empty, since we dissoc&apos;ed all the keys), and reports its count as being two (wrong - not sure whether it should be zero or one given the other breakage). As far as I can tell, each duplicated hash value is represented once in the output map, and the map&apos;s count is the number of keys that hashed to something duplicated.&lt;/p&gt;

&lt;p&gt;The problem seems to be restricted to transients, as if we remove the transient/persistent! pair and use dissoc instead of dissoc!, the map is always empty.&lt;/p&gt;

&lt;p&gt;Inspired by discussion at &lt;a href=&quot;http://groups.google.com/group/clojure/browse_thread/thread/313ac122667bb4b5/c3e7faa8635403f1&quot;&gt;http://groups.google.com/group/clojure/browse_thread/thread/313ac122667bb4b5/c3e7faa8635403f1&lt;/a&gt;&lt;/p&gt;</description>
                <environment></environment>
            <key id="14579">CLJ-829</key>
            <summary>Transient hashmaps mishandle hash collisions</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="6" iconUrl="http://dev.clojure.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Completed</resolution>
                                <assignee username="cgrand">Christophe Grand</assignee>
                                <reporter username="amalloy">Alan Malloy</reporter>
                        <labels>
                    </labels>
                <created>Wed, 24 Aug 2011 03:30:21 -0500</created>
                <updated>Fri, 1 Mar 2013 12:47:05 -0600</updated>
                    <resolved>Fri, 7 Oct 2011 09:12:36 -0500</resolved>
                            <version>Release 1.3</version>
                                <fixVersion>Release 1.4</fixVersion>
                                        <due></due>
                    <votes>0</votes>
                        <watches>3</watches>
                        <comments>
                    <comment id="26733" author="amalloy" created="Thu, 25 Aug 2011 12:26:12 -0500"  >&lt;p&gt;By the way, since this involves randomness, on occasion it doesn&apos;t fail. With the input as given it seems to fail around 80% of the time, but if you want to be sure to reproduce you can add another 0 to the input size.&lt;/p&gt;</comment>
                    <comment id="26735" author="aaron" created="Fri, 26 Aug 2011 09:20:43 -0500"  >&lt;p&gt;Thanks for the update.  I was able to reproduce with the extra zero. Moving this ticket to Release.Next so that it will ship with 1.3.&lt;/p&gt;</comment>
                    <comment id="26777" author="cgrand" created="Thu, 8 Sep 2011 13:15:20 -0500"  >&lt;p&gt;Sorry for the delay. Here is a fix and a reduced test case.&lt;/p&gt;</comment>
                    <comment id="26780" author="stu" created="Fri, 9 Sep 2011 15:50:56 -0500"  >&lt;p&gt;I have checked behavior with an independent test&lt;/p&gt;

&lt;p&gt;&lt;a href=&quot;https://github.com/clojure/test.generative/commit/b1350235eb219b76f5b7c4cc21c8255f567892b3&quot;&gt;https://github.com/clojure/test.generative/commit/b1350235eb219b76f5b7c4cc21c8255f567892b3&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;which looks good, but don&apos;t have context to evaluate the code (particularly the array allocation) in the time I have available today.&lt;/p&gt;</comment>
                    <comment id="26781" author="richhickey" created="Fri, 9 Sep 2011 16:14:01 -0500"  >&lt;p&gt;The array alloc looks suspicious:&lt;/p&gt;

&lt;p&gt;+		Object[] newArray = new Object&lt;span class=&quot;error&quot;&gt;&amp;#91;2*(array.length+1)&amp;#93;&lt;/span&gt;; // make room for next assoc&lt;br/&gt;
+		System.arraycopy(array, 0, newArray, 0, 2*count);&lt;/p&gt;

&lt;p&gt;should it not be array.length + 2, (or 2*(count + 1), whichever?&lt;/p&gt;</comment>
                    <comment id="26783" author="cgrand" created="Sat, 10 Sep 2011 03:48:51 -0500"  >&lt;p&gt;Thanks Rich for spotting this copy&amp;amp;paste error.&lt;/p&gt;

&lt;p&gt;I attached an updated patch.&lt;/p&gt;

&lt;p&gt;The problem reported by Alan was double:&lt;/p&gt;
&lt;ul&gt;
	&lt;li&gt;the misplaced removedLeaf.val = removedLeaf was causing the global count to be incorrect&lt;/li&gt;
	&lt;li&gt;the missing array copy in ensureEditable was causing the seq returned by (keys m) to be mutated (shortened) and this is why all values were not dissoced.&lt;/li&gt;
&lt;/ul&gt;


&lt;p&gt;Mutable code is hard, one should invent a cool language with sane state management &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="26784" author="stu" created="Sat, 10 Sep 2011 14:54:57 -0500"  >&lt;p&gt;New tests continue to pass.&lt;/p&gt;

&lt;p&gt;It seems to me that the allocation in the second path is too big by two in some cases (e.g. it gets called in the dissoc! path when the array needs to be copied, but not get bigger). But this might be considered innocuous. The same method is called in the assoc! path where the +2 is needed, so avoiding two objects worth of allocation would require a more substantial patch.&lt;/p&gt;</comment>
                    <comment id="26787" author="cgrand" created="Mon, 12 Sep 2011 03:39:27 -0500"  >&lt;p&gt;The larger array allocation is similar to the one performed in BitmapIndexedNode.ensureEditable. My line of thought behind this heuristic is that the copying dominates the allocation and that I prefer one slightly larger array than having to allocates two arrays in case of growth.&lt;/p&gt;

&lt;p&gt;Anyway it&apos;s on collision nodes so it&apos;s a rare occurence: I won&apos;t bother arguing further if switching to a more conservative allocation helps the patch landing in 1.3.  &lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="10340" name="clj-829-2.diff" size="2531" author="cgrand" created="Sat, 10 Sep 2011 03:48:51 -0500" />
                    <attachment id="10333" name="clj-829.diff" size="2537" author="cgrand" created="Thu, 8 Sep 2011 13:15:20 -0500" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_10002" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Approval</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10007">Ok</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-956] [java.lang.ClassFormatError: Duplicate method name&amp;signature] when using gen-class</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-956</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;Hi,&lt;/p&gt;

&lt;p&gt;When extending a class that defines a method with the signature &quot;public void load();&quot;, I get the following load time error:&lt;/p&gt;

&lt;p&gt;java.lang.ClassFormatError: Duplicate method name&amp;amp;signature&lt;/p&gt;

&lt;p&gt;Looking into javap, I see that in fact gen-class is generating two entries for the load method. Prefix does not help in this case, as the defined load method is generated anyway.&lt;/p&gt;

&lt;p&gt;Cheers,&lt;/p&gt;
&lt;ul class=&quot;alternate&quot; type=&quot;square&quot;&gt;
	&lt;li&gt;Daniel&lt;/li&gt;
&lt;/ul&gt;
</description>
                <environment>$ java -version&lt;br/&gt;
java version &amp;quot;1.6.0_29&amp;quot;&lt;br/&gt;
Java(TM) SE Runtime Environment (build 1.6.0_29-b11-402-11M3527)&lt;br/&gt;
Java HotSpot(TM) 64-Bit Server VM (build 20.4-b02-402, mixed mode)&lt;br/&gt;
&lt;br/&gt;
</environment>
            <key id="15286">CLJ-956</key>
            <summary>[java.lang.ClassFormatError: Duplicate method name&amp;signature] when using gen-class</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="6" iconUrl="http://dev.clojure.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="2">Declined</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="danielribeiro">Daniel Ribeiro</reporter>
                        <labels>
                        <label>AOT</label>
                    </labels>
                <created>Tue, 20 Mar 2012 04:06:40 -0500</created>
                <updated>Fri, 1 Mar 2013 12:47:05 -0600</updated>
                    <resolved>Fri, 9 Nov 2012 08:40:05 -0600</resolved>
                            <version>Release 1.3</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>1</watches>
                        <comments>
                    <comment id="27976" author="danielribeiro" created="Thu, 22 Mar 2012 05:10:59 -0500"  >&lt;p&gt;Hi,&lt;/p&gt;

&lt;p&gt;I&apos;ve create this small sample project to exemplify the bug ocurring: &lt;a href=&quot;https://github.com/danielribeiro/ClojureBugReport&quot;&gt;https://github.com/danielribeiro/ClojureBugReport&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;Cheers,&lt;/p&gt;
&lt;ul class=&quot;alternate&quot; type=&quot;square&quot;&gt;
	&lt;li&gt;Daniel&lt;/li&gt;
&lt;/ul&gt;
</comment>
                    <comment id="28005" author="danielribeiro" created="Sat, 24 Mar 2012 18:57:59 -0500"  >&lt;p&gt;Note that the name load is not special: it works with any abstract method, no matter the name.&lt;/p&gt;</comment>
                    <comment id="28006" author="danielribeiro" created="Sat, 24 Mar 2012 19:34:50 -0500"  >&lt;p&gt;Not a bug: I was declaring the method load, which was already defined on the abstract class. The docs do mention this:&lt;/p&gt;

&lt;p&gt;&lt;a href=&quot;http://clojuredocs.org/clojure_core/clojure.core/gen-class&quot;&gt;http://clojuredocs.org/clojure_core/clojure.core/gen-class&lt;/a&gt;&lt;/p&gt;</comment>
                    <comment id="29918" author="stuart.sierra" created="Fri, 9 Nov 2012 08:40:05 -0600"  >&lt;p&gt;Closed as not-a-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-933] Compiler warning on clojure.test-clojure.require-scratch</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-933</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;During Clojure build:&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] Testing clojure.test-clojure.java-interop
    [java] WARNING: with-bindings already refers to: #&apos;clojure.core/with-bindings in namespace: clojure.test-clojure.require-scratch, being replaced by: #&apos;clojure.main/with-bindings&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;</description>
                <environment></environment>
            <key id="15234">CLJ-933</key>
            <summary>Compiler warning on clojure.test-clojure.require-scratch</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="6" iconUrl="http://dev.clojure.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Completed</resolution>
                                <assignee username="stuart.sierra">Stuart Sierra</assignee>
                                <reporter username="stuart.sierra">Stuart Sierra</reporter>
                        <labels>
                    </labels>
                <created>Mon, 20 Feb 2012 09:07:47 -0600</created>
                <updated>Fri, 1 Mar 2013 12:47:05 -0600</updated>
                    <resolved>Mon, 20 Feb 2012 17:18:44 -0600</resolved>
                                                                    <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                        <comments>
                    <comment id="27775" author="stuart.sierra" created="Mon, 20 Feb 2012 09:33:24 -0600"  >&lt;p&gt;Fixed in patch, which uses a different namespace for the test.&lt;/p&gt;</comment>
                    <comment id="27783" author="stuart.sierra" created="Mon, 20 Feb 2012 17:18:44 -0600"  >&lt;p&gt;Patch applied.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="10930" name="CLJ-933-0001.patch" size="1075" author="stuart.sierra" created="Mon, 20 Feb 2012 09:33:24 -0600" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_10002" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Approval</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10007">Ok</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-416] improvments on agent</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-416</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;hi,i have some ideas to improve the agent system:&lt;br/&gt;
1.Agent&apos;s thread pool must use a custom ThreadFactory to new threads.Set new thread a system name and set it to be daemon.Thread&apos;s name would be used for debug or monitor.And set thread to be daemon asking user to shutdown agents explicitly.&lt;/p&gt;

&lt;p&gt;2.Beacause agent&apos;s thread is daemon,so if a application doesn&apos;t use any agents,the thread pool must not started.I think the agent&apos;s thread pools should be lazy initialized.&lt;/p&gt;

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

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

&lt;p&gt;Second, the actions which global thread pool execute are from a&lt;br/&gt;
variety of agents, the actions are not homogeneous, and can not&lt;br/&gt;
maximize the efficient use of the thread pool.&lt;/p&gt;

&lt;p&gt;These are my suggestions on agent,thanks for this great language,i enjoy it.&lt;/p&gt;</description>
                <environment></environment>
            <key id="13813">CLJ-416</key>
            <summary>improvments on agent</summary>
                <type id="4" iconUrl="http://dev.clojure.org/jira/images/icons/improvement.gif">Enhancement</type>
                                        <status id="6" iconUrl="http://dev.clojure.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Completed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="-1">None</reporter>
                        <labels>
                    </labels>
                <created>Fri, 30 Jul 2010 16:15:00 -0500</created>
                <updated>Fri, 1 Mar 2013 12:47:03 -0600</updated>
                    <resolved>Tue, 27 Nov 2012 14:18:49 -0600</resolved>
                                            <fixVersion>Backlog</fixVersion>
                                        <due></due>
                    <votes>0</votes>
                        <watches>2</watches>
                        <comments>
                    <comment id="24167" author="importer" created="Tue, 24 Aug 2010 18:42:00 -0500"  >&lt;p&gt;Converted from &lt;a href=&quot;http://www.assembla.com/spaces/clojure/tickets/416&quot;&gt;http://www.assembla.com/spaces/clojure/tickets/416&lt;/a&gt;&lt;/p&gt;</comment>
                    <comment id="30063" author="halgari" created="Tue, 27 Nov 2012 14:18:49 -0600"  >&lt;p&gt;Closing as &quot;completed&quot; as most of these requests are handled in 1.5 via the new send-via, and set executor functions.&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-184] n-ary bit functions, also inlining of n-ary bit and math operations</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-184</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;Add an &amp;amp;more version to the bit operations bit-and bit-or bit-xor bit-and-not (via reduce),&lt;br/&gt;
Inline the n-ary version of the math ops, + - * /, inline the n-ary versions of bit-and bit-or bit-xor bit-and-not&lt;/p&gt;</description>
                <environment></environment>
            <key id="13581">CLJ-184</key>
            <summary>n-ary bit functions, also inlining of n-ary bit and math operations</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="6" iconUrl="http://dev.clojure.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Completed</resolution>
                                <assignee username="alan@thinkrelevance.com">Alan Dipert</assignee>
                                <reporter username="importer">Assembla Importer</reporter>
                        <labels>
                    </labels>
                <created>Wed, 26 Aug 2009 17:37:00 -0500</created>
                <updated>Fri, 1 Mar 2013 12:47:03 -0600</updated>
                    <resolved>Sat, 14 May 2011 16:21:04 -0500</resolved>
                                            <fixVersion>Release 1.3</fixVersion>
                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                        <comments>
                    <comment id="23159" author="importer" created="Tue, 24 Aug 2010 06:19:00 -0500"  >&lt;p&gt;Converted from &lt;a href=&quot;http://www.assembla.com/spaces/clojure/tickets/184&quot;&gt;http://www.assembla.com/spaces/clojure/tickets/184&lt;/a&gt;&lt;br/&gt;
Attachments:&lt;br/&gt;
inlinemath.patch - &lt;a href=&quot;https://www.assembla.com/spaces/clojure/documents/dlFRFQKPyr3RaoeJe5aVNr/download/dlFRFQKPyr3RaoeJe5aVNr&quot;&gt;https://www.assembla.com/spaces/clojure/documents/dlFRFQKPyr3RaoeJe5aVNr/download/dlFRFQKPyr3RaoeJe5aVNr&lt;/a&gt;&lt;/p&gt;</comment>
                    <comment id="23160" author="importer" created="Tue, 24 Aug 2010 06:19:00 -0500"  >&lt;p&gt;Jonathan A Smith said: [&lt;a href=&quot;file:dlFRFQKPyr3RaoeJe5aVNr&quot;&gt;file:dlFRFQKPyr3RaoeJe5aVNr&lt;/a&gt;]: inline math and bit-or patch file&lt;/p&gt;</comment>
                    <comment id="23161" author="importer" created="Tue, 24 Aug 2010 06:19:00 -0500"  >&lt;p&gt;Jonathan A Smith said: original math defs stay, new ones get re-defined after proxy is available.&lt;/p&gt;</comment>
                    <comment id="23162" author="importer" created="Tue, 24 Aug 2010 06:19:00 -0500"  >&lt;p&gt;mikehinchey said: Applies clean (though has extra whitespace and tabs).  Existing tests still pass.&lt;/p&gt;</comment>
                    <comment id="23163" author="importer" created="Tue, 24 Aug 2010 06:19:00 -0500"  >&lt;p&gt;Jonathan A Smith said: The defn functions are within a let, which means that they get tabbed in by Emacs ctrl+alt+Q. Is this the referred to &apos;extra whitespace and tabs&apos;?&lt;/p&gt;

&lt;p&gt;I think that this line: &lt;br/&gt;
&amp;gt;0-arities (rule-set (fn &lt;span class=&quot;error&quot;&gt;&amp;#91;x&amp;#93;&lt;/span&gt; (&amp;gt; x 1)))&lt;/p&gt;

&lt;p&gt;might be a mistake, and perhaps should be:&lt;br/&gt;
&amp;gt;0-arities (rule-set (fn &lt;span class=&quot;error&quot;&gt;&amp;#91;x&amp;#93;&lt;/span&gt; (&amp;gt; x 0)))&lt;/p&gt;

&lt;p&gt;But I will have to look at it and rebuild it when I get home tonight. resulting tests would still pass as the only effected function would be the single arity subtraction operation.&lt;/p&gt;</comment>
                    <comment id="23164" author="importer" created="Tue, 24 Aug 2010 06:19:00 -0500"  >&lt;p&gt;mikehinchey said: &quot;git am&quot; complained about whitespace at the ends of lines.  When I tab on each line to re-indent, emacs replaced tabs with spaces and deleted space at the end.  Also, you could combine the 2 let blocks into 1.&lt;/p&gt;</comment>
                    <comment id="23165" author="importer" created="Tue, 24 Aug 2010 06:19:00 -0500"  >&lt;p&gt;richhickey said: This still needs work. I&apos;d like to avoid the need for proxy. It would be easy to make Compiler.isInline() in the compiler presume :inline-arities is an IFn (so sets literals would still work, but so would predicate fns)&lt;/p&gt;</comment>
                    <comment id="23166" author="importer" created="Tue, 24 Aug 2010 06:19:00 -0500"  >&lt;p&gt;richhickey said: I&apos;ve made that change, so isInline now treats :inline-arities as a predicate IFn. This should allow for a simpler implementation&lt;/p&gt;</comment>
                    <comment id="26385" author="redinger" created="Fri, 22 Apr 2011 11:40:46 -0500"  >&lt;p&gt;Adding patch from Assembla&lt;/p&gt;</comment>
                    <comment id="26415" author="alan@thinkrelevance.com" created="Sat, 30 Apr 2011 15:59:33 -0500"  >&lt;p&gt;inlining and n-ary bit functions and math ops&lt;/p&gt;
&lt;ul class=&quot;alternate&quot; type=&quot;square&quot;&gt;
	&lt;li&gt;n-ary versions and inlines of bit-and, bit-or, bit-xor, bit-and-not&lt;/li&gt;
	&lt;li&gt;n-ary inlines for +, +&apos;, *, *&apos;, /, -, -&apos;&lt;/li&gt;
&lt;/ul&gt;


&lt;p&gt;This patch doesn&apos;t optimize / such that the &amp;amp; more version expands to equivalent of (/ x (reduce * y more)) rather than (reduce / (/ x y) more).  The original patch had a divide-by-zero bug, and I think adding this should be another ticket.&lt;/p&gt;</comment>
                    <comment id="26416" author="alan@thinkrelevance.com" created="Sat, 30 Apr 2011 16:12:34 -0500"  >&lt;p&gt;Created &lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-785&quot; title=&quot;Optimize /&quot;&gt;&lt;del&gt;CLJ-785&lt;/del&gt;&lt;/a&gt; for optimizing n-ary /&lt;/p&gt;</comment>
                    <comment id="26417" author="ataggart" created="Tue, 3 May 2011 13:46:16 -0500"  >&lt;p&gt;You&apos;d have less copypasta using this:&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 ^:private binary-inline
  ([op]
    (fn
      ([x y] `(. clojure.lang.Numbers (~op ~x ~y)))
      ([x y &amp;amp; more]
        (reduce1
          (fn [a b] `(. clojure.lang.Numbers (~op ~a ~b)))
          `(. clojure.lang.Numbers (~op ~x ~y)) more))))
  ([op unchecked-op]
    (if *unchecked-math*
      (binary-inline unchecked-op)
      (binary-inline op))))

(defn ^:private &amp;gt;1? [n] (clojure.lang.Numbers/gt n 1))
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;Also, &lt;tt&gt;^:static&lt;/tt&gt; doesn&apos;t do anything anymore.&lt;/p&gt;

&lt;p&gt;The above was from &lt;a href=&quot;https://github.com/ataggart/clojure/commits/n-ary&quot;&gt;the branch I made&lt;/a&gt;, that I mentioned in &lt;a href=&quot;http://groups.google.com/group/clojure-dev/msg/a9d7d36f3c4f96bb&quot;&gt;the thread on ticket status&lt;/a&gt;.  It also included a fix for the inefficient divide.  &lt;/p&gt;</comment>
                    <comment id="26418" author="alan@thinkrelevance.com" created="Tue, 3 May 2011 20:50:37 -0500"  >&lt;p&gt;Thanks, I&apos;ll extract a patch for this from your branch.&lt;/p&gt;</comment>
                    <comment id="26422" author="alan@thinkrelevance.com" created="Fri, 6 May 2011 12:39:20 -0500"  >&lt;p&gt;This patch incorporates Alex Taggart&apos;s work in the comments, but leaves out the change to &lt;tt&gt;/&lt;/tt&gt;.  It made a call to the nonexistent Numbers/unchecked_divide method and multiplies in the denominator, which is faster but has different overflow behavior than divide/reduce.&lt;/p&gt;</comment>
                    <comment id="26423" author="ataggart" created="Sat, 7 May 2011 00:30:17 -0500"  >&lt;p&gt;One problem with the patch: while the bit-ops fns have n-ary support for their inlines, the fns themselves do not.  They need to be updated to something like:&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 bit-and
  &quot;Bitwise and&quot;
  {:inline (nary-inline &apos;and)
   :inline-arities &amp;gt;1?
   :added &quot;1.0&quot;}
  ([x y] (. clojure.lang.Numbers and x y))
  ([x y &amp;amp; more]
    (reduce1 bit-and (bit-and x y) more)))
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;</comment>
                    <comment id="26424" author="alan@thinkrelevance.com" created="Mon, 9 May 2011 23:42:31 -0500"  >&lt;p&gt;Attached 184-inlining-nary-math-3.diff. Same as previous patch, but adds n-ary version of bit fns in addition to inlines, which were missing as Alex Taggart pointed out.  Thanks for catching that!&lt;/p&gt;</comment>
                    <comment id="26440" author="alan@thinkrelevance.com" created="Sat, 14 May 2011 16:21:05 -0500"  >&lt;p&gt;Patch is in 1.3-alpha7&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="10218" name="184-inlining-nary-math-2.diff" size="4878" author="alan@thinkrelevance.com" created="Fri, 6 May 2011 12:39:20 -0500" />
                    <attachment id="10220" name="184-inlining-nary-math-3.diff" size="5329" author="alan@thinkrelevance.com" created="Mon, 9 May 2011 23:42:30 -0500" />
                    <attachment id="10214" name="184-inlining-nary-math.diff" size="5884" author="alan@thinkrelevance.com" created="Sat, 30 Apr 2011 15:59:33 -0500" />
                    <attachment id="10196" name="inlinemath.patch" size="4322" author="redinger" created="Fri, 22 Apr 2011 11:40:46 -0500" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_10002" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Approval</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10007">Ok</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-851] Type-hinting a var with primitive array pseudo-class results in IllegalArgumentException when the var is used as an arg</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-851</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;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;user=&amp;gt; (def ^longs la (long-array 0))
#&apos;user/la
user=&amp;gt; (defn foo [] (alength la))
CompilerException java.lang.IllegalArgumentException: Unable to resolve classname: clojure.core$longs@32dfcb47, compiling:(NO_SOURCE_PATH:9) 
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;Workaround: use the class string, e.g., &lt;tt&gt;^&quot;[J&quot;&lt;/tt&gt;&lt;/p&gt;</description>
                <environment></environment>
            <key id="14679">CLJ-851</key>
            <summary>Type-hinting a var with primitive array pseudo-class results in IllegalArgumentException when the var is used as an arg</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="6" iconUrl="http://dev.clojure.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="2">Declined</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="ataggart">Alexander Taggart</reporter>
                        <labels>
                    </labels>
                <created>Mon, 10 Oct 2011 00:26:46 -0500</created>
                <updated>Fri, 1 Mar 2013 12:47:03 -0600</updated>
                    <resolved>Fri, 9 Nov 2012 08:39:08 -0600</resolved>
                            <version>Release 1.3</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>2</watches>
                        <comments>
                    <comment id="26988" author="bsmith.occs@gmail.com" created="Sat, 15 Oct 2011 11:40:05 -0500"  >&lt;p&gt;&lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-851&quot; title=&quot;Type-hinting a var with primitive array pseudo-class results in IllegalArgumentException when the var is used as an arg&quot;&gt;&lt;del&gt;CLJ-851&lt;/del&gt;&lt;/a&gt;-test.patch&lt;/p&gt;

&lt;p&gt;Provides a test to reproduce this issue, as well as a test that shows that the workaround of using ^&quot;[J&quot; as type hint works correctly.&lt;/p&gt;</comment>
                    <comment id="26995" author="bsmith.occs@gmail.com" created="Sun, 16 Oct 2011 02:23:54 -0500"  >&lt;p&gt;OK, I see the problem here: &lt;tt&gt;longs&lt;/tt&gt; plays two roles in Clojure:&lt;/p&gt;

&lt;ol&gt;
	&lt;li&gt;As an unqualified symbol, it&apos;s taken to mean &lt;tt&gt;long[].class&lt;/tt&gt;.&lt;/li&gt;
	&lt;li&gt;&lt;tt&gt;clojure.core/longs&lt;/tt&gt; is a definline function which calls &lt;tt&gt;clojure.lang.Numbers.longs(...)&lt;/tt&gt;.&lt;/li&gt;
&lt;/ol&gt;


&lt;p&gt;The example in the issue description is expecting the first interpretation, but what we&apos;re actually getting is the second interpretation, i.e. the :tag is not a symbol &lt;tt&gt;longs&lt;/tt&gt;, but rather a function (an instance of the class &lt;tt&gt;clojure.core$longs&lt;/tt&gt;, to be precise).&lt;/p&gt;

&lt;p&gt;So, it&apos;s as if we&apos;d written this:&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 ^{:tag clojure.core/longs} la (long-array 0))
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;When really, we meant this:&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 ^{:tag &apos;longs} la (long-array 0))
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;While the behavior described by this issue is confusing, it looks to me like it&apos;s &lt;em&gt;not a bug&lt;/em&gt;.&lt;/p&gt;</comment>
                    <comment id="29917" author="stuart.sierra" created="Fri, 9 Nov 2012 08:39:08 -0600"  >&lt;p&gt;Correct, this is not a bug. The reader will attempt to resolve symbols in the ^tag metadata form, so that it can resolve unqualified class names.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="10399" name="CLJ-851-test.patch" size="2225" author="bsmith.occs@gmail.com" created="Sat, 15 Oct 2011 11:40: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>
                                                                                                            </customfields>
    </item>

<item>
            <title>[CLJ-1040] reduce-kv on sorted maps should reduce, in sorted order</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1040</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;Currently reduces, but not in sorted order. &lt;/p&gt;</description>
                <environment></environment>
            <key id="15620">CLJ-1040</key>
            <summary>reduce-kv on sorted maps should reduce, in sorted order</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="6" iconUrl="http://dev.clojure.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="3">Duplicate</resolution>
                                <assignee username="stu">Stuart Halloway</assignee>
                                <reporter username="stu">Stuart Halloway</reporter>
                        <labels>
                    </labels>
                <created>Fri, 10 Aug 2012 10:47:08 -0500</created>
                <updated>Fri, 1 Mar 2013 12:47:03 -0600</updated>
                    <resolved>Wed, 15 Aug 2012 12:25:35 -0500</resolved>
                                                                    <due></due>
                    <votes>0</votes>
                        <watches>2</watches>
                        <comments>
                    <comment id="29109" author="amalloy" created="Fri, 10 Aug 2012 15:09:10 -0500"  >&lt;p&gt;Stuart, your patch doesn&apos;t check for Reduced after calling f on the current node; I think you need to move that check along with the call to f.&lt;/p&gt;</comment>
                    <comment id="29111" author="amalloy" created="Fri, 10 Aug 2012 15:18:52 -0500"  >&lt;p&gt;&lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-1041&quot; title=&quot;reduce-kv on sorted maps should stop on seeing a Reduced value&quot;&gt;&lt;del&gt;CLJ-1041&lt;/del&gt;&lt;/a&gt; is a related issue, and its patch also includes a commit that I think would fix your patch.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="11418" name="fix-reduce-kv-for-sorted-maps.patch" size="1171" author="stu" created="Fri, 10 Aug 2012 10:55:08 -0500" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_10002" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Approval</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10007">Ok</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-1153] Change *read-eval* default value to false</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1153</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;Discussion on the security implications of &lt;b&gt;read-eval&lt;/b&gt; defaulting to true here: &lt;a href=&quot;https://groups.google.com/forum/?fromgroups=#!topic/clojure/qUk-bM0JSGc&quot;&gt;https://groups.google.com/forum/?fromgroups=#!topic/clojure/qUk-bM0JSGc&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;I&apos;m not sure whether the unit test that needs &lt;b&gt;read-eval&lt;/b&gt; true in order to pass is a sign of lots of other code that would break if &lt;b&gt;read-eval&lt;/b&gt; defaulted to false.&lt;/p&gt;</description>
                <environment></environment>
            <key id="15982">CLJ-1153</key>
            <summary>Change *read-eval* default value to false</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="6" iconUrl="http://dev.clojure.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="2">Declined</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="jafingerhut">Andy Fingerhut</reporter>
                        <labels>
                    </labels>
                <created>Wed, 30 Jan 2013 10:49:54 -0600</created>
                <updated>Fri, 1 Mar 2013 12:47:03 -0600</updated>
                    <resolved>Sat, 9 Feb 2013 09:17:03 -0600</resolved>
                            <version>Release 1.3</version>
                <version>Release 1.4</version>
                <version>Release 1.5</version>
                                                        <due></due>
                    <votes>33</votes>
                        <watches>14</watches>
                        <comments>
                    <comment id="30518" author="technomancy" created="Thu, 31 Jan 2013 11:55:29 -0600"  >&lt;p&gt;It&apos;s worth noting that there was a breakin to rubygems.org over the weekend that was caused by what amounts to this same issue, but with YAML: &lt;a href=&quot;https://news.ycombinator.com/item?id=5141138&quot;&gt;https://news.ycombinator.com/item?id=5141138&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;The current default is both dangerous and undocumented; this needs to change.&lt;/p&gt;</comment>
                    <comment id="30519" author="sorenmacbeth" created="Thu, 31 Jan 2013 12:33:07 -0600"  >&lt;p&gt;Seconded!&lt;/p&gt;</comment>
                    <comment id="30520" author="mikera" created="Fri, 1 Feb 2013 00:52:16 -0600"  >&lt;p&gt;Thirded. &lt;/p&gt;

&lt;p&gt;For what it&apos;s worth, on the topic of breaking changes I&apos;d &lt;b&gt;much&lt;/b&gt; rather my old code break than continue to work with an unnoticed security hole.&lt;/p&gt;</comment>
                    <comment id="30521" author="stu" created="Fri, 1 Feb 2013 07:21:24 -0600"  >&lt;p&gt;Fourthed.  I hope folks will pitch in and help deal with any breakage.&lt;/p&gt;</comment>
                    <comment id="30523" author="cemerick" created="Fri, 1 Feb 2013 12:57:14 -0600"  >&lt;p&gt;New patch attached, {{&lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-1185&quot; title=&quot;`reductions should respect `reduced&quot;&gt;CLJ-1185&lt;/a&gt;.patch}}.&lt;/p&gt;

&lt;p&gt;This patch eliminates the use of &lt;tt&gt;&amp;#42;print-dup&amp;#42;&lt;/tt&gt; in the compiler entirely.  &lt;tt&gt;read-string&lt;/tt&gt; continues to be used to support values that can only be represented via tagged reader literals; I don&apos;t think there&apos;s any way around that, since the mapping between particular data readers and values&apos; types are buried in individual &lt;tt&gt;print-method&lt;/tt&gt; implementations.&lt;/p&gt;

&lt;p&gt;All tests pass (including cases like &lt;tt&gt;(eval (list + 1 2 3))&lt;/tt&gt; as discussed in the ML thread referenced in the issue description), and a variety of sanity checks around evaluation and compilation tooling (e.g. AOT, nREPL, introspection utilities in Leiningen/Reply/Counterclockwise) all work as expected.&lt;/p&gt;

&lt;p&gt;Of course, if this is applied, then any usage of &lt;tt&gt;read&lt;/tt&gt; over &lt;b&gt;trusted&lt;/b&gt; content containing &lt;tt&gt;#=&lt;/tt&gt; forms will need to be done with &lt;tt&gt;&amp;#42;read-eval&amp;#42;&lt;/tt&gt; bound to &lt;tt&gt;true&lt;/tt&gt;.&lt;/p&gt;

&lt;p&gt;To aid in testing, a Clojure build (&lt;tt&gt;1.5.0-RC4&lt;/tt&gt;) + this patch is available here:&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;[com.cemerick/clojure &lt;span class=&quot;code-quote&quot;&gt;&quot;1.5.0-SNAPSHOT&quot;&lt;/span&gt;]&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;Note that you&apos;ll have to exclude the standard Clojure dependency from your project in order for this one to take precedence; you can do this by adding&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;:exclusions [org.clojure/clojure]&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;to your &lt;tt&gt;project.clj&lt;/tt&gt;.&lt;/p&gt;</comment>
                    <comment id="30524" author="pjstadig" created="Fri, 1 Feb 2013 14:49:18 -0600"  >&lt;p&gt;I ran the Sonian test base against this patch.  I wouldn&apos;t say our test cases are comprehensive, but they&apos;re not trivial.  We talk to databases through JDBC, and we deal with lots of different data types (BigInts, Strings, Dates, and such).&lt;/p&gt;

&lt;p&gt;I had to make a few small changes to our code base, because we rely pretty heavily on &lt;b&gt;print-dup&lt;/b&gt; to serialize non-user originated data.  We have to add corresponding binding blocks when reading to set &lt;b&gt;read-eval&lt;/b&gt; to true.  Other than that, the tests all passed.&lt;/p&gt;

&lt;p&gt;+1&lt;/p&gt;</comment>
                    <comment id="30525" author="cemerick" created="Fri, 1 Feb 2013 16:28:22 -0600"  >&lt;p&gt;Thanks to all that have tested the patch!  Looks like we&apos;ve made some progress.  I&apos;m going to post to the main Clojure ML now and hopefully get more yay/nay votes.&lt;/p&gt;</comment>
                    <comment id="30527" author="jafingerhut" created="Sat, 2 Feb 2013 11:05:03 -0600"  >&lt;p&gt;clj-1153-patch-v2.txt dated Feb 2 2013 is functionally identical to Chas Emerick&apos;s &lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-1185&quot; title=&quot;`reductions should respect `reduced&quot;&gt;CLJ-1185&lt;/a&gt;.patch dated Feb 1 2013, and no retesting is needed by anyone because of it.&lt;/p&gt;

&lt;p&gt;The only change I have made to his patch is: the doc string for &lt;b&gt;read-eval&lt;/b&gt; now says its default value is false.&lt;/p&gt;</comment>
                    <comment id="30528" author="jafingerhut" created="Sat, 2 Feb 2013 11:06:09 -0600"  >&lt;p&gt;Also removed my original didn&apos;t-fix-enough-things patch from Jan 30 2013.&lt;/p&gt;</comment>
                    <comment id="30532" author="timmc" created="Sat, 2 Feb 2013 15:22:49 -0600"  >&lt;p&gt;I&apos;m bumping the Priority field from its default value to &quot;Major&quot; to reflect recent events. (I personally feel &quot;blocker&quot; would be more appropriate, or at least &quot;critical&quot;, but I don&apos;t want to step on any toes.)&lt;/p&gt;</comment>
                    <comment id="30548" author="richhickey" created="Mon, 4 Feb 2013 19:55:25 -0600"  >&lt;p&gt;&lt;a href=&quot;https://github.com/clojure/clojure/commit/974a64c06917861b7557fd73154254195b2de548&quot;&gt;https://github.com/clojure/clojure/commit/974a64c06917861b7557fd73154254195b2de548&lt;/a&gt;&lt;/p&gt;</comment>
                    <comment id="30574" author="richhickey" created="Sat, 9 Feb 2013 09:17:03 -0600"  >&lt;p&gt;This ticket is an excellent example of a terrible ticket.&lt;/p&gt;

&lt;p&gt;1) It does not lead with a problem statement. The title takes the form akin to &quot;I want X&quot;. It proposes a tactic.&lt;/p&gt;

&lt;p&gt;2) The description is woefully inadequate. Here too, no problem statement. Descriptions should point to any discussions, but discussions are long and rambling, and no substitute for a succinct problem statement in the description. Descriptions need to be maintained, with the current strategy and name of best patch.&lt;/p&gt;

&lt;p&gt;3) No resolution strategy. Just patches attached. How is a reviewer supposed to assess your patch if you don&apos;t even bother stating what the problem is and what your approach will be in fixing it, how that approach does fix it, and what if any tradeoffs are being made?&lt;/p&gt;

&lt;p&gt;4) The change being requested would be a breaking change. That should be made extremely clear in the description, and doubles the threshold for quality of motivation and implementation.&lt;/p&gt;

&lt;p&gt;5) Any breaking change would have to carefully enumerate what would break and when, what the migration strategy would be etc.&lt;/p&gt;

&lt;p&gt;6) The patch breaks the compiler. If you don&apos;t understand how the compiler works, and why features are there, you shouldn&apos;t submit patches that alter it. The only assessments made in comments are &apos;it works for me&apos;, which, while useful anecdotes, are insufficient. &lt;/p&gt;

&lt;p&gt;While the ticket itself was bad, the uncritical rallying behind it was more troubling. This is not how Clojure was built, and will not be how it is maintained.&lt;/p&gt;

&lt;p&gt;In the end, the ticket proposed a tactic, and that tactic has been rejected. Read safety has been addressed by other means.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="11828" name="clj-1153-patch-v2.txt" size="8106" author="jafingerhut" created="Sat, 2 Feb 2013 11:05:03 -0600" />
                    <attachment id="11826" name="CLJ-1185.patch" size="7394" author="cemerick" created="Fri, 1 Feb 2013 12:57: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="10001">Code</customfieldvalue>

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

<item>
            <title>[CLJ-234] Adding provenance of deprecation warnings to the LispReader</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-234</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;The LispReader has some deprecation warnings, but they do not show their provenance. The attached patch provide improved warning messages by modifying the LineNumberingPushbackReader to include the source path of the file being read, so that it can be retrieved by the LispReader.&lt;/p&gt;</description>
                <environment></environment>
            <key id="13631">CLJ-234</key>
            <summary>Adding provenance of deprecation warnings to the LispReader</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="6" iconUrl="http://dev.clojure.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="2">Declined</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="importer">Assembla Importer</reporter>
                        <labels>
                    </labels>
                <created>Fri, 1 Jan 2010 15:30:00 -0600</created>
                <updated>Fri, 1 Mar 2013 12:47:03 -0600</updated>
                    <resolved>Fri, 31 Dec 2010 15:59:02 -0600</resolved>
                                            <fixVersion>Release 1.3</fixVersion>
                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                        <comments>
                    <comment id="23365" author="importer" created="Tue, 28 Sep 2010 07:02:00 -0500"  >&lt;p&gt;Converted from &lt;a href=&quot;http://www.assembla.com/spaces/clojure/tickets/234&quot;&gt;http://www.assembla.com/spaces/clojure/tickets/234&lt;/a&gt;&lt;br/&gt;
Attachments:&lt;br/&gt;
0002-Modified-the-LineNumberingPushbackReader-to-include-.patch - &lt;a href=&quot;https://www.assembla.com/spaces/clojure/documents/bmHcpC9Yur3RGweJe5afGb/download/bmHcpC9Yur3RGweJe5afGb&quot;&gt;https://www.assembla.com/spaces/clojure/documents/bmHcpC9Yur3RGweJe5afGb/download/bmHcpC9Yur3RGweJe5afGb&lt;/a&gt;&lt;/p&gt;</comment>
                    <comment id="26046" author="stu" created="Fri, 17 Dec 2010 14:31:14 -0600"  >&lt;p&gt;Alan: please bounce this if incomplete, or screen if it seems simple enough.&lt;/p&gt;</comment>
                    <comment id="26047" author="alan@thinkrelevance.com" created="Fri, 17 Dec 2010 14:53:37 -0600"  >&lt;p&gt;The patch looks good, but as of 1.2 there are no longer any deprecated reader macros.  This might be worth adding in case any macros are deprecated in the future.&lt;/p&gt;</comment>
                    <comment id="26075" author="stu" created="Fri, 31 Dec 2010 15:59:02 -0600"  >&lt;p&gt;If we ever have another deprecation, we should bring this back along with a test case.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="10052" name="0234_LispReader_deprecation_provenance.patch" size="3736" author="aaron" created="Sun, 12 Dec 2010 16:53:57 -0600" />
                    <attachment id="10051" name="0234_LispReader_deprecation_provenance.patch" size="3736" author="aaron" created="Sun, 12 Dec 2010 16:37:13 -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>
                                                                                                            </customfields>
    </item>

<item>
            <title>[CLJ-736] Docstring of defrecord (and =) does not correctly describe equality behavior for records. </title>
                <link>http://dev.clojure.org/jira/browse/CLJ-736</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;&lt;a href=&quot;http://groups.google.com/group/clojure/browse_frm/thread/eba691b38c45196b#&quot;&gt;http://groups.google.com/group/clojure/browse_frm/thread/eba691b38c45196b#&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;The docstring of defrecord says it &quot;will define type-and- &lt;br/&gt;
value-based equality and hashCode&quot;.   In reality, record types are included in = but not .equals (or hashCode), and so records of different types can collide as map keys.   &lt;/p&gt;

&lt;p&gt;Along the same lines, the docstring of = says &quot;same as Java x.equals&lt;img class=&quot;emoticon&quot; src=&quot;http://dev.clojure.org/jira/images/icons/emoticons/thumbs_up.gif&quot; height=&quot;19&quot; width=&quot;19&quot; align=&quot;absmiddle&quot; alt=&quot;&quot; border=&quot;0&quot;/&gt;, except it ... compares numbers and collections in a type-independent manner&quot;.   To me, this seems to imply the opposite of what actually happens with records. &lt;/p&gt;

&lt;p&gt;FWIW I think it would be more clear if the behavior for = and .equals were the same in this respect, but in any case the implemented behavior should be properly documented.&lt;/p&gt;</description>
                <environment></environment>
            <key id="14349">CLJ-736</key>
            <summary>Docstring of defrecord (and =) does not correctly describe equality behavior for records. </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="6" iconUrl="http://dev.clojure.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Completed</resolution>
                                <assignee username="stu">Stuart Halloway</assignee>
                                <reporter username="jawolfe">Jason Wolfe</reporter>
                        <labels>
                    </labels>
                <created>Wed, 9 Feb 2011 18:00:40 -0600</created>
                <updated>Fri, 1 Mar 2013 12:47:03 -0600</updated>
                    <resolved>Fri, 2 Sep 2011 09:39:50 -0500</resolved>
                            <version>Release 1.2</version>
                <version>Release 1.3</version>
                <version>Release 1.4</version>
                                <fixVersion>Release 1.3</fixVersion>
                <fixVersion>Release 1.4</fixVersion>
                                        <due></due>
                    <votes>0</votes>
                        <watches>2</watches>
                        <comments>
                    <comment id="26493" author="stuart.sierra" created="Mon, 6 Jun 2011 09:37:25 -0500"  >&lt;p&gt;Also discussed at &lt;a href=&quot;https://groups.google.com/d/topic/clojure/e6UhXVny8Xc/discussion&quot;&gt;https://groups.google.com/d/topic/clojure/e6UhXVny8Xc/discussion&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;Per Rich, &quot;The policy is: = includes the type and .equals doesn&apos;t. In this way records can still be proper j.u.Maps and = remains most useful for records (e.g. including type).&quot;&lt;/p&gt;</comment>
                    <comment id="26494" author="jawolfe" created="Mon, 6 Jun 2011 11:25:25 -0500"  >&lt;p&gt;On a related note:&lt;/p&gt;

&lt;p&gt;&lt;a href=&quot;http://dev.clojure.org/display/doc/Enhanced+Primitive+Support?focusedCommentId=1573146#comment-1573146&quot;&gt;http://dev.clojure.org/display/doc/Enhanced+Primitive+Support?focusedCommentId=1573146#comment-1573146&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;Regarding &quot;hash maps and sets now use = for keys ... will use stricter .equals when calling through java.util interfaces&quot;:&lt;/p&gt;

&lt;p&gt;Note that &quot;=&quot; is actually stricter than &quot;.equals&quot; for record types currently, because it includes type information.&lt;/p&gt;

&lt;p&gt;This has important consequences for how (and whether) hash maps and sets actually obey the java.util interfaces.&lt;/p&gt;

&lt;p&gt;For instance, if &lt;/p&gt;

&lt;p&gt;(defrecord P []), ...&lt;/p&gt;

&lt;p&gt;what should (.get {(P.) 1 (Q.) 2} (Q.)) return?  How about if we .get an element of a third type (R.)?&lt;br/&gt;
&lt;br/&gt;
In a similar vein, this behavior seems confusing at best:&lt;br/&gt;
&lt;br/&gt;
user=&amp;gt; (java.util.HashMap. {(P.) 1 (Q.) 2})&lt;br/&gt;
#&amp;lt;HashMap {user.P@0=2}&amp;gt;&lt;/p&gt;</comment>
                    <comment id="26538" author="aaron" created="Tue, 28 Jun 2011 18:36:32 -0500"  >&lt;p&gt;Open question:&lt;/p&gt;

&lt;ul&gt;
	&lt;li&gt;the phrase &quot;type-independent&quot; is confusing. It is intended to talk about concrete numeric and collection types, but I can see why it gets confusing with records. Need an idea for two different terms here (and define them someplace). If somebody has one, please add it to this ticket.&lt;/li&gt;
&lt;/ul&gt;


&lt;p&gt;Non-issues:&lt;/p&gt;

&lt;ul&gt;
	&lt;li&gt;= and .equals are not and will not be the same. The whole point is to avoid Java&apos;s broken semantics (=) while providing an interop formula for those who need it (.equals)&lt;/li&gt;
	&lt;li&gt;Any types can collide as hash keys.&lt;/li&gt;
&lt;/ul&gt;
</comment>
                    <comment id="26724" author="aaron" created="Fri, 19 Aug 2011 11:34:39 -0500"  >&lt;p&gt;Any thoughts on the open questions part Rich?&lt;/p&gt;</comment>
                    <comment id="26752" author="stu" created="Fri, 2 Sep 2011 09:37:00 -0500"  >&lt;p&gt;I think the following is better:&lt;/p&gt;

&lt;p&gt;&lt;tt&gt;monospaced&lt;/tt&gt;&lt;br/&gt;
  In addition, defrecord will define type-and-value-based =,&lt;br/&gt;
  and will defined Java .hashCode and .equals consistent with the&lt;br/&gt;
  contract for java.util.Map.&lt;br/&gt;
&lt;tt&gt;monospaced&lt;/tt&gt;&lt;/p&gt;

&lt;p&gt;But I don&apos;t want to hold release for discussion, so bumping this to approved backlog for further bikeshedding. &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="26753" author="stu" created="Fri, 2 Sep 2011 09:39:50 -0500"  >&lt;p&gt;Better yet, let&apos;s just agreed on my prose and call this done.&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="10005">Accepted</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_10003" key="com.atlassian.jira.plugin.system.customfieldtypes:userpicker">
                <customfieldname>Waiting On</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>stu</customfieldvalue>
                </customfieldvalues>
            </customfield>
                            </customfields>
    </item>

<item>
            <title>[CLJ-743] Error messages for invalid destructured bindings are not helpful</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-743</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;Errors in destructured forms throw errors that give no clue to what the actual problem is. For example, evaluating (let [&lt;span class=&quot;error&quot;&gt;&amp;#91;a b&amp;#93;&lt;/span&gt; 3] a) throws a &apos;nth not supported on type Long&apos; error. It is not obvious that the destructuring expression is at fault.&lt;/p&gt;

&lt;p&gt;There should be another exception at the top level in the stack trace, something along the lines of of &quot;DestructuringException: value &amp;lt;value&amp;gt; could not be destructured&quot;, with the &apos;nth not supported&apos; exception as its cause.&lt;/p&gt;</description>
                <environment></environment>
            <key id="14357">CLJ-743</key>
            <summary>Error messages for invalid destructured bindings are not helpful</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="6" iconUrl="http://dev.clojure.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="2">Declined</resolution>
                                <assignee username="lvanderhart">Luke VanderHart</assignee>
                                <reporter username="lvanderhart">Luke VanderHart</reporter>
                        <labels>
                    </labels>
                <created>Tue, 22 Feb 2011 19:28:26 -0600</created>
                <updated>Fri, 1 Mar 2013 12:47:03 -0600</updated>
                    <resolved>Thu, 24 Feb 2011 18:36:24 -0600</resolved>
                            <version>Release 1.3</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                        <comments>
                    <comment id="26235" author="lvanderhart" created="Wed, 23 Feb 2011 20:27:27 -0600"  >&lt;p&gt;This may not be possible. Destructuring is implemented as a macro-like transformation on the expressions - by the time the expressions are evaluated and an error occurs, the runtime has no way of knowing that the expression was once destructured.&lt;/p&gt;

&lt;p&gt;Tagging the expressions with some sort of flag to indicate they were destructured is unviable. Not only is is complicated, it has runtime performance penalties.&lt;/p&gt;</comment>
                    <comment id="26237" author="stu" created="Thu, 24 Feb 2011 18:35:48 -0600"  >&lt;p&gt;I don&apos;t see a way to do this without runtime implications, even in the no-error case. I guess the destructure macro could emit special variants &lt;tt&gt;destructuring-nth&lt;/tt&gt; and &lt;tt&gt;destructuring-get&lt;/tt&gt;, etc. that provide specaliazed error messages...&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-845] Unexpected interaction between protocol extension and namespaced method keyword/symbols</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-845</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;If the keywords of a protocol&apos;s method map are namespaced, the map is accepted, but lookup fails since lookup uses non-namespaced keywords.&lt;/p&gt;

&lt;p&gt;See &lt;a href=&quot;http://dev.clojure.org/jira/browse/TLOG-4&quot; title=&quot;Provided implementations of logging protocols fail.&quot;&gt;&lt;del&gt;TLOG-4&lt;/del&gt;&lt;/a&gt; for an actual case of this being an issue.&lt;/p&gt;

&lt;p&gt;Work-around for namespaced keywords with &lt;tt&gt;extend&lt;/tt&gt;:&lt;br/&gt;
don&apos;t use namespaced keywords&lt;/p&gt;

&lt;p&gt;Work-around for syntax-quoting with &lt;tt&gt;extend-type&lt;/tt&gt; or &lt;tt&gt;extend-protocol&lt;/tt&gt;:&lt;br/&gt;
use &lt;tt&gt;extend&lt;/tt&gt; with non-namespaced keywords&lt;/p&gt;

&lt;p&gt;Possible solutions:&lt;/p&gt;
&lt;ol&gt;
	&lt;li&gt;Inside &lt;tt&gt;extend&lt;/tt&gt;, remove namespace of keywords&lt;/li&gt;
	&lt;li&gt;or
	&lt;ul&gt;
		&lt;li&gt;Inside &lt;tt&gt;extend&lt;/tt&gt;, error on namespaced keywords.&lt;/li&gt;
		&lt;li&gt;Inside &lt;tt&gt;emit-hinted-impl&lt;/tt&gt;, only grab name portion of symbols before converting to keyword.&lt;/li&gt;
	&lt;/ul&gt;
	&lt;/li&gt;
&lt;/ol&gt;

</description>
                <environment></environment>
            <key id="14653">CLJ-845</key>
            <summary>Unexpected interaction between protocol extension and namespaced method keyword/symbols</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="6" iconUrl="http://dev.clojure.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Completed</resolution>
                                <assignee username="ataggart">Alexander Taggart</assignee>
                                <reporter username="ataggart">Alexander Taggart</reporter>
                        <labels>
                    </labels>
                <created>Thu, 29 Sep 2011 19:46:43 -0500</created>
                <updated>Fri, 1 Mar 2013 12:47:03 -0600</updated>
                    <resolved>Fri, 16 Dec 2011 14:07:06 -0600</resolved>
                            <version>Release 1.3</version>
                                <fixVersion>Release 1.4</fixVersion>
                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                        <comments>
                    <comment id="26878" author="ataggart" created="Thu, 29 Sep 2011 20:01:39 -0500"  >&lt;p&gt;Simple test case to see the issue.&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;=&amp;gt; (defprotocol P
     (self [p]))
P
=&amp;gt; (extend String
     P
     {::self identity})
nil
=&amp;gt; (self &quot;foo&quot;)
#&amp;lt;IllegalArgumentException java.lang.IllegalArgumentException: No implementation of method: :self of protocol: #&apos;user/P found for class: java.lang.String&amp;gt;
=&amp;gt; (defmacro try-extend-type [c]
     `(extend-type String
        P
        (self [p#] p#)))
#&apos;user/try-extend-type
=&amp;gt; (try-extend-type String)
nil
=&amp;gt; (self &quot;foo&quot;)
#&amp;lt;IllegalArgumentException java.lang.IllegalArgumentException: No implementation of method: :self of protocol: #&apos;user/P found for class: java.lang.String&amp;gt;
=&amp;gt; (keys (get-in P [:impls String]))
(:user/self)
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;</comment>
                    <comment id="26905" author="richhickey" created="Fri, 7 Oct 2011 07:28:50 -0500"  >&lt;p&gt;Most of this is a non-issue. :self and :foo/self are not the same.&lt;/p&gt;

&lt;p&gt;This:&lt;/p&gt;

&lt;p&gt;&quot;Inside emit-hinted-impl, only grab name portion of symbols before converting to keyword.&quot;&lt;/p&gt;

&lt;p&gt;is the only needed change.&lt;/p&gt;</comment>
                    <comment id="27447" author="stuart.sierra" created="Fri, 9 Dec 2011 15:26:55 -0600"  >&lt;p&gt;Screened.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="10377" name="clj-845-1.patch" size="1814" author="ataggart" created="Sat, 8 Oct 2011 02:31:48 -0500" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_10002" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Approval</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10007">Ok</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-905] clojure.string/replace-first treats \ and $ specially when match is a string, unlike clojure.string/replace</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-905</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;clojure.string/replace only gives special treatment to replacement string when match is a regex pattern.  clojure.string/replace-first does so in those cases, but also when match is a string to be matched literally.  For example, these cases are not consistent with each other:&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; (str/replace &quot;food&quot; &quot;o&quot; &quot;$&quot;)&lt;br/&gt;
&quot;f$$d&quot;&lt;br/&gt;
user=&amp;gt; (str/replace-first &quot;food&quot; &quot;o&quot; &quot;$&quot;)&lt;br/&gt;
java.lang.StringIndexOutOfBoundsException: String index out of range: 1 (NO_SOURCE_FILE:0)&lt;/p&gt;</description>
                <environment></environment>
            <key id="15092">CLJ-905</key>
            <summary>clojure.string/replace-first treats \ and $ specially when match is a string, unlike clojure.string/replace</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="6" iconUrl="http://dev.clojure.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Completed</resolution>
                                <assignee username="stuart.sierra">Stuart Sierra</assignee>
                                <reporter username="jafingerhut">Andy Fingerhut</reporter>
                        <labels>
                    </labels>
                <created>Sat, 31 Dec 2011 17:02:38 -0600</created>
                <updated>Fri, 1 Mar 2013 12:47:03 -0600</updated>
                    <resolved>Fri, 24 Aug 2012 07:41:28 -0500</resolved>
                            <version>Release 1.3</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>1</watches>
                        <comments>
                    <comment id="27501" author="jafingerhut" created="Sat, 31 Dec 2011 17:04:54 -0600"  >&lt;p&gt;Suggested fix for &lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-905&quot; title=&quot;clojure.string/replace-first treats \ and $ specially when match is a string, unlike clojure.string/replace&quot;&gt;&lt;del&gt;CLJ-905&lt;/del&gt;&lt;/a&gt;, plus addition of function clojure.string/re-qr for quoting replacement strings that caller wishes to be treated literally when match is a pattern.&lt;/p&gt;</comment>
                    <comment id="27653" author="jafingerhut" created="Sat, 4 Feb 2012 13:59:52 -0600"  >&lt;p&gt;&lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-870&quot; title=&quot;clojure.string/replace behaves unexpectedly when \ or $ are part of the result string&quot;&gt;&lt;del&gt;CLJ-870&lt;/del&gt;&lt;/a&gt; has a proposed combined patch for this issue and that one.&lt;/p&gt;</comment>
                    <comment id="29224" author="jafingerhut" created="Sat, 18 Aug 2012 12:09:41 -0500"  >&lt;p&gt;This issue should now be corrected with the patch, attached to &lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-870&quot; title=&quot;clojure.string/replace behaves unexpectedly when \ or $ are part of the result string&quot;&gt;&lt;del&gt;CLJ-870&lt;/del&gt;&lt;/a&gt;, that was applied on Aug 18, 2012.&lt;/p&gt;</comment>
                    <comment id="29258" author="stuart.sierra" created="Fri, 24 Aug 2012 07:41:28 -0500"  >&lt;p&gt;&lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-905&quot; title=&quot;clojure.string/replace-first treats \ and $ specially when match is a string, unlike clojure.string/replace&quot;&gt;&lt;del&gt;CLJ-905&lt;/del&gt;&lt;/a&gt; same status as &lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-753&quot; title=&quot;clojure.string/replace-first returns nil with replacement fn when regex doesn&amp;#39;t match&quot;&gt;&lt;del&gt;CLJ-753&lt;/del&gt;&lt;/a&gt;: patch applied for &lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-870&quot; title=&quot;clojure.string/replace behaves unexpectedly when \ or $ are part of the result string&quot;&gt;&lt;del&gt;CLJ-870&lt;/del&gt;&lt;/a&gt; addresses this one, too, applied Aug 18, 2012 &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="10002">Code and Test</customfieldvalue>

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

<item>
            <title>[CLJ-818] doc string for resolve mentions &amp;env</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-818</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;(defn resolve&lt;br/&gt;
  &quot;same as (ns-resolve &lt;b&gt;ns&lt;/b&gt; symbol) or (ns-resolve &lt;b&gt;ns&lt;/b&gt; &amp;amp;env symbol)&quot;&lt;/p&gt;

&lt;p&gt;The ampersand on &quot;&amp;amp;env&quot; in the doc string is distracting.  There&apos;s no macro magic involved so it should just say &quot;env&quot;.&lt;/p&gt;</description>
                <environment></environment>
            <key id="14483">CLJ-818</key>
            <summary>doc string for resolve mentions &amp;env</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="6" iconUrl="http://dev.clojure.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="2">Declined</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="steveminer">Steve Miner</reporter>
                        <labels>
                    </labels>
                <created>Thu, 7 Jul 2011 14:55:01 -0500</created>
                <updated>Fri, 1 Mar 2013 12:47:03 -0600</updated>
                    <resolved>Fri, 23 Mar 2012 08:41:20 -0500</resolved>
                            <version>Release 1.3</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>2</watches>
                        <comments>
                    <comment id="27837" author="jafingerhut" created="Fri, 24 Feb 2012 11:20:38 -0600"  >&lt;p&gt;There are earlier uses of &amp;amp;form and &amp;amp;env in core.clj, but they are all in bootstrap code and none of them become visible in doc strings.  There are no other occurrences of &amp;amp; in resolve or ns-resolve, so it seems reasonable to remove it from resolve&apos;s doc string.&lt;/p&gt;

&lt;p&gt;Patch applies cleanly to latest master as of Feb 24, 2012.&lt;/p&gt;</comment>
                    <comment id="27991" author="stuart.sierra" created="Fri, 23 Mar 2012 08:41:20 -0500"  >&lt;p&gt;The only way to access local environments in Clojure is with the special &lt;tt&gt;&amp;amp;env&lt;/tt&gt; argument in a macro, so the use of &lt;tt&gt;&amp;amp;env&lt;/tt&gt; in the ns-resolve docstring makes sense.&lt;/p&gt;

&lt;p&gt;Declined.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="10956" name="clj-818-resolve-doc-string-patch.txt" size="798" author="jafingerhut" created="Fri, 24 Feb 2012 11:20: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-681] Build Clojure with Maven 2</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-681</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;See &lt;a href=&quot;http://dev.clojure.org/display/design/Common+Contrib+Build&quot;&gt;Common Contrib Build&lt;/a&gt; wiki page and the lengthy &lt;a href=&quot;http://groups.google.com/group/clojure-dev/browse_thread/thread/8d11cdd6d27ceb13&quot;&gt;clojure-dev discussion&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;For examples of the CI/release process under Hudson, see &lt;a href=&quot;http://build.clojure.org/job/clojure-testbuild/&quot;&gt;clojure-testbuild&lt;/a&gt;&lt;/p&gt;</description>
                <environment></environment>
            <key id="14289">CLJ-681</key>
            <summary>Build Clojure with Maven 2</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="6" iconUrl="http://dev.clojure.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Completed</resolution>
                                <assignee username="stuart.sierra">Stuart Sierra</assignee>
                                <reporter username="stuart.sierra">Stuart Sierra</reporter>
                        <labels>
                    </labels>
                <created>Fri, 26 Nov 2010 14:05:33 -0600</created>
                <updated>Fri, 1 Mar 2013 12:47:02 -0600</updated>
                    <resolved>Wed, 5 Jan 2011 07:20:08 -0600</resolved>
                            <version>Backlog</version>
                                <fixVersion>Release 1.3</fixVersion>
                                        <due></due>
                    <votes>0</votes>
                        <watches>1</watches>
                        <comments>
                    <comment id="25962" author="stuart.sierra" created="Fri, 26 Nov 2010 14:09:02 -0600"  >&lt;p&gt;Replaces previous patch.&lt;/p&gt;

&lt;ul&gt;
	&lt;li&gt;fixed SCM URLs in pom.xml&lt;/li&gt;
&lt;/ul&gt;
</comment>
                    <comment id="25970" author="stu" created="Mon, 29 Nov 2010 06:48:48 -0600"  >&lt;p&gt;Maven is capable of using the directory structure we already have. It seems this patch is doing two things: getting us onto maven, and reorganizing the project. Is there any reason these can&apos;t be considered separately?&lt;/p&gt;</comment>
                    <comment id="25979" author="stuart.sierra" created="Mon, 29 Nov 2010 18:28:56 -0600"  >&lt;p&gt;Updated patch replaces previous patches.&lt;/p&gt;

&lt;p&gt;This does minimal file/directory renaming while preserving the same functionality as the previous patches.&lt;/p&gt;

&lt;p&gt;But an older problem has resurfaced: the nondeterministic load-order sometimes causes compilation to fail.  For example, &lt;a href=&quot;http://build.clojure.org/job/clojure-testbuild/22/console&quot;&gt;on Hudson&lt;/a&gt;&lt;/p&gt;</comment>
                    <comment id="25986" author="stuart.sierra" created="Wed, 1 Dec 2010 08:05:52 -0600"  >&lt;p&gt;Patch maven-build-4.diff.gz replaces previous patches.&lt;/p&gt;

&lt;p&gt;This works around compilation-order issues by using a bootstrap script to compile namespaces in the correct order.&lt;/p&gt;</comment>
                    <comment id="25987" author="stuart.sierra" created="Wed, 1 Dec 2010 08:59:23 -0600"  >&lt;p&gt;Patch maven-build-5.diff.gz replaces previous patches.&lt;/p&gt;

&lt;p&gt;This fixes a few more testing issues.&lt;/p&gt;</comment>
                    <comment id="25988" author="stuart.sierra" created="Wed, 1 Dec 2010 09:02:57 -0600"  >&lt;p&gt;Finally got a &lt;a href=&quot;http://build.clojure.org/job/clojure-testbuild/32/&quot;&gt;successful staging release&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;Unfortunately, the JAR file is misnamed.  This is a &lt;a href=&quot;http://groups.google.com/group/clojure-maven-plugin/browse_thread/thread/16b5c73adb7a672c&quot;&gt;clojure-maven-plugin bug&lt;/a&gt; that will be fixed in the next release.&lt;/p&gt;</comment>
                    <comment id="25990" author="stuart.sierra" created="Fri, 3 Dec 2010 09:39:57 -0600"  >&lt;p&gt;Patch maven-build-6.diff.gz replaces previous patches.&lt;/p&gt;

&lt;p&gt;This updates to clojure-maven-plugin version 1.3.7; README updates.&lt;/p&gt;</comment>
                    <comment id="26006" author="stuart.sierra" created="Fri, 3 Dec 2010 16:13:23 -0600"  >&lt;p&gt;Patch maven-build-7.diff.gz replaces previous patches.&lt;/p&gt;

&lt;p&gt;This patch adds back in a simplified build.xml for local development using Ant only.&lt;/p&gt;

&lt;p&gt;The Ant build.xml script reads the project version number from pom.xml, so pom.xml remains the definitive project description.&lt;/p&gt;</comment>
                    <comment id="26019" author="stuart.sierra" created="Thu, 9 Dec 2010 17:14:26 -0600"  >&lt;p&gt;Patch maven-build-8.diff.gz replaces previous patches.&lt;/p&gt;

&lt;p&gt;This version uses a hybrid Maven + Ant build process.  For local development, only Ant is needed.  The POM does not depend on anything outside of the standard Maven toolchain and the Sonatype open-source deployment configuration.&lt;/p&gt;</comment>
                    <comment id="26032" author="stuart.sierra" created="Wed, 15 Dec 2010 12:01:24 -0600"  >&lt;p&gt;Patch &quot;maven-build-8&quot; answers those questions by postponing them.&lt;/p&gt;

&lt;p&gt;This patch is ready to test and apply.&lt;/p&gt;</comment>
                    <comment id="26033" author="stuart.sierra" created="Wed, 15 Dec 2010 12:04:22 -0600"  >&lt;p&gt;To elaborate: patch &quot;maven-build-8&quot; avoids both clojure-maven-plugin and bootstrap load order by using maven-ant-plugin and Ant to drive the Clojure steps in the build.&lt;/p&gt;

&lt;p&gt;We still need to address these issues, but that may take a long time, and we want to move forward with releases to public repositories.&lt;/p&gt;</comment>
                    <comment id="26044" author="stu" created="Fri, 17 Dec 2010 14:05:58 -0600"  >&lt;p&gt;Can you please run down two small issues:&lt;/p&gt;

&lt;p&gt;(1) I get a warning on the maven build:&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;[WARNING] 
[WARNING] Some problems were encountered &lt;span class=&quot;code-keyword&quot;&gt;while&lt;/span&gt; building the effective model &lt;span class=&quot;code-keyword&quot;&gt;for&lt;/span&gt; org.clojure:clojure:jar:1.3.0-testbuild10-SNAPSHOT
[WARNING] &apos;build.plugins.plugin.version&apos; &lt;span class=&quot;code-keyword&quot;&gt;for&lt;/span&gt; org.apache.maven.plugins:maven-compiler-plugin is missing. @ line 52, column 15
[WARNING] &apos;build.plugins.plugin.version&apos; &lt;span class=&quot;code-keyword&quot;&gt;for&lt;/span&gt; org.apache.maven.plugins:maven-surefire-plugin is missing. @ line 181, column 15
[WARNING] 
[WARNING] It is highly recommended to fix these problems because they threaten the stability of your build.
[WARNING] 
[WARNING] For &lt;span class=&quot;code-keyword&quot;&gt;this&lt;/span&gt; reason, &lt;span class=&quot;code-keyword&quot;&gt;future&lt;/span&gt; Maven versions might no longer support building such malformed projects.
[WARNING]&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;(2) The version is set to 1.3.0-testbuild10-SNAPSHOT. Am I supposed to change this by hand-editing the pom?&lt;/p&gt;</comment>
                    <comment id="26053" author="stuart.sierra" created="Fri, 17 Dec 2010 16:10:11 -0600"  >&lt;p&gt;Patch maven-build-9.diff.gz replaces previous patches.&lt;/p&gt;

&lt;p&gt;Differences from previous patches:&lt;/p&gt;

&lt;ul&gt;
	&lt;li&gt;Adds plugin coordinates to fix the warnings reported by Stu Halloway&lt;/li&gt;
	&lt;li&gt;Avoids compiling the test sources twice&lt;/li&gt;
	&lt;li&gt;Correctly sets POM version to 1.3.0-master-SNAPSHOT&lt;/li&gt;
&lt;/ul&gt;
</comment>
                    <comment id="26054" author="stuart.sierra" created="Fri, 17 Dec 2010 16:11:42 -0600"  >&lt;p&gt;Reported issues should be fixed, although I cannot reproduce the warning messages.&lt;/p&gt;

&lt;p&gt;What version of Maven produced those warnings?&lt;/p&gt;</comment>
                    <comment id="26082" author="stu" created="Tue, 4 Jan 2011 16:03:40 -0600"  >&lt;p&gt;Patch 10 merely updates patch 9 to apply to current master. (A test namespace had changed. The list of test files has always been hard-coded and fragile, but that&apos;s a patch for another day.)&lt;/p&gt;

&lt;p&gt;I tested all the Ant and Maven commands documented in the reademe, and everything looks sensible.&lt;/p&gt;</comment>
                    <comment id="26088" author="stu" created="Tue, 4 Jan 2011 21:03:35 -0600"  >&lt;p&gt;Patch 10 is bad. The pom file from patch 9 was lost, and my local environment didn&apos;t notice somehow. Will test and resubmit a patch 11 that is basically patch 10 with the correct pom.xml from patch 9. &lt;/p&gt;

&lt;p&gt;Grumble.&lt;/p&gt;</comment>
                    <comment id="26090" author="stu" created="Wed, 5 Jan 2011 07:18:23 -0600"  >&lt;p&gt;Patch 11 is basically patch 10 + the correct pom.xml from patch 9. &lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="10068" name="0681-patch-10.patch" size="30918" author="stu" created="Tue, 4 Jan 2011 16:03:40 -0600" />
                    <attachment id="10070" name="0681-patch-11.patch" size="35484" author="stu" created="Wed, 5 Jan 2011 07:18:23 -0600" />
                    <attachment id="10029" name="maven-build-1.diff.gz" size="912349" author="stuart.sierra" created="Fri, 26 Nov 2010 14:05:33 -0600" />
                    <attachment id="10030" name="maven-build-2.diff.gz" size="912347" author="stuart.sierra" created="Fri, 26 Nov 2010 14:09:02 -0600" />
                    <attachment id="10037" name="maven-build-3.diff.gz" size="8437" author="stuart.sierra" created="Mon, 29 Nov 2010 18:28:56 -0600" />
                    <attachment id="10039" name="maven-build-4.diff.gz" size="8567" author="stuart.sierra" created="Wed, 1 Dec 2010 08:05:52 -0600" />
                    <attachment id="10040" name="maven-build-5.diff.gz" size="8684" author="stuart.sierra" created="Wed, 1 Dec 2010 08:59:23 -0600" />
                    <attachment id="10041" name="maven-build-6.diff.gz" size="8738" author="stuart.sierra" created="Fri, 3 Dec 2010 09:39:57 -0600" />
                    <attachment id="10044" name="maven-build-7.diff.gz" size="9146" author="stuart.sierra" created="Fri, 3 Dec 2010 16:13:23 -0600" />
                    <attachment id="10049" name="maven-build-8.diff.gz" size="9133" author="stuart.sierra" created="Thu, 9 Dec 2010 17:14:26 -0600" />
                    <attachment id="10058" name="maven-build-9.diff.gz" size="9128" author="stuart.sierra" created="Fri, 17 Dec 2010 16:10:11 -0600" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_10002" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Approval</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10007">Ok</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>stu</customfieldvalue>
                </customfieldvalues>
            </customfield>
                            </customfields>
    </item>

<item>
            <title>[CLJ-780] race condition in reference cache on Java 5</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-780</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;Map.Entry instances can have null values prior to Java 6&lt;/p&gt;

&lt;p&gt;Test failure: &lt;a href=&quot;http://build.clojure.org/job/test.generative/1/org.clojure$test.generative/console&quot;&gt;http://build.clojure.org/job/test.generative/1/org.clojure$test.generative/console&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;Discussion: &lt;a href=&quot;http://concurrency.markmail.org/message/pbruo2uxgur6wkoo?q=map%2Eentry+null&amp;amp;page=3#query:map.entry%20null+page:3+mid:z5arnbbzl2k32jda+state:results&quot;&gt;http://concurrency.markmail.org/message/pbruo2uxgur6wkoo?q=map%2Eentry+null&amp;amp;page=3#query:map.entry%20null+page:3+mid:z5arnbbzl2k32jda+state:results&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;Note that the fix must hold val in a local variable, because &lt;tt&gt;cache.remove&lt;/tt&gt; will bomb if the value is null.&lt;/p&gt;</description>
                <environment></environment>
            <key id="14406">CLJ-780</key>
            <summary>race condition in reference cache on Java 5</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="6" iconUrl="http://dev.clojure.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Completed</resolution>
                                <assignee username="stu">Stuart Halloway</assignee>
                                <reporter username="stu">Stuart Halloway</reporter>
                        <labels>
                    </labels>
                <created>Wed, 27 Apr 2011 13:53:57 -0500</created>
                <updated>Fri, 1 Mar 2013 12:47:02 -0600</updated>
                    <resolved>Wed, 27 Apr 2011 16:29:11 -0500</resolved>
                                            <fixVersion>Release 1.3</fixVersion>
                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                <attachments>
                    <attachment id="10199" name="check-map-entry-value.patch" size="899" author="stu" created="Wed, 27 Apr 2011 13:53:58 -0500" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_10002" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Approval</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10007">Ok</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-890] Tagged literals in reader</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-890</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;See &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;&lt;/p&gt;</description>
                <environment></environment>
            <key id="15045">CLJ-890</key>
            <summary>Tagged literals in reader</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="6" iconUrl="http://dev.clojure.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Completed</resolution>
                                <assignee username="stuart.sierra">Stuart Sierra</assignee>
                                <reporter username="stuart.sierra">Stuart Sierra</reporter>
                        <labels>
                    </labels>
                <created>Fri, 2 Dec 2011 17:15:43 -0600</created>
                <updated>Fri, 1 Mar 2013 12:47:02 -0600</updated>
                    <resolved>Fri, 3 Feb 2012 09:12:01 -0600</resolved>
                                                                    <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                        <comments>
                    <comment id="27411" author="stuart.sierra" created="Fri, 2 Dec 2011 17:32:48 -0600"  >&lt;p&gt;Rough draft in &lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-890&quot; title=&quot;Tagged literals in reader&quot;&gt;&lt;del&gt;CLJ-890&lt;/del&gt;&lt;/a&gt;-001.patch:&lt;/p&gt;

&lt;p&gt;This adds reader tags like &lt;tt&gt;#user/foo&lt;/tt&gt;. If the symbol following the &lt;tt&gt;#&lt;/tt&gt; is namespace-qualified, or if it is one of a predefined set of built-in tags (currently empty) it is interpreted as a tag. Otherwise, it is interpreted as a class name, as in defrecord literals.&lt;/p&gt;

&lt;p&gt;The dynamic Var &lt;tt&gt;&amp;#42;data-readers&amp;#42;&lt;/tt&gt; is a map from tags (symbols) to reader functions/Vars. Each invocation of &lt;tt&gt;Compiler.load&lt;/tt&gt; creates a new thread-local binding, as does the REPL. At the top of a source file, use &lt;tt&gt;(set! &amp;#42;data-readers&amp;#42; ...)&lt;/tt&gt; to define the tags just for that file. For runtime invocations of the reader, use &lt;tt&gt;binding&lt;/tt&gt;.&lt;/p&gt;

&lt;p&gt;When reading a tagged literal, if the tag is &lt;b&gt;not&lt;/b&gt; defined in &lt;tt&gt;&amp;#42;data-readers&amp;#42;&lt;/tt&gt; it is added as &lt;tt&gt;:data&lt;/tt&gt; metadata on the following form. If the following form does not support metadata, the tag is ignored. This causes a problem when an undefined tag is used in source code, because the compiler tries to evaluate it:&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; #foo.bar/bar {:a 1}
CompilerException java.lang.RuntimeException: No such &lt;span class=&quot;code-keyword&quot;&gt;var&lt;/span&gt;: foo.bar/bar, compiling:(NO_SOURCE_PATH:0) 
user=&amp;gt; (quote #foo.bar/bar {:a 1})
{:a 1}
user=&amp;gt; (meta *1)
{:data foo.bar/bar}&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;</comment>
                    <comment id="27445" author="stuart.sierra" created="Fri, 9 Dec 2011 15:08:23 -0600"  >&lt;p&gt;New file &lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-890&quot; title=&quot;Tagged literals in reader&quot;&gt;&lt;del&gt;CLJ-890&lt;/del&gt;&lt;/a&gt;-002.patch:&lt;/p&gt;

&lt;ul&gt;
	&lt;li&gt;tag definitions loaded from &lt;tt&gt;/data_readers.clj&lt;/tt&gt; files on classpath&lt;/li&gt;
	&lt;li&gt;read as a series of symbol-symbol pairs&lt;/li&gt;
	&lt;li&gt;&quot;target&quot; symbol interpreted as a Var&lt;/li&gt;
	&lt;li&gt;creates namespaces and interns Vars as necessary&lt;/li&gt;
	&lt;li&gt;may be more than one file&lt;/li&gt;
	&lt;li&gt;throws exception on conflict&lt;/li&gt;
	&lt;li&gt;sets root binding of &lt;tt&gt;&amp;#42;data-readers&amp;#42;&lt;/tt&gt;&lt;/li&gt;
&lt;/ul&gt;
</comment>
                    <comment id="27557" author="stuart.sierra" created="Fri, 13 Jan 2012 08:28:23 -0600"  >&lt;p&gt;Patch &lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-890&quot; title=&quot;Tagged literals in reader&quot;&gt;&lt;del&gt;CLJ-890&lt;/del&gt;&lt;/a&gt;-002.patch applied following discussion with Rich. Will be included in release 1.4.0-alpha4&lt;/p&gt;</comment>
                    <comment id="29200" author="bbloom" created="Thu, 16 Aug 2012 21:48:08 -0500"  >&lt;p&gt;It would be a small extension to allow overriding of readers for untagged forms as well.&lt;/p&gt;

&lt;p&gt;For example, MapReader currently calls RT.map(a) when it could call RT.get(data_readers, MAP_TAG).invoke(a)&lt;/p&gt;

&lt;p&gt;This would allow consumers of the reader to supply their own implementations for any basic data structure. Not that anyone is likely to have a &lt;b&gt;better&lt;/b&gt; map/set/etc, but I could see it being useful for using a different RegExp engine or something like that. The primary use case I have in mind, however, is the ClojureScript compiler. The compiler needs to know the &lt;b&gt;order&lt;/b&gt; of the key-value-pairs in a map or the elements in a set. See &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;</comment>
                </comments>
                    <attachments>
                    <attachment id="10731" name="CLJ-890-001.patch" size="4945" author="stuart.sierra" created="Fri, 2 Dec 2011 17:32:48 -0600" />
                    <attachment id="10737" name="CLJ-890-002.patch" size="6626" author="stuart.sierra" created="Fri, 9 Dec 2011 15:08:23 -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-693] VerifyError with symbol metadata, macros, and defrecord</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-693</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;The code below defines a macro wrapper around defrecord. Using it causes a VerifyError:&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;(defmacro mac1 [name properties] 
  (let [key-info (keyword (first (filter #(meta %) properties)))] 
    (prn key-info) 
    `(defrecord ~name ~properties))) 

(mac1 One [^:key one, two])
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;Once this happens, the running Clojure process is oddly damaged. Changing the macro to a working version (see below) will not make the sample work with the tagged symbol, almost as if the symbol &lt;br/&gt;
&apos;one (below) became corrupt. You either need to start a new REPL, or try to invoke the macro with a different tagged symbol.&lt;/p&gt;

&lt;p&gt;The following code does work (note the forced conversion to a string):&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;(defmacro mac2 [name properties] 
  (let [key-info (keyword (str (first (filter #(meta %) properties))))] 
    (prn key-info) 
    `(defrecord ~name ~properties))) 

(mac2 Two [^:key three, four])
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;</description>
                <environment>Affects Clojure from 1.2.0 to 1.3.0-alpha4</environment>
            <key id="14302">CLJ-693</key>
            <summary>VerifyError with symbol metadata, macros, and defrecord</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="6" iconUrl="http://dev.clojure.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Completed</resolution>
                                <assignee username="richhickey">Rich Hickey</assignee>
                                <reporter username="vetoshev">Constantine Vetoshev</reporter>
                        <labels>
                    </labels>
                <created>Thu, 16 Dec 2010 08:54:46 -0600</created>
                <updated>Fri, 1 Mar 2013 12:47:01 -0600</updated>
                    <resolved>Fri, 17 Dec 2010 16:19:45 -0600</resolved>
                            <version>Approved Backlog</version>
                <version>Backlog</version>
                <version>Release 1.2</version>
                <version>Release 1.3</version>
                                <fixVersion>Release 1.3</fixVersion>
                                        <due></due>
                    <votes>0</votes>
                        <watches>1</watches>
                        <comments>
                    <comment id="26039" author="richhickey" created="Fri, 17 Dec 2010 08:47:25 -0600"  >&lt;p&gt;Stu, can you please verify?&lt;/p&gt;</comment>
                    <comment id="26043" author="stu" created="Fri, 17 Dec 2010 13:53:27 -0600"  >&lt;p&gt;Very confusing. Reproduced everything in the report. Moreover, leaving out the call to &lt;tt&gt;keyword&lt;/tt&gt; is enough to avoid the problem. The following variant works fine:&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;(defmacro mac4 [name properties] 
  (let [key-info (first (filter #(meta %) properties))] 
    (prn key-info) 
    `(defrecord ~name ~properties)))&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;</comment>
                    <comment id="26057" author="vetoshev" created="Sat, 18 Dec 2010 13:02:26 -0600"  >&lt;p&gt;Thanks for the fix! Works great.&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="10007">Ok</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-752] Remove *earmuff* == dynamic support</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-752</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;As a compatibility bridge, when dynamic var support was first added, &amp;#42;earmuffed&amp;#42; vars were automagically considered dynamic. Users were promised this bridge would be removed before release. Let&apos;s get this change in so people can start dealing with it.&lt;/p&gt;</description>
                <environment></environment>
            <key id="14368">CLJ-752</key>
            <summary>Remove *earmuff* == dynamic support</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="6" iconUrl="http://dev.clojure.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Completed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="richhickey">Rich Hickey</reporter>
                        <labels>
                    </labels>
                <created>Wed, 9 Mar 2011 11:34:00 -0600</created>
                <updated>Fri, 1 Mar 2013 12:47:01 -0600</updated>
                    <resolved>Fri, 8 Apr 2011 09:03:53 -0500</resolved>
                                            <fixVersion>Release 1.3</fixVersion>
                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                        <comments>
                    <comment id="26293" author="ataggart" created="Wed, 9 Mar 2011 13:59:49 -0600"  >&lt;p&gt;Remove the warning message as well?&lt;/p&gt;</comment>
                    <comment id="26294" author="richhickey" created="Wed, 9 Mar 2011 14:05:42 -0600"  >&lt;p&gt;The warning message should be changed to say: &lt;/p&gt;

&lt;p&gt;Warning: &amp;#42;x&amp;#42; not declared dynamic and thus is not dynamically rebindable, but its name suggests otherwise. Please either indicate ^:dynamic &amp;#42;x&amp;#42; or change the name.&lt;/p&gt;</comment>
                    <comment id="26295" author="ataggart" created="Wed, 9 Mar 2011 14:34:37 -0600"  >&lt;p&gt;752.patch removes inferring ^:dynamic from earmuffed var; updates warning message.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="10142" name="752.patch" size="1662" author="ataggart" created="Wed, 9 Mar 2011 14:34:37 -0600" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_10002" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Approval</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10007">Ok</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-830] Report source file and line number when throwing syntax-related error from core macros</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-830</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;If you botch or misunderstand certain macros in core, they throw exceptions with very unhelpful error messages:&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; (let [a])
#&amp;lt;IllegalArgumentException java.lang.IllegalArgumentException:
  let requires an even number of forms in binding vector&amp;gt;

=&amp;gt; (&lt;span class=&quot;code-keyword&quot;&gt;if&lt;/span&gt;-let [a 5
            b 6]
     &lt;span class=&quot;code-keyword&quot;&gt;true&lt;/span&gt;)
#&amp;lt;IllegalArgumentException java.lang.IllegalArgumentException:
  &lt;span class=&quot;code-keyword&quot;&gt;if&lt;/span&gt;-let requires exactly 2 forms in binding vector&amp;gt;&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;No mention of userland file/namespace or line number is in the stack trace.  If this code happens to be in code being loaded via some chain of :requires, tracking it down can be way more painful than it reasonably should be.&lt;/p&gt;

&lt;p&gt;Something like this would be much better:&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;IllegalArgumentException java.lang.IllegalArgumentException:
  let requires an even number of forms in binding vector in com.foo.namespace:80&amp;gt;&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;These errors are all thrown via the same &lt;tt&gt;assert-args&lt;/tt&gt; function used by a variety of macros in &lt;tt&gt;clojure.core&lt;/tt&gt;; modifying it so it emits a reasonable error message should be straightforward.&lt;/p&gt;</description>
                <environment></environment>
            <key id="14580">CLJ-830</key>
            <summary>Report source file and line number when throwing syntax-related error from core macros</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="6" iconUrl="http://dev.clojure.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Completed</resolution>
                                <assignee username="cemerick">Chas Emerick</assignee>
                                <reporter username="cemerick">Chas Emerick</reporter>
                        <labels>
                    </labels>
                <created>Wed, 24 Aug 2011 08:09:12 -0500</created>
                <updated>Fri, 1 Mar 2013 12:47:01 -0600</updated>
                    <resolved>Fri, 7 Oct 2011 09:12:37 -0500</resolved>
                            <version>Release 1.2</version>
                                <fixVersion>Release 1.4</fixVersion>
                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                        <comments>
                    <comment id="26740" author="stuart.sierra" created="Sat, 27 Aug 2011 15:25:46 -0500"  >&lt;p&gt;Only affects the &lt;tt&gt;assert-args&lt;/tt&gt; macro, which is private in &lt;tt&gt;clojure.core&lt;/tt&gt;. Patch works as advertised.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="10317" name="CLJ-830.diff" size="6038" author="cemerick" created="Wed, 24 Aug 2011 13:04:46 -0500" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_10002" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Approval</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10007">Ok</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-947] It would be very useful to be able to annotate the constructors of classes created with gen-class</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-947</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;gen-class currently provides a way to annotate methods, but not constructors.&lt;/p&gt;

&lt;p&gt;when interoperating with java code that uses google juice heavily the ability to annotate constructors is required.&lt;/p&gt;</description>
                <environment></environment>
            <key id="15265">CLJ-947</key>
            <summary>It would be very useful to be able to annotate the constructors of classes created with gen-class</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="6" iconUrl="http://dev.clojure.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="3">Duplicate</resolution>
                                <assignee username="hiredman">Kevin Downey</assignee>
                                <reporter username="hiredman">Kevin Downey</reporter>
                        <labels>
                    </labels>
                <created>Tue, 6 Mar 2012 07:59:08 -0600</created>
                <updated>Fri, 1 Mar 2013 12:47:01 -0600</updated>
                    <resolved>Tue, 6 Mar 2012 10:41:04 -0600</resolved>
                                                                    <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                        <comments>
                    <comment id="27903" author="hiredman" created="Tue, 6 Mar 2012 10:41:04 -0600"  >&lt;p&gt;dup of &lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-948&quot; title=&quot;It would be very useful to be able to annotate the constructors of classes created with gen-class&quot;&gt;&lt;del&gt;CLJ-948&lt;/del&gt;&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-389] slurp should not read one character at a time</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-389</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;A discussion of slurp performance came up on the mailing list. The attached patch makes slurp use a 4kb buffer size instead of reading one character at a time, resulting in a significant performance improvement.&lt;/p&gt;</description>
                <environment></environment>
            <key id="13786">CLJ-389</key>
            <summary>slurp should not read one character at a time</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="6" iconUrl="http://dev.clojure.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="2">Declined</resolution>
                                <assignee username="aaron">Aaron Bedra</assignee>
                                <reporter username="aaron">Aaron Bedra</reporter>
                        <labels>
                    </labels>
                <created>Fri, 25 Jun 2010 08:15:00 -0500</created>
                <updated>Fri, 1 Mar 2013 12:47:01 -0600</updated>
                    <resolved>Fri, 2 Dec 2011 13:30:22 -0600</resolved>
                            <version>Approved Backlog</version>
                                <fixVersion>Release 1.4</fixVersion>
                                        <due></due>
                    <votes>0</votes>
                        <watches>2</watches>
                        <comments>
                    <comment id="24059" author="importer" created="Mon, 25 Oct 2010 21:30:00 -0500"  >&lt;p&gt;Converted from &lt;a href=&quot;http://www.assembla.com/spaces/clojure/tickets/389&quot;&gt;http://www.assembla.com/spaces/clojure/tickets/389&lt;/a&gt;&lt;br/&gt;
Attachments:&lt;br/&gt;
slurp-buffer-size.patch - &lt;a href=&quot;https://www.assembla.com/spaces/clojure/documents/c7INhmGfSr34YDeJe5cbCb/download/c7INhmGfSr34YDeJe5cbCb&quot;&gt;https://www.assembla.com/spaces/clojure/documents/c7INhmGfSr34YDeJe5cbCb/download/c7INhmGfSr34YDeJe5cbCb&lt;/a&gt;&lt;/p&gt;</comment>
                    <comment id="24060" author="importer" created="Mon, 25 Oct 2010 21:30:00 -0500"  >&lt;p&gt;stu said: Updating tickets (#389, #371)&lt;/p&gt;</comment>
                    <comment id="24061" author="importer" created="Mon, 25 Oct 2010 21:30:00 -0500"  >&lt;p&gt;aaron said: Patch does not apply.  It is not in the proper format.  Please take a look at &lt;a href=&quot;http://clojure.org/patches&quot;&gt;http://clojure.org/patches&lt;/a&gt; and resubmit.  I will continue to review the code itself against the current master.&lt;/p&gt;</comment>
                    <comment id="25884" author="aaron" created="Fri, 29 Oct 2010 09:43:45 -0500"  >&lt;p&gt;Contacted original poster about this to inform him of the move to JIRA and ensure interest in this patch&lt;/p&gt;</comment>
                    <comment id="25936" author="aaron" created="Fri, 12 Nov 2010 13:55:32 -0600"  >&lt;p&gt;The patch has been reformatted and submitted.&lt;/p&gt;</comment>
                    <comment id="25937" author="juergenhoetzel" created="Sat, 13 Nov 2010 02:07:29 -0600"  >&lt;p&gt;Maybe duplicate: &lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-668&quot; title=&quot;Improve slurp performance by using native Java StringWriter and jio/copy&quot;&gt;CLJ-668&lt;/a&gt;&lt;/p&gt;</comment>
                    <comment id="25960" author="aaron" created="Fri, 26 Nov 2010 10:17:34 -0600"  >&lt;p&gt;&lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-668&quot; title=&quot;Improve slurp performance by using native Java StringWriter and jio/copy&quot;&gt;CLJ-668&lt;/a&gt; is a duplicate of this ticket. I have tested your patch and would like to consider it as a resolution to this ticket along with closing &lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-668&quot; title=&quot;Improve slurp performance by using native Java StringWriter and jio/copy&quot;&gt;CLJ-668&lt;/a&gt; as a duplicate. Can you please submit a patch to this ticket instead of a link to github?  I am going to test all of the patches presented on OSX, Linux, EC2, and Windows.&lt;/p&gt;</comment>
                    <comment id="25964" author="juergenhoetzel" created="Sat, 27 Nov 2010 04:57:21 -0600"  >&lt;p&gt;Seems like the changes are already applied by your previous commit:&lt;/p&gt;

&lt;p&gt;&lt;a href=&quot;https://github.com/clojure/clojure/commit/cbd789d1a5b472d92b91f2fe0e273f48c2583483&quot;&gt;https://github.com/clojure/clojure/commit/cbd789d1a5b472d92b91f2fe0e273f48c2583483&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;Just a leftover StringBuilder Object (patch attached)&lt;/p&gt;</comment>
                    <comment id="25968" author="aaron" created="Sun, 28 Nov 2010 10:06:05 -0600"  >&lt;p&gt;Yes, that was a mistake.  It should not have gone in under #441.  I was doing some testing and somehow I didn&apos;t properly revert what I was working on.  Please consider that a mistake for now and include a patch here so you can get credit for your work.&lt;/p&gt;</comment>
                    <comment id="25969" author="juergenhoetzel" created="Mon, 29 Nov 2010 02:50:03 -0600"  >&lt;p&gt;Thanks. Patch enclosed.&lt;/p&gt;</comment>
                    <comment id="25989" author="aaron" created="Fri, 3 Dec 2010 08:19:40 -0600"  >&lt;p&gt;Thanks. I am going to be testing the various ideas on multiple platforms to see which (if any) is the best fit.&lt;/p&gt;</comment>
                    <comment id="27382" author="aaron" created="Wed, 30 Nov 2011 19:59:41 -0600"  >&lt;p&gt;This patch carries a performance hit. For example:&lt;/p&gt;

&lt;p&gt;Clojure 1.4.0&lt;/p&gt;
&lt;table class=&apos;confluenceTable&apos;&gt;&lt;tbody&gt;
&lt;tr&gt;
&lt;td class=&apos;confluenceTd&apos;&gt; File Size &lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt; best timed 10x slurp &lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td class=&apos;confluenceTd&apos;&gt; 7.3 MB    &lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt; 2960.363 msecs       &lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td class=&apos;confluenceTd&apos;&gt; 260 KB    &lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt; 105.255 msecs        &lt;/td&gt;
&lt;/tr&gt;
&lt;/tbody&gt;&lt;/table&gt;


&lt;p&gt;With Patch&lt;/p&gt;
&lt;table class=&apos;confluenceTable&apos;&gt;&lt;tbody&gt;
&lt;tr&gt;
&lt;td class=&apos;confluenceTd&apos;&gt; File Size &lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt; best timed 10x slurp &lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td class=&apos;confluenceTd&apos;&gt; 7.3 MB    &lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt; 3700.406 msecs       &lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td class=&apos;confluenceTd&apos;&gt; 260 KB    &lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt; 129.311 msecs        &lt;/td&gt;
&lt;/tr&gt;
&lt;/tbody&gt;&lt;/table&gt;

&lt;p&gt;This was tested with&lt;/p&gt;

&lt;p&gt;(time (dotimes &lt;span class=&quot;error&quot;&gt;&amp;#91;_ 10&amp;#93;&lt;/span&gt; (slurp &quot;file&quot;)))&lt;/p&gt;

&lt;p&gt;with each execution of this form done 20 times.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="10034" name="0001-Improve-slurp-performance-by-using-native-Java-Strin.patch" size="1060" author="juergenhoetzel" created="Mon, 29 Nov 2010 02:50:02 -0600" />
                    <attachment id="10031" name="0001-needles-StrinbBuilder-in-slurp.patch" size="728" author="juergenhoetzel" created="Sat, 27 Nov 2010 04:57:21 -0600" />
                    <attachment id="10018" name="0389_buffered_slurp.diff" size="1228" author="aaron" created="Fri, 12 Nov 2010 13:55:57 -0600" />
                </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-753] clojure.string/replace-first returns nil with replacement fn when regex doesn&apos;t match</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-753</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;&lt;a href=&quot;https://groups.google.com/d/topic/clojure/wDO1u7wRmDQ/discussion&quot;&gt;Originally reported by Takahiro Hozumi&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;With a function as the &quot;replacement&quot; argument, clojure.string/replace-first returns nil if there is no match, instead of returning the original string unchanged.&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; (use &apos;clojure.string)
nil
user=&amp;gt; (replace-first &lt;span class=&quot;code-quote&quot;&gt;&quot;abcdef&quot;&lt;/span&gt; &lt;span class=&quot;code-quote&quot;&gt;&quot;ghi&quot;&lt;/span&gt; &lt;span class=&quot;code-quote&quot;&gt;&quot;jkl&quot;&lt;/span&gt;)
&lt;span class=&quot;code-quote&quot;&gt;&quot;abcdef&quot;&lt;/span&gt;
user=&amp;gt; (replace-first &lt;span class=&quot;code-quote&quot;&gt;&quot;abcdef&quot;&lt;/span&gt; #&lt;span class=&quot;code-quote&quot;&gt;&quot;ghi&quot;&lt;/span&gt; &lt;span class=&quot;code-quote&quot;&gt;&quot;jkl&quot;&lt;/span&gt;)
&lt;span class=&quot;code-quote&quot;&gt;&quot;abcdef&quot;&lt;/span&gt;
user=&amp;gt; (replace-first &lt;span class=&quot;code-quote&quot;&gt;&quot;abcdef&quot;&lt;/span&gt; #&lt;span class=&quot;code-quote&quot;&gt;&quot;ghi&quot;&lt;/span&gt; (fn [a] &lt;span class=&quot;code-quote&quot;&gt;&quot;jkl&quot;&lt;/span&gt;))
nil&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;</description>
                <environment></environment>
            <key id="14369">CLJ-753</key>
            <summary>clojure.string/replace-first returns nil with replacement fn when regex doesn&apos;t match</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="6" iconUrl="http://dev.clojure.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Completed</resolution>
                                <assignee username="stuart.sierra">Stuart Sierra</assignee>
                                <reporter username="stuart.sierra">Stuart Sierra</reporter>
                        <labels>
                    </labels>
                <created>Fri, 11 Mar 2011 07:54:15 -0600</created>
                <updated>Fri, 1 Mar 2013 12:47:01 -0600</updated>
                    <resolved>Fri, 24 Aug 2012 07:41:03 -0500</resolved>
                                            <fixVersion>Approved Backlog</fixVersion>
                                        <due></due>
                    <votes>2</votes>
                        <watches>2</watches>
                        <comments>
                    <comment id="26322" author="fbrubacher" created="Mon, 21 Mar 2011 07:36:49 -0500"  >&lt;p&gt;This is my patch for this issue. I have a CA signed. Any suggestions and i can try again. Federico&lt;/p&gt;</comment>
                    <comment id="27353" author="cperkins" created="Mon, 28 Nov 2011 09:31:31 -0600"  >&lt;p&gt;Same fix as Frederico&apos;s patch, but also removes unnecessary allocation of a StringBuffer when there is no match, for both replace and replace first.&lt;/p&gt;</comment>
                    <comment id="27354" author="cperkins" created="Mon, 28 Nov 2011 09:46:03 -0600"  >&lt;p&gt;Same again, but with docstring typo fixes too.&lt;/p&gt;</comment>
                    <comment id="27355" author="steveminer@gmail.com" created="Mon, 28 Nov 2011 10:12:17 -0600"  >&lt;p&gt;You should use StringBuilder instead of StringBuffer.&lt;/p&gt;

&lt;p&gt;&lt;a href=&quot;http://stackoverflow.com/questions/355089/stringbuilder-and-stringbuffer-in-java&quot;&gt;http://stackoverflow.com/questions/355089/stringbuilder-and-stringbuffer-in-java&lt;/a&gt;&lt;/p&gt;</comment>
                    <comment id="27356" author="cperkins" created="Mon, 28 Nov 2011 10:37:56 -0600"  >&lt;p&gt;Yup, that&apos;s what I thought, but it turns out it doesn&apos;t work because java&apos;s Matcher/appendReplacement requires a StringBuffer, unfortunately.&lt;/p&gt;</comment>
                    <comment id="27360" author="jafingerhut" created="Mon, 28 Nov 2011 17:09:40 -0600"  >&lt;p&gt;I&apos;ve tested Chris&apos;s clojure-string-with-no-match-returns-original-2.patch against latest github Clojure as of this morning, and the tests pass.  Cool that he found a straightforward performance improvement for the no match case.  The code appears correct.  I also verified that for the reason Chris mentions, StringBuilder will not work as a replacement for StringBuffer.  At least there will never be any contention on the locks implementing the StringBuffer synchronization the way they are used here.&lt;/p&gt;</comment>
                    <comment id="27363" author="stuart.sierra" created="Tue, 29 Nov 2011 08:45:01 -0600"  >&lt;p&gt;Vetted &amp;amp; moved to Approved Backlog.&lt;/p&gt;</comment>
                    <comment id="27544" author="jafingerhut" created="Thu, 12 Jan 2012 00:06:50 -0600"  >&lt;p&gt;&lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-870&quot; title=&quot;clojure.string/replace behaves unexpectedly when \ or $ are part of the result string&quot;&gt;&lt;del&gt;CLJ-870&lt;/del&gt;&lt;/a&gt; has an attached proposed combined patch for this issue and that one.&lt;/p&gt;</comment>
                    <comment id="29223" author="jafingerhut" created="Sat, 18 Aug 2012 12:09:29 -0500"  >&lt;p&gt;This issue should now be corrected with the patch, attached to &lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-870&quot; title=&quot;clojure.string/replace behaves unexpectedly when \ or $ are part of the result string&quot;&gt;&lt;del&gt;CLJ-870&lt;/del&gt;&lt;/a&gt;, that was applied on Aug 18, 2012.&lt;/p&gt;</comment>
                    <comment id="29257" author="stuart.sierra" created="Fri, 24 Aug 2012 07:41:03 -0500"  >&lt;p&gt;&lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-753&quot; title=&quot;clojure.string/replace-first returns nil with replacement fn when regex doesn&amp;#39;t match&quot;&gt;&lt;del&gt;CLJ-753&lt;/del&gt;&lt;/a&gt; patch applied for &lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-870&quot; title=&quot;clojure.string/replace behaves unexpectedly when \ or $ are part of the result string&quot;&gt;&lt;del&gt;CLJ-870&lt;/del&gt;&lt;/a&gt; addresses this one, too, applied Aug 18, 2012 &lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="10157" name="0001-clojure.string-replace-first-now-returns-the-origina.patch" size="1598" author="fbrubacher" created="Mon, 21 Mar 2011 07:36:49 -0500" />
                    <attachment id="10721" name="clojure-string-with-no-match-returns-original-2.patch" size="4460" author="cperkins" created="Mon, 28 Nov 2011 09:46:03 -0600" />
                    <attachment id="10720" name="clojure-string-with-no-match-returns-original.patch" size="3262" author="cperkins" created="Mon, 28 Nov 2011 09:31:31 -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-838] dev.clojure.org/display/doc/1. 3 renders badly</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-838</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;The page &lt;a href=&quot;http://dev.clojure.org/display/doc/1.3&quot;&gt;http://dev.clojure.org/display/doc/1.3&lt;/a&gt; has markup issues: &lt;/p&gt;

&lt;ul class=&quot;alternate&quot; type=&quot;square&quot;&gt;
	&lt;li&gt;&lt;tt&gt;&amp;#42;earmuffs&amp;#42;&lt;/tt&gt; become &lt;b&gt;bold&lt;/b&gt;&lt;/li&gt;
	&lt;li&gt;clearly [ ] must mean something special, &apos;cause they all turn pink.&lt;/li&gt;
	&lt;li&gt;presumably there&apos;s some way to make confluence use monospace for code snippets.&lt;/li&gt;
	&lt;li&gt;I&apos;m sure confluence has some way to mark headings, but It doesn&apos;t look like &quot;==&quot; is it.&lt;/li&gt;
	&lt;li&gt;I&apos;d like to evict the &quot;frowning face&quot; from &lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-751&quot; title=&quot;cl-format: ~( thows an exception with an empty string&quot;&gt;&lt;del&gt;CLJ-751&lt;/del&gt;&lt;/a&gt;&apos;s clj-format example.&lt;/li&gt;
	&lt;li&gt;2.29 seems to have suffered some encoding debacle, though I&apos;m not quite sure what happened.&lt;/li&gt;
&lt;/ul&gt;


&lt;p&gt;Further discussion revealed that this was just a copy/paste of changes.txt in the source repository. Discussions on clojure-dev suggested the idea of recoding changes.txt to changes.md and recoding it as proper markdown so that it will be rendered nicely by github.&lt;/p&gt;

&lt;p&gt;This would make &lt;a href=&quot;http://dev.clojure.org/display/doc/1.3&quot;&gt;http://dev.clojure.org/display/doc/1.3&lt;/a&gt; obsolete, its contents could be replaced by a link to &apos;changes.md&apos; on github. That makes more sense than maintaining two copies of the document in mutually incompatible markups (markdown and whatever confluence uses).&lt;/p&gt;

&lt;p&gt;See also the following clojure-dev thread:&lt;/p&gt;

&lt;p&gt;&lt;a href=&quot;http://groups.google.com/group/clojure-dev/browse_thread/thread/ecf65c4e50d3fd76&quot;&gt;http://groups.google.com/group/clojure-dev/browse_thread/thread/ecf65c4e50d3fd76&lt;/a&gt;&lt;/p&gt;</description>
                <environment></environment>
            <key id="14630">CLJ-838</key>
            <summary>dev.clojure.org/display/doc/1. 3 renders badly</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="6" iconUrl="http://dev.clojure.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Completed</resolution>
                                <assignee username="bsmith.occs@gmail.com">Ben Smith-Mannschott</assignee>
                                <reporter username="bsmith.occs@gmail.com">Ben Smith-Mannschott</reporter>
                        <labels>
                    </labels>
                <created>Wed, 14 Sep 2011 14:11:17 -0500</created>
                <updated>Fri, 1 Mar 2013 12:47:01 -0600</updated>
                    <resolved>Fri, 7 Oct 2011 09:12:22 -0500</resolved>
                            <version>Release 1.4</version>
                                <fixVersion>Release 1.4</fixVersion>
                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                        <comments>
                    <comment id="26812" author="bsmith.occs@gmail.com" created="Wed, 14 Sep 2011 14:23:40 -0500"  >&lt;p&gt;0001-&lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-838&quot; title=&quot;dev.clojure.org/display/doc/1. 3 renders badly&quot;&gt;&lt;del&gt;CLJ-838&lt;/del&gt;&lt;/a&gt;-changes.txt-recoded-as-markdown.patch&lt;/p&gt;

&lt;p&gt;This recodes changes.txt as proper Markdown.  Text is not hard-wrapped because github&apos;s Markdown dialect handles hard line breaks differently than standard Markdown. Also, the original wasn&apos;t hard-wrapped either.&lt;/p&gt;

&lt;p&gt;0002-&lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-838&quot; title=&quot;dev.clojure.org/display/doc/1. 3 renders badly&quot;&gt;&lt;del&gt;CLJ-838&lt;/del&gt;&lt;/a&gt;-rename-changes.txt-changes.md.patch&lt;/p&gt;

&lt;p&gt;This patch just renames changes.txt to changes.md. I didn&apos;t want to rename and edit changes.txt in a single patch, not knowing how well git would handle that when it came time to apply the changes.&lt;/p&gt;

&lt;p&gt;0003-&lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-838&quot; title=&quot;dev.clojure.org/display/doc/1. 3 renders badly&quot;&gt;&lt;del&gt;CLJ-838&lt;/del&gt;&lt;/a&gt;-add-example-for-Add-docstring-support-to-def.patch&lt;/p&gt;

&lt;p&gt;Meikel Brandmeyer provided an example of docstring support in def in response to my query, so I&apos;ve included a patch to integrate that.&lt;/p&gt;</comment>
                    <comment id="26813" author="bsmith.occs@gmail.com" created="Wed, 14 Sep 2011 14:28:16 -0500"  >&lt;p&gt;I don&apos;t believe Markdown provides a good way of handling the contents section at the start of the document. I&apos;ve improvised it by just formatting the thing as if it were a code sample. &lt;/p&gt;

&lt;p&gt;Is the TOC really necessary? It&apos;s not ideal from a Don&apos;t Repeat Yourself standpoint. Also, manually maintaining the section numbers also strikes me as busy work? Can we do without?&lt;/p&gt;</comment>
                    <comment id="26814" author="bsmith.occs@gmail.com" created="Wed, 14 Sep 2011 14:28:55 -0500"  >&lt;p&gt;You can view a rendered version of &lt;tt&gt;changes.md&lt;/tt&gt; here:&lt;/p&gt;

&lt;p&gt;&lt;a href=&quot;https://github.com/bpsm/clojure/blob/CLJ-838/changes.md&quot;&gt;https://github.com/bpsm/clojure/blob/CLJ-838/changes.md&lt;/a&gt;&lt;/p&gt;</comment>
                    <comment id="26853" author="bsmith.occs@gmail.com" created="Fri, 23 Sep 2011 15:18:17 -0500"  >&lt;p&gt;patches updated for f0b092b66 &quot;more changes.txt tweaks&quot;&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="10369" name="0001-changes.txt-recoded-as-markdown.patch" size="23465" author="bsmith.occs@gmail.com" created="Fri, 23 Sep 2011 15:18:16 -0500" />
                    <attachment id="10370" name="0002-rename-changes.txt-changes.md.patch" size="534" author="bsmith.occs@gmail.com" created="Fri, 23 Sep 2011 15:18:16 -0500" />
                    <attachment id="10371" name="0003-add-example-for-Add-docstring-support-to-def.patch" size="705" author="bsmith.occs@gmail.com" created="Fri, 23 Sep 2011 15:18:17 -0500" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_10002" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Approval</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10007">Ok</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-920] Adds support for FreeDesktop&apos;s xdg-open in clojure.java.browse/browse-url.</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-920</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;This patch allows environments that support FreeDesktop to browse a URL in their default browser. This is important because unless the desktop environment bridges to Java (like Gnome does) the URL will be opened in a Swing window, which is not always desired.&lt;/p&gt;

&lt;p&gt;See: &lt;a href=&quot;https://github.com/clojure/clojure/pull/14&quot;&gt;https://github.com/clojure/clojure/pull/14&lt;/a&gt;&lt;/p&gt;</description>
                <environment>Any environment that supports FreeDesktop, so Linux and BSD mainly.</environment>
            <key id="15150">CLJ-920</key>
            <summary>Adds support for FreeDesktop&apos;s xdg-open in clojure.java.browse/browse-url.</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="6" iconUrl="http://dev.clojure.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Completed</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="jeremyheiler">Jeremy Heiler</reporter>
                        <labels>
                        <label>enhancement</label>
                    </labels>
                <created>Sat, 28 Jan 2012 10:45:35 -0600</created>
                <updated>Fri, 1 Mar 2013 12:47:01 -0600</updated>
                    <resolved>Wed, 29 Feb 2012 13:19:52 -0600</resolved>
                            <version>Release 1.3</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>1</watches>
                        <comments>
                    <comment id="27704" author="jafingerhut" created="Fri, 10 Feb 2012 05:08:51 -0600"  >&lt;p&gt;Is this a duplicate of &lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-896&quot; title=&quot;Make browse-url aware of xdg-open&quot;&gt;&lt;del&gt;CLJ-896&lt;/del&gt;&lt;/a&gt;?  Can you look at the patch there and see if there is any advantage to the patch for it vs. the one here?  Or perhaps some combination that is an improvement on them both?&lt;/p&gt;</comment>
                    <comment id="27890" author="jafingerhut" created="Wed, 29 Feb 2012 13:19:53 -0600"  >&lt;p&gt;The issue is definitely a duplicate of &lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-896&quot; title=&quot;Make browse-url aware of xdg-open&quot;&gt;&lt;del&gt;CLJ-896&lt;/del&gt;&lt;/a&gt;.  The proposed patches were different.  &lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-896&quot; title=&quot;Make browse-url aware of xdg-open&quot;&gt;&lt;del&gt;CLJ-896&lt;/del&gt;&lt;/a&gt; now has an attached patch that is an enhancement of what Jeremy Heiler created.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="10793" name="browseurl.patch" size="653" author="jeremyheiler" created="Sat, 28 Jan 2012 10:45:35 -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-921] Ant 1.8 gives warning about &apos;includeantruntime&apos; when building Clojure</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-921</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;I&apos;m building Clojure locally with Ant 1.8.2.  I get a warning:&lt;/p&gt;

&lt;p&gt;compile-java:&lt;br/&gt;
   &lt;span class=&quot;error&quot;&gt;&amp;#91;javac&amp;#93;&lt;/span&gt; /Users/miner/cljproj/clojure/build.xml:39: warning: &apos;includeantruntime&apos; was not set, defaulting to build.sysclasspath=last; set to false for repeatable builds&lt;/p&gt;

&lt;p&gt;A good explanation is available here:&lt;/p&gt;

&lt;p&gt;&lt;a href=&quot;http://stackoverflow.com/questions/5103384/ant-warning-includeantruntime-was-not-set&quot;&gt;http://stackoverflow.com/questions/5103384/ant-warning-includeantruntime-was-not-set&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;The simple fix is to add an attribute to the javac task:  includeAntRuntime=&quot;false&quot;.&lt;/p&gt;</description>
                <environment>Mac OS X 10.7, Ant 1.8.2, Java 1.6</environment>
            <key id="15151">CLJ-921</key>
            <summary>Ant 1.8 gives warning about &apos;includeantruntime&apos; when building Clojure</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="6" iconUrl="http://dev.clojure.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Completed</resolution>
                                <assignee username="stuart.sierra">Stuart Sierra</assignee>
                                <reporter username="steveminer@gmail.com">Steve Miner</reporter>
                        <labels>
                    </labels>
                <created>Mon, 30 Jan 2012 16:48:07 -0600</created>
                <updated>Fri, 1 Mar 2013 12:47:01 -0600</updated>
                    <resolved>Fri, 3 Feb 2012 09:11:44 -0600</resolved>
                            <version>Release 1.4</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>1</watches>
                                <attachments>
                    <attachment id="10794" name="0001-includeAntRuntime.patch" size="657" author="steveminer@gmail.com" created="Mon, 30 Jan 2012 16:48:07 -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="10009">Fixed</customfieldvalue>

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

<item>
            <title>[CLJ-816] Transient vectors mutations leak into their source persistent vector </title>
                <link>http://dev.clojure.org/jira/browse/CLJ-816</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;(let &lt;span class=&quot;error&quot;&gt;&amp;#91;pv (vec (range 34))&amp;#93;&lt;/span&gt;&lt;br/&gt;
  (-&amp;gt; pv transient pop! pop! pop! (conj! 42))&lt;br/&gt;
  (nth pv 31))&lt;br/&gt;
; returns 42 instead of 31&lt;/p&gt;
</description>
                <environment></environment>
            <key id="14477">CLJ-816</key>
            <summary>Transient vectors mutations leak into their source persistent vector </summary>
                <type id="1" iconUrl="http://dev.clojure.org/jira/images/icons/bug.gif">Defect</type>
                                <priority id="2" iconUrl="http://dev.clojure.org/jira/images/icons/priority_critical.gif">Critical</priority>
                    <status id="6" iconUrl="http://dev.clojure.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Completed</resolution>
                                <assignee username="cgrand">Christophe Grand</assignee>
                                <reporter username="cgrand">Christophe Grand</reporter>
                        <labels>
                    </labels>
                <created>Fri, 24 Jun 2011 11:49:58 -0500</created>
                <updated>Fri, 1 Mar 2013 12:47:00 -0600</updated>
                    <resolved>Fri, 19 Aug 2011 11:36:54 -0500</resolved>
                            <version>Release 1.1</version>
                <version>Release 1.2</version>
                <version>Release 1.3</version>
                                <fixVersion>Release 1.3</fixVersion>
                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                        <comments>
                    <comment id="26532" author="cgrand" created="Fri, 24 Jun 2011 11:50:45 -0500"  >&lt;p&gt;The patch may apply to 1.1 and 1.2 too.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="10264" name="fix-transientvectors.diff" size="2194" author="cgrand" created="Fri, 24 Jun 2011 11:50:01 -0500" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_10002" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Approval</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10007">Ok</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-846] Javadoc does not detect 1.7 when setting *core-java-api*</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-846</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;When initializing &lt;b&gt;core-java-api&lt;/b&gt;, javadoc.clj checks whether the java specification version is 1.5; if not, it uses a url for the 1.6 docs. Unfortunately, this won&apos;t find documentation for new in 1.7 classes (such as those in the java.nio.file package).&lt;/p&gt;</description>
                <environment>Windows 7; Java 1.7</environment>
            <key id="14666">CLJ-846</key>
            <summary>Javadoc does not detect 1.7 when setting *core-java-api*</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="6" iconUrl="http://dev.clojure.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Completed</resolution>
                                <assignee username="stu">Stuart Halloway</assignee>
                                <reporter username="glchapman">Greg Chapman</reporter>
                        <labels>
                    </labels>
                <created>Mon, 3 Oct 2011 13:06:26 -0500</created>
                <updated>Fri, 1 Mar 2013 12:47:00 -0600</updated>
                    <resolved>Tue, 25 Oct 2011 17:32:18 -0500</resolved>
                            <version>Release 1.3</version>
                                <fixVersion>Release 1.4</fixVersion>
                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                                <attachments>
                    <attachment id="10376" name="CLJ-846.patch" size="1041" author="stu" created="Fri, 7 Oct 2011 12:09:47 -0500" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                <customfield id="customfield_10002" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Approval</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10007">Ok</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-855] catch receives a RuntimeException rather than the expected checked exception</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-855</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;Expressions passed to try that trigger the use of clojure.lang.Reflector result in their thrown checked exceptions being wrapped in RuntimeException.  As a result, the subsequent set of catches won&apos;t switch on the expected checked exception.&lt;/p&gt;


&lt;p&gt;Attached: patch for regression test that exposes the problem&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;(defn- get-exception [expression]
  (try (eval expression)
    nil
    (catch java.lang.Throwable t
      t)))

(deftest catch-receives-checked-exception
  (are [expression expected-exception] (= expected-exception
                                          (type (get-exception expression)))
    &quot;Eh, I&apos;m pretty safe&quot; nil
    &apos;(java.io.FileReader. &quot;CAFEBABEx0/idonotexist&quot;) java.io.FileNotFoundException)) ; fails&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;Clojure ML Thread: &lt;a href=&quot;https://groups.google.com/forum/#!topic/clojure/I5l1YHVMgkI/discussion&quot;&gt;https://groups.google.com/forum/#!topic/clojure/I5l1YHVMgkI/discussion&lt;/a&gt;&lt;br/&gt;
Introduced: &lt;a href=&quot;https://github.com/clojure/clojure/commit/8fda34e4c77cac079b711da59d5fe49b74605553&quot;&gt;https://github.com/clojure/clojure/commit/8fda34e4c77cac079b711da59d5fe49b74605553&lt;/a&gt;&lt;/p&gt;</description>
                <environment></environment>
            <key id="14692">CLJ-855</key>
            <summary>catch receives a RuntimeException rather than the expected checked exception</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="6" iconUrl="http://dev.clojure.org/jira/images/icons/status_closed.gif">Closed</status>
                    <resolution id="1">Completed</resolution>
                                <assignee username="bsmith.occs@gmail.com">Ben Smith-Mannschott</assignee>
                                <reporter username="pmbauer">Paul Michael Bauer</reporter>
                        <labels>
                    </labels>
                <created>Tue, 11 Oct 2011 20:44:25 -0500</created>
                <updated>Fri, 1 Mar 2013 12:47:00 -0600</updated>
                    <resolved>Wed, 29 Feb 2012 15:07:14 -0600</resolved>
                            <version>Release 1.3</version>
                                <fixVersion>Release 1.4</fixVersion>
                                        <due></due>
                    <votes>2</votes>
                        <watches>5</watches>
                        <comments>
                    <comment id="26942" author="bsmith.occs@gmail.com" created="Wed, 12 Oct 2011 02:06:09 -0500"  >&lt;p&gt;(marked up code snippet in description to display as code.)&lt;/p&gt;</comment>
                    <comment id="26945" author="bsmith.occs@gmail.com" created="Wed, 12 Oct 2011 16:23:34 -0500"  >&lt;p&gt;(This incorporates a slightly modified version of Paul Michael Bauer&apos;s&lt;br/&gt;
checked-exception-regression-test patch.)&lt;/p&gt;

&lt;p&gt;ClojureException is an RTE. RTEs that originate from Clojure all are&lt;br/&gt;
of this type. This isn&apos;t strictly necessary for this proof of concept,&lt;br/&gt;
but it seemed prudent since it seems that the lack of specificity resulting&lt;br/&gt;
from using plain RTE everywhere got us into this mess in the first place.&lt;/p&gt;

&lt;p&gt;WrappedException is a ClojureException. It is used when Clojure is&lt;br/&gt;
wrapping the underlying cause to work around Java&apos;s obsession with&lt;br/&gt;
checked exceptions. It&apos;s &lt;b&gt;always&lt;/b&gt; the underlying cause of&lt;br/&gt;
WrappedException that is relevant to catchers.&lt;/p&gt;

&lt;p&gt;Util.runtimeException(s) now returns a ClojureException&lt;br/&gt;
This is not strictly necessary for this patch to work&lt;/p&gt;

&lt;p&gt;Util.runtimeException(s,e) now returns a WrappedException.&lt;/p&gt;

&lt;p&gt;Util.runtimeException(e) now retuns a WrappedException when e is not&lt;br/&gt;
already a RuntimeException.&lt;/p&gt;

&lt;p&gt;clojure.core/treye is a macro built on top of the compiler-provided&lt;br/&gt;
special form try. (A &lt;b&gt;real&lt;/b&gt; solution to this problem would involve&lt;br/&gt;
altering the try special form itself, but this ist just a trial balloon&lt;br/&gt;
to figure out if this is the right way to go.)&lt;/p&gt;

&lt;p&gt;Paul Michael Bauer&apos;s try_catch.clj uses treye in place of try and passes.&lt;/p&gt;</comment>
                    <comment id="26951" author="hiredman" created="Wed, 12 Oct 2011 17:34:35 -0500"  >&lt;p&gt;&amp;gt;  &lt;a href=&quot;http://james-iry.blogspot.com/2010/08/on-removing-java-checked-exceptions-by.html&quot;&gt;http://james-iry.blogspot.com/2010/08/on-removing-java-checked-exceptions-by.html&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;seems like refactoring Reflector.java to rethrow using this approach&lt;br/&gt;
is preferable to some wrapping/unwrapping scheme&lt;/p&gt;</comment>
                    <comment id="26952" author="pmbauer" created="Wed, 12 Oct 2011 17:42:48 -0500"  >&lt;p&gt;(edit: missed Kevin&apos;s post)&lt;br/&gt;
&lt;a href=&quot;http://james-iry.blogspot.com/2010/08/on-removing-java-checked-exceptions-by.html&quot;&gt;http://james-iry.blogspot.com/2010/08/on-removing-java-checked-exceptions-by.html&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;I&apos;d rather see Reflector.java modified to use this &quot;chucking&quot; technique than have a special try form that specially unwraps an exception and re-throws.&lt;/p&gt;

&lt;p&gt;Maybe there&apos;s a need for WrappedException, but since it&apos;s not immediately necessary if we fix Reflector, then I&apos;d rather see it in a separate commit.&lt;/p&gt;

&lt;p&gt;(I&apos;m swamped at work today and don&apos;t have time to fix Reflector myself right now)&lt;/p&gt;</comment>
                    <comment id="26954" author="bendlas" created="Wed, 12 Oct 2011 21:27:02 -0500"  >&lt;p&gt;I added Util.throwUnchecked and Util.throwCause (also Util.declareThrows and Util.invokeThrowing) as justified in &lt;a href=&quot;https://groups.google.com/d/msg/clojure-dev/4QynV81W0Qk/rIN9fYUK-AkJ&quot;&gt;https://groups.google.com/d/msg/clojure-dev/4QynV81W0Qk/rIN9fYUK-AkJ&lt;/a&gt;&lt;br/&gt;
I&apos;ve used this to fix the invoke* methods in Reflector. Please review.&lt;/p&gt;

&lt;p&gt;There are a lot of other instances in the code, where checked exceptions are runtime-ified, but that&apos;s a separate issue.&lt;/p&gt;</comment>
                    <comment id="26956" author="bsmith.occs@gmail.com" created="Thu, 13 Oct 2011 01:07:55 -0500"  >&lt;p&gt;Applying the patch &lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-855&quot; title=&quot;catch receives a RuntimeException rather than the expected checked exception&quot;&gt;&lt;del&gt;CLJ-855&lt;/del&gt;&lt;/a&gt;_throw_un