<!--
RSS generated by JIRA (4.4#649-r158309) at Thu May 23 15:16:28 CDT 2013

It is possible to restrict the fields that are returned in this document by specifying the 'field' parameter in your request.
For example, to request only the issue key and summary add field=key&field=summary to the URL of your request.
For example:
http://dev.clojure.org/jira/sr/jira.issueviews:searchrequest-xml/temp/SearchRequest.xml?jqlQuery=project+%3D+CLJ+AND+status+%3D+%22In+Progress%22+ORDER+BY+priority+DESC&tempMax=1000&field=key&field=summary
-->
<!-- If you wish to do custom client-side styling of RSS, uncomment this:
<?xml-stylesheet href="http://dev.clojure.org/jira/styles/jiraxml2html.xsl" type="text/xsl"?>
-->
<rss version="0.92">
    <channel>
        <title>Clojure JIRA</title>
        <link>http://dev.clojure.org/jira/secure/IssueNavigator.jspa?reset=true&amp;jqlQuery=project+%3D+CLJ+AND+status+%3D+%22In+Progress%22+ORDER+BY+priority+DESC</link>
        <description>An XML representation of a search request</description>
                <language>en-us</language>
                        <issue start="0" end="13" total="13"/>
                <build-info>
            <version>4.4</version>
            <build-number>649</build-number>
            <build-date>25-07-2011</build-date>
        </build-info>
<item>
            <title>[CLJ-113] GC Issue 109:  RT.load&apos;s &quot;don&apos;t load if already loaded&quot; mechanism breaks &quot;:reload-all&quot;</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-113</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 scgilardi, Apr 24, 2009

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

&lt;span class=&quot;code-quote&quot;&gt;&quot;require&quot;&lt;/span&gt; and &lt;span class=&quot;code-quote&quot;&gt;&quot;use&quot;&lt;/span&gt; support a &lt;span class=&quot;code-quote&quot;&gt;&quot;:reload-all&quot;&lt;/span&gt; flag that is intended to  
cause the specified libs to be reloaded along with all libs on which  
they directly or indirectly depend. This is implemented by temporarily  
binding a &lt;span class=&quot;code-quote&quot;&gt;&quot;loaded-libs&quot;&lt;/span&gt; &lt;span class=&quot;code-keyword&quot;&gt;var&lt;/span&gt; to the empty set and then loading the  
specified libs.

AOT compilation added another &lt;span class=&quot;code-quote&quot;&gt;&quot;already loaded&quot;&lt;/span&gt; mechanism to  
clojure.lang.RT.load() which is currently not sensitive to a &quot;reload-
all&quot; being in progress and breaks its operation in the following &lt;span class=&quot;code-keyword&quot;&gt;case&lt;/span&gt;:

        A, B, and C are libs
        A depends on B. (via :require in its ns form)
        B depends on C. (via :require in its ns form)
        B has been compiled (B.class is on classpath)

        At the repl I &lt;span class=&quot;code-quote&quot;&gt;&quot;require&quot;&lt;/span&gt; A which loads A, B, and C (either from
class files or clj files)
        I modify C.clj
        At the repl I &lt;span class=&quot;code-quote&quot;&gt;&quot;require&quot;&lt;/span&gt; A with the :reload-all flag, intending to  
pick up the changes to C
        C is not reloaded because RT.load() skips loading B: B.class
exists, is already loaded, and B.clj hasn&apos;t changed since it was compiled.


What is the expected output? What &lt;span class=&quot;code-keyword&quot;&gt;do&lt;/span&gt; you see instead?

I expect :reload-all to be effective. It isn&apos;t.

What version are you using?

svn 1354, 1.0.0RC1

Was &lt;span class=&quot;code-keyword&quot;&gt;this&lt;/span&gt; discussed on the group? If so, please provide a link to the
discussion:

http:&lt;span class=&quot;code-comment&quot;&gt;//groups.google.com/group/clojure/browse_frm/thread/9bbc290321fd895f/e6a967250021462a#e6a967250021462a
&lt;/span&gt;
Please provide any additional information below.

I&apos;ll upload a patch soon that creates a &lt;span class=&quot;code-quote&quot;&gt;&quot;*reload-all*&quot;&lt;/span&gt; &lt;span class=&quot;code-keyword&quot;&gt;var&lt;/span&gt; with a  
root binding of nil and code to bind it to &lt;span class=&quot;code-keyword&quot;&gt;true&lt;/span&gt; when the current  
thread has a :reload-all call pending. When *reload-all* is &lt;span class=&quot;code-keyword&quot;&gt;true&lt;/span&gt;,  
RT.load() will (re)load all libs from their &lt;span class=&quot;code-quote&quot;&gt;&quot;.clj&quot;&lt;/span&gt; files even &lt;span class=&quot;code-keyword&quot;&gt;if&lt;/span&gt;  
they&apos;re already loaded.

The fix &lt;span class=&quot;code-keyword&quot;&gt;for&lt;/span&gt; &lt;span class=&quot;code-keyword&quot;&gt;this&lt;/span&gt; may need to be coordinated with a fix &lt;span class=&quot;code-keyword&quot;&gt;for&lt;/span&gt; issue #3.&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;</description>
                <environment></environment>
            <key id="13510">CLJ-113</key>
            <summary>GC Issue 109:  RT.load&apos;s &quot;don&apos;t load if already loaded&quot; mechanism breaks &quot;:reload-all&quot;</summary>
                <type id="1" iconUrl="http://dev.clojure.org/jira/images/icons/bug.gif">Defect</type>
                                        <status id="3" iconUrl="http://dev.clojure.org/jira/images/icons/status_inprogress.gif">In Progress</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="scgilardi">Stephen C. Gilardi</assignee>
                                <reporter username="-1">None</reporter>
                        <labels>
                    </labels>
                <created>Wed, 17 Jun 2009 14:07:00 -0500</created>
                <updated>Tue, 9 Aug 2011 20:31:28 -0500</updated>
                                                    <fixVersion>Approved Backlog</fixVersion>
                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                        <comments>
                    <comment id="22796" author="importer" created="Tue, 24 Aug 2010 03:45:00 -0500"  >&lt;p&gt;Converted from &lt;a href=&quot;http://www.assembla.com/spaces/clojure/tickets/113&quot;&gt;http://www.assembla.com/spaces/clojure/tickets/113&lt;/a&gt;&lt;/p&gt;</comment>
                    <comment id="22797" author="importer" created="Tue, 24 Aug 2010 03: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="22798" author="importer" created="Tue, 24 Aug 2010 03: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="26713" author="hiredman" created="Mon, 8 Aug 2011 19:40:02 -0500"  >&lt;p&gt;seems like the code that is emitted in the static init for namespace classes could be emitted into a init_ns() static method and the static init could call init_ns(). then RT.load could call init_ns() to get the behavior of reloading an AOT compiled namespace. &lt;/p&gt;</comment>
                    <comment id="26715" author="hiredman" created="Tue, 9 Aug 2011 20:31:28 -0500"  >&lt;p&gt;looking at the compiler it looks like most of what I mentioned above is already implemented, just need RT to reflectively call load() on the namespace class in the right place&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-326] add :as-of option to refer</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-326</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;Discussed here: &lt;a href=&quot;http://groups.google.com/group/clojure-dev/msg/74af612909dcbe56&quot;&gt;http://groups.google.com/group/clojure-dev/msg/74af612909dcbe56&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;:as-of allows library authors to specify a known subset of vars to refer from clojure (or &lt;b&gt;any other library&lt;/b&gt; which would use :added metadata).&lt;/p&gt;

