http://dev.clojure.org/jira/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+10010+AND+labels+%3D+enhancement An XML representation of a search request en-us 4.4 649 25-07-2011 http://dev.clojure.org/jira/browse/CLJ-1203 Clojure <p>I oftentimes use sorted collections, and my comparator functions usually look like that:</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>(fn [a b] (let [x (compare-according-to-my-use-case a b)] (if (zero? x) (compare a b) x))) </pre> </div></div> <p>That is, I define the sorting order depending on the requirements of my use-case, and if that doesn't suffice to make a distinction, I simply fall back to the standard `compare` function in order to get a stable ordering anyhow. I think that's a widely used idiom, e.g., also used in "Clojure Programming" (for example page 109).</p> <p>The problem with this approach is that several data structures don't implement Comparable, and thus aren't applicable to `compare` (you'll get a ClassCastException). Examples are maps, records, deftypes, and sequences.</p> <p>The patch I'm going to attach extends `Util.compare()` with a fallback clause that performs a `hasheq()`-based comparison. This results in a meaningless but at least stable sorting order which suffices for use-cases like the one shown above.</p> CLJ-1203

Fallback to hash-based comparison for non-Comparables in Util.compare()

Enhancement Minor Closed Declined Unassigned Tassilo Horn enhancement patch Wed, 17 Apr 2013 02:42:29 -0500 Mon, 29 Apr 2013 02:30:08 -0500 Mon, 29 Apr 2013 02:30:08 -0500 0 3 <p>Patch 0001-Add-hasheq-based-fallback-to-Util.compare.patch dated Apr 17 2013 applies cleanly to latest master, but causes several unit tests in data_structures.clj to fail. These are the kinds of things you would expect to fail with the change made in the patch, because the failing tests expect an exception to be thrown when comparing objects that don't implement Comparable, and with this patch's changes they no longer do. If this patch's change is desired, those tests should probably be removed.</p> <p>Thanks Andy, I can't believe I've forgotten to re-run the tests. <img class="emoticon" src="http://dev.clojure.org/jira/images/icons/emoticons/smile.gif" height="20" width="20" align="absmiddle" alt="" border="0"/></p> <p>Anyway, I'm attaching a new version of the patch that deletes the few sorted-set and sorted-set-by invocations that check that an exception is thrown when creating sorted sets containing non-Comparables.</p> <p>New version of the patch.</p> <p>Tassilo, you say that one of your use cases is sorted collections. Note that any compare function that returns 0 for two values will cause sorted sets and maps to treat the two compared values as equal, and at most one of them will get into the ordered set/map, the second treated as a duplicate, even though the values are not equal. See <a href="https://github.com/jafingerhut/thalia/blob/master/doc/other-topics/comparators.md#comparators-for-sorted-sets-and-maps-are-easy-to-get-wrong">https://github.com/jafingerhut/thalia/blob/master/doc/other-topics/comparators.md#comparators-for-sorted-sets-and-maps-are-easy-to-get-wrong</a> for an example (not based on your modified compare, but on a comparator that returns 0 for non-equal items).</p> <p>With your proposed change to compare, this occurrence would become very dependent upon the hash function used. Probably quite rare, but it would crop up from time to time, and could potentially be very difficult to detect and track down the source.</p> <p>Hi Andy, you are right. It's possible to add an explicit equals()-check in cases the hashcodes are the same, but I think there's nothing you can do in the hashcodes-equal-but-objects-are-not case. That is, there's no way to ensure the rule sgn(compare(x, y)) == -sgn(compare(y, x)), the transitivity rule, and the compare(x, y)==0 ==&gt; sgn(compare(x, z))==sgn(compare(y, z)) for all z rule.</p> <p>I'm closing that ticket.</p> Global Rank Patch Code http://dev.clojure.org/jira/browse/CLJ-1177 Clojure <p>clojure.java.io/resource corrupts path containing UTF-8 characters without issuing warning.</p> <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java">user=&gt; (<span class="code-object">System</span>/getProperty <span class="code-quote">"java.runtime.version"</span>) <span class="code-quote">"1.8.0-ea-b79"</span> user=&gt; (clojure-version) <span class="code-quote">"1.5.0"</span> user=&gt; (<span class="code-object">System</span>/getProperty <span class="code-quote">"user.dir"</span>) <span class="code-quote">"/dir/déf"</span> user=&gt; (clojure.java.io/resource <span class="code-quote">"myfile.txt"</span>) #&lt;URL file:/dir/d%c3%a9f/resources/myfile.txt&gt; user=&gt; (slurp (clojure.java.io/resource <span class="code-quote">"myfile.txt"</span>) :encoding <span class="code-quote">"UTF-8"</span>) FileNotFoundException /dir/déf/resources/myfile.txt (No such file or directory) java.io.FileInputStream.open (FileInputStream.java:-2)</pre> </div></div> CLJ-1177

clojure.java.io/resource and non-ASCII characters

