<!--
RSS generated by JIRA (4.4#649-r158309) at Tue Jun 18 22:56:27 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=fixVersion+%3D+%22Reviewed+Backlog%22+AND+project+%3D+CLJ&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=fixVersion+%3D+%22Reviewed+Backlog%22+AND+project+%3D+CLJ</link>
        <description>An XML representation of a search request</description>
                <language>en-us</language>
                        <issue start="0" end="5" total="5"/>
                <build-info>
            <version>4.4</version>
            <build-number>649</build-number>
            <build-date>25-07-2011</build-date>
        </build-info>
<item>
            <title>[CLJ-892] sort changes its argument, if a Java array</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-892</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;user&amp;gt; (let [a (to-array &lt;span class=&quot;error&quot;&gt;&amp;#91;32 11&amp;#93;&lt;/span&gt;)] &lt;br/&gt;
        (prn (seq a))&lt;br/&gt;
        (sort a)&lt;br/&gt;
        (prn (seq a)))&lt;br/&gt;
(32 11)&lt;br/&gt;
(11 32)&lt;br/&gt;
nil&lt;/p&gt;

&lt;p&gt;Where the second line printed ought to be the same as the first.&lt;/p&gt;</description>
                <environment>java version &amp;quot;1.6.0_22&amp;quot;&lt;br/&gt;
OpenJDK Runtime Environment (IcedTea6 1.10.4) (6b22-1.10.4-0ubuntu1~11.04.1)&lt;br/&gt;
(clojure-version)&lt;br/&gt;
&amp;quot;1.4.0-alpha2&amp;quot;</environment>
            <key id="15058">CLJ-892</key>
            <summary>sort changes its argument, if a Java array</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="s11001001">Stephen Compall</reporter>
                        <labels>
                    </labels>
                <created>Thu, 8 Dec 2011 19:14:37 -0600</created>
                <updated>Fri, 18 May 2012 12:35:48 -0500</updated>
                    <resolved>Fri, 18 May 2012 12:35:48 -0500</resolved>
                            <version>Release 1.3</version>
                <version>Release 1.4</version>
                                <fixVersion>Reviewed Backlog</fixVersion>
                <fixVersion>Release 1.5</fixVersion>
                                        <due></due>
                    <votes>0</votes>
                        <watches>1</watches>
                        <comments>
                    <comment id="27438" author="stu" created="Fri, 9 Dec 2011 09:37:53 -0600"  >&lt;p&gt;This is an enhancement request, since the docs for sort make no promise one way or the other. &lt;/p&gt;

&lt;p&gt;For performance, I prefer the current behavior, so another possibility is a clarifying doc string.&lt;/p&gt;</comment>
                    <comment id="28016" author="jafingerhut" created="Mon, 26 Mar 2012 17:32:41 -0500"  >&lt;p&gt;clj-892-clarify-sort-sort-by-doc-strings-patch1.txt of Mar 26, 2012 applies cleanly to latest master on that date.  Only doc string changes, to make it clear that by sort and sort-by will modify Java arrays given as arguments.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="11012" name="clj-892-clarify-sort-sort-by-doc-strings-patch1.txt" size="1409" author="jafingerhut" created="Mon, 26 Mar 2012 17:32:41 -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-891] make (symbol foo &quot;bar&quot;) work with foo being a namespace</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-891</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;I&apos;ve run across the need to do (symbol &lt;b&gt;ns&lt;/b&gt; &quot;bar&quot;) a few times, and the existing approach (symbol (name (ns-name &lt;b&gt;ns&lt;/b&gt;)) &quot;bar&quot;) just doesn&apos;t seem like it ought to be the only way to do the job.  Includes a patch to make this work, by adding a new arity to Symbol.intern().&lt;/p&gt;

&lt;p&gt;Some discussion on this idea, here: &lt;a href=&quot;https://groups.google.com/forum/#!topic/clojure/n25aZ5HA7hc/discussion&quot;&gt;https://groups.google.com/forum/#!topic/clojure/n25aZ5HA7hc/discussion&lt;/a&gt;&lt;/p&gt;</description>
                <environment></environment>
            <key id="15047">CLJ-891</key>
            <summary>make (symbol foo &quot;bar&quot;) work with foo being a namespace</summary>
                <type id="4" iconUrl="http://dev.clojure.org/jira/images/icons/improvement.gif">Enhancement</type>
                                <priority id="4" iconUrl="http://dev.clojure.org/jira/images/icons/priority_minor.gif">Minor</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="joegallo">Joe Gallo</reporter>
                        <labels>
                    </labels>
                <created>Mon, 5 Dec 2011 10:13:58 -0600</created>
                <updated>Fri, 2 Mar 2012 16:53:07 -0600</updated>
                                                    <fixVersion>Reviewed Backlog</fixVersion>
                                        <due></due>
                    <votes>3</votes>
                        <watches>4</watches>
                        <comments>
                    <comment id="27439" author="stu" created="Fri, 9 Dec 2011 09:39:43 -0600"  >&lt;p&gt;I am not sure I like this, but I would like a rethink of names and namespaces. Doing a lot of cross language work, it would be great to have protocols for &quot;I have a name&quot; and for &quot;I have a namespace&quot;.&lt;/p&gt;

&lt;p&gt;With such protocols in place, it would also be possible to separately consider implementing symbol et al in terms of them. &lt;/p&gt;</comment>
                    <comment id="27443" author="hiredman" created="Fri, 9 Dec 2011 12:24:06 -0600"  >&lt;p&gt;Named being a protocol or an interface seems orthogonal to being able to create a symbol qualified with a namespace when you have a namespace in hand.&lt;/p&gt;

&lt;p&gt;I don&apos;t think the patch goes far enough, not only should (symbol &lt;b&gt;ns&lt;/b&gt; &quot;foo&quot;) be supported, but also (symbol &lt;b&gt;ns&lt;/b&gt; &apos;foo), given that (symbol &apos;foo) works and (symbol &quot;foo&quot;) works, (symbol &apos;bar &apos;foo) should also work, but doesn&apos;t.&lt;/p&gt;

&lt;p&gt;if Named is a protocol, and if you extend it to String, and if you make the symbol function create symbols from one or two Named things you still end up having to do (symbol (ns-name &lt;b&gt;ns&lt;/b&gt;) &apos;foo) or (symbol (ns-name &lt;b&gt;ns&lt;/b&gt;) &quot;foo&quot;)&lt;/p&gt;</comment>
                    <comment id="27480" author="joegallo" created="Fri, 16 Dec 2011 16:18:02 -0600"  >&lt;p&gt;Stuart, I&apos;m not opposed to the idea of separate protocols for Named and Namespaced.  Where should I go about creating a proposal to create those protocols and get them into clojure?  I&apos;m interested in doing the leg-work, or being a part of it.  But as an outsider, I don&apos;t know what to do next &amp;#8211; creating a ticket in Jira exhausted my knowledge of the process.&lt;/p&gt;</comment>
                    <comment id="27901" author="franks" created="Fri, 2 Mar 2012 16:53:07 -0600"  >&lt;p&gt;The same enhancement that joe suggests for symbol, would also apply to keyword.&lt;/p&gt;

&lt;p&gt;See: &lt;a href=&quot;http://groups.google.com/group/clojure/browse_thread/thread/222e4abc16df8b20&quot;&gt;http://groups.google.com/group/clojure/browse_thread/thread/222e4abc16df8b20&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;Probably same/similar solution applies to both issues.&lt;/p&gt;

&lt;p&gt;-FrankS.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="10732" name="0001-add-Symbol.intern-arity-for-a-Namespace-and-String.patch" size="7437" author="joegallo" created="Mon, 5 Dec 2011 10:13:58 -0600" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10000" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Patch</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10001">Code</customfieldvalue>

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

<item>
            <title>[CLJ-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-862] pmap level of parallelism inconsistent for chunked vs non-chunked input</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-862</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;The code of pmap creates futures for the set of map operations it needs to perform with (map #(future %) coll), then acts on that sequence in a fashion obviously intended to keep only #CPUs+2 unfinished futures realized at any given time.  It works exactly this way for non-chunked input seqs, but when pmap is passed a chunked seq, the seq of futures also becomes chunked.  This causes an arbitrary number of futures to be realized as the #CPUs+2 window and chunk-size window interact.&lt;/p&gt;

&lt;p&gt;The doc-string for pmap doesn&apos;t promise any particular level of parallelism, but I think the inconsistent parallelism for chunked vs non-chunked input comprises a bug.&lt;/p&gt;</description>
                <environment></environment>
            <key id="14805">CLJ-862</key>
            <summary>pmap level of parallelism inconsistent for chunked vs non-chunked input</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="jim.blomo">Jim Blomo</assignee>
                                <reporter username="llasram">Marshall T. Vandegrift</reporter>
                        <labels>
                    </labels>
                <created>Sun, 23 Oct 2011 09:50:38 -0500</created>
                <updated>Sat, 20 Oct 2012 00:45:48 -0500</updated>
                                    <version>Release 1.1</version>
                <version>Release 1.2</version>
                <version>Release 1.3</version>
                <version>Release 1.4</version>
                                <fixVersion>Reviewed Backlog</fixVersion>
                                        <due></due>
                    <votes>0</votes>
                        <watches>2</watches>
                        <comments>
                    <comment id="27093" author="stu" created="Tue, 25 Oct 2011 18:51:55 -0500"  >&lt;p&gt;Next person to take a deep look at pmap should probably also think through fork/join.&lt;/p&gt;</comment>
                    <comment id="28533" author="jim.blomo" created="Sat, 19 May 2012 00:31:23 -0500"  >&lt;p&gt;fork/join is a Java 7 feature. Would a proposed patch need to be able to fall back to Java 5 features?&lt;/p&gt;</comment>
                    <comment id="28535" author="jafingerhut" created="Sat, 19 May 2012 01:06:37 -0500"  >&lt;p&gt;Clojure/core folks can say more authoritatively, but I believe with the recent reduce enhancements that rely on jsr166 code, Clojure 1.5 will most likely require Java 6 or later, and Java 5 will no longer be supported.&lt;/p&gt;</comment>
                    <comment id="28630" author="jim.blomo" created="Mon, 28 May 2012 17:29:01 -0500"  >&lt;p&gt;Spinning up more threads than CPU cores is not a good idea when the work is CPU bound.  Currently (1.4) pmap uses an unbounded thread pool, so chunked sequences will create more threads than intended.  The least invasive change is to use a fixed sized thread pool (ForkJoinPool being one example).  pmap is differentiated from core.reducers by the fact that it is lazy.  This implies a one-at-a-time ThreadPool.submit model, instead of the recursive fork/join model.  Tradeoffs include:&lt;/p&gt;

&lt;p&gt;Enforce look-ahead even on chunked sequences:&lt;/p&gt;
&lt;ul class=&quot;alternate&quot; type=&quot;square&quot;&gt;
	&lt;li&gt;+ no threadPool changes&lt;/li&gt;
	&lt;li&gt;- working against chunking, which is presumably being used for a reason&lt;/li&gt;
&lt;/ul&gt;


&lt;p&gt;Move to a fixed size thread pool:&lt;/p&gt;
&lt;ul class=&quot;alternate&quot; type=&quot;square&quot;&gt;
	&lt;li&gt;+ reduce contention for cpu-bound functions on chunked sequences&lt;/li&gt;
	&lt;li&gt;- increase total realization time for io-bound functions&lt;/li&gt;
&lt;/ul&gt;


&lt;p&gt;Use ForkJoinPool for fixed thread pool (instead of newFixedThreadPool):&lt;/p&gt;
&lt;ul class=&quot;alternate&quot; type=&quot;square&quot;&gt;
	&lt;li&gt;+ automatic and dynamic parallelism&lt;/li&gt;
	&lt;li&gt;- more complex setup (picking Java 6 vs 7 implementation, sharing pool with core.reducers)&lt;/li&gt;
&lt;/ul&gt;


&lt;p&gt;I think using a traditional fixed size thread pool is the right option.  Most of the time all of pmap&apos;s results will be realized, so I don&apos;t think it&apos;s worth saving work by being strict about the look-ahead size.  This is also the decision map has made.  Since we&apos;re not using ForkJoin&apos;s main strength (recursive work queuing), I don&apos;t think it is worth setting it up in clojure.core.&lt;/p&gt;

&lt;p&gt;I&apos;ll use Agent/pooledExecutor as the fixed size thread.&lt;/p&gt;

&lt;p&gt;Let me know if I forgot or misunderstood anything.&lt;/p&gt;</comment>
                    <comment id="28637" author="jim.blomo" created="Mon, 28 May 2012 19:59:01 -0500"  >&lt;p&gt;2012-05-28 pmap-chunking-862.diff uses a fixed size thread pool for pmap functions.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="11265" name="pmap-chunking-862.diff" size="2825" author="jim.blomo" created="Mon, 28 May 2012 19:59:01 -0500" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10000" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Patch</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10002">Code and Test</customfieldvalue>

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

<item>
            <title>[CLJ-445] Method/Constructor resolution does not factor in widening conversion of primitive args</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-445</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;Problem:&lt;br/&gt;
When making java calls (or inlined functions), if both args and param are primitive, no widening conversion is used to locate the proper overloaded method/constructor.&lt;/p&gt;

&lt;p&gt;Examples:&lt;/p&gt;
&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;user=&amp;gt; (&lt;span class=&quot;code-object&quot;&gt;Integer&lt;/span&gt;. (&lt;span class=&quot;code-object&quot;&gt;byte&lt;/span&gt; 0))
java.lang.IllegalArgumentException: No matching ctor found &lt;span class=&quot;code-keyword&quot;&gt;for&lt;/span&gt; class java.lang.&lt;span class=&quot;code-object&quot;&gt;Integer&lt;/span&gt; (NO_SOURCE_FILE:0)
&amp;lt;/code&amp;gt;&amp;lt;/pre&amp;gt;
The above occurs because there is no &lt;span class=&quot;code-object&quot;&gt;Integer&lt;/span&gt;(&lt;span class=&quot;code-object&quot;&gt;byte&lt;/span&gt;) constructor, though it should match on &lt;span class=&quot;code-object&quot;&gt;Integer&lt;/span&gt;(&lt;span class=&quot;code-object&quot;&gt;int&lt;/span&gt;).
&amp;lt;pre&amp;gt;&amp;lt;code&amp;gt;user=&amp;gt; (bit-shift-left (&lt;span class=&quot;code-object&quot;&gt;byte&lt;/span&gt; 1) 1)
Reflection warning, NO_SOURCE_PATH:3 - call to shiftLeft can&apos;t be resolved.
2&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;
&lt;p&gt;In the above, a call is made via reflection to Numbers.shiftLeft(Object, Object) and its associated auto-boxing, instead of directly to the perfectly adequate Numbers.shiftLeft(long, int).&lt;/p&gt;

&lt;p&gt;Workarounds:&lt;br/&gt;
Explicitly casting to the formal type.&lt;/p&gt;

&lt;p&gt;Ancillary benefits of fixing:&lt;br/&gt;
It would also reduce the amount of method overloading, e.g., RT.intCast(char), intCast(byte), intCast(short), could all be removed, since such calls would pass to RT.intCast(int).&lt;/p&gt;</description>
                <environment></environment>
            <key id="13842">CLJ-445</key>
            <summary>Method/Constructor resolution does not factor in widening conversion of primitive args</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="ataggart">Alexander Taggart</assignee>
                                <reporter username="ataggart">Alexander Taggart</reporter>
                        <labels>
                    </labels>
                <created>Wed, 29 Sep 2010 01:02:00 -0500</created>
                <updated>Mon, 20 Feb 2012 14:04:42 -0600</updated>
                                                    <fixVersion>Reviewed Backlog</fixVersion>
                                        <due></due>
                    <votes>2</votes>
                        <watches>4</watches>
                        <comments>
                    <comment id="24255" author="importer" created="Sat, 23 Oct 2010 18:43:00 -0500"  >&lt;p&gt;Converted from &lt;a href=&quot;http://www.assembla.com/spaces/clojure/tickets/445&quot;&gt;http://www.assembla.com/spaces/clojure/tickets/445&lt;/a&gt;&lt;br/&gt;
Attachments:&lt;br/&gt;
fixbug445.diff - &lt;a href=&quot;https://www.assembla.com/spaces/clojure/documents/b6gDSUZOur36b9eJe5cbCb/download/b6gDSUZOur36b9eJe5cbCb&quot;&gt;https://www.assembla.com/spaces/clojure/documents/b6gDSUZOur36b9eJe5cbCb/download/b6gDSUZOur36b9eJe5cbCb&lt;/a&gt;&lt;/p&gt;</comment>
                    <comment id="24256" author="importer" created="Sat, 23 Oct 2010 18:43:00 -0500"  >&lt;p&gt;ataggart said: [&lt;a href=&quot;file:b6gDSUZOur36b9eJe5cbCb&quot;&gt;file:b6gDSUZOur36b9eJe5cbCb&lt;/a&gt;]&lt;/p&gt;</comment>
                    <comment id="24257" author="importer" created="Sat, 23 Oct 2010 18:43:00 -0500"  >&lt;p&gt;ataggart said: Also fixes #446.&lt;/p&gt;</comment>
                    <comment id="26001" author="stu" created="Fri, 3 Dec 2010 12:50:23 -0600"  >&lt;p&gt;The patch is causing a test failure &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] Exception in thread &lt;span class=&quot;code-quote&quot;&gt;&quot;main&quot;&lt;/span&gt; java.lang.IllegalArgumentException: 
     More than one matching method found: equiv, compiling:(clojure/pprint/cl_format.clj:428)&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;Can you take a look?&lt;/p&gt;</comment>
                    <comment id="26192" author="stu" created="Fri, 28 Jan 2011 12:30:18 -0600"  >&lt;p&gt;The failing test happens when trying to find the correct equiv for signature &lt;tt&gt;(Number, long)&lt;/tt&gt;. Is the compiler wrong to propose this signature, or is the resolution method wrong in not having an answer? (It thinks two signatures are tied: &lt;tt&gt;(Object, long)&lt;/tt&gt; and &lt;tt&gt;(Number, Number)&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;Exception in thread &lt;span class=&quot;code-quote&quot;&gt;&quot;main&quot;&lt;/span&gt; java.lang.IllegalArgumentException: More than one matching method found: equiv, compiling:(clojure/pprint/cl_format.clj:428)
	at clojure.lang.&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;.analyzeSeq(&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;.java:6062)
	at clojure.lang.&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;.analyze(&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;.java:5866)
	at clojure.lang.&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;.analyze(&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;.java:5827)
	at clojure.lang.&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;.analyzeSeq(&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;.java:6050)
	at clojure.lang.&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;.analyze(&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;.java:5866)
	at clojure.lang.&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;.access$100(&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;.java:35)
	at clojure.lang.&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;$LetExpr$Parser.parse(&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;.java:5492)
	at clojure.lang.&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;.analyzeSeq(&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;.java:6055)
	at clojure.lang.&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;.analyze(&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;.java:5866)
	at clojure.lang.&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;.analyzeSeq(&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;.java:6043)
	at clojure.lang.&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;.analyze(&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;.java:5866)
	at clojure.lang.&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;.analyzeSeq(&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;.java:6043)
	at clojure.lang.&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;.analyze(&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;.java:5866)
	at clojure.lang.&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;.analyze(&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;.java:5827)
	at clojure.lang.&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;$IfExpr$Parser.parse(&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;.java:2372)
	at clojure.lang.&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;.analyzeSeq(&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;.java:6055)
	at clojure.lang.&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;.analyze(&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;.java:5866)
	at clojure.lang.&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;.analyzeSeq(&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;.java:6043)
	at clojure.lang.&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;.analyze(&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;.java:5866)
	at clojure.lang.&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;.analyze(&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;.java:5827)
	at clojure.lang.&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;$InvokeExpr.parse(&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;.java:3277)
	at clojure.lang.&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;.analyzeSeq(&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;.java:6057)
	at clojure.lang.&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;.analyze(&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;.java:5866)
	at clojure.lang.&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;.analyze(&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;.java:5827)
	at clojure.lang.&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;$BodyExpr$Parser.parse(&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;.java:5231)
	at clojure.lang.&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;$LetExpr$Parser.parse(&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;.java:5527)
	at clojure.lang.&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;.analyzeSeq(&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;.java:6055)
	at clojure.lang.&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;.analyze(&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;.java:5866)
	at clojure.lang.&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;.analyzeSeq(&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;.java:6043)
	at clojure.lang.&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;.analyze(&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;.java:5866)
	at clojure.lang.&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;.analyze(&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;.java:5827)
	at clojure.lang.&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;$BodyExpr$Parser.parse(&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;.java:5231)
	at clojure.lang.&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;.analyzeSeq(&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;.java:6055)
	at clojure.lang.&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;.analyze(&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;.java:5866)
	at clojure.lang.&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;.analyze(&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;.java:5827)
	at clojure.lang.&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;$IfExpr$Parser.parse(&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;.java:2385)
	at clojure.lang.&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;.analyzeSeq(&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;.java:6055)
	at clojure.lang.&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;.analyze(&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;.java:5866)
	at clojure.lang.&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;.analyze(&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;.java:5827)
	at clojure.lang.&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;$BodyExpr$Parser.parse(&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;.java:5231)
	at clojure.lang.&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;$LetExpr$Parser.parse(&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;.java:5527)
	at clojure.lang.&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;.analyzeSeq(&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;.java:6055)
	at clojure.lang.&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;.analyze(&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;.java:5866)
	at clojure.lang.&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;.analyzeSeq(&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;.java:6043)
	at clojure.lang.&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;.analyze(&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;.java:5866)
	at clojure.lang.&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;.analyze(&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;.java:5827)
	at clojure.lang.&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;$IfExpr$Parser.parse(&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;.java:2385)
	at clojure.lang.&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;.analyzeSeq(&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;.java:6055)
	at clojure.lang.&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;.analyze(&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;.java:5866)
	at clojure.lang.&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;.analyze(&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;.java:5827)
	at clojure.lang.&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;$BodyExpr$Parser.parse(&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;.java:5231)
	at clojure.lang.&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;$LetExpr$Parser.parse(&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;.java:5527)
	at clojure.lang.&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;.analyzeSeq(&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;.java:6055)
	at clojure.lang.&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;.analyze(&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;.java:5866)
	at clojure.lang.&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;.analyzeSeq(&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;.java:6043)
	at clojure.lang.&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;.analyze(&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;.java:5866)
	at clojure.lang.&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;.analyze(&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;.java:5827)
	at clojure.lang.&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;$BodyExpr$Parser.parse(&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;.java:5231)
	at clojure.lang.&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;$FnMethod.parse(&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;.java:4667)
	at clojure.lang.&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;$FnExpr.parse(&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;.java:3397)
	at clojure.lang.&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;.analyzeSeq(&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;.java:6053)
	at clojure.lang.&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;.analyze(&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;.java:5866)
	at clojure.lang.&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;.analyzeSeq(&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;.java:6043)
	at clojure.lang.&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;.analyze(&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;.java:5866)
	at clojure.lang.&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;.access$100(&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;.java:35)
	at clojure.lang.&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;$DefExpr$Parser.parse(&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;.java:480)
	at clojure.lang.&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;.analyzeSeq(&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;.java:6055)
	at clojure.lang.&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;.analyze(&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;.java:5866)
	at clojure.lang.&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;.analyze(&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;.java:5827)
	at clojure.lang.&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;.eval(&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;.java:6114)
	at clojure.lang.&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;.load(&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;.java:6545)
	at clojure.lang.RT.loadResourceScript(RT.java:340)
	at clojure.lang.RT.loadResourceScript(RT.java:331)
	at clojure.lang.RT.load(RT.java:409)
	at clojure.lang.RT.load(RT.java:381)
	at clojure.core$load$fn__1427.invoke(core.clj:5308)
	at clojure.core$load.doInvoke(core.clj:5307)
	at clojure.lang.RestFn.invoke(RestFn.java:409)
	at clojure.pprint$eval3969.invoke(pprint.clj:46)
	at clojure.lang.&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;.eval(&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;.java:6110)
	at clojure.lang.&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;.load(&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;.java:6545)
	at clojure.lang.RT.loadResourceScript(RT.java:340)
	at clojure.lang.RT.loadResourceScript(RT.java:331)
	at clojure.lang.RT.load(RT.java:409)
	at clojure.lang.RT.load(RT.java:381)
	at clojure.core$load$fn__1427.invoke(core.clj:5308)
	at clojure.core$load.doInvoke(core.clj:5307)
	at clojure.lang.RestFn.invoke(RestFn.java:409)
	at clojure.core$load_one.invoke(core.clj:5132)
	at clojure.core$load_lib.doInvoke(core.clj:5169)
	at clojure.lang.RestFn.applyTo(RestFn.java:143)
	at sun.reflect.GeneratedMethodAccessor11.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at clojure.lang.Reflector.invokeMatchingMethod(Reflector.java:77)
	at clojure.lang.Reflector.invokeInstanceMethod(Reflector.java:28)
	at clojure.core$apply.invoke(core.clj:602)
	at clojure.core$load_libs.doInvoke(core.clj:5203)
	at clojure.lang.RestFn.applyTo(RestFn.java:138)
	at sun.reflect.GeneratedMethodAccessor11.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at clojure.lang.Reflector.invokeMatchingMethod(Reflector.java:77)
	at clojure.lang.Reflector.invokeInstanceMethod(Reflector.java:28)
	at clojure.core$apply.invoke(core.clj:604)
	at clojure.core$use.doInvoke(core.clj:5283)
	at clojure.lang.RestFn.invoke(RestFn.java:409)
	at clojure.main$repl.doInvoke(main.clj:196)
	at clojure.lang.RestFn.invoke(RestFn.java:422)
	at clojure.main$repl_opt.invoke(main.clj:267)
	at clojure.main$main.doInvoke(main.clj:362)
	at clojure.lang.RestFn.invoke(RestFn.java:409)
	at clojure.lang.Var.invoke(Var.java:401)
	at clojure.lang.AFn.applyToHelper(AFn.java:163)
	at clojure.lang.Var.applyTo(Var.java:518)
	at clojure.main.main(main.java:37)
Caused by: java.lang.IllegalArgumentException: More than one matching method found: equiv
	at clojure.lang.Reflector.getMatchingParams(Reflector.java:639)
	at clojure.lang.Reflector.getMatchingParams(Reflector.java:578)
	at clojure.lang.Reflector.getMatchingMethod(Reflector.java:569)
	at clojure.lang.&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;$StaticMethodExpr.&amp;lt;init&amp;gt;(&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;.java:1439)
	at clojure.lang.&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;$HostExpr$Parser.parse(&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;.java:896)
	at clojure.lang.&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;.analyzeSeq(&lt;span class=&quot;code-object&quot;&gt;Compiler&lt;/span&gt;.java:6055)
	... 115 more&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;</comment>
                    <comment id="26214" author="ataggart" created="Tue, 8 Feb 2011 18:27:03 -0600"  >&lt;p&gt;In working on implementing support for vararg methods, I found a number of flaws with the previous solutions.  Please disregard them.&lt;/p&gt;

&lt;p&gt;I&apos;ve attached a single patch (reflector-compiler-numbers.diff) which is a rather substantial overhaul of the Reflector code, with some enhancements to the Compiler and Numbers code.  &lt;/p&gt;

&lt;p&gt;The patch notes:&lt;/p&gt;

&lt;ul class=&quot;alternate&quot; type=&quot;square&quot;&gt;
	&lt;li&gt;Moved reflection functionality from Compiler to Reflector.&lt;/li&gt;
	&lt;li&gt;Reflector supports finding overloaded methods by widening conversion, boxing conversion, and casting.&lt;/li&gt;
	&lt;li&gt;During compilation Reflector attempts to find best wildcard match.&lt;/li&gt;
	&lt;li&gt;Reflector refers to &lt;tt&gt;&amp;#42;unchecked-math*&lt;/tt&gt; when reflectively invoking methods and constructors.&lt;/li&gt;
	&lt;li&gt;Both Reflector and Compiler support variable arity java methods and constructor; backwards compatible with passing an array or nil in the vararg slot.&lt;/li&gt;
	&lt;li&gt;Added more informative error messages to Reflector.&lt;/li&gt;
	&lt;li&gt;Added tests to clojure.test-clojure.reflector.&lt;/li&gt;
	&lt;li&gt;Altered overloaded functions of clojure.lang.Numbers to service Object/double/long params; fixes some ambiguity issues and avoids unnecessary boxing in some cases.&lt;/li&gt;
	&lt;li&gt;Patch closes issues 380, 440, 445, 666, and possibly 259 (not enough detail provided).&lt;/li&gt;
&lt;/ul&gt;
</comment>
                    <comment id="26215" author="ataggart" created="Thu, 10 Feb 2011 19:35:57 -0600"  >&lt;p&gt;Updated patch to fix a bug where a concrete class with multiple identical Methods (e.g., one from an interface, another from an abstract class) would result in ambiguity.  Now resolved by arbitrary selection (this is what the original code did as well albeit not explicitly).&lt;/p&gt;</comment>
                    <comment id="26245" author="ataggart" created="Fri, 25 Feb 2011 21:29:21 -0600"  >&lt;p&gt;Updated patch to work with latest master branch.&lt;/p&gt;</comment>
                    <comment id="26289" author="stu" created="Sun, 6 Mar 2011 13:54:58 -0600"  >&lt;p&gt;patch appears to be missing test file clojure/test_clojure/reflector.clj.&lt;/p&gt;</comment>
                    <comment id="26290" author="ataggart" created="Sun, 6 Mar 2011 14:39:37 -0600"  >&lt;p&gt;Bit by git.&lt;/p&gt;

&lt;p&gt;Patch corrected to contain clojure.test-clojure.reflector.&lt;/p&gt;</comment>
                    <comment id="26300" author="stu" created="Fri, 11 Mar 2011 10:30:59 -0600"  >&lt;p&gt;Rich: I verified that the patch applied but reviewed only briefly, knowing you will want to go over this one closely.&lt;/p&gt;</comment>
                    <comment id="26301" author="stu" created="Fri, 11 Mar 2011 10:55:21 -0600"  >&lt;p&gt;After applying this patch, I am getting method missing errors:&lt;/p&gt;

&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;java.lang.NoSuchMethodError: clojure.lang.Numbers.lt(JLjava/lang/&lt;span class=&quot;code-object&quot;&gt;Object&lt;/span&gt;;)&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;but only when using compiled code, e.g. the same code works in the REPL and then fails after compilation. Haven&apos;t been able to isolate an example that I can share here yet, but hoping this will cause someone to have an &quot;a, hah&quot; moment...&lt;/p&gt;</comment>
                    <comment id="26341" author="ataggart" created="Sat, 2 Apr 2011 12:55:14 -0500"  >&lt;p&gt;The patch now contains only the minimal changes needed to support widening conversion. Cleanup of Numbers overloads, etc., can wait until this patch gets applied.  The vararg support is in a separate patch on &lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-440&quot; title=&quot;java method calls cannot omit varargs&quot;&gt;CLJ-440&lt;/a&gt;.&lt;/p&gt;</comment>
                    <comment id="26370" author="redinger" created="Fri, 15 Apr 2011 12:50:43 -0500"  >&lt;p&gt;Please test patch&lt;/p&gt;</comment>
                    <comment id="26377" author="redinger" created="Thu, 21 Apr 2011 11:02:31 -0500"  >&lt;p&gt;FYI: Patch applies cleanly on master and all tests pass as of 4/21 (2011)&lt;/p&gt;</comment>
                    <comment id="26384" author="redinger" created="Fri, 22 Apr 2011 09:57:18 -0500"  >&lt;p&gt;This work is too big to take into the 1.3 beta right now. We&apos;ll revisit for a future release.&lt;/p&gt;</comment>
                    <comment id="26399" author="ataggart" created="Thu, 28 Apr 2011 13:19:50 -0500"  >&lt;p&gt;To better facilitate understanding of the changes, I&apos;ve broken them up into two patches, each with a number of isolable, incremental commits:&lt;/p&gt;

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

&lt;p&gt;&lt;b&gt;prim-conversion.patch:&lt;/b&gt; Depends on the above. Alters the method/constructor resolution process:&lt;/p&gt;
&lt;ul&gt;
	&lt;li&gt;more consistent with java resolution, especially when calling pre-1.5 APIs&lt;/li&gt;
	&lt;li&gt;adds support for widening conversion of primitive numerics of the same category (this is more strict than java, and more clojuresque)&lt;/li&gt;
	&lt;li&gt;adds support for wildcard matches at compile-time (i.e., you don&apos;t need to type-hint every arg to avoid reflection).&lt;/li&gt;
&lt;/ul&gt;


&lt;p&gt;This also provides a base to add further features, e.g., &lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-666&quot; title=&quot;Add support for Big* numeric types to Reflector&quot;&gt;CLJ-666&lt;/a&gt;.&lt;/p&gt;</comment>
                    <comment id="26406" author="ataggart" created="Fri, 29 Apr 2011 15:01:22 -0500"  >&lt;p&gt;It&apos;s documented in situ, but here are the conversion rules that the reflector uses to find methods:&lt;/p&gt;


&lt;ol&gt;
	&lt;li&gt;By Type:
	&lt;ul&gt;
		&lt;li&gt;object to ancestor type&lt;/li&gt;
		&lt;li&gt;primitive to a wider primitive of the same numeric category (new)&lt;/li&gt;
	&lt;/ul&gt;
	&lt;/li&gt;
	&lt;li&gt;Boxing:
	&lt;ul&gt;
		&lt;li&gt;boxed number to its primitive&lt;/li&gt;
		&lt;li&gt;boxed number to a wider primitive of the same numeric category (new for Short and Byte args)&lt;/li&gt;
		&lt;li&gt;primitive to its boxed value&lt;/li&gt;
		&lt;li&gt;primitive to Number or Object (new)&lt;/li&gt;
	&lt;/ul&gt;
	&lt;/li&gt;
	&lt;li&gt;Casting:
	&lt;ul&gt;
		&lt;li&gt;long to int&lt;/li&gt;
		&lt;li&gt;double to float&lt;/li&gt;
	&lt;/ul&gt;
	&lt;/li&gt;
&lt;/ol&gt;
</comment>
                    <comment id="26428" author="ataggart" created="Tue, 10 May 2011 15:13:33 -0500"  >&lt;p&gt;prim-conversion-update-1.patch applies to current master.&lt;/p&gt;</comment>
                    <comment id="26429" author="ataggart" created="Wed, 11 May 2011 14:15:13 -0500"  >&lt;p&gt;Created &lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-792&quot; title=&quot;Refactor method resolution code out of Compiler and into Reflector&quot;&gt;CLJ-792&lt;/a&gt; for the reflector reorg.&lt;/p&gt;</comment>
                    <comment id="27753" author="stuart.sierra" created="Fri, 17 Feb 2012 14:29:42 -0600"  >&lt;p&gt;prim-conversion-update-1.patch does not apply as of f5bcf64. &lt;/p&gt;

&lt;p&gt;Is &lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-792&quot; title=&quot;Refactor method resolution code out of Compiler and into Reflector&quot;&gt;CLJ-792&lt;/a&gt; now a prerequisite of this ticket?&lt;/p&gt;</comment>
                    <comment id="27758" author="ataggart" created="Fri, 17 Feb 2012 15:15:17 -0600"  >&lt;p&gt;Yes, after the original patch was deemed &quot;too big&quot;.&lt;/p&gt;

&lt;p&gt;After this much time with no action from TPTB, feel free to kill both tickets.&lt;/p&gt;</comment>
                    <comment id="27778" author="jafingerhut" created="Mon, 20 Feb 2012 14:04:42 -0600"  >&lt;p&gt;Again, not sure if this is any help, but I&apos;ve tested starting from Clojure head as of Feb 20, 2012, applying clj-792-reorg-reflector-patch2.txt attached to &lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-792&quot; title=&quot;Refactor method resolution code out of Compiler and into Reflector&quot;&gt;CLJ-792&lt;/a&gt;, and then applying clj-445-prim-conversion-update-2-patch.txt attached to this ticket, and the result compiles and passes all but 2 tests.  I don&apos;t know whether those failures are easy to fix or not, or whether issues may have been introduced with these patches.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="10932" name="clj-445-prim-conversion-update-2-patch.txt" size="36531" author="jafingerhut" created="Mon, 20 Feb 2012 14:04:42 -0600" />
                    <attachment id="10205" name="prim-conversion.patch" size="36375" author="ataggart" created="Fri, 29 Apr 2011 06:43:21 -0500" />
                    <attachment id="10225" name="prim-conversion-update-1.patch" size="36473" author="ataggart" created="Tue, 10 May 2011 15:13:33 -0500" />
                    <attachment id="10203" name="reorg-reflector.patch" size="73345" author="ataggart" created="Thu, 28 Apr 2011 13:19:50 -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>
                                                                                                            </customfields>
    </item>
</channel>
</rss>