&lt;p&gt;(ns foo (:refer-clojure :as-of &quot;1.1&quot;)) is equivalent to (ns foo (:refer-clojure :only &lt;span class=&quot;error&quot;&gt;&amp;#91;public-documented-vars-which-already-existed-in-1.1&amp;#93;&lt;/span&gt;))&lt;/p&gt;</description>
                <environment></environment>
            <key id="13723">CLJ-326</key>
            <summary>add :as-of option to refer</summary>
                <type id="4" iconUrl="http://dev.clojure.org/jira/images/icons/improvement.gif">Enhancement</type>
                                        <status id="3" iconUrl="http://dev.clojure.org/jira/images/icons/status_inprogress.gif">In Progress</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="cgrand">Christophe Grand</assignee>
                                <reporter username="-1">None</reporter>
                        <labels>
                    </labels>
                <created>Fri, 30 Apr 2010 02:49:00 -0500</created>
                <updated>Tue, 24 Aug 2010 10:19:00 -0500</updated>
                                                    <fixVersion>Approved Backlog</fixVersion>
                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                        <comments>
                    <comment id="23803" author="importer" created="Tue, 24 Aug 2010 10:19:00 -0500"  >&lt;p&gt;Converted from &lt;a href=&quot;http://www.assembla.com/spaces/clojure/tickets/326&quot;&gt;http://www.assembla.com/spaces/clojure/tickets/326&lt;/a&gt;&lt;br/&gt;
Attachments:&lt;br/&gt;
add-as-of-to-refer.patch - &lt;a href=&quot;https://www.assembla.com/spaces/clojure/documents/a8SumUvcOr37SmeJe5cbLA/download/a8SumUvcOr37SmeJe5cbLA&quot;&gt;https://www.assembla.com/spaces/clojure/documents/a8SumUvcOr37SmeJe5cbLA/download/a8SumUvcOr37SmeJe5cbLA&lt;/a&gt;&lt;/p&gt;</comment>
                    <comment id="23804" author="importer" created="Tue, 24 Aug 2010 10:19:00 -0500"  >&lt;p&gt;cgrand said: [&lt;a href=&quot;file:a8SumUvcOr37SmeJe5cbLA&quot;&gt;file:a8SumUvcOr37SmeJe5cbLA&lt;/a&gt;]: requires application of #325&lt;/p&gt;</comment>
                    <comment id="23805" author="importer" created="Tue, 24 Aug 2010 10:19:00 -0500"  >&lt;p&gt;richhickey said: Do we still need this?&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="10013">Test</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-130] Namespace metadata lost in AOT compile</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-130</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;For example, the namespace @clojure.contrib.def@ has metadata for doc and author.&lt;/p&gt;

&lt;p&gt;We see this when we load the file directly from source:&lt;br/&gt;
&amp;lt;pre&amp;gt;&lt;br/&gt;
&amp;lt;code&amp;gt;&lt;br/&gt;
 tom@goya:~/src/clj$ java -cp clojure/clojure.jar:clojure-contrib/src clojure.lang.Repl&lt;br/&gt;
 Clojure 1.1.0-alpha-SNAPSHOT&lt;br/&gt;
 user=&amp;gt; (load &quot;clojure/contrib/def&quot;)&lt;br/&gt;
 nil&lt;br/&gt;
 user=&amp;gt; (find-ns &apos;clojure.contrib.def)     &lt;br/&gt;
 #&amp;lt;Namespace clojure.contrib.def&amp;gt;&lt;br/&gt;
 user=&amp;gt; ^(find-ns &apos;clojure.contrib.def)&lt;br/&gt;
 {:author &quot;Stephen C. Gilardi&quot;, :doc &quot;def.clj provides variants of def that make including doc strings and\nmaking private definitions more succinct.&quot;}&lt;br/&gt;
 user=&amp;gt; &lt;br/&gt;
&amp;lt;/code&amp;gt;&lt;br/&gt;
&amp;lt;/pre&amp;gt;&lt;/p&gt;

&lt;p&gt;But if we load the file from the jar where it&apos;s been compiled, the metadata is lost:&lt;br/&gt;
&amp;lt;pre&amp;gt;&lt;br/&gt;
&amp;lt;code&amp;gt;&lt;br/&gt;
 tom@goya:~/src/clj$ java -cp clojure/clojure.jar:clojure-contrib/clojure-contrib.jar clojure.lang.Repl&lt;br/&gt;
 Clojure 1.1.0-alpha-SNAPSHOT&lt;br/&gt;
 user=&amp;gt; (use &apos;clojure.contrib.def)&lt;br/&gt;
 nil&lt;br/&gt;
 user=&amp;gt; (find-ns &apos;clojure.contrib.def)&lt;br/&gt;
 #&amp;lt;Namespace clojure.contrib.def&amp;gt;&lt;br/&gt;
 user=&amp;gt; ^(find-ns &apos;clojure.contrib.def)&lt;br/&gt;
 nil&lt;br/&gt;
 user=&amp;gt; &lt;br/&gt;
&amp;lt;/code&amp;gt;&lt;br/&gt;
&amp;lt;/pre&amp;gt;&lt;/p&gt;

&lt;p&gt;Even if we use @load@, we don&apos;t see metadata on the item:&lt;br/&gt;
&amp;lt;pre&amp;gt;&lt;br/&gt;
&amp;lt;code&amp;gt;&lt;br/&gt;
 tom@goya:~/src/clj$ java -cp clojure/clojure.jar:clojure-contrib/clojure-contrib.jar clojure.lang.Repl&lt;br/&gt;
 Clojure 1.1.0-alpha-SNAPSHOT&lt;br/&gt;
 user=&amp;gt; (load &quot;clojure/contrib/def&quot;)&lt;br/&gt;
 nil&lt;br/&gt;
 user=&amp;gt; (find-ns &apos;clojure.contrib.def)&lt;br/&gt;
 #&amp;lt;Namespace clojure.contrib.def&amp;gt;&lt;br/&gt;
 user=&amp;gt; ^(find-ns &apos;clojure.contrib.def)&lt;br/&gt;
 nil&lt;br/&gt;
 user=&amp;gt; &lt;br/&gt;
&amp;lt;/code&amp;gt;&lt;br/&gt;
&amp;lt;/pre&amp;gt;&lt;/p&gt;


&lt;p&gt;The jar isn&apos;t the problem, for if we use the slim jar (without the AOT&lt;br/&gt;
class files), we see that the metadata is fine: &lt;br/&gt;
&amp;lt;pre&amp;gt;&lt;br/&gt;
&amp;lt;code&amp;gt;&lt;br/&gt;
 tom@goya:~/src/clj$ java -cp clojure/clojure.jar:clojure-contrib/clojure-contrib-slim.jar clojure.lang.Repl&lt;br/&gt;
 Clojure 1.1.0-alpha-SNAPSHOT&lt;br/&gt;
 user=&amp;gt; (use &apos;clojure.contrib.def)&lt;br/&gt;
 nil&lt;br/&gt;
 user=&amp;gt; (find-ns &apos;clojure.contrib.def)&lt;br/&gt;
 #&amp;lt;Namespace clojure.contrib.def&amp;gt;&lt;br/&gt;
 user=&amp;gt; ^(find-ns &apos;clojure.contrib.def)&lt;br/&gt;
 {:author &quot;Stephen C. Gilardi&quot;, :doc &quot;def.clj provides variants of def that make including doc strings and\nmaking private definitions more succinct.&quot;}&lt;br/&gt;
 user=&amp;gt; &lt;br/&gt;
&amp;lt;/code&amp;gt;&lt;br/&gt;
&amp;lt;/pre&amp;gt;&lt;/p&gt;

&lt;p&gt;This seems to be true usually, but not always. For example the&lt;br/&gt;
metadata on the pretty print namespace is just fine from the AOT version:&lt;br/&gt;
&amp;lt;pre&amp;gt;&lt;br/&gt;
&amp;lt;code&amp;gt;&lt;br/&gt;
 tom@goya:~/src/clj$ java -cp clojure/clojure.jar:clojure-contrib/clojure-contrib.jar clojure.lang.Repl&lt;br/&gt;
 Clojure 1.1.0-alpha-SNAPSHOT&lt;br/&gt;
 user=&amp;gt; (use &apos;clojure.contrib.pprint)&lt;br/&gt;
 nil&lt;br/&gt;
 user=&amp;gt; (find-ns &apos;clojure.contrib.pprint)&lt;br/&gt;
 #&amp;lt;Namespace clojure.contrib.pprint&amp;gt;&lt;br/&gt;
 user=&amp;gt; ^(find-ns &apos;clojure.contrib.pprint)&lt;br/&gt;
 {:author &quot;Tom Faulhaber&quot;, :doc &quot;This module comprises two elements:\n1) A pretty printer for Clojure data structures, implemented in the function \&quot;pprint\&quot;\n2) A Common Lisp compatible format function, implemented as \&quot;cl-format\&quot; because\n   Clojure is using the name \&quot;format\&quot; for its own format.\n\nComplete documentation is available on the wiki at the contrib google code site.&quot;, :see-also [&lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;quot;PrettyPrinting&amp;quot; &amp;quot;Documentation for the pretty printer&amp;quot;&amp;#93;&lt;/span&gt; &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;quot;CommonLispFormat&amp;quot; &amp;quot;Documentation for Common Lisp format function&amp;quot;&amp;#93;&lt;/span&gt;]}&lt;br/&gt;
 user=&amp;gt; &lt;br/&gt;
&amp;lt;/code&amp;gt;&lt;br/&gt;
&amp;lt;/pre&amp;gt;&lt;/p&gt;</description>
                <environment></environment>
            <key id="13527">CLJ-130</key>
            <summary>Namespace metadata lost in AOT compile</summary>
                <type id="1" iconUrl="http://dev.clojure.org/jira/images/icons/bug.gif">Defect</type>
                                        <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="-1">None</reporter>
                        <labels>
                    </labels>
                <created>Fri, 19 Jun 2009 00:47:00 -0500</created>
                <updated>Fri, 3 Dec 2010 10:48:15 -0600</updated>
                                                    <fixVersion>Backlog</fixVersion>
                                        <due></due>
                    <votes>0</votes>
                        <watches>3</watches>
                        <comments>
                    <comment id="22905" author="importer" created="Tue, 24 Aug 2010 06:45:00 -0500"  >&lt;p&gt;Converted from &lt;a href=&quot;http://www.assembla.com/spaces/clojure/tickets/130&quot;&gt;http://www.assembla.com/spaces/clojure/tickets/130&lt;/a&gt;&lt;/p&gt;</comment>
                    <comment id="22906" author="importer" created="Tue, 24 Aug 2010 06:45:00 -0500"  >&lt;p&gt;richhickey said: Updating tickets (#127, #128, #129, #130)&lt;/p&gt;</comment>
                    <comment id="22907" author="importer" created="Tue, 24 Aug 2010 06:45:00 -0500"  >&lt;p&gt;juergenhoetzel said: This is still a issue on &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.2.0-master-SNAPSHOT&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;Any progress, hints? I prefer interactive documentiation via slime/repl&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-129] Add documentation to sorted-set-by detailing how the provided comparator may change set membership semantics</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-129</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;To start, let&apos;s look at some simple default sorted-set behaviour (which uses PersistentHashMap via PersistentHashSet, and therefore uses equality/hashCode to determine identity):&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; (sorted-set [1 2] [-5 10] [1 5])
#{[-5 10] [1 2] [1 5]}
&amp;lt;/code&amp;gt;&amp;lt;/pre&amp;gt;

sorted-set-by uses PersistentTreeMap via PersistentTreeSet though, which implies that the comparator provided to sorted-set-by will be used to determine identity, and therefore member in the set.  This can lead to (IMO) non-intuitive behaviour:

&amp;lt;pre&amp;gt;&amp;lt;code&amp;gt;
user=&amp;gt; (sorted-set-by #(&amp;gt; (first %) (first %2)) [1 2] [-5 10] [1 5])
#{[1 2] [-5 10]}&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;Notice that because the provided comparison fn determines that &lt;span class=&quot;error&quot;&gt;&amp;#91;1 2&amp;#93;&lt;/span&gt; and &lt;span class=&quot;error&quot;&gt;&amp;#91;1 5&amp;#93;&lt;/span&gt; have the same sort order, the latter value is considered identical to the former, and not included in the set.  This behaviour could be very handy, but is also likely to cause confusion when what the user almost certainly wants is to maintain the membership semantics of the original set (e.g. relying upon equality/hashCode), but only modify the ordering.&lt;/p&gt;

&lt;p&gt;(BTW, yes, I know there&apos;s far easier ways to get the order I&apos;m indicating above over a set of vectors thanks to vectors being comparable via the compare fn.  The examples are only meant to be illustrative.  The same non-intuitive result would occur, with no easy fallback (like the &apos;compare&apos; fn when working with vectors) when the members of the set are non-Comparable Java object, and the comparator provided to sorted-set-by is defining a sort over some values returned by method calls into those objects.)&lt;/p&gt;

&lt;p&gt;I&apos;d be happy to change the docs for sorted-set-by, but I suspect that there are others who could encapsulate what&apos;s going on here more correctly and more concisely than I.&lt;/p&gt;</description>
                <environment></environment>
            <key id="13526">CLJ-129</key>
            <summary>Add documentation to sorted-set-by detailing how the provided comparator may change set membership semantics</summary>
                <type id="4" iconUrl="http://dev.clojure.org/jira/images/icons/improvement.gif">Enhancement</type>
                                        <status id="3" iconUrl="http://dev.clojure.org/jira/images/icons/status_inprogress.gif">In Progress</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="cemerick">Chas Emerick</assignee>
                                <reporter username="-1">None</reporter>
                        <labels>
                    </labels>
                <created>Thu, 18 Jun 2009 16:14:00 -0500</created>
                <updated>Tue, 24 Aug 2010 07:45:00 -0500</updated>
                                                    <fixVersion>Backlog</fixVersion>
                                        <due></due>
                    <votes>0</votes>
                        <watches>1</watches>
                        <comments>
                    <comment id="22903" author="importer" created="Tue, 24 Aug 2010 07:45:00 -0500"  >&lt;p&gt;Converted from &lt;a href=&quot;http://www.assembla.com/spaces/clojure/tickets/129&quot;&gt;http://www.assembla.com/spaces/clojure/tickets/129&lt;/a&gt;&lt;/p&gt;</comment>
                    <comment id="22904" author="importer" created="Tue, 24 Aug 2010 07:45:00 -0500"  >&lt;p&gt;richhickey said: Updating tickets (#127, #128, #129, #130)&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-42] GC Issue 38: When using AOT compilation, &quot;load&quot;ed files are not reloaded on (require :reload &apos;name.space)</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-42</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 m...@kotka.de, Jan 07, 2009
What (small set of) steps will reproduce the problem?

1. Create a file src/foo.clj

cat &amp;gt;src/foo.clj &amp;lt;&amp;lt;EOF
(ns foo (:load &lt;span class=&quot;code-quote&quot;&gt;&quot;bar&quot;&lt;/span&gt;))
EOF

2. Create a file src/bar.clj

cat &amp;gt;src/bar.clj &amp;lt;&amp;lt;EOF
(clojure.core/in-ns &apos;foo)
(def x 8)
EOF

3. Start Clojure Repl: java -cp src:classes clojure.main -r

4. Compile the namespace.

user=&amp;gt; (compile &apos;foo)
foo

5. Require the namespace
user=&amp;gt; (require :reload-all :verbose &apos;foo)
(clojure.core/load &lt;span class=&quot;code-quote&quot;&gt;&quot;/foo&quot;&lt;/span&gt;)
(clojure.core/load &lt;span class=&quot;code-quote&quot;&gt;&quot;/bar&quot;&lt;/span&gt;)

What is the expected output? What &lt;span class=&quot;code-keyword&quot;&gt;do&lt;/span&gt; you see instead?

6. Re-Require the namespace

user=&amp;gt; (require :reload-all :verbose &apos;foo)
(clojure.core/load &lt;span class=&quot;code-quote&quot;&gt;&quot;/foo&quot;&lt;/span&gt;)

Only the &lt;span class=&quot;code-quote&quot;&gt;&quot;master&quot;&lt;/span&gt; file is loaded, but not the bar file.
Expected would have been to also load the bar file.
Changes to bar.clj are not reflected, and depending
on the setting (eg. using multimethods in foo from
a different namespace) code may be corrupted.

What version are you using?

SVN rev. 1195&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;</description>
                <environment></environment>
            <key id="13439">CLJ-42</key>
            <summary>GC Issue 38: When using AOT compilation, &quot;load&quot;ed files are not reloaded on (require :reload &apos;name.space)</summary>
                <type id="1" iconUrl="http://dev.clojure.org/jira/images/icons/bug.gif">Defect</type>
                                        <status id="3" iconUrl="http://dev.clojure.org/jira/images/icons/status_inprogress.gif">In Progress</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="scgilardi">Stephen C. Gilardi</assignee>
                                <reporter username="-1">None</reporter>
                        <labels>
                    </labels>
                <created>Wed, 17 Jun 2009 15:15:00 -0500</created>
                <updated>Tue, 24 Aug 2010 06:44:00 -0500</updated>
                                                    <fixVersion>Approved Backlog</fixVersion>
                                        <due></due>
                    <votes>0</votes>
                        <watches>1</watches>
                        <comments>
                    <comment id="22573" author="importer" created="Tue, 24 Aug 2010 06:44:00 -0500"  >&lt;p&gt;Converted from &lt;a href=&quot;http://www.assembla.com/spaces/clojure/tickets/42&quot;&gt;http://www.assembla.com/spaces/clojure/tickets/42&lt;/a&gt;&lt;/p&gt;</comment>
                    <comment id="22574" author="importer" created="Tue, 24 Aug 2010 06:44: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="22575" author="importer" created="Tue, 24 Aug 2010 06:44:00 -0500"  >&lt;p&gt;richhickey said: Updating tickets (#42, #71)&lt;/p&gt;</comment>
                    <comment id="22576" author="importer" created="Tue, 24 Aug 2010 06:44: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>
                </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-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>

<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;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, 12 Apr 2013 09:52:24 -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>
                </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="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>
                                                                                    <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-84] GC Issue 81:    compile gen-class fail when class returns self</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-84</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 davidhaub, Feb 14, 2009

When attempting to compile the following program, clojure fails with a
ClassNotFoundException.  It occurs because one of the methods returns the
same class that is being generated.  If the returnMe method below is
changed to &lt;span class=&quot;code-keyword&quot;&gt;return&lt;/span&gt; an &lt;span class=&quot;code-object&quot;&gt;Object&lt;/span&gt;, the compile succeeds.

Beware when testing! If the classpath contains a class file (say from a
prior successful build when the returnMe method was changed to &lt;span class=&quot;code-keyword&quot;&gt;return&lt;/span&gt; an
object), the compile will succeed.  Always clear out the
clojure.compile.path prior to compiling.

;badgenclass.clj
(ns badgenclass
  (:gen-class
     :state state
     :methods
     [[returnMe [] badgenclass]]
     :init init))
(defn -init []
  [[] nil])

(defn -returnMe [&lt;span class=&quot;code-keyword&quot;&gt;this&lt;/span&gt;]
  &lt;span class=&quot;code-keyword&quot;&gt;this&lt;/span&gt;)

#!/bin/sh
rm -rf classes
mkdir classes
java -cp lib/clojure.jar:classes:. -Dclojure.compile.path=classes \
clojure.lang.Compile badgenclass


Comment 1 by chouser, Mar 07, 2009

Attached is a patch that accepts strings or symbols &lt;span class=&quot;code-keyword&quot;&gt;for&lt;/span&gt; parameter and &lt;span class=&quot;code-keyword&quot;&gt;return&lt;/span&gt; class
names, and generates the appropriate bytecode without calling &lt;span class=&quot;code-object&quot;&gt;Class&lt;/span&gt;/forName.  It
fixes &lt;span class=&quot;code-keyword&quot;&gt;this&lt;/span&gt; issue, but because &apos;ns&apos; doesn&apos;t resolve :gen-class&apos;s arguments, class
names aren&apos;t checked as early anymore.  :gen-class-created classes with invalid
parameter or &lt;span class=&quot;code-keyword&quot;&gt;return&lt;/span&gt; types can even be instantiated, and no error will be reported
until the broken method is called.

One possible alternative would be to call &lt;span class=&quot;code-object&quot;&gt;Class&lt;/span&gt;/forName on any symbols given, but
allow strings to use the method given by &lt;span class=&quot;code-keyword&quot;&gt;this&lt;/span&gt; patch.  To &lt;span class=&quot;code-keyword&quot;&gt;return&lt;/span&gt; your own type, you&apos;d
need a method defined like:

  [returnMe [] &lt;span class=&quot;code-quote&quot;&gt;&quot;badgenclass&quot;&lt;/span&gt;]

Any thoughts?&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;</description>
                <environment></environment>
            <key id="13481">CLJ-84</key>
            <summary>GC Issue 81:    compile gen-class fail when class returns self</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="richhickey">Rich Hickey</assignee>
                                <reporter username="importer">Assembla Importer</reporter>
                        <labels>
                    </labels>
                <created>Wed, 17 Jun 2009 22:30:00 -0500</created>
                <updated>Fri, 10 Dec 2010 09:30:52 -0600</updated>
                                    <version>Approved Backlog</version>
                                <fixVersion>Approved Backlog</fixVersion>
                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                        <comments>
                    <comment id="22702" 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/84&quot;&gt;http://www.assembla.com/spaces/clojure/tickets/84&lt;/a&gt;&lt;br/&gt;
Attachments:&lt;br/&gt;
genclass-allow-unresolved-classname.patch - &lt;a href=&quot;https://www.assembla.com/spaces/clojure/documents/cWS6Aww30r3RbzeJe5afGb/download/cWS6Aww30r3RbzeJe5afGb&quot;&gt;https://www.assembla.com/spaces/clojure/documents/cWS6Aww30r3RbzeJe5afGb/download/cWS6Aww30r3RbzeJe5afGb&lt;/a&gt;&lt;/p&gt;</comment>
                    <comment id="22703" author="importer" created="Tue, 28 Sep 2010 17:09:00 -0500"  >&lt;p&gt;oranenj said: [&lt;a href=&quot;file:cWS6Aww30r3RbzeJe5afGb&quot;&gt;file:cWS6Aww30r3RbzeJe5afGb&lt;/a&gt;]: on comment 1&lt;/p&gt;</comment>
                    <comment id="22704" author="importer" created="Tue, 28 Sep 2010 17:09: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="25904" author="stu" created="Sat, 30 Oct 2010 11:58:08 -0500"  >&lt;p&gt;The approach take in the initial patch (delaying resolution of symbols into classes) is fine: gen-class makes no promise about when this happens, and the dynamic approach feels more consistent with Clojure. I think the proposed (but not implemented) use of string/symbol to control when class names are resolved is a bad idea: magical and not implied by the types.&lt;/p&gt;

&lt;p&gt;Needed:&lt;/p&gt;

&lt;ul&gt;
	&lt;li&gt;update the patch to apply cleanly&lt;/li&gt;
	&lt;li&gt;consider whether totype could live in clojure.reflect.java. (Beware load order dependencies.)&lt;/li&gt;
&lt;/ul&gt;
</comment>
                    <comment id="25910" author="chouser@n01se.net" created="Sat, 30 Oct 2010 21:29:59 -0500"  >&lt;p&gt;Wow, 18-month-old patch, back to haunt me for Halloway&apos;een&lt;/p&gt;

&lt;p&gt;So what does it mean that the assignee is Rich, but it&apos;s waiting on me?&lt;/p&gt;</comment>
                    <comment id="25915" author="stu" created="Mon, 1 Nov 2010 09:17:22 -0500"  >&lt;p&gt;I am using Approval = Incomplete plus Waiting On = Someone to let submitters know that there is feedback waiting, and that they can move the ticket forward by acting on it. The distinction is opportunity to contribute (something has been provided to let you move forward) vs. expectation of contribution. &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>chouser@n01se.net</customfieldvalue>
                </customfieldvalues>
            </customfield>
                            </customfields>
    </item>

<item>
            <title>[CLJ-69] GC Issue 66: Add &quot;keyset&quot; to Clojure; make .keySet for APersistentMap return IPersistentSet</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-69</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 wolfe.a.jason, Feb 04, 2009

Describe the feature/change.

Add &lt;span class=&quot;code-quote&quot;&gt;&quot;keyset&quot;&lt;/span&gt; to Clojure; make .keySet &lt;span class=&quot;code-keyword&quot;&gt;for&lt;/span&gt; APersistentMap &lt;span class=&quot;code-keyword&quot;&gt;return&lt;/span&gt; an
IPersistentSet

Was &lt;span class=&quot;code-keyword&quot;&gt;this&lt;/span&gt; discussed on the group? If so, please provide a link to the
discussion:

http:&lt;span class=&quot;code-comment&quot;&gt;//groups.google.com/group/clojure/browse_thread/thread/66e708e477ae992f/ff3d8d588068b60e?hl=en#ff3d8d588068b60e
&lt;/span&gt;
-----------------------------------------------------

A patch is attached.  Some notes:

I chose to add a &lt;span class=&quot;code-quote&quot;&gt;&quot;keyset&quot;&lt;/span&gt; function, rather than change the existing &lt;span class=&quot;code-quote&quot;&gt;&quot;keys&quot;&lt;/span&gt;,
so as to avoid breaking anything.

The corresponding RT.keyset function just calls .keySet on the argument.
I would have liked to have &lt;span class=&quot;code-quote&quot;&gt;&quot;keyset&quot;&lt;/span&gt; &lt;span class=&quot;code-keyword&quot;&gt;return&lt;/span&gt; an IPersistentSet even when
passed a (non-Clojure) java.util.Map, but &lt;span class=&quot;code-keyword&quot;&gt;this&lt;/span&gt; seems impossible to &lt;span class=&quot;code-keyword&quot;&gt;do&lt;/span&gt; in
sublinear time because of essentially the same limitation mentioned in the
above thread (the Map &lt;span class=&quot;code-keyword&quot;&gt;interface&lt;/span&gt; does not support getKey() or entryAt()) --
assuming, again, that &lt;span class=&quot;code-quote&quot;&gt;&quot;get&quot;&lt;/span&gt; is supposed to &lt;span class=&quot;code-keyword&quot;&gt;return&lt;/span&gt; the actual (identical?)
key in a set, and not just an .equal key.

I then changed the implementation of .keySet &lt;span class=&quot;code-keyword&quot;&gt;for&lt;/span&gt; APersistentMap to
essentially copy APersistentSet.  A more concise alternative would have
been to extend APersistentSet and override the .get method, but that made
me a bit nervous (since &lt;span class=&quot;code-keyword&quot;&gt;if&lt;/span&gt; APeristentSet changed &lt;span class=&quot;code-keyword&quot;&gt;this&lt;/span&gt; could &lt;span class=&quot;code-keyword&quot;&gt;break&lt;/span&gt;). 

Anyway, &lt;span class=&quot;code-keyword&quot;&gt;this&lt;/span&gt; is my first patch &lt;span class=&quot;code-keyword&quot;&gt;for&lt;/span&gt; the Java side of Clojure, and I&apos;m not
yet solid on the conventions and aesthetics, so
comments/questions/criticisms/requests &lt;span class=&quot;code-keyword&quot;&gt;for&lt;/span&gt; revisions are very welcome.&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;</description>
                <environment></environment>
            <key id="13466">CLJ-69</key>
            <summary>GC Issue 66: Add &quot;keyset&quot; to Clojure; make .keySet for APersistentMap return IPersistentSet</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="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="importer">Assembla Importer</reporter>
                        <labels>
                    </labels>
                <created>Wed, 17 Jun 2009 00:55:00 -0500</created>
                <updated>Fri, 10 Dec 2010 08:48:40 -0600</updated>
                                    <version>Approved Backlog</version>
                                <fixVersion>Approved Backlog</fixVersion>
                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                        <comments>
                    <comment id="22640" author="importer" created="Tue, 28 Sep 2010 07:00:00 -0500"  >&lt;p&gt;Converted from &lt;a href=&quot;http://www.assembla.com/spaces/clojure/tickets/69&quot;&gt;http://www.assembla.com/spaces/clojure/tickets/69&lt;/a&gt;&lt;br/&gt;
Attachments:&lt;br/&gt;
keyset.patch - &lt;a href=&quot;https://www.assembla.com/spaces/clojure/documents/dKgE6mw3Gr3O2PeJe5afGb/download/dKgE6mw3Gr3O2PeJe5afGb&quot;&gt;https://www.assembla.com/spaces/clojure/documents/dKgE6mw3Gr3O2PeJe5afGb/download/dKgE6mw3Gr3O2PeJe5afGb&lt;/a&gt;&lt;/p&gt;</comment>
                    <comment id="22641" author="importer" created="Tue, 28 Sep 2010 07:00:00 -0500"  >&lt;p&gt;oranenj said: [&lt;a href=&quot;file:dKgE6mw3Gr3O2PeJe5afGb&quot;&gt;file:dKgE6mw3Gr3O2PeJe5afGb&lt;/a&gt;]&lt;/p&gt;</comment>
                    <comment id="22642" author="importer" created="Tue, 28 Sep 2010 07:00: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="26003" author="stu" created="Fri, 3 Dec 2010 13:12:52 -0600"  >&lt;p&gt;patch not in correct format&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>
                                                                                                            </customfields>
    </item>

<item>
            <title>[CLJ-211] Support arbitrary functional destructuring via -&gt; and -&gt;&gt;</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-211</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;Support arbitrary functional destructuring, that is the use of&lt;br/&gt;
any function in any destructuring form to help unpack data in&lt;br/&gt;
arbitrary ways.&lt;/p&gt;

&lt;p&gt;The discussion began here:&lt;br/&gt;
&lt;a href=&quot;http://clojure-log.n01se.net/date/2009-11-17.html#09:31c&quot;&gt;http://clojure-log.n01se.net/date/2009-11-17.html#09:31c&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;The attached patch implements the spec described here:&lt;br/&gt;
&lt;a href=&quot;http://clojure-log.n01se.net/date/2009-11-17.html#10:50a&quot;&gt;http://clojure-log.n01se.net/date/2009-11-17.html#10:50a&lt;/a&gt;&lt;/p&gt;


&lt;p&gt;That is, the following examples would now work:&lt;/p&gt;

&lt;p&gt;user=&amp;gt; (let &lt;span class=&quot;error&quot;&gt;&amp;#91;(-&amp;gt; str a) 1&amp;#93;&lt;/span&gt; a)&lt;br/&gt;
&quot;1&quot;&lt;/p&gt;

&lt;p&gt;user=&amp;gt; (let [&lt;span class=&quot;error&quot;&gt;&amp;#91;a (-&amp;gt; str b) c&amp;#93;&lt;/span&gt; &lt;span class=&quot;error&quot;&gt;&amp;#91;1 2&amp;#93;&lt;/span&gt;] (list a b c))&lt;br/&gt;
(1 &quot;2&quot; nil)&lt;/p&gt;

&lt;p&gt;user=&amp;gt; (let [(-&amp;gt;&amp;gt; (map int) &lt;span class=&quot;error&quot;&gt;&amp;#91;a b&amp;#93;&lt;/span&gt;) &quot;ab&quot;] (list a b))&lt;br/&gt;
(97 98)&lt;/p&gt;</description>
                <environment></environment>
            <key id="13608">CLJ-211</key>
            <summary>Support arbitrary functional destructuring via -&gt; and -&gt;&gt;</summary>
                <type id="4" iconUrl="http://dev.clojure.org/jira/images/icons/improvement.gif">Enhancement</type>
                                <priority id="4" iconUrl="http://dev.clojure.org/jira/images/icons/priority_minor.gif">Minor</priority>
                    <status id="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="importer">Assembla Importer</reporter>
                        <labels>
                    </labels>
                <created>Tue, 17 Nov 2009 10:43:00 -0600</created>
                <updated>Fri, 10 Dec 2010 08:49:03 -0600</updated>
                                                    <fixVersion>Approved Backlog</fixVersion>
                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                        <comments>
                    <comment id="23273" author="importer" created="Tue, 28 Sep 2010 06:57:00 -0500"  >&lt;p&gt;Converted from &lt;a href=&quot;http://www.assembla.com/spaces/clojure/tickets/211&quot;&gt;http://www.assembla.com/spaces/clojure/tickets/211&lt;/a&gt;&lt;br/&gt;
Attachments:&lt;br/&gt;
destructuring-fns.diff - &lt;a href=&quot;https://www.assembla.com/spaces/clojure/documents/aHWQ_W06Kr3O89eJe5afGb/download/aHWQ_W06Kr3O89eJe5afGb&quot;&gt;https://www.assembla.com/spaces/clojure/documents/aHWQ_W06Kr3O89eJe5afGb/download/aHWQ_W06Kr3O89eJe5afGb&lt;/a&gt;&lt;/p&gt;</comment>
                    <comment id="23274" author="importer" created="Tue, 28 Sep 2010 06:57:00 -0500"  >&lt;p&gt;chouser@n01se.net said: [&lt;a href=&quot;file:aHWQ_W06Kr3O89eJe5afGb&quot;&gt;file:aHWQ_W06Kr3O89eJe5afGb&lt;/a&gt;]: &lt;span class=&quot;error&quot;&gt;&amp;#91;PATCH&amp;#93;&lt;/span&gt; Support -&amp;gt; and -&amp;gt;&amp;gt; in destructuring forms.&lt;/p&gt;</comment>
                    <comment id="23275" author="importer" created="Tue, 28 Sep 2010 06:57:00 -0500"  >&lt;p&gt;cgrand said: I think the current patch suffers from the problem described here &lt;a href=&quot;http://groups.google.com/group/clojure-dev/msg/80ba7fad2ff04708&quot;&gt;http://groups.google.com/group/clojure-dev/msg/80ba7fad2ff04708&lt;/a&gt; too.&lt;/p&gt;</comment>
                    <comment id="23276" author="importer" created="Tue, 28 Sep 2010 06:57:00 -0500"  >&lt;p&gt;richhickey said: so, don&apos;t use syntax-quote, just use clojure.core/-&amp;gt;&lt;/p&gt;</comment>
                    <comment id="23277" author="importer" created="Tue, 28 Sep 2010 06:57:00 -0500"  >&lt;p&gt;chouser@n01se.net said: Only -&amp;gt; and -&amp;gt;&amp;gt; are actually legal here anyway &amp;#8211; if you&apos;ve locally bound foo to -&amp;gt; there&apos;s not really any good reason to think (fn &lt;span class=&quot;error&quot;&gt;&amp;#91;(foo inc a)&amp;#93;&lt;/span&gt; a) should work.  And if you&apos;ve redefined -&amp;gt; or -&amp;gt;&amp;gt; to mean something else in your ns, do we need to catch that at compile time, or is it okay to emit the rearranged code and see what happens?&lt;/p&gt;

&lt;p&gt;In short, would &apos;#{&lt;del&gt;&amp;gt; -&amp;gt;&amp;gt; clojure.core/&lt;/del&gt;&amp;gt; clojure.core/-&amp;gt;&amp;gt;} be sufficient?&lt;/p&gt;</comment>
                    <comment id="23278" author="importer" created="Tue, 28 Sep 2010 06:57:00 -0500"  >&lt;p&gt;cgrand said: Only -&amp;gt; and -&amp;gt;&amp;gt; are legal here but what if they are aliased or shadowed? Instead of testing the symboil per se I would check, if:&lt;/p&gt;
&lt;ul&gt;
	&lt;li&gt;the symbol is not in &amp;amp;env&lt;/li&gt;
	&lt;li&gt;the symbol resolve to #&apos;clojure.core/&lt;del&gt;&amp;gt; or  #&apos;clojure.core/&lt;/del&gt;&amp;gt;&amp;gt;&lt;/li&gt;
&lt;/ul&gt;


&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;(when-not (&amp;amp;env (first b)) (#{#&apos;clojure.core/-&amp;gt; #&apos;clojure.core/-&amp;gt;&amp;gt;} (resolve (first b))))&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;but it requires to change destructure&apos;s sig to pass the env around&lt;/p&gt;</comment>
                    <comment id="26002" author="stu" created="Fri, 3 Dec 2010 13:03:07 -0600"  >&lt;p&gt;Rich: Are you assigned to this by accident? If so, please deassign yourself.&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>
                                                                                                            </customfields>
    </item>

<item>
            <title>[CLJ-291] (take-nth 0 coll) redux...</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-291</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;I dont seem to be able make the old ticket uninvalid so here goes&lt;br/&gt;
(take-nth 0 coll) causes (at least on Solaris) infinite space and time consumption&lt;br/&gt;
It&apos;s not a printout error as the following code causes the problem too&lt;/p&gt;

&lt;p&gt;(let [j 0&lt;br/&gt;
 firstprod (apply * (doall (map #(- 1 %) (take-nth j (:props mix)))))]) ; from my parameter update function&lt;/p&gt;

&lt;p&gt;I used jvisualvm and the jvm is doing some RNI call - no clojure code is running at all&lt;br/&gt;
If left alone it will crash the jvm with all heap space consumed&lt;br/&gt;
0 is an InvalidArgument for take-nth&lt;br/&gt;
I wouldnt mind if it produced an infinite lazy sequence of nils even though thats wrong&lt;br/&gt;
It doesnt do this though it actively destroys the JVM&lt;br/&gt;
Its a bug nasty destructive and it took me half a day to figure out what was going on&lt;br/&gt;
please let someone fix it!&lt;/p&gt;</description>
                <environment></environment>
            <key id="13688">CLJ-291</key>
            <summary>(take-nth 0 coll) redux...</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="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="importer">Assembla Importer</reporter>
                        <labels>
                    </labels>
                <created>Thu, 8 Apr 2010 06:29:00 -0500</created>
                <updated>Fri, 10 Dec 2010 08:50:19 -0600</updated>
                                                    <fixVersion>Approved Backlog</fixVersion>
                                        <due></due>
                    <votes>0</votes>
                        <watches>0</watches>
                        <comments>
                    <comment id="23615" author="importer" created="Sun, 17 Oct 2010 09:47:00 -0500"  >&lt;p&gt;Converted from &lt;a href=&quot;http://www.assembla.com/spaces/clojure/tickets/291&quot;&gt;http://www.assembla.com/spaces/clojure/tickets/291&lt;/a&gt;&lt;br/&gt;
Attachments:&lt;br/&gt;
fixbug291.diff - &lt;a href=&quot;https://www.assembla.com/spaces/clojure/documents/dfNhoS2Cir3543eJe5cbLA/download/dfNhoS2Cir3543eJe5cbLA&quot;&gt;https://www.assembla.com/spaces/clojure/documents/dfNhoS2Cir3543eJe5cbLA/download/dfNhoS2Cir3543eJe5cbLA&lt;/a&gt;&lt;/p&gt;</comment>
                    <comment id="23616" author="importer" created="Sun, 17 Oct 2010 09:47:00 -0500"  >&lt;p&gt;bhurt said: Before this bug gets marked as invalid as well, let me point out that the problem here is that (take-nth 0 any-list) is a meaningless construction- the only question is what to do when this happens.  IMHO, the correct behavior is to throw an exception.&lt;/p&gt;</comment>
                    <comment id="23617" author="importer" created="Sun, 17 Oct 2010 09:47:00 -0500"  >&lt;p&gt;ataggart said: [&lt;a href=&quot;file:dfNhoS2Cir3543eJe5cbLA&quot;&gt;file:dfNhoS2Cir3543eJe5cbLA&lt;/a&gt;]: throws IllegalArgumentException on negative step size&lt;/p&gt;</comment>
                    <comment id="25891" author="stu" created="Fri, 29 Oct 2010 10:36:34 -0500"  >&lt;p&gt;Does calling (take-nth 0 ...) cause the problem, or only realizing the result?&lt;/p&gt;</comment>
                    <comment id="25892" author="chouser@n01se.net" created="Fri, 29 Oct 2010 11:06:01 -0500"  >&lt;p&gt;I&apos;m not seeing a problem.  Calling take-nth and even partially consuming the seq it returns works fine for me:&lt;/p&gt;

&lt;p&gt;(take 5 (take-nth 0 &lt;span class=&quot;error&quot;&gt;&amp;#91;1 2 3&amp;#93;&lt;/span&gt;))&lt;br/&gt;
;=&amp;gt; (1 1 1 1 1)&lt;/p&gt;

&lt;p&gt;Note however that it is returning an infinite lazy seq.  The example in the issue description seems to include essentially (doall &amp;lt;infinite-lazy-seq&amp;gt;) which does blow the heap:&lt;/p&gt;

&lt;p&gt;(doall (range))&lt;/p&gt;

&lt;p&gt;This issue still strikes me as invalid.&lt;/p&gt;</comment>
                    <comment id="25893" author="richhickey" created="Fri, 29 Oct 2010 11:06:02 -0500"  >&lt;p&gt;(take-nth 0 ...) returns an infinite sequence of the first item:&lt;/p&gt;

&lt;p&gt;(take 12 (take-nth 0 &lt;span class=&quot;error&quot;&gt;&amp;#91;1 2 3&amp;#93;&lt;/span&gt;))&lt;br/&gt;
=&amp;gt; (1 1 1 1 1 1 1 1 1 1 1 1)&lt;/p&gt;

&lt;p&gt;Is something other than this happening on Solaris?&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>
                                                                                                            </customfields>
    </item>

<item>
            <title>[CLJ-304] contrib get-source no longer works with deftype</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-304</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;Now that deftype creates a class (but not a var), you can&apos;t use c.c.repl-utils/get-source on a deftype. Is there something we can do on the Clojure side to help this work again?&lt;/p&gt;</description>
                <environment></environment>
            <key id="13701">CLJ-304</key>
            <summary>contrib get-source no longer works with deftype</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="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="importer">Assembla Importer</reporter>
                        <labels>
                    </labels>
                <created>Tue, 20 Apr 2010 21:18:00 -0500</created>
                <updated>Fri, 3 Dec 2010 11:44:01 -0600</updated>
                                                    <fixVersion>Backlog</fixVersion>
                                        <due></due>
                    <votes>2</votes>
                        <watches>1</watches>
                        <comments>
                    <comment id="23670" author="importer" created="Tue, 24 Aug 2010 16:38:00 -0500"  >&lt;p&gt;Converted from &lt;a href=&quot;http://www.assembla.com/spaces/clojure/tickets/304&quot;&gt;http://www.assembla.com/spaces/clojure/tickets/304&lt;/a&gt;&lt;/p&gt;</comment>
                    <comment id="23671" author="importer" created="Tue, 24 Aug 2010 16:38:00 -0500"  >&lt;p&gt;chouser@n01se.net said: That&apos;s a great question.  get-source just needs a file name and line number.&lt;/p&gt;

&lt;p&gt;If IMeta were a protocol, it could be extended to Class.  That implementation could look for a &quot;well-known&quot; static field, perhaps?  __clojure_meta or something?  Then deftype would just have to populate that field, and get-source would be all set.&lt;/p&gt;

&lt;p&gt;Does that plan have any merit?  Is there a better place to store a file name and line number?&lt;/p&gt;</comment>
                    <comment id="23672" author="importer" created="Tue, 24 Aug 2010 16:38:00 -0500"  >&lt;p&gt;stu said: Seems like a reasonable idea, but this is going to get back-burnered for now, unless there is a dire use case we have missed.&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-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>
</channel>
</rss>