Enhancement Minor Open Unresolved Unassigned Trevor Wennblom bug enhancement Thu, 7 Mar 2013 16:54:43 -0600 Sun, 10 Mar 2013 17:56:52 -0500 Release 1.5 1 0 <p>Below is a workaround, at least. I don't know, but perhaps the as-file method for URLs in io.clj of Clojure, the part that converts %hh sequences to a character with code point in the range 0 through 255, is at least partly at fault here. I don't know right now if it is possible to modify that code to handle the general case of whatever character encoding munging is going on here to when .getResource creates the URL object.</p> <p>clojure.java.io/resource is documented to return a Java object of type java.net.URL, which seems like it does %hh escaping of many characters. Reference <span class="error">&#91;1&#93;</span> to a Java bug from 2001 where a Java user was surprised by the then-recent change in behavior of the getResource method <span class="error">&#91;2&#93;</span>.</p> <p>Doing a little searching I found this StackOverflow question <span class="error">&#91;3&#93;</span>, which has what might be a workaround. I tried it on my Mac OS X 10.6 system running JDK 1.6 and it seemed to work:</p> <p>(slurp (.getContent (clojure.java.io/resource "abcíd/foo.txt")))</p> <p>That getContent is a method for class java.net.URL <span class="error">&#91;4&#93;</span></p> <p><span class="error">&#91;1&#93;</span> <a href="http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4466485">http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4466485</a><br/> <span class="error">&#91;2&#93;</span> <a href="http://docs.oracle.com/javase/1.5.0/docs/api/java/lang/Class.html#getResource%28java.lang.String%29">http://docs.oracle.com/javase/1.5.0/docs/api/java/lang/Class.html#getResource%28java.lang.String%29</a><br/> <span class="error">&#91;3&#93;</span> <a href="http://stackoverflow.com/questions/13013629/best-international-alternative-to-javas-getclass-getresource">http://stackoverflow.com/questions/13013629/best-international-alternative-to-javas-getclass-getresource</a><br/> <span class="error">&#91;4&#93;</span> <a href="http://docs.oracle.com/javase/1.5.0/docs/api/java/net/URL.html#getContent%28%29">http://docs.oracle.com/javase/1.5.0/docs/api/java/net/URL.html#getContent%28%29</a></p> <p>Hi Andy,</p> <p>Thanks for the background and suggestions, that's very helpful.</p> <p>I'm gradually learning Clojure with no Java experience. In this case I was searching for the preferred Clojure way to access items in directories declared under :resource-paths in a Leiningen project.clj file. Perhaps clojure.java.io/resource isn't the best way to do this as it's possibly too tied to the expectation for a URI instead of a more general IRI.</p> <p>You're suggested workaround did work for my use case:</p> <p>(slurp (.getContent (clojure.java.io/resource "abcíd/foo.txt")))</p> <p>but hopefully there would be more native/direct Clojure way to accomplish the same eventually.</p> <p>I don't know if java.net.IDN would be useful internally as a fix in clojure.java.io/resource — I'm assuming not since it wasn't added until Java 6.<span class="error">&#91;1&#93;</span></p> <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java">user=&gt; (<span class="code-keyword">import</span> 'java.net.IDN) java.net.IDN user=&gt; (java.net.IDN/toASCII <span class="code-quote">"/dir/déf"</span>) <span class="code-quote">"xn--/dir/df-gya"</span> user=&gt; (java.net.IDN/toUnicode <span class="code-quote">"xn--/dir/df-gya"</span>) <span class="code-quote">"/dir/déf"</span></pre> </div></div> <p><span class="error">&#91;1&#93;</span>: <a href="http://docs.oracle.com/javase/6/docs/api/java/net/IDN.html">http://docs.oracle.com/javase/6/docs/api/java/net/IDN.html</a></p> <p>Patch clj-1177-patch-v1.txt dated Mar 8 2013 is an attempt to solve this issue, in what I think may be a correct way. As specified in RFC 3986, when taking a Unicode string and making a URL of it, it should be encoded in UTF-8 and then each individual byte is subject to the %HH hex encoding. This patch reverses that to turn URLs into file names.</p> <p>Tested on Mac OS X 10.6 with a command line like this (it doesn't work without the -Dfile.encoding=UTF-8 option on my Mac, probably because the default encoding is MacRoman):</p> <p>% java -cp clojure.jar:path/to/resource -Dfile.encoding=UTF-8 clojure.main<br/> user=&gt; (require '<span class="error">&#91;clojure.java.io :as io&#93;</span>)<br/> nil<br/> user=&gt; (io/resource "abcíd/foo.txt")<br/> #&lt;URL <a href="file:/Users/jafinger/clj/clj-ns-browser/resource/abc%c3%add/foo.txt">file:/Users/jafinger/clj/clj-ns-browser/resource/abc%c3%add/foo.txt</a>&gt;<br/> user=&gt; (slurp (io/resource "abcíd/foo.txt"))<br/> "The quick brown fox jumped over the lázy dög!\n"</p> Global Rank Patch Code http://dev.clojure.org/jira/browse/CLJ-1165 Clojure <p>Protocol, interface method declarations don't allow for varags. Currently, for example</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre> (defprotocol FooBar (foo [this &amp; more])) </pre> </div></div> <p>compiles just fine, and <tt>&amp;</tt> is interpreted as a usual argument that happens to be<br/> named <tt>&amp;</tt> without special meaning. But clearly, the user wanted to specify a<br/> varags parameter here. The same applies to <tt>definterface</tt>.</p> <p>Similarly, providing method implementations via <tt>defrecord</tt>, <tt>deftype</tt>, and <tt>reify</tt><br/> don't allow for varags (but dynamic extensions via <tt>extend</tt> do).</p> <p>So this patch makes <tt>defprotocol</tt> and <tt>definterface</tt> throw an<br/> <tt>IllegalArgumentException</tt> if a user tries to use varargs in method signatures.</p> <p>Similarly, <tt>defrecord</tt>, <tt>deftype</tt>, and <tt>reify</tt> throw an <tt>IllegalArgumentException</tt> if<br/> any method implementation arglist contains a varargs argument.</p> <p>This patch is a cut-down variant of my patch to <a href="http://dev.clojure.org/jira/browse/CLJ-1024">http://dev.clojure.org/jira/browse/CLJ-1024</a><br/> which has been reverted shortly before Clojure 1.5 was released. The <a href="http://dev.clojure.org/jira/browse/CLJ-1024" title="Varargs protococol impls can be defined but not called"><del>CLJ-1024</del></a> patch<br/> was the same as this one, but it has also forbidden destructuring in <tt>defprotocol</tt> and<br/> <tt>definterface</tt>. This was a bit too much, because although destructuring has no<br/> semantic meaning with method declarations, it still can serve a documentation purpose.</p> <p>This has been discussed on the list: <a href="https://groups.google.com/d/topic/clojure-dev/qjkW-cv8nog/discussion">https://groups.google.com/d/topic/clojure-dev/qjkW-cv8nog/discussion</a></p> CLJ-1165

Forbid varargs defprotocol/definterface method declarations because those cannot be defined anyway

Enhancement Major Open Unresolved Stuart Halloway Tassilo Horn enhancement patch Fri, 15 Feb 2013 02:13:32 -0600 Thu, 4 Apr 2013 19:24:27 -0500 0 0 <p>I think that this patch would be much more helpful to users if it reported the problem form (both name and params). </p> <p>(And I wonder if we should be using ex-info for all errors going forward.)</p> <p>New version of the patch that mentions both method name and argument vector, and uses ex-info as Stu suggested.</p> <p>Presumuptuously changing Approval from Incomplete back to None, since the reason for marking it Incomplete seems to have been addressed with a new patch.</p> Global Rank Patch Code http://dev.clojure.org/jira/browse/CLJ-1155 Clojure <p>It would be really nice if we could hide the Java traceback from the compiler when it's not relevant. When there's no Java interop, it's not useful. I can't see any case where we want the tracebacks from the compiler referencing clojure.core.</p> <p>Here's how a syntax error traceback looks at the moment on trunk:</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>$ more dodgy-map.clj (defn dodgy-map [] {:1 :2 :3}) $ java -cp target/clojure-1.5.0-master-SNAPSHOT.jar clojure.main dodgy-map.clj Exception in thread "main" java.lang.RuntimeException: Map literal must contain an even number of forms, compiling:(/home/wilfred/src/clojure/dodgy-map.clj:2:13) at clojure.lang.Compiler.load(Compiler.java:7070) at clojure.lang.Compiler.loadFile(Compiler.java:7020) at clojure.main$load_script.invoke(main.clj:286) at clojure.main$script_opt.invoke(main.clj:348) at clojure.main$main$fn__6682.invoke(main.clj:432) at clojure.main$main.doInvoke(main.clj:429) at clojure.lang.RestFn.invoke(RestFn.java:408) at clojure.lang.Var.invoke(Var.java:415) at clojure.lang.AFn.applyToHelper(AFn.java:161) at clojure.lang.Var.applyTo(Var.java:532) at clojure.main.main(main.java:37) Caused by: java.lang.RuntimeException: Map literal must contain an even number of forms at clojure.lang.Util.runtimeException(Util.java:219) at clojure.lang.LispReader$MapReader.invoke(LispReader.java:1090) at clojure.lang.LispReader.readDelimitedList(LispReader.java:1145) at clojure.lang.LispReader$ListReader.invoke(LispReader.java:979) at clojure.lang.LispReader.read(LispReader.java:182) at clojure.lang.Compiler.load(Compiler.java:7058) ... 10 more </pre> </div></div> <p>With my patch, this is simplified to:</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>$ java -cp target/clojure-1.5.0-master-SNAPSHOT.jar clojure.main dodgy-map.clj java.lang.RuntimeException: Map literal must contain an even number of forms, compiling:(/home/wilfred/src/clojure/dodgy-map.clj:2:13) </pre> </div></div> <p>Another example: here's how name errors appear on trunk:</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>$ more i-dont-exist.clj (defn no-such-variable [] i-dont-exist) $ java -cp target/clojure-1.5.0-master-SNAPSHOT.jar clojure.main i-dont-exist.clj Exception in thread "main" java.lang.RuntimeException: Unable to resolve symbol: i-dont-exist in this context, compiling:(/home/wilfred/src/clojure/i-dont-exist.clj:1:1) at clojure.lang.Compiler.analyze(Compiler.java:6380) at clojure.lang.Compiler.analyze(Compiler.java:6322) at clojure.lang.Compiler$BodyExpr$Parser.parse(Compiler.java:5708) at clojure.lang.Compiler$FnMethod.parse(Compiler.java:5139) at clojure.lang.Compiler$FnExpr.parse(Compiler.java:3751) at clojure.lang.Compiler.analyzeSeq(Compiler.java:6558) at clojure.lang.Compiler.analyze(Compiler.java:6361) at clojure.lang.Compiler.analyzeSeq(Compiler.java:6548) at clojure.lang.Compiler.analyze(Compiler.java:6361) at clojure.lang.Compiler.access$100(Compiler.java:37) at clojure.lang.Compiler$DefExpr$Parser.parse(Compiler.java:529) at clojure.lang.Compiler.analyzeSeq(Compiler.java:6560) at clojure.lang.Compiler.analyze(Compiler.java:6361) at clojure.lang.Compiler.analyze(Compiler.java:6322) at clojure.lang.Compiler.eval(Compiler.java:6623) at clojure.lang.Compiler.load(Compiler.java:7063) at clojure.lang.Compiler.loadFile(Compiler.java:7020) at clojure.main$load_script.invoke(main.clj:286) at clojure.main$script_opt.invoke(main.clj:348) at clojure.main$main$fn__6682.invoke(main.clj:432) at clojure.main$main.doInvoke(main.clj:429) at clojure.lang.RestFn.invoke(RestFn.java:408) at clojure.lang.Var.invoke(Var.java:415) at clojure.lang.AFn.applyToHelper(AFn.java:161) at clojure.lang.Var.applyTo(Var.java:532) at clojure.main.main(main.java:37) Caused by: java.lang.RuntimeException: Unable to resolve symbol: i-dont-exist in this context at clojure.lang.Util.runtimeException(Util.java:219) at clojure.lang.Compiler.resolveIn(Compiler.java:6874) at clojure.lang.Compiler.resolve(Compiler.java:6818) at clojure.lang.Compiler.analyzeSymbol(Compiler.java:6779) at clojure.lang.Compiler.analyze(Compiler.java:6343) ... 25 more </pre> </div></div> <p>With patch:</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>$ java -cp target/clojure-1.5.0-master-SNAPSHOT.jar clojure.main i-dont-exist.clj java.lang.RuntimeException: Unable to resolve symbol: i-dont-exist in this context, compiling:(/home/wilfred/src/clojure/i-dont-exist.clj:1:1) </pre> </div></div> <p>I'm not familiar with the compiler internals, but I've attached a tentative patch. Undoubtedly it isn't perfect. For one, it would be nicer to say 'Syntax error' rather than 'java.lang.RuntimeException'. All the tests pass with this change.</p> <p>Relevant mailing list discussion: <a href="https://groups.google.com/forum/?fromgroups=#!searchin/clojure/wilfred/clojure/M5NlEW7HJ_c/joUY6mo6Rd8J">https://groups.google.com/forum/?fromgroups=#!searchin/clojure/wilfred/clojure/M5NlEW7HJ_c/joUY6mo6Rd8J</a></p> <p>Please let me know what you think. This would make my life easier when developing.</p> CLJ-1155

Suppress tracebacks from clojure.core

Enhancement Minor Closed Declined Unassigned Wilfred Hughes enhancement Fri, 1 Feb 2013 17:44:16 -0600 Fri, 29 Mar 2013 06:06:12 -0500 Fri, 29 Mar 2013 06:06:12 -0500 0 0 <p>It is easy for tools that consume Clojure to hide stack traces for those who do not want to see them. If Clojure itself eats stack traces, it is impossible for those of us who <b>do</b> want to see them to get them back.</p> <p>Please do this kind of work in tool (if at all) and make it optional for users.</p> Global Rank Patch Code http://dev.clojure.org/jira/browse/CLJ-1050 Clojure <p>Currently, when deref is called in Delay.java, a lock on the Delay is always acquired.<br/> This is wasteful as most of the time you just want to read the val.</p> <p>The attached patch changes this behaviour to the following:</p> <ul class="alternate" type="square"> <li>val is initialised to a known secret value. (During its constructor so it is visible from any thread).</li> <li>When deref is called, val is checked to the known secret value.</li> </ul> <ul> <li>If it is not the secret value, then it has to be the value computed by the function and we return it.</li> <li>If it is the secret value, then we lock this object and revert to the current behaviour.</li> </ul> <p>This is faster than what is done currently and can be very much faster if there is contention on the delay.</p> CLJ-1050

Remove a lock in the common case of deref of delay

Enhancement Trivial Closed Declined Unassigned Nicolas Oury enhancement patch performance Sun, 26 Aug 2012 13:24:00 -0500 Tue, 18 Sep 2012 06:53:01 -0500 Tue, 18 Sep 2012 06:53:01 -0500 Release 1.4 0 0 <p>Please close and reject. The patch is not working if val has non final fields.</p> Global Rank http://dev.clojure.org/jira/browse/CLJ-1042 Clojure <p>This adds Python-style negative string indices for (subs), e.g.:</p> <p>(subs "foo bar" -3) ;; -&gt; "bar"</p> CLJ-1042

[PATCH] Allow negative substring indices for (subs)

Enhancement Minor Closed Declined Unassigned Ian Eure enhancement patch Tue, 14 Aug 2012 13:11:40 -0500 Wed, 19 Sep 2012 13:34:50 -0500 Mon, 17 Sep 2012 07:07:57 -0500 Release 1.5 0 3 <p>Ian, thanks for the patch. It is Rich Hickey's policy only to consider applying patches to Clojure from those who have signed a Clojure contributor agreement: <a href="http://clojure.org/contributing">http://clojure.org/contributing</a></p> <p>Were you interested in doing so, or perhaps it is already in progress?</p> <p>I wasn't aware that this was necessary. I'm mailing the form in.</p> <p>Patch clj-1042-negative-subs-patch2.txt dated Aug 27 2012 is identical to Ian Eure's negative-subs.patch, except it is in the desired git format.</p> <p>Ian, for future reference on creating patches in the desired format, see the instructions under the heading "Development" on this page: <a href="http://dev.clojure.org/display/design/JIRA+workflow">http://dev.clojure.org/display/design/JIRA+workflow</a></p> <p>Thanks, will do.</p> <p>If Clojure decides to support Python-style negative indices, you should also consider adding support to subvec.</p> <p>Patch extended to support negative indices on (subvec) as well.</p> <p>The arg to rindex should probably be tagged with ^clojure.lang.Counted instead of ^String now.</p> <p>Regarding the previous comment, String is a Java class so it isn't a clojure.lang.Counted. Is the type hint necessary? Maybe it should be on the call rather than the defn. </p> <p>Ignoring the type hinting, I'll suggest a slightly simpler way to implement the rindex logic:</p> <p>(defn rindex <span class="error">&#91;coll i&#93;</span><br/> (if (neg? i) (+ (count coll) i) i))</p> <p>In any case, I'm not sure rindex should be public even if you want the subs and subvec enhancements. Someone needs to make the case for adding a new function to core.</p> <p>The Pythonic negative index is a debatable feature since it's pretty easy to implement for yourself if you want it.</p> <p>Sorry, the type hint on rindex args isn't necessary at all. Just looked up in the source, calling count should never be reflective, since (count ..) emits calls to clojure.lang.RT/count.</p> <p>Your solution looks good.</p> <p>Negative indices were considered and rejected a long time ago. (I am merely conveying information--I have no strong opinion on this one.)</p> <p>Note: If some people really like negative index behavior as in Perl or Python, it is straightforward to create a library of functions in a different namespace, perhaps with different names, that can do it. Perhaps a "pythonisms" library?</p> <p>Would this be accepted as part of clojure.string instead? I considered putting it there, but thought it would be confusing to have multiple substring functions in different namespaces.</p> <p>This is very helpful in practice, and I'd really like to see at least the (subs) stuff in Clojure.</p> <p>Disclaimer: I'm no Clojure/core member, so can't speak authoritatively on whether something would or would not be accepted into clojure.string.</p> <p>However, given that clojure.string is distributed with clojure.core, my guess is it would not be accepted. You'd be able to get things like this out for you and others as a separate library distributed on Clojars. That would also make it easy to include other Python-like things that you don't find in Clojure already.</p> <p>This isn't about "python-like things," this is about a useful feature. Lots of languages support this: Perl, PHP, Ruby, Python, JavaScript, to name a few. Are you really suggesting that I should create a whole package for a version of a function in clojure.core with slightly different semantics? That's insane.</p> <p>Anyway, I'm done wasting my time trying to navigate this hopelessly broken process. Maybe it would have been accepted if I included yet another way to interoperate with Java types.</p> <p>Stuart, do you remember why specifically negative indexes were rejected? Developing a separate library for a minor improvement to an existing function sounds unreasonable.</p> <p>some explanation about this topic was given by Rich Hickey himself here: <a href="http://news.ycombinator.com/item?id=2053908">http://news.ycombinator.com/item?id=2053908</a></p> <p>citation:<br/> "...Yes, there is a backlog from when it was just me, and it will take a while to whittle down. We have finite resources and have to prioritize. I can assure you we have more important things to concentrate on than your negative index substring enhancement, and are doing so. You'll just have to be patient. Or, if you insist, I'll just reject it now because a) IMO it's goofy, b) you can make your own function that works that way c) we don't get a free ride from j.l.String, d) it begs the question of negative indices elsewhere..."</p> <p>i've been following this thread hoping this feature would be included. but whatever the reason was for the rejection, i'm sure it was thoughtful. great thanks for this wonderful language, and thanks Ian Eure for his effort.</p> <p>That HN link eventually leads back to <a href="http://dev.clojure.org/jira/browse/CLJ-688" title="subs function should count back from the end of the string when given negative offset"><del>CLJ-688</del></a> which was rejected.</p> <p>Michael: A proposal for negative indexes would need to be systematic in considering implications for all functions that have index arguments.</p> <p>Ian: Clojure is driven by design, not incremental piling of features.</p> <p>All: clojure.string is incomplete in more important and fundamental ways than negative indexes. This sucks now, and will suck worse as more code is written in different dialects. I find myself wishing string was a contrib, so we could iterate faster.</p> <p>Stuart: Any specific proposals for how you'd like to see clojure.string improve? If it can be made a contrib, that would be cool, but understood if that would be considered too breaking of a change. Even if it isn't made a contrib, having tickets for improvement ideas you are willing to see means patches might get written, and they'll get in some time.</p> Global Rank Patch Code and Test http://dev.clojure.org/jira/browse/CLJ-1011 Clojure <p>Current behaviour of clojure.data/diff:</p> <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java">=&gt; (diff {:a <span class="code-keyword">false</span>} {:a <span class="code-keyword">true</span>}) (nil {:a <span class="code-keyword">true</span>} nil) =&gt; (diff {:a <span class="code-keyword">false</span>} {:a nil}) (nil nil nil)</pre> </div></div> <p>Proposed behaviour:</p> <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java">=&gt; (diff {:a <span class="code-keyword">false</span>} {:a <span class="code-keyword">true</span>}) ({:a <span class="code-keyword">false</span>} {:a <span class="code-keyword">true</span>} nil) =&gt; (diff {:a <span class="code-keyword">false</span>} {:a nil}) ({:a <span class="code-keyword">false</span>} {:a nil} nil)</pre> </div></div> CLJ-1011

clojure.data/diff should cope with null and false values in maps

Defect Minor Closed Completed Unassigned Philip Aston enhancement patch Tue, 12 Jun 2012 05:04:16 -0500 Sat, 18 Aug 2012 07:12:52 -0500 Sat, 18 Aug 2012 07:12:52 -0500 Release 1.3 Release 1.4 Release 1.5 0 2 <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre> From e03a8060214d122ea2ebadf9e8a368f7f593d9f4 Mon Sep 17 00:00:00 2001 From: Philip Aston &lt;philipa@mail.com&gt; Date: Sun, 10 Jun 2012 13:11:36 +0100 Subject: [PATCH] clojure.data/diff: cope with falsey values in maps --- src/clj/clojure/data.clj | 18 +++++++++++++++++- test/clojure/test_clojure/data.clj | 3 ++- 2 files changed, 19 insertions(+), 2 deletions(-) diff --git a/src/clj/clojure/data.clj b/src/clj/clojure/data.clj index 6e8dbcf..345b234 100644 --- a/src/clj/clojure/data.clj +++ b/src/clj/clojure/data.clj @@ -30,6 +30,22 @@ (vec (repeat (apply max (keys m)) nil)) m))) +(defn- diff-associative-key + "Diff associative things a and b, comparing only the key k." + [a b k] + (let [va (get a k) + vb (get b k) + [a* b* ab] (diff va vb) + in-a (contains? a k) + in-b (contains? b k) + same (and in-a in-b + (or (not (nil? ab)) + (and (nil? va) (nil? vb))))] + [(when (and in-a (or (not (nil? a*)) (not same))) {k a*}) + (when (and in-b (or (not (nil? b*)) (not same))) {k b*}) + (when same {k ab}) + ])) + (defn- diff-associative "Diff associative things a and b, comparing only keys in ks." [a b ks] @@ -38,7 +54,7 @@ (doall (map merge diff1 diff2))) [nil nil nil] (map - (fn [k] (map #(when % {k %}) (diff (get a k) (get b k)))) + (partial diff-associative-key a b) ks))) (defn- diff-sequential diff --git a/test/clojure/test_clojure/data.clj b/test/clojure/test_clojure/data.clj index 9bab766..5a241e0 100644 --- a/test/clojure/test_clojure/data.clj +++ b/test/clojure/test_clojure/data.clj @@ -27,5 +27,6 @@ [#{1} #{3} #{2}] (HashSet. [1 2]) (HashSet. [2 3]) [nil nil [1 2]] [1 2] (into-array [1 2]) [nil nil [1 2]] (into-array [1 2]) [1 2] - [{:a {:c [1]}} {:a {:c [0]}} {:a {:c [nil 2] :b 1}}] {:a {:b 1 :c [1 2]}} {:a {:b 1 :c [0 2]}})) + [{:a {:c [1]}} {:a {:c [0]}} {:a {:c [nil 2] :b 1}}] {:a {:b 1 :c [1 2]}} {:a {:b 1 :c [0 2]}} + [{:a nil} {:a false} {:b nil :c false}] {:a nil :b nil :c false} {:a false :b nil :c false})) -- 1.7.9.5 </pre> </div></div> <p>Philip, thanks for writing that patch. Could you please attach it as a file to this ticket, instead of copying and pasting it into a comment? Instructions are under the heading "Adding patches" on this page:</p> <p><a href="http://dev.clojure.org/display/design/JIRA+workflow">http://dev.clojure.org/display/design/JIRA+workflow</a></p> <p>Rich Hickey's policy is only to include code in Clojure that is written by those who have signed a contributor agreement. You can find out more at <a href="http://clojure.org/contributing">http://clojure.org/contributing</a></p> <p>Thanks Andy. Patch attached: </p> <p>0001-clojure.data-diff-cope-with-falsey-values-in-maps.patch</p> <p>I'll send in a CA.</p> <p>CA snail-mailed yesterday, I guess it will take a week to arrive.</p> <p>I now have a CA in place.</p> <p>Yeah, this should be fixed.</p> <p>Patch applies cleanly against 4004d267e124f12b65b0d7fb6522f32a75e3c4fb. Submitter is a confirmed CA signer.</p> Approval Ok Global Rank Patch Code and Test http://dev.clojure.org/jira/browse/CLJ-1010 Clojure <p>The function composition function `comp` is quite inefficient in cases like `(apply comp large-seq-of-fns)`, because its arity-greater-than-3 version reverses the seq.</p> <p>I would be great if there was an alternative `comp*` (or whatever) function which is just like `comp` but composes left-to-right.</p> CLJ-1010

A left-to-right-variant of `comp`

Enhancement Minor Open Unresolved Unassigned Tassilo Horn enhancement patch Mon, 11 Jun 2012 04:57:55 -0500 Thu, 14 Jun 2012 18:27:23 -0500 0 1 <p>Here's an implementation.</p> <p>There's something strange with my patch. The creation of a composition of a huge seq of functions is much faster with `comp*` than with `comp`, which is expected, because the seq doesn't need to be reversed.</p> <p>The strange thing however is that the compositions created with `comp` evaluate about 10-20% faster than those created with `comp*` although the arbitrary-arity version of `comp` is defined in terms of `comp*`: `(apply comp* (reverse (list* f1 f2 f3 fs)))`.</p> <p>For some benchmarking details, see: <a href="https://groups.google.com/d/msg/clojure/MizwTxHwLE4/hGLrMfetlP8J">https://groups.google.com/d/msg/clojure/MizwTxHwLE4/hGLrMfetlP8J</a></p> <p>Here's some benchmark:</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>user&gt; (use 'criterium.core) nil user&gt; (let [coll (doall (take 1000000 (repeat inc))) f1 (apply comp* coll) f2 (apply comp coll)] (bench (f1 0) :verbose) (println "---------------------------------------") (bench (f2 0) :verbose)) amd64 Linux 3.4.2-gentoo 2 cpu(s) OpenJDK 64-Bit Server VM 22.0-b10 Runtime arguments: -agentlib:jdwp=transport=dt_socket,server=y,suspend=n -XX:+TieredCompilation -Xmx1G -Dclojure.compile.path=/home/horn/Repos/clj/testi/target/classes -Dtesti.version=0.1.0-SNAPSHOT -Dclojure.debug=false Evaluation count : 600 Execution time mean : 112.324465 ms 95.0% CI: (112.247218 ms, 112.380682 ms) Execution time std-deviation : 6.513809 ms 95.0% CI: (6.477450 ms, 6.553029 ms) Execution time lower ci : 105.609401 ms 95.0% CI: (105.609401 ms, 105.622918 ms) Execution time upper ci : 122.353763 ms 95.0% CI: (122.353763 ms, 122.405315 ms) --------------------------------------- amd64 Linux 3.4.2-gentoo 2 cpu(s) OpenJDK 64-Bit Server VM 22.0-b10 Runtime arguments: -agentlib:jdwp=transport=dt_socket,server=y,suspend=n -XX:+TieredCompilation -Xmx1G -Dclojure.compile.path=/home/horn/Repos/clj/testi/target/classes -Dtesti.version=0.1.0-SNAPSHOT -Dclojure.debug=false Evaluation count : 1440 Execution time mean : 43.519663 ms 95.0% CI: (43.516732 ms, 43.524062 ms) Execution time std-deviation : 492.299089 us 95.0% CI: (490.829889 us, 494.198137 us) Execution time lower ci : 42.781398 ms 95.0% CI: (42.781398 ms, 42.781398 ms) Execution time upper ci : 44.157311 ms 95.0% CI: (44.157311 ms, 44.158513 ms) nil </pre> </div></div> <p>Ok, I've tracked down the performance difference. This comes from the fact that `reverse` creates a clojure.lang.PersistentList which can be iterated much faster than a (fully realized) LazySeq. If you provide your fncoll in `(apply comp* fncoll)` as vector or list, the application of the created composition is as fast as for `comp`.</p> <p>So for me, the patch is good and makes sense.</p> Global Rank Patch Code http://dev.clojure.org/jira/browse/CLJ-991 Clojure CLJ-991

partition-by reducer

Enhancement Minor Open Unresolved Unassigned Kevin Downey enhancement patch patch, Thu, 10 May 2012 20:08:20 -0500 Mon, 4 Mar 2013 14:49:42 -0600 0 2 <p>I'd like to see something much faster than this.</p> <p>For reference here is a benchmark of a non-reducers (seq based) process that uses partition-by</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>user=&gt; (def x (vec (range 1e6))) #'user/x user=&gt; (bench (reduce + (map count (partition-by #(or (zero? (mod % 3)) (zero? (mod % 5))) x)))) Evaluation count : 60 Execution time mean : 1.072157 sec 95.0% CI: (1.070606 sec, 1.073381 sec) Execution time std-deviation : 165.818282 ms 95.0% CI: (163.873585 ms, 168.271261 ms) Execution time lower ci : 972.562000 ms 95.0% CI: (972.562000 ms, 973.301850 ms) Execution time upper ci : 1.419148 sec 95.0% CI: (1.419148 sec, 1.419148 sec) Found 7 outliers in 60 samples (11.6667 %) low-severe 2 (3.3333 %) low-mild 5 (8.3333 %) Variance from outliers : 85.8489 % Variance is severely inflated by outliers nil user=&gt; </pre> </div></div> <p>Same again using r/partition-by from reducer-partition-by.diff</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>user=&gt; (bench (r/reduce + (r/map count (r/partition-by #(or (zero? (mod % 3)) (zero? (mod % 5))) x)))) Evaluation count : 60 Execution time mean : 1.418350 sec 95.0% CI: (1.417738 sec, 1.418948 sec) Execution time std-deviation : 66.736477 ms 95.0% CI: (66.186568 ms, 67.610777 ms) Execution time lower ci : 1.370419 sec 95.0% CI: (1.370419 sec, 1.370419 sec) Execution time upper ci : 1.544151 sec 95.0% CI: (1.544151 sec, 1.544156 sec) Found 10 outliers in 60 samples (16.6667 %) low-severe 2 (3.3333 %) low-mild 8 (13.3333 %) Variance from outliers : 33.5591 % Variance is moderately inflated by outliers nil user=&gt; </pre> </div></div> <p>(using <a href="https://github.com/hugoduncan/criterium">https://github.com/hugoduncan/criterium</a> for benchmarking)</p> <p>same again for r/partition-by from reducers-partition-by2.diff</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>user=&gt; (bench (r/reduce + (r/map count (r/partition-by #(or (zero? (mod % 3)) (zero? (mod % 5))) x)))) Evaluation count : 180 Execution time mean : 307.596806 ms 95.0% CI: (307.271339 ms, 307.961550 ms) Execution time std-deviation : 34.060809 ms 95.0% CI: (33.613169 ms, 34.416837 ms) Execution time lower ci : 285.339333 ms 95.0% CI: (285.339333 ms, 285.339333 ms) Execution time upper ci : 385.087950 ms 95.0% CI: (385.087950 ms, 385.087950 ms) Found 10 outliers in 60 samples (16.6667 %) low-severe 4 (6.6667 %) low-mild 6 (10.0000 %) Variance from outliers : 73.8053 % Variance is severely inflated by outliers nil user=&gt; </pre> </div></div> <p>same again driven using r/fold (for grins) instead of r/reduce</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>user=&gt; (bench (r/fold + (r/map count (r/partition-by #(or (zero? (mod % 3)) (zero? (mod % 5))) x)))) Evaluation count : 360 Execution time mean : 215.214486 ms 95.0% CI: (214.915417 ms, 215.664236 ms) Execution time std-deviation : 36.588464 ms 95.0% CI: (36.305548 ms, 36.847846 ms) Execution time lower ci : 185.575000 ms 95.0% CI: (185.575000 ms, 185.575000 ms) Execution time upper ci : 287.605175 ms 95.0% CI: (286.547833 ms, 287.605175 ms) Found 6 outliers in 60 samples (10.0000 %) low-severe 3 (5.0000 %) low-mild 3 (5.0000 %) Variance from outliers : 87.6303 % Variance is severely inflated by outliers nil user=&gt; </pre> </div></div> <p>reducers-partition-by2.diff is faster, but I am not wild about introducing a type and a protocol. also not sure about the CollFold impl.</p> <p>Let's leave fold out for this first patch, please.</p> <p>reducer-partition-by3.diff is a cleaned up version of reducer-partition-by2.diff without fold</p> <p>Per Andy Fingerhut's email reducer-partition-by3.diff was failing to apply. This patch should apply cleanly to current master.</p> <p>Presumptuously changing Approval from Incomplete to None, since the reason for its being marked Incomplete seems to have been addressed with the latest patch.</p> <p>should this be assigned to someone?</p> Global Rank Patch Code and Test http://dev.clojure.org/jira/browse/CLJ-982 Clojure <p>clojure.core implements a class? predicate to detect if a thing is an instance of java.lang.Class. The attached patch implements interface? to further distinguish classes that are also interfaces. This gives us Clojure api for e.g., enumerating all interfaces a thing's base class implements; as in, (filter #(interface? %) (supers (class my-thing))).</p> Any CLJ-982

Implement an interface? predicate to balance class?

Enhancement Trivial Closed Declined Unassigned David Rupp enhancement patch test Fri, 4 May 2012 21:16:07 -0500 Sat, 9 Jun 2012 09:08:46 -0500 Fri, 8 Jun 2012 12:29:30 -0500 Release 1.5 0 0 <p>I would prefer to see this, and other interop/reflective items, in a separate contrib lib.</p> <p>Thanks for the feedback, Stu. Is there an existing contrib lib for stuff like this? Or should I create one?</p> Global Rank Patch Code and Test http://dev.clojure.org/jira/browse/CLJ-920 Clojure <p>This patch allows environments that support FreeDesktop to browse a URL in their default browser. This is important because unless the desktop environment bridges to Java (like Gnome does) the URL will be opened in a Swing window, which is not always desired.</p> <p>See: <a href="https://github.com/clojure/clojure/pull/14">https://github.com/clojure/clojure/pull/14</a></p> Any environment that supports FreeDesktop, so Linux and BSD mainly. CLJ-920

Adds support for FreeDesktop's xdg-open in clojure.java.browse/browse-url.

Enhancement Minor Closed Completed Unassigned Jeremy Heiler enhancement Sat, 28 Jan 2012 10:45:35 -0600 Fri, 1 Mar 2013 12:47:01 -0600 Wed, 29 Feb 2012 13:19:52 -0600 Release 1.3 0 1 <p>Is this a duplicate of <a href="http://dev.clojure.org/jira/browse/CLJ-896" title="Make browse-url aware of xdg-open"><del>CLJ-896</del></a>? Can you look at the patch there and see if there is any advantage to the patch for it vs. the one here? Or perhaps some combination that is an improvement on them both?</p> <p>The issue is definitely a duplicate of <a href="http://dev.clojure.org/jira/browse/CLJ-896" title="Make browse-url aware of xdg-open"><del>CLJ-896</del></a>. The proposed patches were different. <a href="http://dev.clojure.org/jira/browse/CLJ-896" title="Make browse-url aware of xdg-open"><del>CLJ-896</del></a> now has an attached patch that is an enhancement of what Jeremy Heiler created.</p> Global Rank Patch Code http://dev.clojure.org/jira/browse/CLJ-918 Clojure <p>When defining a var with <tt>^{:macro true</tt>} the call of the binded macro does emit a warning when the definition has been AOT compiled.</p> <p>See example outputs with demo code here: <a href="https://refheap.com/paste/389">https://refheap.com/paste/389</a></p> <p>Bronsa on #clojure created a patch: <a href="http://sprunge.us/bWcc">http://sprunge.us/bWcc</a></p> Tested with 1.3.0 and 1.4.0 CLJ-918

Vars with {:macro true} meta data do not work when loaded from AOT compiled file

Enhancement Trivial Closed Duplicate Unassigned Jannik Schorg Compiler enhancement metadata Mon, 23 Jan 2012 16:06:06 -0600 Thu, 13 Sep 2012 14:29:01 -0500 Thu, 13 Sep 2012 14:29:01 -0500 0 1 <p>Duplicate of <a href="http://dev.clojure.org/jira/browse/CLJ-1021" title="(let [i 5] (defmacro m [v] v) m) interprets m as a function, not a macro">CLJ-1021</a>. Later ticket kept in preference to this one, because it has a patch and this one does not.</p> Global Rank Patch New