Clojure JIRA

[CLJ-21] GC Issue 17: arity checking during compilation

Tue, 24 Aug 2010 14:44:00 -0500

Reported by richhickey, Dec 17, 2008
Use available metadata to check calls when possible

[CLJ-47] GC Issue 43: Dead code in generated bytecode

Fri, 8 Oct 2010 10:21:00 -0500

Reported by Levente.Santha, Jan 11, 2009
The bug was described in detail in this thread: http://groups.google.com/
group/clojure/browse_thread/thread/81ba15d7e9130441

For clojure.core$last__2954.invoke the correct bytecode would be (notice 
the removed "goto    65" after "41:  goto    0"):

public java.lang.Object invoke(java.lang.Object)   throws 
java.lang.Exception;
  Code:
   0:   getstatic       #22; //Field const__0:Lclojure/lang/Var;
   3:   invokevirtual   #37; //Method clojure/lang/Var.get:()Ljava/lang/
Object;
   6:   checkcast       #39; //class clojure/lang/IFn
   9:   aload_1
   10:  invokeinterface #41,  2; //InterfaceMethod clojure/lang/IFn.invoke:
(Ljava/lang/Object;)Ljava/lang/Object;
   15:  dup
   16:  ifnull  44
   19:  getstatic       #47; //Field java/lang/Boolean.FALSE:Ljava/lang/
Boolean;
   22:  if_acmpeq       45
   25:  getstatic       #22; //Field const__0:Lclojure/lang/Var;
   28:  invokevirtual   #37; //Method clojure/lang/Var.get:()Ljava/lang/
Object;
   31:  checkcast       #39; //class clojure/lang/IFn
   34:  aload_1
   35:  invokeinterface #41,  2; //InterfaceMethod clojure/lang/IFn.invoke:
(Ljava/lang/Object;)Ljava/lang/Object;
   40:  astore_1
   41:  goto    0
   44:  pop
   45:  getstatic       #26; //Field const__1:Lclojure/lang/Var;
   48:  invokevirtual   #37; //Method clojure/lang/Var.get:()Ljava/lang/
Object;
   51:  checkcast       #39; //class clojure/lang/IFn
   54:  aload_1
   55:  aconst_null
   56:  astore_1
   57:  invokeinterface #41,  2; //InterfaceMethod clojure/lang/IFn.invoke:
(Ljava/lang/Object;)Ljava/lang/Object;
   62:  areturn

Our JIT reported incorrect stack size along the basic block introduced by 
the unneeded goto.
The bug was present in SVN rev 1205.

[CLJ-64] GC Issue 61: Make Clojure datatype Java Serializable

Tue, 24 Aug 2010 14:44:00 -0500

Reported by straszheimjeffrey, Jan 30, 2009

I mentioned this on Google Groups.

Currently the core Clojure datatypes are not Java Serializable.  This means
that they cannot easily be streamed as binary objects.  Also, it will be
difficult to use them with certain Java features like RMI.

Comment 1 by rob.nikander, Mar 11, 2009

I voted for this because I'm experimenting with using Clojure for web apps.  Tomcat barfs trying to serialize 
objects in the session, like clojure.lang.Cons.

Comment 2 by cjkent, Mar 25, 2009

I'm experimenting with Clojure and Wicket.  Any Wicket page classes containing maps
that use Keywords as keys can't be saved to the session because Keyword isn't
serializable.

[CLJ-77] GC Issue 74: Clojure compiler emits too-large classfiles (results in ClassFormatError)

Tue, 24 Aug 2010 06:45:00 -0500

Reported by cemer...@snowtide.com, Feb 10, 2009

The jvm has certain implementation limits around the maximum size of
classfiles, literal strings, method length, etc; however, in certain
circumstances, the Clojure compiler can currently emit classfiles that
violate some of those limitations, causing an error later when the
classfile is loaded.

While test coverage would necessarily detect this sort of problem on a
project-by-project basis when one's tests attempted to load a project's
classfiles, it seems like Clojure should do the following to ensure failure
as quickly as possible:

- throw an exception immediately if, while compiling a lib, it is detected
that the resulting classfile(s) would violate any classfile implementation
limits.  Ideally, the exception's message would detail what file and on
which line number the offending form is (e.g. if a method's bytecode would
be too long).  I can imagine that doing this may not be straightforward; a
reasonable stop-gap would be for the compiler to immediately attempt to
load the generated classfile in order to ensure up-front failure.

- emit a warning if any clojure form is read that would, upon being
compiled, require violating any of the classfile implementation limits; I
suspect that *most* people looking to generate classfiles would be doing so
in a "build" environment (rather than loading some code, tinkering, and
then using clojure.core/compile), but for those that aren't, I can imagine
there being a good deal of frustration around seeing that loading and using
some code successfully would eventually produce unusable classfiles.

I've appended a sample stack trace emitted by java when it attempted to
load a too-long method implementation (which was produced by embedding a
large list literal in a compiled lib).

Exception in thread "main" java.lang.ClassFormatError: Invalid method  
Code length 105496 in class file com/foo/MyClass__init
         at java.lang.ClassLoader.defineClass1(Native Method)
         at java.lang.ClassLoader.defineClass(ClassLoader.java:675)
         at  
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)
         at java.net.URLClassLoader.defineClass(URLClassLoader.java:260)
         at java.net.URLClassLoader.access$000(URLClassLoader.java:56)
         at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
         at java.security.AccessController.doPrivileged(Native Method)
         at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
         at java.lang.ClassLoader.loadClass(ClassLoader.java:316)
         at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:
288)
         at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
         at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:
374)
         at java.lang.Class.forName0(Native Method)
         at java.lang.Class.forName(Class.java:247)
         at clojure.lang.RT.loadClassForName(RT.java:1512)
         at clojure.lang.RT.load(RT.java:394)
         at clojure.lang.RT.load(RT.java:374)
         at clojure.core$load__4911$fn__4913.invoke(core.clj:3623)
         at clojure.core$load__4911.doInvoke(core.clj:3622)
         at clojure.lang.RestFn.invoke(RestFn.java:413)
         at clojure.core$load_one__4863.invoke(core.clj:3467)
         at clojure.core$compile__4918$fn__4920.invoke(core.clj:3633)
         at clojure.core$compile__4918.invoke(core.clj:3632)
         at clojure.lang.Var.invoke(Var.java:336)
         at clojure.lang.Compile.main(Compile.java:56)

[CLJ-115] GC Issue 111: Enable naming an array parameter for areduce

Tue, 24 Aug 2010 05:45:00 -0500

Reported by bo...@boriska.com, Apr 28, 2009

Currently there is no way to access anonymous array parameter of areduce.

Consider:

(areduce (.. System getProperties values toArray) 
     i r 0 (some_expression))
some_expression has no way to access the array.

Per Rich:
--------------------
Yes, areduce would be nicer if it looked like a binding set:

(areduce [aname anarray, ret init] expr)
(areduce [aname anarray, ret init, start-idx  start-n] expr)
(areduce [aname anarray, ret init, start-idx  start-n, end-idx end-n]
expr) 
--------------------

This was discussed here:
http://groups.google.com/group/clojure/tree/browse_frm/thread/40597a8ac322bc37/8cf6b17328ea7e8b?rnum=1&_done=%2Fgroup%2Fclojure%2Fbrowse_frm%2Fthread%2F40597a8ac322bc37%2F8cf6b17328ea7e8b%3Ftvc%3D1%26pli%3D1%26#doc_9ea7e3c5d500ed3c

[CLJ-126] abstract superclass with non-public accessibility

Tue, 24 Aug 2010 04:45:00 -0500

The following code works in Java 6 but not in Java 5:

(def Clojure 1.1.0-alpha-SNAPSHOT
user=> (def s (new StringBuilder "aaa"))
#'user/s
user=> (. s setCharAt (int 0) (char \a))
java.lang.Exception: Unable to resolve symbol: setCharAt in this context

This was discussed on the Clojure mailing list and Stephen C. Gillardi came up with the following conclusion:

_StringBuilder extends AbstractStringBuilder (though the JavaDoc docs lie and say it extends Object). AbstractStringBuilder has default accessibility (not public, protected, or private) which makes the class inaccessible to code outside the java.lang package. In both Java SE 5 and Java SE 6, StringBuilder does not contain a .setCharAt method definition. It relies on the inherited public method in AbstractStringBuilder. (I downloaded the source code for both versions from Sun to check.)

In Java SE 5, when Clojure checks whether or not .setCharAt on StringBuilder is public, it finds that it's a public method of a non-public base class and throws the exception you saw. (It looks like you're using a version of Clojure older than 18 May 2009 (Clojure svn r1371). Versions later than that print the more detailed message I saw.)

In Java SE 6, Clojure's checks for accessibility of this method succeed and the method call works.

I'm not sure whether or not Clojure could be modified to make this method call work in Java 5. Google searches turn up discussion that this pattern of using an undocumented abstract superclass with non-public accessibility is not common in the JDK._

This ticket is being filed in the event that Clojure can handle these types of situations somehow.

[CLJ-127] DynamicClassLoader's call to ClassLoader.getSystemClassLoader is prohibited in some environments

Tue, 24 Aug 2010 03:45:00 -0500

Currently, clojure.lang.DynamicClassLoader's constructor has the
following call to super():

super(EMPTY_URLS,
      (Thread.currentThread().getContextClassLoader() == null ||
        Thread.currentThread().getContextClassLoader() == ClassLoader.getSystemClassLoader()) ?
          Compiler.class.getClassLoader() : Thread.currentThread().getContextClassLoader());

That call to ClassLoader.getSystemClassLoader() is forbidden by Google
AppEngine's security policies. That restricts you from being able to
load any resources from the classpath that haven't been AOT-compiled.
I've verified that just removing that removing the " ||
Thread.currentThread().getContextClassLoader() ==
ClassLoader.getSystemClassLoader()" does in fact result in something
that works in GAE (as far as my needs go). Unfortunately, I'm not sure
whether that breaks anything, which, presumably, it does.

[CLJ-150] Doc for array-map should mention its characteristics/caveats

Tue, 24 Aug 2010 04:54:00 -0500

Doc for array-map should mention its characteristics: preserves order of keys, linear O search so appropriate only for small maps, operations on array-maps return hash-maps.

[CLJ-153] Suggest adding set-precision! API to accompany with-precision

Tue, 24 Aug 2010 00:55:00 -0500

Ticket #137 makes math-context</code> settable at the REPL. However, <code>math-context is not a public name in Clojure.

The related public function is with-precision</code> which works by pushing a new binding for <code>math-context</code>. This ticket suggests adding <code>set-precision!</code> to Clojure's public API. Its effect would be the same as <code>with-precision</code>, but accomplished by using <code>set!</code> on the current <code>math-context binding rather than by pushing a new binding.

Chouser suggests that we also add a doc string for math-context</code> noting that it is private and pointing the user to <code>with-precision</code> and <code>set-precision!. I agree.

[CLJ-140] Single :tag for type hints conflates value's type with type of return value from an invoke

Tue, 24 Aug 2010 03:51:00 -0500

The value of a Var can be operated on directly, or, if it is a fn, it can be invoked and the resulting value operated on. :tag metadata on a Var is used to provide a type hint to the compiler to avoid reflection. Having a single metadata key for this two distinct uses makes it possible (even easy, if unlikely) to create a situation where type-hinting the value causes a ClassCastException on an operation on the invocation return value, or the reverse. The only obvious solution is two use different keys for the two uses.

[CLJ-213] Invariants and the STM

Tue, 24 Aug 2010 07:23:00 -0500

(ticket requested here http://groups.google.com/group/clojure/browse_thread/thread/119311e89fa46806/4903ce25ff6deaa6#4903ce25ff6deaa6)

The general idea is to declare invariants inside a transaction and, when at commit time an invariant doesn't hold anymore, the transaction retries.
So it can both act as a kind of soft ensure or to specify actions that "partially commute".
Thus it would enable coarser refs.

See the attached file for quick prototype.

User code would looks like:

(invariant (@world :key))
(commute world update-in [:key] val-transform-fn)

This means the commute will occur only if (@world :key) returns the same value in-transaction and at commit point.

[CLJ-233] better error reporting of nonexistent var

Wed, 29 Sep 2010 05:29:00 -0500

simple improvement to error message when referencing a var that doesn't exist.

[CLJ-270] defn-created fns inherit old metadata from the Var they are assigned to

Tue, 24 Aug 2010 06:23:00 -0500

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

user> (def #^{:foo "bar"} x 5)
#'user/x
user> (meta #'x)
{:ns #<Namespace user>, :name x, :file "NO_SOURCE_FILE", :line 1, :foo "bar"}
user> (defn x [] 5)
#'user/x
user> (meta #'x)
{:ns #<Namespace user>, :name x, :file "NO_SOURCE_FILE", :line 1, :arglists ([])}
user> (meta x)
{:ns #<Namespace user>, :name x, :file "NO_SOURCE_FILE", :line 1, :foo "bar"}

What is the expected output? What do you see instead?

I expect (meta #'x) to evaluate to the value of the final (meta x) in the above.

What version are you using?

Current master (commit 61202d2ff6925002400a9843e8fbd080f3bef3a5).

Was this discussed on the group? If so, please provide a link to the discussion.

http://groups.google.com/group/clojure/browse_thread/thread/4c7151aa9c4d919c/d1b033ef5a13dd89?lnk=gst&q=off-by-one#d1b033ef5a13dd89

Prompted by discussion at

http://groups.google.com/group/clojure/browse_thread/thread/6553d48c981019eb/3c55b0bd43a5d8e9?lnk=gst&q=off-by-one#3c55b0bd43a5d8e9

Initial attempt at a diagnosis:

I think this is due to DefExpr's eval method binding the Var to init.eval() first and attaching the supplied metadata to the Var later – see Compiler.java lines 341-352. (Note the Var is always already in place when init.eval() is called, regardless of whether it existed prior to the evaluation of the def / defn.) Thus the init expression supplied by defn sees the old (and wrong) metadata on the Var.

[CLJ-252] Support typed non-primitive fields in deftype

Tue, 24 Aug 2010 06:07:00 -0500

Right now hints are accepted but not used as field type.

[CLJ-273] def with a function value returns meta {:macro false}, but def itself doesn't have meta

Tue, 24 Aug 2010 09:32:00 -0500

On the master (1.2) branch, if you create a def with an initial function value, {:macro false} is added to the metadata of the return value for def. However, if you look again at the metadata on the var itself, the {:macro false} is not present! This breaks the use of contrib's defalias when aliasing macros, because the new alias is marked as {:macro false}.

The code below demonstrates the issue, which was introduced in http://github.com/richhickey/clojure/commit/430dd4fa711d0008137d7a82d4b4cd27b6e2d6d1, "metadata for fns."

;; all running on 1.2, DIFF noted in comments

(defmacro foo [])
-> #'user/foo

(meta (def bar (.getRoot #'foo)))
-> {:macro false, :ns #<Namespace user>, :name bar, :file "NO_SOURCE_PATH", :line 83}
;; DIFF: where did that :macro false come from??

(def bar (.getRoot #'foo))
-> #'user/bar

(meta #'bar)
-> {:ns #<Namespace user>, :name bar, :file "NO_SOURCE_PATH", :line 84}
;; LIKE 1.1, but really weird: now the :macro false is gone again!

[CLJ-277] Making clojure.xml/emit a little friendler to xml consumers

Tue, 24 Aug 2010 09:41:00 -0500

Currently, clojure.xml/emit breaks the eBay api, because emit adds whitespace before and after :contents. This trivial patch fixes it for me:
http://github.com/tjg/clojure/commit/bbff079d26e627c655b847319a58d76b8b3cec7c

(Dunno whether there's a good reason emit works that way, or if I'm missing something obvious.)

I realize that emit's behavior conforms to the XML spec and it's probably eBay at fault here. But I can nevertheless see this whitespace causing problems.

[CLJ-319] TransactionalHashMap bug

Fri, 1 Oct 2010 16:06:00 -0500

TransactionalHashMap computation of the bin is buggy. The implementation doesn't unset the sign bit before using it in accessing the bin array which in some cases cause an ArrayOutOfBoundException to be thrown.

As Rich Hickey has pointed out, this is an unsupported experimental Class and won't be fixed unless I provided a patch, so attached is the patch file.

[CLJ-434] Additional copy methods for URLs in clojure.java.io

Fri, 10 Sep 2010 07:32:00 -0500

The copy method in clojure.java.io doesn't handle java.net.URL as input.
The necessary methods can be found in the mailing list post:
[[url:http://groups.google.com/group/clojure/browse_thread/thread/24a105b12466a8e8]]

[CLJ-459] RFE: modify description of "assoc"

Thu, 14 Oct 2010 16:55:00 -0500

The documentation for "assoc" in clojure.core should probably
include

(assoc vector index val)
</code></pre>
and

<pre><code>(assoc vector index val & ivs)

in the usage line.

[CLJ-148] Poor reporting of symbol conflicts when using (ns)

Tue, 28 Jun 2011 18:42:50 -0500

I have a module that includes pprint and my own utils.

When com.howard.lewisship.cascade.dom/write was changed from private to public I get the following error:

java.lang.IllegalStateException: write already refers to: #'clojure.contrib.pprint/write in namespace: com.howardlewisship.cascade.test-views (test_views.clj:0)

(ns com.howardlewisship.cascade.test-views ; line 15
(:use
(clojure.contrib test-is pprint duck-streams)
(app1 views fragments)
(com.howardlewisship.cascade config dom view-manager)
com.howardlewisship.cascade.internal.utils))

That line number is wrong but better yet, identifying the true conflict (com.howard.lewisship.cascade.dom/write) would be even more important.

[CLJ-272] load/ns/require/use overhaul

Tue, 28 Feb 2012 03:56:11 -0600

Creating this ticket to describe various things people have wanted to change about how ns works:

Minimal needs

there should be a primitive level of loading (presumably load) that just loads without question.
the api should be unified across the ns and direct forms. No more keywords or quoting! So (use foo)</code> not <code>(use 'foo)</code>. This makes <code>use</code> et al macros, so there should also be new fn versions (maybe <code>use*).

Other possibilities to discuss.

Feature addressing the {{:like</code> and <code>:clone</code> ideas from http://onclojure.com/2010/02/17/managing-namespaces/. I think I would prefer a single new option <code>:clone</code> which allows <code>:only</code> and <code>:exclude}} features as subspecifiers.
Convenience fn to unmap all names in a namespace?

[CLJ-400] A faster flatten

Tue, 24 Aug 2010 00:19:00 -0500

As discussed in this thread, I am submitting a more performant version of flatten for review. It has the same semantics as the current core/flatten. I have also updated the doc string to say that "(flatten nil) returns the empty list", because that's what the current version of core/flatten does as well.

I haven't mailed in a CA yet, but I will tomorrow morning.

Edit: Of course I'd mess my first ticket up . I am not immediately seeing an option to edit this to add the "patch" tag or add the "ready to test" action. Sorry folks

[CLJ-190] enhance with-open to be extensible with a new close multimethod

Fri, 23 Dec 2011 06:50:59 -0600

Discussion: http://groups.google.com/group/clojure/browse_thread/thread/8e4e56f6fc65cc8e/618a893a5b2a5410

Currently, with-open calls .close when it's finished. I'd like it to have a (defmulti close type) so it's behavior is extensible. A standard method could be defined for java.io.Closeable and a :default method with no type hint. I've come across a few cases where some external library defines what is essentially a close method but names it shutdown or disable, etc., and adding my own "defmethod close" would be much easier than rewriting with-open. This would also allow people to eliminate reflection for classes like sql Connection that were created before Closeable.

[CLJ-450] Add default predicate argument to filter, every?, take-while

Fri, 27 Apr 2012 11:38:28 -0500

Some seq processing functions that take predicates could be improved by the addition of a default value of identity for the predicate argument.

This has been discussed on the mailing list, and people seem favorable:
http://groups.google.com/group/clojure/browse_thread/thread/600559b7ee261908/3bc5d144ac54854e?lnk=gst&q=filter+identity#3bc5d144ac54854e
http://groups.google.com/group/clojure-dev/browse_thread/thread/0a9b5750dd7ec4ca

I can put together a patch.

[CLJ-451] fn literals lack name/arglists/namespace metadata

Tue, 5 Oct 2010 00:29:00 -0500

I would expect (meta (fn not-so-anonymous [a b c])) to include {:name not-so-anonymous :arglists ([a b c])} alongside line number information and possibly namespace/file as well, but currently it only includes :line.

[CLJ-396] Better support for multiple inheritance in hierarchies and multimethods

Tue, 24 Aug 2010 11:06:00 -0500

While the hierarchies produced with 'derive' allow multiple parents per child, there is no way to indicate precedence between those parents, other than by laboriously specifying 'prefer-method' for every type X every multimethod. When 2 multimethods are both applicable to the supplied arguments, Clojure produces a nonspecific IllegalArgumentException containing only an error string. All this means that while Clojure does have an "inheritance" mechanism in the form of the ad hoc hierarchies, it is currently not really possible to implement multiple inheritance using the ad hoc hierarchy mechanism. 'Prefer-method' will not scale up to use in large applications with complex type hierarchies and heavy use of multimethods.

Some potential ways to solve this are:

allowing 'defmulti' to take a 'tie-breaker' function (tie-breaker [arglist speclist1 speclist2] ...) which is called instead of throwing an IllegalArgumentException, and must return the 'winning speclist'.
instead of throwing IllegalArgumentException, throw a TiedMultiMethodsException – the exception instance should contain the offending speclists, the function, and the arguments that were supplied.
allowing specification of precedence when using 'derive' (if only via a "last in = highest precedence" rule).

Paul

[CLJ-405] better error messages for bad defrecord calls

Tue, 24 Aug 2010 00:28:00 -0500

defrecord could tell you if, e.g., you didn't specify an interface before leaping into method bodies. See http://groups.google.com/group/clojure/browse_thread/thread/f52f90954edd8b09

[CLJ-379] problem with classloader when run as windows service

Tue, 24 Aug 2010 10:40:00 -0500

I found following error when I run clojure application as MS Windows service (via procrun from Apache Daemon project). When I tried to do 'require' during run-time, I got NullPointerException. This happened as baseLoader function from RT class returned null in such environment (the value of Thread.currentThread().getContextClassLoader()). (Although my app works fine when I run my application as standalone program, not as service).
This error was fixed by explicit setting of class loader with following code:

(.setContextClassLoader (Thread/currentThread) (java.lang.ClassLoader/getSystemClassLoader))

before any call to 'require'....

May be you need to modify 'baseLoader' function, so it will check is value of Thread.currentThread().getContextClassLoader() is null or not, and if null, then return value of java.lang.ClassLoader.getSystemClassLoader() ?

[CLJ-401] Promote "seqable?" from contrib?

Tue, 24 Aug 2010 09:19:00 -0500

This was vaguely discussed here and could potenntially help this ticket as well as be generally useful.

I don't speak for everyone but when I saw sequential? I assumed it would have the semantics that seqable? does. Just my opinion, I'd love to hear someone's who is more informed than mine.

In the proposed patch referenced in the ticket above, if seqable? could be used in place of sequential? flatten could be more powerful and work with maps/sets/java collections. Here's how it would look:

(defn flatten [coll]
  (lazy-seq
    (when-let [coll (seq coll)]
      (let [x (first coll)]
        (if (seqable? x)
          (concat (flatten x) (flatten (next coll)))
          (cons x (flatten (next coll))))))))

And an example:

user=> (flatten #{1 2 3 #{4 5 {6 {7 8 9 10 #�tok1-block-tok}}}})
(1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18)

[CLJ-112] GC Issue 108: All Clojure interfaces should specify CharSequence instead of String when possible

Tue, 24 Aug 2010 03:45:00 -0500

Reported by redchin, Apr 20, 2009

rhickey: unlink: then just use a map {:escaped true :val "foo"}

unlink: What I meant is, everything in between would want to see something 
String-y, not caring whether it's a String or MyString.

hiredman: unlink: if you use something that implements CharSequence and 
IMeta (I think it's IMeta) you get something that is basically a String, 
but with metadata

rhickey: what hiredman said

hiredman: ideally most things would not specify String but CharSequence in 
their interface

hiredman: but somehow I doubt that is case

unlink: ok.

unlink: Good to know.

rhickey: hiredman: unfortunately that's not true of some of Clojure - could 
you enter an issue for it please - use CharSequence when possible?

[CLJ-163] Enhance = and == docs

Tue, 24 Aug 2010 13:04:00 -0500

Enhance = and == docs as far as numbers handling is concerned (make them self referenced, make clear what == offers beyond = -except that it will only work for numbers)

[CLJ-440] java method calls cannot omit varargs

Mon, 29 Oct 2012 10:56:32 -0500

From http://groups.google.com/group/clojure/browse_thread/thread/7d0d6cb32656a621

E.g., trying to call java.util.Collections.addAll(Collection c, T... elements)

user=> (Collections/addAll [] (object-array 0))
false
user=> (Collections/addAll [])
IllegalArgumentException No matching method: addAll  clojure.lang.Compiler$StaticMethodExpr.<init> (Compiler.java:1401)

The Method class provides an isVarArg() method, which could be used to inform the compiler to process things differently.

[CLJ-19] GC Issue 15: JavaDoc for interfaces

Sat, 17 Nov 2012 20:05:58 -0600

Reported by richhickey, Dec 17, 2008
Add JavaDoc to those interfaces supported for public use - IFn,
IPersistentCollection etc.

[CLJ-274] cannot close over mutable fields (in deftype)

Fri, 1 Oct 2010 09:35:00 -0500

Simplest case:

user=>
(deftype Bench [#^{:unsynchronized-mutable true} val]
Runnable
(run [_]
(fn [] (set! val 5))))

java.lang.IllegalArgumentException: Cannot assign to non-mutable: val (NO_SOURCE_FILE:5)

Functions should be able to mutate mutable fields in their surrounding deftype (just like inner classes do in Java).

Filed as bug, because the loop special form expands into a fn form sometimes:

user=>
(deftype Bench [#^{:unsynchronized-mutable true} val]
Runnable
(run [_]
(let [x (loop [] (set! val 5))])))
java.lang.IllegalArgumentException: Cannot assign to non-mutable: val (NO_SOURCE_FILE:9)

[CLJ-15] GC Issue 11: incremental hashcode calculation for collections

Fri, 8 Mar 2013 06:20:08 -0600

Reported by richhickey, Dec 17, 2008
So hachCode can be final, more efficient to calc as you go.

[CLJ-259] clojure.lang.Reflector.invokeMatchingMethod is not complete (rejects pontentially valid method invocations)

Tue, 24 Aug 2010 15:12:00 -0500

There exists invoke expressions on instances, where Java is able to perform the call, yet clojure is not reflectively.
The problem is when the declaringClass of the found method is not public then the call to getAsMethodOfPublicBase uses the found method or searching for classes/interfaces that contain/define this method yet are declared publicly.

This restricts the possible search space. I suggest that if target is not null (e.g. is not a static method), the target.getClass() should be used instead as a root for getAsMethodOfPublicBase.
This fixes my issue.

[CLJ-1001] Proxy cannot call proper super-class method

Wed, 23 May 2012 22:24:43 -0500

Attached is a program that reproduces this issue. We have a proxy, `p', which sub-classes java.io.InputStream. There are three methods named `read' in java.io.InputStream: abstract int read(); int read(byte[] b); and int read(byte[] b, int off, int len); see http://docs.oracle.com/javase/6/docs/api/java/io/InputStream.html. In the definition of proxy `p', we implement the abstract variant of method `read', making `p' a concrete instance of java.io.InputStream.

The first invocation, (. p read), returns -1, which is expected.

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

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

[CLJ-698] class accessible from deftype method bodies is not suitable for instance?, ...

Wed, 29 Dec 2010 12:45:45 -0600

Example interaction: http://pastebin.com/cTdUCKfp
Which directly contradicts documentation for deftype

In the method bodies, the (unqualified) name can be used to name the class (for calls to new, instance? etc).

[CLJ-740] Unnecessary boxing of primitives in case form

Tue, 1 Mar 2011 02:51:43 -0600

Found this while profiling some performance-critical code.

Consider the following Clojure function:

(defn test-case ^double [^long i ^double d1 ^double d2]
  (case (int i)
    0 d1
    d2))

Current Clojure 1.3 snapshot compiles it to:

public final double invokePrim(long, double, double)   throws java.lang.Exception;
  Code:
   0:	lload_1
   1:	invokestatic	#67; //Method clojure/lang/RT.intCast:(J)I
   4:	istore	7
   6:	iload	7
   8:	i2l
   9:	invokestatic	#73; //Method clojure/lang/Numbers.num:(J)Ljava/lang/Number;
   12:	invokestatic	#79; //Method clojure/lang/Util.hash:(Ljava/lang/Object;)I
   15:	iconst_0
   16:	ishr
   17:	iconst_1
   18:	iand
   19:	tableswitch{ //0 to 0
		0: 36;
		default: 58 }
   36:	iload	7
   38:	i2l
   39:	invokestatic	#73; //Method clojure/lang/Numbers.num:(J)Ljava/lang/Number;
   42:	getstatic	#45; //Field const__3:Ljava/lang/Object;
   45:	invokestatic	#83; //Method clojure/lang/Util.equals:(Ljava/lang/Object;Ljava/lang/Object;)Z
   48:	ifeq	58
   51:	dload_3
   52:	invokestatic	#88; //Method java/lang/Double.valueOf:(D)Ljava/lang/Double;
   55:	goto	63
   58:	dload	5
   60:	invokestatic	#88; //Method java/lang/Double.valueOf:(D)Ljava/lang/Double;
   63:	checkcast	#92; //class java/lang/Number
   66:	invokevirtual	#96; //Method java/lang/Number.doubleValue:()D
   69:	dreturn
}

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

At 60-66 primitive double is boxed into Double only to be converted back into primitive.

The equivalent Java code compiles to much simpler and faster bytecode:

public double testCase(long, double, double);
  Code:
   0:	lload_1
   1:	l2i
   2:	lookupswitch{ //1
		0: 20;
		default: 22 }
   20:	dload_3
   21:	dreturn
   22:	dload	5
   24:	dreturn
}

[CLJ-760] ClassNotFound when AOT compiling a self-referring deftype extended to a protocol

Fri, 18 Mar 2011 10:27:46 -0500

If I create a deftype that refers to itself in a protocol extension like below:

(ns type-test)

(defprotocol Foo
  (isa-foo [x]))

(deftype TypeTest []
  Foo
  (isa-foo [x]
           (instance? TypeTest x)))

And use that code via another namespace:

(ns test-type-user
  (:use [type-test :only (isa-foo)])
  (:import [type-test TypeTest]))

(isa-foo (TypeTest.))

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

This came up in a test at Revelytix. We worked around this issue by not using instance? and instead comparing based on class name. Another workaround is to define the deftype and the extension separately (using extend-type or something similar). This problem also doesn't occur if the usage of the deftype and the definition of it are in the same namespace (i.e. if type-test and test-type-user were in the same file).

[CLJ-864] defrecord positional arity factory fn should have an inline version that calls the record constructor

Wed, 26 Oct 2011 03:17:55 -0500

defrecord positional arity factory fn should have an inline version that calls the record constructor

[CLJ-1046] Drop-while as a reducer

Sat, 18 Aug 2012 19:11:59 -0500

Implement drop-while as a reducer. Follows the same atom-based strategy as drop and take.

Does not depend on any of my other reducer patches, but there will probably be some minor merge conflicts unless it is merged after CLJ-1045, and before CLJ-992 and CLJ-993.

[CLJ-887] Error when calling primitive functions with destructuring in the arg vector

Tue, 29 Nov 2011 15:48:19 -0600

If one defines a primitive-taking function with destructuring, calling that function will result in a ClassCastException, IFF the primitive return-type hint is present.

Clojure 1.4.0-master-SNAPSHOT
user=> (defn foo [[a b] ^long x ^long y] 0)
#'user/foo
user=> (foo [1 2] 3 4)
0
user=> (defn foo ^long [[a b] ^long x ^long y] 0)
#'user/foo
user=> (foo [1 2] 3 4)
ClassCastException user$foo cannot be cast to clojure.lang.IFn$OLLL  user/eval9 (NO_SOURCE_FILE:4)
user=> (pst)
ClassCastException user$foo cannot be cast to clojure.lang.IFn$OLLL
	user/eval9 (NO_SOURCE_FILE:4)
	clojure.lang.Compiler.eval (Compiler.java:6493)
	clojure.lang.Compiler.eval (Compiler.java:6459)
	clojure.core/eval (core.clj:2796)
	clojure.main/repl/read-eval-print--5967 (main.clj:244)
	clojure.main/repl/fn--5972 (main.clj:265)
	clojure.main/repl (main.clj:265)
	clojure.main/repl-opt (main.clj:331)
	clojure.main/main (main.clj:427)
	clojure.lang.Var.invoke (Var.java:397)
	clojure.lang.Var.applyTo (Var.java:518)
	clojure.main.main (main.java:37)
nil

[CLJ-884] Reflector error messages can be improved when no matching method is found.

Fri, 23 Mar 2012 01:14:18 -0500

When accessing a java method with an arity mismatch or a mismatched parameter type, Reflector.java returns the following error on REPL:
IllegalArgumentException No matching method found: xyz for class com.abc.MyClass

eventhough method xyz might exist on MyClass, but was being called with the wrong number of arguments.

Attached is a patch that fixes that problem.

[CLJ-1016] Global scope overrides lexical scope for classes (Clojure assumes no classes in default package / Clojure cannot handle yFiles JARs in classpath)

Mon, 27 Aug 2012 21:24:13 -0500

The most visible symptom of this bug is having a class named 'w' (default package) in your classpath (such classes are produced by Java obfuscation tools such as yFiles) and then attempting to load Clojure's core class. For example:

java -cp hotspotapi.jar:clojure-1.4.0-slim.jar clojure.main

(where hotspotapi.jar is a stereotypical example of an obfuscated JAR) results in:

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

To understand what is going on, consider this simple test:

import java.io.StringReader;

import clojure.lang.Compiler;
import clojure.lang.RT;

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

It should be clear that 'mumble' in the dot operator is referencing the locally defined mumble. However, if we define a class named 'mumble' in the default package, Clojure picks that one up instead.

To forestall any objections: yes, we know that placing classes in the default package is extremely poor form. Point of the matter is, the Java ecosystem is extremely diverse and there are a lot of JARs people may not have control over. While one might argue, "Don't put classes in the default namespace", point of the matter is, Clojure is wrong here, and these situations arise in practice, through no fault of the implementer.

[CLJ-959] after call to clojure.java.shell/sh, jvm won't exit

Fri, 8 Jun 2012 12:47:07 -0500

Create the following four-line file, shell_example.clj:

;; simple example of call to sh that causes jvm to hang after print
(require '[clojure.java.shell :as shell])
(shell/sh "ls")
(println "jvm should exit after this, but it doesn't")

Run:
java -jar clojure-1.3.0.jar shell_example.clj

After the message is printed, the jvm doesn't quit. It just sits there. I have to hit Ctrl-C to force the jvm to quit.

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

My workaround right now is to do (System/exit 0) to force the jvm to quit.

Thank you for your work on Clojure, it's simply an amazing language.

[CLJ-1013] Clojure's classloader cannot handle out-of-order loading

Wed, 13 Jun 2012 15:21:42 -0500

Here is a minimal test-case:

import java.io.IOException;

import clojure.lang.PersistentTreeMap;
import clojure.lang.RT;

public class TestClass {

static Class y = RT.class;
//static PersistentTreeMap x = PersistentTreeMap.EMPTY;

/**

@param args
@throws ClassNotFoundException
@throws IOException
*/
public static void main(String[] args) throws IOException, ClassNotFoundException { PersistentTreeMap x = PersistentTreeMap.EMPTY; }

}

This results in the exception:

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

The crux of the issue appears Clojure's classloader doesn't understand how to handle out-of-order classloading.

[CLJ-968] ns emitting gen-class before imports results in imported annotations being discarded.

Mon, 9 Apr 2012 15:38:07 -0500

The following discards the imported annotations:

(ns com.example.BaseXModuleTest
  (:import (org.basex.query QueryModule QueryModule$Deterministic))
  (:gen-class
     :extends org.basex.query.QueryModule
     :methods [
       [^{QueryModule$Deterministic {}}
        addOne [int] int]]))

However, when moving the gen-class call out of the ns declaration, the annotation is correctly applied:

(ns com.example.BaseXModuleTest
  (:import (org.basex.query QueryModule QueryModule$Deterministic)))

(gen-class
  :extends org.basex.query.QueryModule
  :name com.example.BaseXModuleTest
  :methods [
    [^{QueryModule$Deterministic {}}
     addOne [int] int]])

It appears that imported names are not yet in-scope when gen-class is run from a ns declaration.

[CLJ-969] Symbol/keyword implements IFn for lookup but a non-collection argument produces non-intuitive results

Mon, 9 Apr 2012 17:29:03 -0500

('+ 1 2) ;; return 2 because it is treated as (get 1 '+ 2)

Whilst this is "consistent" once you know the lookup behavior, it's confusing for Clojure newbies and it seems to be a non-useful behavior.

Proposal: modify Keyword.invoke() and Symbol.invoke() to restrict first Object argument to instanceof ILookup, Map or IPersistentSet (or null) so that the "not found" behavior doesn't produce non-intuitive behavior.

[CLJ-971] Jar within a jar throws a runtime error

Tue, 10 Apr 2012 22:39:36 -0500

I've created two jar files in my multi-project Maven setup. The first jar is the "engine", and it includes the clojure jar in it. The other jar is the "application". It includes the engine and then packages itself into a one-jar jar file. This means we have a jar within a jar: The "onejar" contains the engine jar, which in turn contains that clojure jar.

I then get an error in the runtime:

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

See also my Stack Overflow question on this at http://stackoverflow.com/questions/7763480/making-an-executable-jar-that-evals-clojure-strings

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

I've found that adding a null check solves the problem. My lastModified looks like this now:

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

return url.openConnection().getLastModified();
}

This runs successfully.

If you'd prefer, I can submit a patch, or commit directly.

[CLJ-903] extend-protocol does not allow classnames as a String

Fri, 30 Dec 2011 17:17:12 -0600

In various places Clojure accepts classnames as String, eg. in gen-class or type hints. However it does not in extend-protocol. This does not allow simple specification of array types.

[CLJ-1022] gen-class destroys method annotations

Tue, 3 Jul 2012 06:19:26 -0500

When extending a class gen-class doesn't preserve method annotations.

If class com.bar.Foo has annotated methods then in MyClass all annotations are gone.

(gen-class
:name com.my.MyClass
:extends com.bar.Foo
:implements [com.google.common.base.Supplier]
:prefix demo-
:post-init post-init)

(defn demo-post-init [this]
(info "initialized")
(swank.swank/start-server :port 68478))

(defn demo-get [_]
(get-msg))

Class<?> aClass = Class.forName("com.my.MyClass");
Method[] methods = aClass.getMethods();

for (Method m : methods) {
Annotation[] annotations = m.getAnnotations();
System.out.println(m.getName()+" "+annotations.length);
for (Annotation a : annotations) { System.out.println(a.annotationType().getClass().getName()); }
}

[CLJ-911] 'proxy' prevents overriding Object.finalize (and doesn't document it)

Mon, 16 Jan 2012 08:36:27 -0600

It appears to be impossible to override Object.finalize() using proxy. If the method is defined using proxy, then it cannot be called straightforwardly (see below), and it is not called as a finalizer during normal program execution (not demonstrated below).

See extensive discussion at: https://groups.google.com/group/clojure/browse_thread/thread/a1e2fca45af6c1af

user=> (def m (proxy [java.util.HashMap] []
(finalize []
;(proxy-super finalize)
(prn "finalizing..."))
(hashCode []
99)))
#'user/m
user=> (.hashCode m)
99
user=> (.finalize m)
IllegalArgumentException No matching field found: finalize for class user.proxy$java.util.HashMap$0 clojure.lang.Reflector.getInstanceField (Reflector.java:289)

There is at least one of two bugs here (thanks to Cedric Greevey for summarising this way):

If the inability to override finalize() is unintentional, that's a bug.
If it's intentional for some reason, then (a) that's not documented, and (b) the failure is silent, in the sense that an explicit call produces an apparently completely unrelated error (above), and the failure to call the method during object finalization is completely silent.

[CLJ-1037] Allow doc strings for both interfaces and concrete implementations

Sat, 4 Aug 2012 10:30:53 -0500

In this post
http://groups.google.com/group/clojure/browse_thread/thread/84de74740928da76#

I mentioned the rationale (I think) why this is important and needed. Thank you for consideration.

[CLJ-986] Adds an exit function to exit clojure process

Sun, 6 May 2012 21:25:57 -0500

There is no standard function to exit the clojure process.
In java implementation,we use (System/exit 0),but in other implementations(CLR), i have to use another function.

Why not add a standard function in clojure.core?
For example:

(defn exit
([] (exit 0)
([status] (System/exit status)))

I think it's useful for us.

[CLJ-919] cannot create anonymous primitive functions

Fri, 27 Jan 2012 16:48:42 -0600

Primitive functions only work (e.g. return primitive types) when defined with `defn`. An equivalent function created with `fn` does not behave the same way as when created with `defn`. For example:

(definterface IPrimitiveTester
(getType [^int x])
(getType [^long x])
(getType [^float x])
(getType [^double x])
(getType [^Object x]))

(deftype PrimitiveTester []
IPrimitiveTester
(getType [this ^int x] :int)
(getType [this ^long x] :long)
(getType [this ^float x] :float)
(getType [this ^double x] :double)
(getType [this ^Object x] :object))

(defmacro pt [x]
`(.getType (PrimitiveTester.) ~x))

(defn with-defn ^double [^double x]
(+ x 0.5))

(pt (with-defn 1.0)) ; => :double

(let [a (fn ^double [^double x] (+ x 0.5))]
(pt (a 0.1))) ; => :object

Please see the discussion on the mailing list for more details and thoughts on what is happening:
http://groups.google.com/group/clojure/browse_thread/thread/d83c8643a7c7d595?hl=en

[CLJ-979] map->R returns different class when invoked from AOT ccode

Sun, 13 May 2012 22:35:35 -0500

(defrecord Dontwork [a])

(= (type (Dontwork. nil))
(type (map->Dontwork {:a 1})))

Will return true if the namespace is not AOT compiled and false if it is.

I have created a small example project with AOT and non-AOT namespaces to demonstrate
https://github.com/ejackson/aotquestion

[CLJ-792] Refactor method resolution code out of Compiler and into Reflector

Mon, 20 Feb 2012 13:11:06 -0600

Issues:

Code for obtaining method/constructor instances is duplicated across the Compiler
Code for resolving a preferred overloaded method lives in the Compiler

By consolidating the duplicated code, moving the reflection-related parts into Reflector, and providing a straightforward API, it should be easier to read and understand the method resolution process. Further, improvements to (e.g., CLJ-445) the mechanism for reflecting on class members can largely be isolated from the Compiler. And the few points of coordination (e.g., Compiler emitting same arg and return types as Reflector does when invoking) can be clearly identified and documented.

[CLJ-994] repeat reducer

Fri, 14 Sep 2012 14:37:35 -0500

i'm working on clojure.core/repeat reducer.

[CLJ-995] sorted-set doesn't support IEditableCollection

Mon, 4 Jun 2012 02:32:56 -0500

I think sorted-set (PersistentTreeSet) should implement the transient interface. It's a special-purpose set and should be usable just like every normal set.

[CLJ-1081] REPL binding not working that works with with-bindings

Mon, 1 Oct 2012 05:51:46 -0500

This works as expected:

java -jar clojure-1.4.0.jar -e "(do (require 'clojure.repl) (.setDynamic #'clojure.repl/print-doc) (with-bindings {#'clojure.repl/print-doc str} (eval '(clojure.repl/doc println))))"

Output:

"{:ns #<Namespace clojure.core>, :name println, :arglists ([& more]), :added \"1.0\", :static true, :doc \"Same as print followed by (newline)\", :line 3325, :file \"clojure/core.clj\"}"

But the same thing does not work in the REPL:

java -jar clojure-1.4.0.jar -e "(do (require 'clojure.repl) (.setDynamic #'clojure.repl/print-doc) (clojure.main/repl :init (fn [] {#'clojure.repl/print-doc str}))))"

Output for Output of {{(doc println)}}:

user=> (doc println)
-------------------------
clojure.core/println
([& more])
Same as print followed by (newline)
nil
user=>

[CLJ-1077] thread-bound? returns true (implying set! should succeed) even for non-binding thread

Mon, 1 Oct 2012 11:57:10 -0500

thread-bound? returns true for a non-binding thread, this result (according to the docstring) implies that set! should succeed. However, thread-bound? does not check that any binding that might exist was created by the current thread, and calling set! fails with an exception when it is called from a non-binding thread, even though thread-bound? returns true.

thread-bound? should return false if there is a binding, and that binding was not established by the current thread.

[CLJ-790] Primitive type hints on function names should print error message

Tue, 10 May 2011 12:11:37 -0500

Functions returning primitives are hinted with metadata on the argument list, not on the function name. Using a primitive type hint on a function name should print an error message.

Currently, misplaced primitive hints are read without error.

[CLJ-992] `iterate` reducer

Fri, 12 Oct 2012 08:10:52 -0500

Added a reducer implementation mirroring clojure.core/iterate.

[CLJ-666] Add support for Big* numeric types to Reflector

Thu, 15 Nov 2012 20:07:39 -0600

This should work as expected, for example:

(Integer. 1N)

Probably for BigInt, BigInteger, and BigDecimal.

Method to look at is c.l.Reflector.paramArgTypeMatch, per Rich in irc.

[CLJ-415] smarter assert (prints locals)

Sun, 18 Nov 2012 01:06:07 -0600

Here is an implementation you can paste into a repl. Feedback wanted:

(defn ^{:private true} local-bindings
  "Produces a map of the names of local bindings to their values."
  [env]
  (let [symbols (map key env)]
    (zipmap (map (fn [sym] `(quote ~sym)) symbols) symbols)))

(defmacro assert
  "Evaluates expr and throws an exception if it does not evaluate to
 logical true."
  {:added "1.0"}
  [x]
  (when *assert*
    (let [bindings (local-bindings &env)]
      `(when-not ~x
         (let [sep# (System/getProperty "line.separator")]
           (throw (AssertionError. (apply str "Assert failed: " (pr-str '~x) sep#
                                          (map (fn [[k# v#]] (str "\t" k# " : " v# sep#)) ~bindings)))))))))

[CLJ-457] lazy recursive definition giving incorrect results

Mon, 3 Dec 2012 11:21:29 -0600

If you define a global data var in terms of a lazy sequence referring to that same var, you can get different results depending on the chunkiness of laziness of the functions being used to build the collection.

Clojure's lazy sequences don't promise to support this, but they shouldn't return wrong answers. In the example given in http://groups.google.com/group/clojure/browse_thread/thread/1c342fad8461602d (and repeated below), Clojure should not return bad data. An error message would be good, and even an infinite loop would be more reasonable than the current behavior.

(Similar issue reported here: https://groups.google.com/d/topic/clojure/yD941fIxhyE/discussion)

(def nums (drop 2 (range)))
(def primes (cons (first nums)
             (lazy-seq (->>
               (rest nums)
               (remove
                 (fn [x]
                   (let [dividors (take-while #(<= (* % %) x)
primes)]
                     (println (str "primes = " primes))
                     (some #(= 0 (rem x %)) dividors))))))))
(take 5 primes)

It prints out:
(primes = (2)
primes = (2)
primes = (2)
primes = (2)
primes = (2)
primes = (2)
primes = (2)
primes = (2)
primes = (2)
primes = (2)
primes = (2)
primes = (2)
primes = (2)
primes = (2)
primes = (2)
primes = (2)
primes = (2)
primes = (2)
primes = (2)
primes = (2)
primes = (2)
primes = (2)
primes = (2)
primes = (2)
primes = (2)
primes = (2)
primes = (2)
primes = (2)
primes = (2)
2 3 5 7 9)

[CLJ-993] `range` reducer

Sat, 18 Aug 2012 19:18:48 -0500

Rich mentioned in IRC today he'd welcome a reducer implementation of clojure.core/range. Now that I've figured out how to do iterate, I figure I'll knock out range as well by the end of the night. Just opening the issue early to announce my intentions to anyone else interested in doing it.

[CLJ-1059] PersistentQueue doesn't implement java.util.List, causing nontransitive equality

Tue, 11 Dec 2012 13:58:01 -0600

PersistentQueue implements Sequential but doesn't implement java.util.List. Lists form an equality partition, as do Sequentials. This means that you can end up with nontransitive equality:

(def q (conj clojure.lang.PersistentQueue/EMPTY 1 2 3))
;=> #user/q
(def al (doto (java.util.ArrayList.) (.add 1) (.add 2) (.add 3)))
;=> #user/al
(def v [1 2 3])
;=> #user/v
(= al v)
;=> true
(= v q)
;=> true
(not= al q)
;=> true

This happens because PersistentQueue is a Sequential but not a List, ArrayList is a List but not a Sequential, and PersistentVector is both.

[CLJ-2] Scopes

Thu, 8 Mar 2012 04:01:38 -0600

Add the scope system for dealing with resource lifetime management

[CLJ-939] Exceptions thrown in the top level ns form are reported without file or line number

Sat, 15 Dec 2012 07:50:03 -0600

If there is an error in the `ns` form, an exception is thrown, which is not caught in `load`.

For example, with an invalid :only clause;

(ns clj14.myns
  (:use
   [clojure.core :only seq]))

This generates a Don't know how to create ISeq from: clojure.lang.Symbol exception, with source file or line number.

[CLJ-899] Accept and ignore colon between key and value in map literals

Wed, 19 Dec 2012 07:55:59 -0600

Original title was 'treat colons as whitespace' which isn't a problem description but a (flawed) implementation approach

For JSON compatibility
known problems when no spaces - x:true and y:false

[CLJ-1136] Type hinting for array classes does not work in binding forms

Fri, 21 Dec 2012 11:09:56 -0600

Type hints don't work as expected in binding forms.

The following form results in a reflection warning:

(let [^{:tag (Class/forName "[Ljava.lang.Object;")} a (make-array Object 2)]
(aget a 0))

However, hinting does appear to work correctly on vars:

(def ^{:tag (Class/forName "[Ljava.lang.Object;")} a (make-array Object 2))
(aget a 0) ;; no reflection warning

[CLJ-1108] Allow to specify an Executor instance to be used with future-call

Thu, 27 Dec 2012 02:25:43 -0600

This adds an arity to future-call that expects a java.util.concurrent/ExecutorService instance to be used instead of clojure.lang.Agent/soloExecutor.

[CLJ-1142] Incorrect divide-by-zero error with floating point numbers

Tue, 8 Jan 2013 23:22:50 -0600

The unary call for clojure.core// treats a dividend of 0.0 differently than the binary call, likely due to inlining.

(/ 0.0) ;; java.lang.ArithmeticException: Divide by zero
(/ 1 0.0) ;;= Infinity
(/ 1 (identity 0.0)) ;; java.lang.ArithmeticException: Divide by zero

[CLJ-840] Add a way to access the current test var in :each fixtures for clojure.test

Fri, 18 Jan 2013 09:47:53 -0600

When looking at (log) output from tests written with clojure.test, I would like to be able to identify the output associated with each test. A mechanism to expose the current test var within an :each fixture would enable this.

One mechanism might be to bind a test-var var with the current test var before calling the each-fixture-fn in clojure.test/test-all-vars.

[CLJ-825] Protocol implementation inconsistencies

Mon, 8 Aug 2011 12:35:38 -0500

There seems to be some inconsistencies when implementing protocols that have multi arity functions depending on how the protocol is implemented. I have attached a clj file illustrating this. The short version is that multi arity must be defined as such w/ defrecord:

(defrecord Zomg []
SomeProto
(hello [_] 1)
(hello [_ _] 1))

And as such with extend-type

(extend-type Object
SomeProto
(hello
([_] 1)
([_ _] 1)))

I have only tested defrecord & extend-type. I am unsure how it works with deftype and extend-protocol.

[CLJ-1045] Generalize/refactor implementation of PersistentVector/coll-fold

Fri, 25 Jan 2013 14:29:31 -0600

Vector currently contains a specialized implementation of the folding algorithm "split the collection in half until the pieces are small enough". The attached commit lifts out the general strategy so that it can be reused by other collection types amenable to splitting.

CLJ-993 depends on this patch, as it uses the new fold-by-halves function.

[CLJ-1096] Make destrucring emit direct keyword lookups

Sat, 26 Jan 2013 08:15:49 -0600

Currently associative destructuring emits calls to get. The attached patch modify desctruture to emit direct keyword lookups when possible.

Approved here https://groups.google.com/d/msg/clojure-dev/MaYcHQck8VA/nauMus4mzPgJ

[CLJ-978] bean unable to handle non-public classes

Thu, 29 Nov 2012 10:01:49 -0600

Take the following Java as an example:

public interface IFoo {
  String getBar();
}

class FooImpl {
  String getBar() { return "bar"; }
}

As presently implemented, (bean my-foo) tries to invoke the following:

(. #<Method public java.lang.String FooImpl.getBar> (invoke my-foo nil))

However, as FooImpl is not public, this fails:

java.lang.IllegalAccessException: Class clojure.core$bean$fn__1827$fn__1828 can not access a member of class FooImpl with modifiers "public"
 at sun.reflect.Reflection.ensureMemberAccess (Reflection.java:65)
    java.lang.reflect.Method.invoke (Method.java:588)
    clojure.core$bean$fn__1827$fn__1828.invoke (core_proxy.clj:382)
    clojure.core$bean$v__1832.invoke (core_proxy.clj:388)
    clojure.core$bean$fn__1838$thisfn__1839$fn__1840.invoke (core_proxy.clj:406)
    clojure.lang.LazySeq.sval (LazySeq.java:42)
    clojure.lang.LazySeq.seq (LazySeq.java:60)
    clojure.lang.RT.seq (RT.java:473)

However, the same thing succeeds if we call #<Method public java.lang.String Foo.getBar> rather than #<Method public java.lang.String FooImpl.getBar>.

[CLJ-1079] Don't squash explicit :line and :column metadata in the MetaReader

Thu, 7 Feb 2013 12:35:21 -0600

I have been experimenting with using cljx to produce Clojure and ClojureScript source from a single file. This has gone well so far, with the exception that, due to the way the source transformation works, all of the linebreaks and other formatting is gone from the output. There is an option to include the original :line metadata in the output though, like so:

;;This file autogenerated from 
;;
;;  src/cljx/com/foo/hosty.cljx
;;
^{:line 1} (ns com.foo.hosty)
^{:line 3} (defn ^{:clj true} system-hash [x] ^{:line 5} (System/identityHashCode x))

(Hopefully, such hackery won't be necessary in the future with sjacket or something like it...)

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

=> (meta (read (clojure.lang.LineNumberingPushbackReader.
                 (java.io.StringReader. "^{:line 66} ()"))))
{:line 1}
=> (meta (read (java.io.PushbackReader.
                 (java.io.StringReader. "^{:line 66} ()"))))
{:line 66}

The latter seems more correct to me (and is equivalent to read-string).

[CLJ-859] Built in dynamic vars don't have :dynamic metadata

Fri, 24 Feb 2012 12:41:31 -0600

I'm sure 'built in' is probably not the right term here, but I'm not sure what these are called.

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

user=> (meta #'*err*)
{:ns #<Namespace clojure.core>, :name *err*, :added "1.0", :doc "A java.io.Writer object representing standard error for print operations.\n\n  Defaults to System/err, wrapped in a PrintWriter"}
user=> (meta #'*in*)
{:ns #<Namespace clojure.core>, :name *in*, :added "1.0", :doc "A java.io.Reader object representing standard input for read operations.\n\n  Defaults to System/in, wrapped in a LineNumberingPushbackReader"}
user=> (meta #'*out*)
{:ns #<Namespace clojure.core>, :name *out*, :added "1.0", :doc "A java.io.Writer object representing standard output for print operations.\n\n  Defaults to System/out, wrapped in an OutputStreamWriter", :tag java.io.Writer}
user=> (meta #'*ns*)
{:ns #<Namespace clojure.core>, :name *ns*, :added "1.0", :doc "A clojure.lang.Namespace object representing the current namespace.", :tag clojure.lang.Namespace}

[CLJ-1100] Reader literals cannot contain periods

Thu, 14 Feb 2013 15:04:53 -0600

The LispReader tries to read a record instead of a literal if the tag contains periods:

https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/LispReader.java#L1171

Which effectively means that reader tags cannot contain periods.
The EDN spec is unclear on this:

edn supports extensibility through a simple mechanism. # followed immediately by a symbol starting with an alphabetic character indicates that that symbol is a tag.

(issue opened: https://github.com/edn-format/edn/issues/39)

If periods are allowed, then the LispReader should first check to see if the tag is in *data-readers* and only then if not try to initialize a Java class.

I'm happy to write the patch if this behavior is what is desired.

[CLJ-366] Multiplatform command-line clojure launcher

Fri, 10 Dec 2010 10:13:46 -0600

Clojure needs a lower barrier of entry, long java commands scare people away! We need a script that conveniently launches a clojure repl or executes clojure files, much like the ruby/python/perl/other-favorite-interpreted-language behavior.

NOTES:

From Russ Olson (regarding Dejure/Dejour):

I just fixed a bunch of bugs in the script, so make sure you get the latest from download from: http://github.com/russolsen/dejour
After looking at jruby, scala, and groovy, it seems that the only way to do this right on windows is to write a C or C++ program and have a .exe.

[CLJ-949] let undeclared exceptions continue unchecked

Fri, 1 Mar 2013 09:37:59 -0600

The recent modifications regarding checked exceptions have eliminated the need for several try/catch blocks. This commit removes the blocks that no longer serve a purpose.

[CLJ-1160] reducers/mapcat ignores Reduced

Fri, 1 Mar 2013 09:40:09 -0600

The following code throws an exception:

(->> (concat (range 100) (lazy-seq (throw (Exception. "Too eager"))))
(r/mapcat (juxt inc str))
(r/take 5)
(into []))

This is because r/mapcat introduces an intermediate reduce which swallows the reduced value coming from r/take.

[CLJ-705] Make sorted maps and sets implement j.u.SortedMap and SortedSet interfaces

Sat, 2 Jun 2012 14:29:11 -0500

Make sorted maps and sets implement j.u.SortedMap and SortedSet interfaces

[CLJ-1076] pprint tests fail on Windows, expecting \n

Sat, 2 Mar 2013 14:51:46 -0600

New pprint tests were committed recently, but they fail on Windows because the tests check for \n, while pprint seems to output \r\n. A log with the test failures is attached.

The first failing commit is https://github.com/clojure/clojure/commit/4ca0f7ea17888ba7ed56d2fde0bc2d6397e8e1c0

[CLJ-1180] defprotocol doesn't resolve tag classnames

Sun, 10 Mar 2013 17:56:10 -0500

defprotocol doesn't resolve tag classnames, this results in exceptions being thrown when the declared protocol uses as a tag an imported class that is not imported in the namespace that uses it.

user=> (import 'clojure.lang.ISeq)
clojure.lang.ISeq
user=> (defprotocol p (^ISeq f [_]))
p
user=> (ns x)
nil
x=> (defn x [y] (let [z (user/f y)] (inc z)))
CompilerException java.lang.IllegalArgumentException: Unable to resolve classname: ISeq, compiling:(NO_SOURCE_PATH:4:33)

[CLJ-1181] clojure.pprint/code-dispatch breaks on certain types of anonymous functions

Mon, 18 Mar 2013 17:40:31 -0500

(with-out-str 
  (with-pprint-dispatch code-dispatch 
                        (pp/pprint (read-string "(fn* [x] x)"))))

breaks because the format string here: https://github.com/clojure/clojure/blob/master/src/clj/clojure/pprint/dispatch.clj#L378 expects a sequence. In the case of (fn* [x] x) it is passed a symbol.

[CLJ-200] Extend cond to support inline let, much like for

Sun, 2 Dec 2012 19:35:37 -0600

I find it occasionally very useful to do a few tests in a cond, then introduce some new symbols (for both clarity and efficiency) that can be referenced in later tests (or matching expressions). This parallels similar functionality inside the for macro, where the :let keyword is matched against a vector of symbol bindings and forms an implicit let around the remainder of the comprehension.

I'll be adding a patch for this shortly.

[CLJ-865] Macroexpansion discards &form metadata

Wed, 6 Jun 2012 17:29:38 -0500

As discussed in http://groups.google.com/group/clojure/browse_thread/thread/2690cb6ca0e8beb8 there is a "surprise factor" when type-hinting an expression that represents a macro, such as with (.length ^String (doto (identity "x") prn)). Here the doto macro discards the metadata on &form, causing a reflective lookup. This has the effect that while expressions representing function calls can be type-hinted, expressions representing macros in general cannot. The doto macro could be rewritten to respect its &form metadata, but doing this for every macro in existence would be tedious and error-prone. Instead, I propose a change to the compiler, to cause macroexpansion to hang onto the metadata automatically.

The first patch attached adds a test for the behavior I propose: this test fails. After applying the second patch, the test passes.

There are a couple points that merit further consideration before accepting my patch:

I'm not sure I actually got the Java code formatted correctly. My editor is not well-configured to get the clojure/core style right automatically.
My solution is to take the &form metadata, drop :line/:file keys, and then merge with the returned metadata, with &form taking precedence. I'm not sure whether this is the right approach in all cases, even though it works for :tag metadata.
I achieved this with a change to the compiler, which makes it fairly heavy-weight. It should be possible to instead adjust defmacro if changes to the compiler are not desirable. However, I believe this would involve substantially more work and be harder to test (for example, multiple arities complicate things). It seems nicer to treat the macroexpansion as a black box and then make metadata tweaks to the result, rather than modifying their actual defmacro code.
If a macro expands to something that is not an IObj, such as an Integer, then my patch silently discards the caller's metadata. Would it be better to throw an exception?

[CLJ-700] contains? broken for TransientMaps

Tue, 28 Aug 2012 17:48:49 -0500

(contains? (transient {:x "fine"}) :x)

false

also

(contains? (transient (hash-map :x "fine")) :x)

false

[CLJ-1165] Forbid varargs defprotocol/definterface method declarations because those cannot be defined anyway

Thu, 4 Apr 2013 19:24:27 -0500

Protocol, interface method declarations don't allow for varags. Currently, for example

  (defprotocol FooBar
    (foo [this & more]))

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

Similarly, providing method implementations via defrecord, deftype, and reify
don't allow for varags (but dynamic extensions via extend do).

So this patch makes defprotocol and definterface throw an
IllegalArgumentException if a user tries to use varargs in method signatures.

Similarly, defrecord, deftype, and reify throw an IllegalArgumentException if
any method implementation arglist contains a varargs argument.

This patch is a cut-down variant of my patch to http://dev.clojure.org/jira/browse/CLJ-1024
which has been reverted shortly before Clojure 1.5 was released. The ~~CLJ-1024~~ patch
was the same as this one, but it has also forbidden destructuring in defprotocol and
definterface. This was a bit too much, because although destructuring has no
semantic meaning with method declarations, it still can serve a documentation purpose.

This has been discussed on the list: https://groups.google.com/d/topic/clojure-dev/qjkW-cv8nog/discussion

[CLJ-1197] Allow fold to parallelize over lazy sequences

Wed, 10 Apr 2013 10:34:09 -0500

This patch implements foldable-seq, which allows fold to parallelize over a lazy sequence. See this conversation on the Clojure mailing list:

https://groups.google.com/forum/#!msg/clojure/8RKCjF00ukQ/b5mmmOB5Uh4J

The patch is code only, sadly. No tests because I've not been able to find any existing tests for fold:

https://groups.google.com/d/msg/clojure-dev/plQ16L1_FC0/CIyMVIgSZkkJ

However, I have tested it in a separate project successfully.

[CLJ-1005] Use transient map in zipmap

Thu, 11 Apr 2013 18:19:28 -0500

The attached patch changes zipmap to use a transient map internally. The definition is also moved so that it resides below that of #'transient. The original definition is commented out (like that of #'into).

[CLJ-1036] Util/hasheq should be hashing a BigInteger to the same values as Long, and BigInt

Fri, 12 Apr 2013 08:48:23 -0500

The doc string for hash states that it defines a hash code function that is consistent with =, but for java.math.BigInteger hash is not consistent with =.

user=> (apply = [(Long. -1) -1N (biginteger -1)])
true
user=> (map hash [(Long. -1) -1N (biginteger -1)])
(0 0 -1)
user=>

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

user=> (assoc clojure.lang.PersistentHashMap/EMPTY (biginteger -1) :oops! -1N :one)
{-1N :one, -1 :oops!}

The expected behavior is the same as PersistentArrayMap, which does not have this issue, because it does not hash its keys:

user=> (assoc clojure.lang.PersistentArrayMap/EMPTY (biginteger -1) :oops! -1N :one)
{-1 :one}

This same misbehavior also occurs for Doubles and Floats:

thalia.core=> (apply = [(Float. 1e9) (Double. 1e9)])
true
thalia.core=> (map hash [(Float. 1e9) (Double. 1e9)])
(1315859240 1104006501)

That leads to the same difference in array-map and hash-map behavior as above for BigInteger and BigInt.

[CLJ-1157] Classes generated by gen-class aren't loadable from remote codebase for mis-implementation of static-initializer

Fri, 12 Apr 2013 09:19:05 -0500

When a client program uses a remote service which uses RMI, and the service returns a object which created with gen-class with clojure as the return value, the return value is not loadable at client side.

At client side, a following exeption will be thrown.

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

HOW TO REPRODUCT THIS ISSUE

If you want to see this issue at your computer, clone my example project from my github.

git clone git://github.com/tyano/clojure_genclass_fix.git

and build them (You must have installed Leiningen 2):

cd clojure_genclass_fix
sh build.sh

start rmiregistry:

rmiregistry &

start remoteserver:

cd remoteserver
sh start.sh

You will see a message "Server ready. " or "Server ready. (rebind)".

At last, start client program:

cd ../client
sh start.sh

Without my patch, you will see a same Exception described above. But with clojure with my patch, you will see a right response message: "response = this is sample."

THE REASON

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

static
  {
    RT.var("clojure.core", "load").invoke("/remoteserver/SampleInterfaceImpl");
  }

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

So, gen-class must be create bytecodes that is same with the following java code.

static
  {
    Var.pushThreadBindings(RT.map(new Object[] { Compiler.LOADER, SampleInterfaceImpl.class.getClassLoader() }));
    try {
        RT.var("clojure.core", "load").invoke("/remoteserver/SampleInterfaceImpl");
    }
    finally 
    {
        Var.popThreadBindings();
    }
  }

With this code, RT.load will uses a same classloader which load SampleInterfaceImpl.class.
My patch for gen-class will create bytecodes equal to the above example.

You can use an attached patch '20130204_fix_classloader.diff', or pull 'fix_classloader' branch from my github repositry ( git@github.com:tyano/clojure.git ).

[CLJ-1154] Compile.java closes out preventing java from reporting exceptions

Fri, 12 Apr 2013 09:31:03 -0500

I was trying to compile a project that has some native dependencies. I am using clojure-maven-plugin version 1.3.13 with Maven 2.0. I forgot to set java.library.path properly so that the native library could be found, and only got an error of

[INFO] ------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------
[INFO] Clojure failed.
[INFO] ------------------------------------------------------------------------

I traced this down to Compile.java, where it is flushing and closing

out

in the finally block. The JVM uses out to write out a stack trace for any uncaught exceptions. When out is closed it is unable to write out the stack trace for the UnsatisfiedLinkError that was being thrown. This made it very difficult to debug what was happening.

[CLJ-701] Compiler loses 'loop's return type in some cases

Fri, 12 Apr 2013 09:42:00 -0500

(set! *warn-on-reflection* true)
(fn [] (loop [b 0] (recur (loop [a 1] a))))

Generates the following warnings:

recur arg for primitive local: b is not matching primitive, had: Object, needed: long
Auto-boxing loop arg: b

This is interesting for several reasons. For one, if the arg to recur is a let form, there is no warning:

(fn [] (loop [b 0] (recur (let [a 1] a))))

Also, the compiler appears to understand the return type of loop forms just fine:

(use '[clojure.contrib.repl-utils :only [expression-info]])
(expression-info '(loop [a 1] a))
;=> {:class long, :primitive? true}

The problem can of course be worked around using an explicit cast on the loop form:

(fn [] (loop [b 0] (recur (long (loop [a 1] a)))))

Reported by leafw in IRC: http://clojure-log.n01se.net/date/2011-01-03.html#10:31

[CLJ-1171] Compiler macro for clojure.core/instance? disregards lexical shadows on class names

Fri, 12 Apr 2013 09:42:02 -0500

Summary

The compiler tries to emit jvm native instanceof expressions for direct clojure.core/instance? calls.
For that, it tries to resolve its first argument as a class name. However, it disregards lexical bindings when doing that.
This is incongruent to the default implementation in core.clj

Data

Test case

user=> (let [Long String] (instance? Long "abc"))
false
;; expected true as in
user=> (let [Long String] (apply instance? [Long "abc"]))
true

Culprit method

https://github.com/clojure/clojure/blob/4ccb10edbe66eae81336a4c0972050d9759b0bf7/src/jvm/clojure/lang/Compiler.java#L3578

List Discussion

https://groups.google.com/d/topic/clojure/mf25OlFRpa8/discussion

Tangent

This was discovered because the same compiler macro also omits the arity check implicit in the default definition. This could also conveniently be fixed when touching that method:

user=> (instance? String)
false
;; expected
user=> (apply instance? [String])
ArityException Wrong number of args (1) passed to: core$instance-QMARK-  clojure.lang.AFn.throwArity (AFn.java:437)

EDIT elaborated on ticket title and description; added tangent

[CLJ-1058] StackOverflowError on exception in reducef for PersistentHashMap fold

Fri, 12 Apr 2013 09:42:02 -0500

If reducef throws an exception, the PHM fold code can descend into an infinite loop, causing a stack overflow which masks the problem. This situation is commented "aargh" in PersistentHashMap.java line 444 (as of 412a51d).

To reproduce:

user> (require '[clojure.core.reducers :as r])
nil
user> (r/fold (fn ([]) ([ret k v] (+ 3 "foo") ret)) (into {} (map (juxt identity identity) (range 10000))))
;; boom

This results in a stack like: https://raw.github.com/gist/3bab917287a7fd635a84/f38bfe3e270556e467f3fc02062af7ea10781390/gistfile1.txt

[CLJ-420] Some compiler exceptions erroneously using REPL line numbers.

Fri, 12 Apr 2013 09:42:02 -0500

Certain kinds of errors in loaded source files are coming back tagged with the correct source file, but what seems to be the REPL line number.

http://groups.google.com/group/clojure/browse_frm/thread/beb36e7228eabd69/a7ef16dcc45834bc?hl=en#a7ef16dcc45834bc

jawolfe@[~/Projects/testproj]: cat > src/test.clj

bla
jawolfe@[~/Projects/testproj]: cat > src/test2.clj

(bla)
jawolfe@[~/Projects/testproj]: lein repl
user=> (require 'test)
java.lang.Exception: Unable to resolve symbol: bla in this context
(test.clj:1)
user=> (require 'test)a
java.lang.Exception: Unable to resolve symbol: bla in this context
(test.clj:2)
user=> (require 'test)
java.lang.Exception: Unable to resolve symbol: bla in this context
(test.clj:3)
user=> (require 'test2)
java.lang.Exception: Unable to resolve symbol: bla in this context
(test2.clj:2)
user=> (require 'test2)
java.lang.Exception: Unable to resolve symbol: bla in this context
(test2.clj:2)
user=> (require 'test2)
java.lang.Exception: Unable to resolve symbol: bla in this context
(test2.clj:2)
user=> (require 'test)
java.lang.Exception: Unable to resolve symbol: bla in this context
(test.clj:7)
user=>

[CLJ-124] GC Issue 120: Determine mechanism for controlling automatic shutdown of Agents, with a default policy and mechanism for changing that policy as needed

Fri, 12 Apr 2013 09:52:24 -0500

Reported by cemer...@snowtide.com, Jun 01, 2009

There has been intermittent chatter over the past months from a couple of
people on the group (e.g.
http://groups.google.com/group/clojure/browse_thread/thread/409054e3542adc1f)
and in #clojure about some clojure scripts hanging, either for a constant
time (usually reported as a minute or so with no CPU util) or seemingly
forever (or until someone kills the process).

I just hit a similar situation in our compilation process, which invokes
clojure.lang.Compile from ant.  The build process for this particular
project had taken 15 second or so, but after adding a couple of pmap calls,
that build time jumped to ~1:15, with roughly zero CPU utilization over the
course of that last minute.

Adding a call to Agent.shutdown() in the finally block in
clojure.lang.Compile/main resolved the problem; a patch including this
change is attached.  I wouldn't suspect anyone would have any issues with
such a change.

-----
In general, it doesn't seem like everyone should keep tripping over this
problem in different directions.  It's a very difficult thing to debug if
you're not attuned to how clojure's concurrency primitives work under the
hood, and I would bet that newer users would be particularly affected.

After discussion in #clojure, rhickey suggested adding a
*auto-shutdown-agents* var, which:

- if true when exiting one of the main entry points (clojure.main, or the
legacy script/repl entry points), Agent.shutdown() would be called,
allowing for the clean exit of the application

- would be bound by default to true

- could be easily set to false for anyone with an advanced use-case that
requires agents to remain active after the main thread of the application
exits.

This would obviously not help anyone initializing clojure from a different
entry point, but this may represent the best compromise between
least-surprise and maximal functionality for advanced users.

------

In addition to the above, it perhaps might be worthwhile to change the
keepalive values used to create the Threadpools used by c.l.Actor's
Executors.  Currently, Actor uses a default thread pool executor, which
results in a 60s keepalive.  Lowering this to something much smaller (1s?
5s?) would additionally minimize the impact of Agent's threadpools on Java
applications that embed clojure directly (and would therefore not benefit
from *auto-shutdown-agents* as currently conceived, leading to puzzling
'hanging' behaviour).  I'm not in a position to determine what impact this
would have on performance due to thread churn, but it would at least
minimize what would be perceived as undesirable behaviour by users that are
less familiar with the implementation details of Agent and code that
depends on it.

Comment 1  by cemer...@snowtide.com, Jun 01, 2009

Just FYI, I'd be happy to provide patches for either of the suggestions mentioned
above...

[CLJ-850] Hinting the arg vector of a primitive-taking fn with a non-primitive type results in AbstractMethodError when invoked

Fri, 12 Apr 2013 09:52:25 -0500

See the following examples:

user=> (defn f1 ^String [^String s] s)
#'user/f1
user=> (f1 "foo")
"foo"
user=> (defn f2 ^long [^String s ^long i] i)
#'user/f2
user=> (f2 "foo" 1)
1
user=> (defn f3 ^String [^String s ^long i] s)                                       
#'user/f3
user=> (f3 "foo" 1)
AbstractMethodError user$f3.invokePrim(Ljava/lang/Object;J)Ljava/lang/Object;  user/eval8 (NO_SOURCE_FILE:6)

[CLJ-944] (.containsKey {:one 1} :one) throws Exception

Sat, 13 Apr 2013 12:06:35 -0500

Patch clj944-plus-tests does three things:

includes the previous "0002" patch which has the compiler emit map types consistent with the reader
adds tests
removes tests that were broken all along and now symptomatic

Hi guys, I am getting the following exception:

(.containsKey {:one 1} :one)
;=> ClassCastException clojure.lang.PersistentArrayMap cannot be cast to clojure.lang.PersistentHashMap

The map is a clojure.lang.PersistentArrayMap, which obviously has a containsKey method (https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/PersistentArrayMap.java#L95).

Casting it works fine though:

(.containsKey ^clojure.lang.PersistentArrayMap {:one 1} :one)
;=> true

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

The problem is not present in Clojure 1.2.1.

[CLJ-1205] Update Maven build for Nexus 2.4

Mon, 22 Apr 2013 20:29:15 -0500

These additions to the build configuration are necessary to support changes to the Sonatype Nexus server at oss.sonatype.org, which we use to promote our build artifacts into the Maven Central Repository.

See Sonatype's announcement at https://groups.google.com/d/msg/clojure-dev/lBpfII2u6vM/LQvr_rO5UGgJ

[CLJ-1118] inconsistent numeric comparison semantics between BigDecimal and other Numerics

Thu, 25 Apr 2013 19:58:50 -0500

user> clojure-version
{:major 1, :minor 5, :incremental 0, :qualifier "beta1"}
user> (== 2.0 2.0M)
true
user> (== 2 2.0M)
false <-- this one is not like the others
user> (== 2 2.0)
true
user> (== 2N 2.0)
true
user> (== 2 (double 2.0M))
true

It's not clear if this is a bug or an enhancement request, Should BigDecimal's be special in comparason to their smaller equivalents?

[CLJ-827] unsigned-bit-shift-right

Fri, 12 Apr 2013 09:52:24 -0500

Add a clojure equivalent of >>>.

A simple version of this is implemented here (https://github.com/joegallo/clojure/tree/unsigned-bit-shift-right), and just follows the example set by shift-right.

The downside of this implementation is that it treats all integer types as longs, and shifts them accordingly, which yields different results than you would get in java. A previous version of this did not have the same problem, when BitOps was its own thing. I'm not sure if this limitation is acceptable and appropriate, or needs to be worked around (my inclination is the latter).

[CLJ-1208] Namespace is not loaded on defrecord class init

Fri, 3 May 2013 17:21:54 -0500

As a user of Clojure interop from Java, I want defrecords (and deftypes?) to load their namespaces upon class initialization so that I can simply construct and use AOT'd record classes without manually requiring their namespaces first.

Calling the defrecord's constructor may or may not result in "Attempting to call unbound fn" exceptions, depending on what code has already been run.

This issue has been raised several times over the years, but I could not find an existing ticket for it:

[CLJ-866] Provide a clojure.test function to run a single test case with fixtures

Sat, 4 May 2013 09:36:20 -0500

At present, clojure.test test cases are functions and can be invoked directly. However, in the case that the test relies on fixtures, this does not work. Please provide a function that can run a single test case with all fixtures applied.

[CLJ-1202] protocol fns with dashes may get compiled into property access when used higher order

Fri, 10 May 2013 15:19:29 -0500

user=> (defprotocol Foo (-foo [x]))
Foo
user=> (deftype Bar [] Foo (-foo [_] :baz))
user.Bar
user=> (map -foo [(Bar.)])
IllegalArgumentException No matching field found: foo for class user.Bar  
clojure.lang.Reflector.getInstanceField (Reflector.java:271)

I would have expected to see (:baz). The full stack is:

IllegalArgumentException No matching field found: foo for class user.Bar
	clojure.lang.Reflector.getInstanceField (Reflector.java:271)
	clojure.lang.Reflector.invokeNoArgInstanceMember (Reflector.java:300)
	user/eval79/fn--80/G--71--82 (NO_SOURCE_FILE:11)
	user/eval79/fn--80/G--70--85 (NO_SOURCE_FILE:11)
	clojure.core/map/fn--4207 (core.clj:2485)
	clojure.lang.LazySeq.sval (LazySeq.java:42)
	clojure.lang.LazySeq.seq (LazySeq.java:60)
	clojure.lang.RT.seq (RT.java:484)
	clojure.core/seq (core.clj:133)
	clojure.core/print-sequential (core_print.clj:46)
	clojure.core/fn--5406 (core_print.clj:143)
	clojure.lang.MultiFn.invoke (MultiFn.java:231)
nil

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

~~CLJ-872~~ added dash property support to Clojure.

[CLJ-1207] Importing a class that does not exist fails to report the name of the class that did not exist

Fri, 10 May 2013 16:51:24 -0500

Pop quiz: What Java class is missing from the classpath?

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

If you guess "com.annadaletech.nexus.util.logging__init" you are wrong!

Wait, I'll give you a hint:

(ns com.annadaletech.nexus.util.logging
  (:use [clojure.string :only [trim-newline]]
        [clojure.pprint :only [code-dispatch pprint with-pprint-dispatch *print-right-margin*]])
  (:import [java.io StringWriter]
           [org.slf4j MDC MarkerFactory Marker LoggerFactory]
           [java.util.concurrent.locks ReentrantLock]))

Oh, sorry, did that not help?

The correct answer is "org.slf4j.MDC".

Having that information in the stack trace would have saved me nearly an hour. I think it is worth the effort to get that reported correctly.

[CLJ-1125] Clojure can leak memory when used in a servlet container

Mon, 13 May 2013 19:30:16 -0500

When used within a servlet container
(Jetty/Tomcat/JBossAS/Immutant/etc), the thread locals Var.dvals (used
to store dynamic bindings) and LockingTransaction.transaction (used to
store the currently active transaction(s)) prevent all of the classes
loaded by an application's clojure runtime from being garbage collected,
resulting in a memory leak.

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

I've attached a patch that does the following:

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

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

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

Providing an automated test for this patch is difficult - I've tested
it locally with repeated deployments to a container while monitoring
GC and permgen. All of clojure's tests pass with it applied.

The above is a condensation of:
https://groups.google.com/d/topic/clojure-dev/3CXDe8_9G58/discussion

I'm happy to provide whatever feedback/work is needed to get this
applied.

[CLJ-1183] java interop - cannot call a final method on non-public superclass

Sat, 18 May 2013 04:31:36 -0500

when trying to call a method on a concrete class that is defined as final on its super class that is not public, the runtime throws:

"java.lang.IllegalArgumentException: Can't call public method of non-public class"

even when fully annotated, Reflection is still used and the call fails.

you can read the full description here https://groups.google.com/d/msg/clojure/p2tBMT-BIYc/mDQB8cSponMJ

I included a sample project that demonstrate the problem

[CLJ-699] make sure compile paths shares as much code as possible

Fri, 31 Dec 2010 16:01:39 -0600

Issue http://dev.clojure.org/jira/browse/CLJ-697 highlighted the fact that compilation has more than one entry point. Review these entry points and make them share code.

[CLJ-1002] chunk-* functions not documented

Sun, 27 May 2012 01:17:18 -0500

None of the chunk related functions defined in core.clj have documentation. While their implementations are straightforward, it means the functions do not show up in http://clojure.org/api. Are these not considered part of the API? If so, should they be private? Otherwise, I think they should have public documentation.

For searchability, the function are:

chunk-append, chunk, chunk-first, chunk-rest, chunk-next, chunk-cons, chunked-seq?

[CLJ-761] print-dup generates call to nonexistent method for APersistentVector$SubVector

Fri, 4 Nov 2011 11:31:09 -0500

Originally reported by Carson

print-dup on any collection type generates code to call the create method of the collection's class. APersistentVector$SubVector has no create method.

Example with Clojure at commit ecae8ff08a298777c365a261001adfe9bfa4d83c :

Clojure 1.3.0-master-SNAPSHOT
user=> (read-string (binding [*print-dup* true] (pr-str (subvec [1 2 3] 1))))
IllegalArgumentException No matching method found: create  clojure.lang.Reflector.invokeMatchingMethod (Reflector.java:50)

[CLJ-346] (pprint-newline :fill) is not handled correctly

Mon, 29 Nov 2010 20:48:05 -0600

Filled pretty printing (where we try to fit as many elements on a line as possible) is being too aggressive as we can see when we try to print the following array:

user> (binding [*print-right-margin* 20] (pprint (int-array (range 10))))

Produces:

[0,
1,
2,
3,
4, 5, 6, 7, 8, 9]

Rather than

[0, 1, 2, 3, 4,
5, 6, 7, 8, 9]

or something like that. (I haven't worked through the exact correct representation for this case).

We currently only use :fill style newlines for native java arrays.

[CLJ-807] hash-maps print-dup as literal, thus can be read as array-maps

Fri, 29 Jul 2011 07:42:26 -0500

Per Rich in ~~CLJ-799~~: "The point of print-dup is type preservation"

user=> (hash-map :k :v)
{:k :v}
user=> (type *1)
clojure.lang.PersistentHashMap
user=> (binding [*print-dup* true] (print-str *2))
"{:k :v}"
user=> (read-string *1)
{:k :v}
user=> (type *1)
clojure.lang.PersistentArrayMap

The cause is due to RT.map conditionally creating an array-map if the size is within the PersistentArrayMap.HASHTABLE_THRESHOLD.

[CLJ-941] NullPointerException possible with seq-zip

Sun, 26 Feb 2012 17:54:13 -0600

For example:

Clojure 1.3.0
user=> (require '[clojure.zip :as z])
nil
user=> (-> (z/seq-zip (list 1)) z/down z/remove)
NullPointerException clojure.core/with-meta (core.clj:211)

Possibly the make-node function for seq-zip should be:

(fn [node children] (with-meta (or children ()) (meta node)))

[CLJ-750] clojure.lang.MapEntry violates .equals and .hashCode contracts of HashMap.Entry; leads to non-reflexive .equals, etc.

Fri, 29 Jul 2011 07:45:40 -0500

user> (let [h (HashMap.)]
(.put h 1 2)
(let [p1 (first h)
p2 (first {1 2})]
(println (.hashCode p1) (.hashCode p2)
(= p1 p2) (= p2 p1)
(.equals p1 p2) (.equals p2 p1))))

3 994 false false true false

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

I realize this isn't a simple bug; it's a fundamental issue, in that it's impossible to consistently implement both java.util.List and java.util.Map$Entry, which clojure.lang.MapEntry claims to do. On balance I do find it very useful that Clojure map entries are equivalent to vectors, and probably wouldn't want to give that up. But, I think that at minimum this wart should be documented somewhere, since it could lead to some very strange and hard to catch bugs.

[CLJ-878] DispatchReader always calls CtorReader when no dispatch macro found

Tue, 15 Nov 2011 17:28:46 -0600

At the REPL, I accidentally typed:

user=> # "\w+"
RuntimeException Unsupported escape character: \w clojure.lang.Util.runtimeExce
ption (Util.java:156)
#<core$PLUS clojure.core$PLUS@6b7dc78>

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

user=> (defrecord X [x])
user.X
user=> # "user.X"[5]
#user.X{:x 5}

I'm assuming the fact that the above successfully creates an X is accidental.

[CLJ-880] syntax-quote should be a macro instead of implemented inside the reader

Thu, 17 Nov 2011 17:02:48 -0600

syntax-quote is currently a somewhat gnarly bit of java code in LispReader.java, would be great to replace it with a (hopefully less gnarly) clojure macro.

LispReader.java would be required to do something similar to 'x => (quote x). `x => (syntax-quote x) , ~x => (unquote x), ~@x => (unquote-splicing x)

[CLJ-946] eval reader fail to recognize function object

Wed, 7 Mar 2012 01:24:47 -0600

(defmacro stubbing [stub-forms & body]
(let [stub-pairs (partition 2 stub-forms)
returns (map last stub-pairs)
stub-fns (map constantly returns) ;;(map #(list 'constantly %) returns)
real-fns (map first stub-pairs)]
`(binding [~@(interleave real-fns stub-fns)]
~@body)))

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

(def ^:dynamic $ (fn [x] (* x 10))

(stubbing [$ 1]
($ 1 1))
;; =>
IllegalArgumentException No matching ctor found for class clojure.core$constantly$fn__3656
clojure.lang.Reflector.invokeConstructor (Reflector.java:166)
clojure.lang.LispReader$EvalReader.invoke (LispReader.java:1031)
clojure.lang.LispReader$DispatchReader.invoke (LispReader.java:618)

;;macro can expanded
(macroexpand-all '(stubbing [$ 1]
($ 1 1)))
;; =>
(let* [] (clojure.core/push-thread-bindings (clojure.core/hash-map (var $) #<core$constantly$fn_3656 clojure.core$constantly$fn_3656@161f888>)) (try ($ 1 1) (finally (clojure.core/pop-thread-bindings))))

I thought there is something wrong with eval reader, but i can't figure it out

btw the above code can run on clojure-clr

[CLJ-1008] Make sorted maps and sets implement j.u.NavigableMap and NavigableSet interfaces

Sat, 2 Jun 2012 19:07:31 -0500

Since Clojure 1.5 will probably no longer target JVM 5, add support for the (Concurrent)?Navigable(Map|Set) interfaces. This should involve adding functions to PersistentTreeMap that descend the red-black tree to select the closest items.

[CLJ-248] Add support for subsets and submaps to sorted Sets/Maps

Sat, 2 Jun 2012 19:08:44 -0500

Currently we can have a subseq of a sorted-set|map-by, but this returns a seq and
not a Set or Map.
Implementing the interfaces java.util.SortedSet and java.util.SortedMap would give
us support for calling .subSet and .subMap.

[CLJ-938] Output of clojure.reflect is not suitable for type hints

Fri, 24 Feb 2012 01:37:33 -0600

I'm trying to write a macro which generate reify forms using some reflection.

clojure.reflect produces type symbols similar to 'java.util.Iterator<>

Unfortunately, the compiler doesn't accept the <> syntax in type hints:

(reify Iterable (^{:tag java.util.Iterator} iterator [this] nil)) ; works

(reify Iterable (^{:tag java.util.Iterator<>} iterator [this] nil)) ;; fails
CompilerException java.lang.RuntimeException: java.lang.ClassNotFoundException: java.util.Iterator<>, compiling:(NO_SOURCE_PATH:1325)

It seems like the compiler should understand the <> just enough to strip it, rather than reject it. This would make it much easier to write correct macros involving type hinting and reflection.

The workaround I have been using is:

(defn hint
"clojure.reflect demarks generics with angle brackets, but
the compiler does not support generics in type hints"
[obj tag]
(let [tag (-> tag .toString (.replace "<>" "") symbol)]
(with-meta obj {:tag tag}))

[CLJ-1047] Simplify the process of requiring fj in clojure.core.reducers

Tue, 21 Aug 2012 18:27:01 -0500

this patch removes compile-if in favor of import-if, removing code duplication

[CLJ-955] java object reader constructor doesn't work

Mon, 19 Mar 2012 10:26:00 -0500

Here is a transcript:

;user=> clojure-version
{:major 1, :minor 4, :incremental 0, :qualifier "beta5"}
;user=> (.getProtocol #java.net.URL["file:/home/hara/dj/usr/src/clojurescript/src/cljs/cljs/core.cljs"])
java.lang.RuntimeException: Can't embed object in code, maybe print-dup not defined: file:/home/hara/dj/usr/src/clojurescript/src/cljs/cljs/core.cljs, compiling:(null:2)
;user=> (.getProtocol (java.net.URL. "file:/home/hara/dj/usr/src/clojurescript/src/cljs/cljs/core.cljs"))
"file"

Another transcript from google groups https://groups.google.com/forum/?fromgroups&hl=en#!topic/clojure/vlsFgVaKcSQ

user=> (def x #java.net.URL["file:/home/hara/dj/usr/src/clojurescript/src/cljs/cljs/core.cljs"])
#'user/x
user=> x
#<URL file:/home/hara/dj/usr/src/clojurescript/src/cljs/cljs/core.cljs>
user=> (.getProtocol x)
"file"

user=> (.getProtocol #java.net.URL["file:/home/hara/dj/usr/src/clojurescript/src/cljs/cljs/core.cljs"])
CompilerException java.lang.RuntimeException: Can't embed object in code, maybe print-dup not defined: file:/home/hara/dj/usr/src/clojurescript/src/cljs/cljs/core.cljs, compiling:(NO_SOURCE_PATH:5)
user=> (defmethod print-dup java.net.URL [o, ^java.io.Writer w] (.write w (str o)))
#<MultiFn clojure.lang.MultiFn@2e694f12>

user=> (.getProtocol #java.net.URL["file:/home/hara/dj/usr/src/clojurescript/src/cljs/cljs/core.cljs"])
ClassCastException clojure.lang.Symbol cannot be cast to java.net.URL user/eval11 (NO_SOURCE_FILE:7)
user=>

user=> (def x #java.net.URL["file:///home/hara/dj/usr/src/clojurescript/src/cljs/cljs/core.cljs"])
#'user/x
user=> (printf "(class x)=%s x='%s'\n" (class x) x)
(class x)=class java.net.URL x='file:/home/hara/dj/usr/src/clojurescript/src/cljs/cljs/core.cljs'
nil
user=> (let [x #java.net.URL["file:///home/hara/dj/usr/src/clojurescript/src/cljs/cljs/core.cljs"]]
(printf "(class x)=%s x='%s'\n" (class x) x))
CompilerException java.lang.RuntimeException: Can't embed object in code, maybe print-dup not defined: file:/home/hara/dj/usr/src/clojurescript/src/cljs/cljs/core.cljs, compiling:(NO_SOURCE_PATH:4)

user=> (defmethod print-dup java.net.URL [o, ^java.io.Writer w] (.write w (str o)))
#<MultiFn clojure.lang.MultiFn@3362a63>
user=> (let [x #java.net.URL["file:///home/hara/dj/usr/src/clojurescript/src/cljs/cljs/core.cljs"]]
(printf "(class x)=%s x='%s'\n" (class x) x))
(class x)=class clojure.lang.Symbol x='file:/home/hara/dj/usr/src/clojurescript/src/cljs/cljs/core.cljs'
nil

[CLJ-803] IAtom interface

Mon, 4 Jul 2011 21:18:48 -0500

Atom and the other reference types do not have interfaces and are marked final.

Use cases for interfaces for the reference types include database wrappers. CouchDB behaves exactly like compare-and-set! and is shared, synchronous, independent state, so it makes sense to use the Atom interface to update a CouchDB document.

I talked to Rich about this, and he said "patch welcome for IAtom", complete conversation: http://clojure-log.n01se.net/date/2010-12-29.html#10:04c

[CLJ-1015] Standalone Clojure library for Java users

Thu, 14 Jun 2012 17:39:23 -0500

Many of Clojure's data structures (e.g. PersistentHashMap) may be of interest to the wider Java community, and would benefit from being packaged in a way that makes them easy to include in projects. While they are public (and thus can be accessed by way of clojure.lang), Clojure's classloader is implemented in a way such that Clojure files such as core.clj end up being loaded, even when an end-user is not interested in the Clojure environment itself. The Java classes could also use some documentation!

I'd be happy to work on a patch but this change may require some restructuring of the build process, so it'd be good to get community sign-off first.

[CLJ-735] Improve error message when a protocol method is not found

Fri, 9 Dec 2011 10:05:55 -0600

If you call a protocol function but pass the wrong arity (forget an argument for example), you currently a message that says "No single method ... of interface ... found for function ... of protocol ...". The code in question is getting matching methods from the Reflector and creates this message if the number of matches != 1.

There are really two cases there:

matches == 0 - this happens frequently due to typos
matches > 1 - this presumably happens infrequently

I propose that the == 0 case instead should have slightly different text at the beginning and a hint as to the intended arity within it:

"No method: ... of interface ... with arity ... found for function ... of protocol ...".

The >1 case should have similar changes: "Multiple methods: ... of interface ... with arity ... found for function ... of protocol ...".

Patch is attached. I used case which presumably should have better performance than a nested if/else. I was not sure whether the reported arity should match the actual Java method arity or Clojure protocol function arity (including the target). I did the former.

I did not add a test as I wasn't sure whether checking error messages in tests was appropriate or not. Happy to add that if requested.

[CLJ-900] Document defonce-like behavior of defmulti

Mon, 19 Dec 2011 16:40:59 -0600

Since Clojure 1.2 defmulti behaves similarly to defonce. This fact, and how one deals with it when doing interactive development, does not seem to be documented anywhere. This issue pops up fairly regularly in the #clojure channel.

Commit that introduced the change: https://github.com/clojure/clojure/commit/1b8d5001ba094053b24c55829994785be422cfbf

I can volunteer to update the docstrings and (if I get access to it) the clojure.org page.

[CLJ-5] Unintuitive error response in clojure 1.0

Sat, 28 Apr 2012 22:48:40 -0500

The following broken code:

(let [[x y] {}] x)

provides the following stack trace:

Exception in thread "main" java.lang.UnsupportedOperationException: nth not supported on this type: PersistentArrayMap (test.clj:0)
at clojure.lang.Compiler.eval(Compiler.java:4543)
at clojure.lang.Compiler.load(Compiler.java:4857)
at clojure.lang.Compiler.loadFile(Compiler.java:4824)
at clojure.main$load_script__5833.invoke(main.clj:206)
at clojure.main$script_opt__5864.invoke(main.clj:258)
at clojure.main$main__5888.doInvoke(main.clj:333)
at clojure.lang.RestFn.invoke(RestFn.java:413)
at clojure.lang.Var.invoke(Var.java:346)
at clojure.lang.AFn.applyToHelper(AFn.java:173)
at clojure.lang.Var.applyTo(Var.java:463)
at clojure.main.main(main.java:39)
Caused by: java.lang.UnsupportedOperationException: nth not supported on this type: PersistentArrayMap
at clojure.lang.RT.nth(RT.java:800)
at clojure.core$nth__3578.invoke(core.clj:873)
at user$eval__1.invoke(test.clj:1)
at clojure.lang.Compiler.eval(Compiler.java:4532)
... 10 more

The message "nth not supported on this type" while correct doesn't make the cause of the error very clear. Better error messages when destructuring would be very helpful.

[CLJ-1029] ns defmacro allows arbitrary execution of clojure.core fns

Sun, 5 Aug 2012 10:00:07 -0500

The form:

(ns foo (:print "I AM A ROBOT"))

will print "I AM A ROBOT"

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

This is minor, but it does mean that an otherwise declarative form is not executing code.

[CLJ-776] seque broken for some BlockingQueues

Fri, 22 Apr 2011 09:27:55 -0500

clojure.core/seque takes an optional argument that can be the initial capacity for a LinkedBlockingQueue or an instance of the BlockingQueue interface.

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

user=> (def s (seque (java.util.concurrent.PriorityBlockingQueue. 100) (shuffle (range 100))))
#'user/s
user=> s
java.lang.NullPointerException

user=> (seque (java.util.concurrent.SynchronousQueue.) (shuffle (range 100)))
<never finishes>

user=> (seque (java.util.concurrent.ArrayBlockingQueue. 10) (shuffle (range 100)))
(39 41 27 76 1 24 92 34 72 37 67 99 38 21 5 64 9 26 59 43 82 65 3 11 31 93 50 63 15 90 13 75 40 97 57 88 86 53 19 83 2 12 54 49 71 28 68 73 96 44 8 98 61 6 22 25 78 66 32 84 60 94 70 7 89 4 33 55 74 81 51 56 62 87 69 80 77 20 30 91 52 10 48 18 36 58 47 14 16 42 35 17 95 0 45 85 29 23 46 79)

[CLJ-809] fn's created using defn should not lexical shadow the var that holds them

Fri, 29 Jul 2011 07:39:50 -0500

currently (defn foo [x] (foo x)) expands to something like (def foo
(fn foo [x] (foo x))) so the fn is bound to foo lexically in the scope
of the fn body.

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

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

1.3 has changes to eliminate some of the cost of going through the var.

since going through the var is much cheaper now it would be nice to
eliminate the lexical shadowing.

http://groups.google.com/group/clojure-dev/browse_thread/thread/33b52b24616967f?hl=en

[CLJ-821] should reify merge rather than replace on repeated specs?

Tue, 9 Aug 2011 14:18:40 -0500

reify, deftype, and the like fail silently if you specify a class twice:

(macroexpand '(reify Map (size [this] 0),
Counted (count [this] 0),
Map (keySet [this] nil)))
;=> (reify* [Counted Map] (count [this] 0) (keySet [this] nil))

The later Map section entirely supersedes the former, which I discovered when I wrote a macro that injects some automated method bodies into a reify for you.

I've attached a fix to make the above expand to the expected [for me, anyway] output.

[CLJ-983] proxy-super does not restore original binding if call throws exception

Sat, 5 May 2012 09:04:26 -0500

The code for proxy-call-with-super internally used by proxy-super does not handle exceptions from the call method:

(defn proxy-call-with-super [call this meth]
(let [m (proxy-mappings this)]
(update-proxy this (assoc m meth nil))
(let [ret (call)]
(update-proxy this m)
ret)))

As a result the following sequence behaves unexpectedly:
(def obj (proxy [java.lang.ClassLoader] []
(loadClass [cl] (println "enter")
(proxy-super loadClass cl))))
(.loadClass obj "nonexistent")
;; prints enter, then throws ClassNotFoundException
(.loadClass obj "nonexistent")
;; does not print anything before throwing cnfe

A try-finally block around the invocation would solve this particular issue.

[CLJ-888] defprotocol should throw error when signatures include variable number of parameters

Tue, 29 Nov 2011 16:38:02 -0600

I tried to use & in the signature for a method in defprotocol. Apparently (see below), this is compiled so that & becomes a simple parameter name, and there is no special handling for variable number of parameters. I think the use of & in a protocol signature ought to be detected and immediately cause an exception (I also think this restriction on the signatures ought to be documented; I couldn't find it specified in the current documentation, though of course it is implied (as I later realized) by the fact that defprotocol creates a Java interface).

user=> (defprotocol Applier (app [this f & args]))
Applier
user=> (deftype A [] Applier (app [_ f & args] (prn f & args) (apply f args)))
user.A
user=> (app (A.) + 1 2)
#<core$PLUS clojure.core$PLUS@5d9d0d20> 1 2
IllegalArgumentException Don't know how to create ISeq from: java.lang.Long
clojure.lang.RT.seqFrom (RT.java:487)

[CLJ-1039] Using 'def with metadata {:type :anything} throws ClassCastException

Fri, 10 Aug 2012 13:40:31 -0500

In lein 1.7.1 (and CCW) the form (def ^{:type :anything} mydef 1) throws "ClassCastException clojure.lang.Var cannot be cast to clojure.lang.IObj clojure.core/with-meta (core.clj:211)".
This seems to be due to setting the :type metadata. With other metadata keys it works well.

If it is intended to forbid setting the :type metadata, then there should be an appropriate error message instead of the ClassCastException

In lein2 repl which is using "REPL-y 0.1.0-beta8" the exception does not occur.

Full stacktrace:
java.lang.ClassCastException: clojure.lang.Var cannot be cast to clojure.lang.IObj
at clojure.core$with_meta.invoke (core.clj:211)
clojure.core$vary_meta.doInvoke (core.clj:617)
clojure.lang.RestFn.invoke (RestFn.java:425)
clojure.core/fn (core_print.clj:76)
clojure.lang.MultiFn.invoke (MultiFn.java:167)
clojure.core$pr_on.invoke (core.clj:3266)
clojure.core$pr.invoke (core.clj:3278)
clojure.lang.AFn.applyToHelper (AFn.java:161)
clojure.lang.RestFn.applyTo (RestFn.java:132)
clojure.core$apply.invoke (core.clj:601)
clojure.core$prn.doInvoke (core.clj:3311)
clojure.lang.RestFn.invoke (RestFn.java:408)
clojure.main$repl$read_eval_print__6405.invoke (main.clj:246)
clojure.main$repl$fn__6410.invoke (main.clj:266)
clojure.main$repl.doInvoke (main.clj:266)
clojure.lang.RestFn.invoke (RestFn.java:512)
user$eval27$acc_3261auto__30$fn_32.invoke (NO_SOURCE_FILE:1)
clojure.lang.AFn.run (AFn.java:24)
java.lang.Thread.run (Thread.java:662)

[CLJ-929] Accessing Java property starting with _ has issues in 1.4

Thu, 9 Feb 2012 15:01:53 -0600

When attempting to use interop syntax with symbols which aren't legal Java names (such as deleted?), the names are mangled a bit. That's necessary, of course, and the method of munging can be internal to the compiler. However, the behavior when munging changed a little between 1.3 and 1.4 beta1. Obviously the specifics of munging are something I should avoid relying on, but the way it changed looks like an accident or a bug even so.

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

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

So it looks like the - prefix for properties is not 100% backwards-compatible like it seemed to be. Is this an issue we need to fix, or is the recommendation simply to never have fields that start with - or _?

[CLJ-958] Make APersistentVector.iterator slightly more efficient

Tue, 14 Aug 2012 13:43:53 -0500

The attached patch uses a sequence to create an iterator for persistent vectors. It should be slightly more efficient for PersistentVector objects than repeatedly calling nth (for reasons that I outline in the commit message).

[CLJ-957] Typehints for variadic methods in deftype fail to compile

Sun, 19 Aug 2012 04:31:33 -0500

When a method defined by a protocol has multiple typehinted signatures, it is impossible to implement them using deftype because deftype throws away the typehints. The compiler then looks for the proper signatures (i.e. with typehints) and throws an exception when it can't find them.

[CLJ-668] Improve slurp performance by using native Java StringWriter and jio/copy

Mon, 1 Nov 2010 15:58:31 -0500

Instead of copying each character from InputReader to StringBuffer.

Performance improvement:

From:
user> (time (count (slurp "/home/juergen/test.dat")))
"Elapsed time: 4269.980863 msecs"
104857600
To:
user> (time (count (slurp "/home/juergen/test.dat")))
"Elapsed time: 1140.854023 msecs"
104857600

Patch: http://github.com/juergenhoetzel/clojure/commit/af1a5713cd485ba5f1db25c37906ebaf7d474b47

[CLJ-997] max-key and min-key to return the first entry in case of several candidates

Fri, 18 May 2012 16:03:44 -0500

Consider the following code:

(def values [[1 2] [3 4] [5] [6 7] [8]])
(apply max-key count values)
; => [6 7]

Which returns the last max entry [6 7]. Why its not the first max entry [1 2]?
Well, truth is "max-key" gives no warranty on which max value will be returned.

Consider the following example in Scala:

println(List(List(0, 1, 2), List(2, 3, 4), List(1), List(1, 2, 3)).maxBy(_.length))
> List(0, 1, 2)

The very same function in Scala returns the first max entry (by default).

The code from relase 1.4 file "clojure/core.clj#4419-4426" looks is:
=======================
4419: (defn max-key
4420: "Returns the x for which (k x), a number, is greatest."
4421: {:added "1.0"
4422: :static true}
4423: ([k x] x)
4424: ([k x y] (if (> (k x) (k y)) x y))
4425: ([k x y & more]
4426: (reduce1 #(max-key k %1 %2) (max-key k x y) more)))
=======================

I am unsure what is the motivation in returning the last candidate, but

I suggest two following things:

1. Make "max-key" and "min-key" return the first max/min entry if there are several candidates.

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

Line #4424 should have ">=" instead of ">".

2. Make "max-key" and "min-key" make warranty on order, which max/min entry will be returned (either first or last).

Line #4420 should say "Returns the x for which (k x), a number, is greatest. In case of several matches, the first max entry will be returned" or the same doc, but saying "the last max entry will returned".

[CLJ-731] Create macro to variadically unroll a combinator function definition

Fri, 28 Jan 2011 09:40:05 -0600

Clojure contains a set of combinators that are implemented in a similar, but slightly different way. That is, they are implemented as a complete set of variadic overloads on both the call-side and also on the functions that they return. Visually, they all tend to look something like:

(defn foo
  ([f]
     (fn
       ([] do stuff...)
       ([x] do stuff...)
       ([x y] do stuff...)
       ([x y z] do stuff...)
       ([x y z & args] do variadic stuff...)))
  ([f1 f2]
     (fn
       ([] do stuff...)
       ([x] do stuff...)
       ([x y] do stuff...)
       ([x y z] do stuff...)
       ([x y z & args] do variadic stuff...)))
  ([f1 f2 f3]
     (fn
       ([] do stuff...)
       ([x] do stuff...)
       ([x y] do stuff...)
       ([x y z] do stuff...)
       ([x y z & args] do variadic stuff...)))
  ([f1 f2 f3 & fs]
     (fn
       ([] do stuff...)
       ([x] do stuff...)
       ([x y] do stuff...)
       ([x y z] do stuff...)
       ([x y z & args] do variadic stuff...))))

To build this type of function for each combinator is tedious and error-prone.

There must be a way to implement a macro that takes a "specification" of a combinator including:

1. name
2. docstring
3. do stuff template
4. do variadic stuff template

And builds something like the function foo above. This macro should be able to implement the current batch of combinators (assuming that http://dev.clojure.org/jira/browse/CLJ-730 is completed first for the sake of verification).

[CLJ-373] update-in with empty key paths

Sat, 8 Sep 2012 06:13:29 -0500

To the topic of get-in and update-in. While I realize this is not a bug it is odd and in my eyes unexpected and unwanted behavior.

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

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

(update-in {...} [] f) ist he same as (update-in {...} [nil] f) while (get-in {...} []) is not the same as (get-in {...} [nil]) and of cause differs from what update-in does.

For automatically walking trees the behavior of get-in makes a lot more sense since the current behavior of update-in forces you to check for empty paths and if they are empty fall back to plain assoc and get (or get-in since this works):

(if-let [r (butlast @path)]
(do
  (alter m update-in r dissoc (last @path))
  (alter m update-in r assoc {:name @sr} c))
(do
  (alter m dissoc (last @path))
  (alter m assoc {:name @sr} c)))

Next argument is that update-in with an empty map working on nil isn't easy to gasp, one needs to know the implementation details to realize that it works, I think 90% of the people reading update-in with [] will not instinctively know that it works on the key nil, so changing this would most likely not break any current code, and if it would the code would be bad anyway .

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

Regards,
Heinz

[CLJ-1021] (let [i 5] (defmacro m [v] v) m) interprets m as a function, not a macro

Thu, 13 Sep 2012 14:29:20 -0500

(let [i 5] (defmacro m [& args] args) (def x (m (inc 5) (inc 6) (inc 7))) x m (meta #'m))
is
[(8) #<user$eval522$m_523 user$eval522$m_523@11a74355> {:macro true, :ns #<Namespace user>, :name m, :arglists ([& args]), :line 1, :file "NO_SOURCE_PATH"}]

It appears to be interpreting m as a function despite the metadata. This behavior only shows up inside the (let ...).

[CLJ-1003] :100 is a valid Clojure keyword. Is that intentional?

Thu, 13 Sep 2012 18:34:52 -0500

In the latest clojure (eccde24c7),

These parse as keywords:

:100
:100/a

This is an error:

:a/100

Is this behavior intentional?

In LispReader.java, the pattern for a symbol (and keyword) is "[:]?([\\D&&[^/]].*/)?([
D&&[^/]][^/]*)". If I'm mentally parsing that correctly, it seems like none of my examples should be valid keywords. I don't know why the first two cases parse.

http://clojure.org/reader says that none of my examples should parse.

Clojurescript does not accept any of my examples, see ~~CLJS-142~~

[CLJ-1063] Missing dissoc-in

Mon, 17 Sep 2012 07:04:54 -0500

There is no clojure.core/dissoc-in although there is an assoc-in.
It is correct that dissoc-in can be build with update-in and dissoc but this is an argument against assoc-in as well.
When a shortcut for assoc-in is provided, there should also be one for dissoc-in for consistency reasons.
Implementation is analogical to assoc-in.

[CLJ-1043] Unordered literals does not preserve left-to-right evaluation of arguments

Sun, 23 Sep 2012 19:38:35 -0500

Given: (defn f [x] (println x) x)

#{(f 2) (f 1)}

Prints:

1
2

But expected would be:

2
1

This issue is related to CLJS-288

[CLJ-703] Improve writeClassFile performance

Fri, 5 Oct 2012 19:08:06 -0500

This Discussion about timing issues when writing class files led to the the current implementation of synchronous writes to disk. This leads to bad performance/system-load when compiling Clojure code.

This Discussion questioned the current implentation.

Synchronous writes are not necessary and also do not ensure (crash while calling write) valid classfiles.

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

[CLJ-1087] clojure.data/diff uses set union on key seqs

Mon, 15 Oct 2012 14:52:42 -0500

clojure.data/diff, on line 118, defines:

java.util.Map
(diff-similar [a b]
  (diff-associative a b (set/union (keys a) (keys b))))

Since keys returns a key seq, this seems like an error. clojure.set/union has strange and inconsistent behavior with regard to non-sets, and in this case the two key seqs are concatenated. Based on a cursory benchmark, it seems that this bug is a slight performance gain when the maps have no common keys, and a significant performance loss when the maps have the same keys. The results are still correct because of the merging reduce in diff-associative.

The patch is easy (just call set on each key seq).

[CLJ-862] pmap level of parallelism inconsistent for chunked vs non-chunked input

Sat, 20 Oct 2012 00:45:48 -0500

The code of pmap creates futures for the set of map operations it needs to perform with (map #(future %) coll), then acts on that sequence in a fashion obviously intended to keep only #CPUs+2 unfinished futures realized at any given time. It works exactly this way for non-chunked input seqs, but when pmap is passed a chunked seq, the seq of futures also becomes chunked. This causes an arbitrary number of futures to be realized as the #CPUs+2 window and chunk-size window interact.

The doc-string for pmap doesn't promise any particular level of parallelism, but I think the inconsistent parallelism for chunked vs non-chunked input comprises a bug.

[CLJ-1097] node-seq for clojure.zip

Mon, 29 Oct 2012 21:37:18 -0500

Many times it's easier to get to a zipper node via (first (filter pred ...)) instead of manually walking the tree via next/up/down. Other times it's easier to process certain nodes via filter & map instead of again, walking the tree. This patch provides a single function called node-seq that uses zip/next to generate a lazy-seq of nodes. Tests provide two examples.

[CLJ-1107] 'get' should throw exception on non-Associative argument

Tue, 13 Nov 2012 13:57:31 -0600

The implementation of clojure.core/get returns null if its argument is not a valid associative collection. However, calling 'get' on something which is neither nil nor an Associative collection is almost certainly a bug, and should be indicated by an exception.

This behavior can obscure common programmer errors such as:

(def a (atom {:a 1 :b 2})

(:foo a)   ; forgot to deref a
;;=> nil

~~CLJ-932~~ was accepted as a similar enhancement to 'clojure.core/contains?'

Attached patch 0001 throws an IllegalArgumentException as the fall-through case of RT.getFrom.

[CLJ-842] clojure.pprint uses the old-style metadata.

Wed, 14 Nov 2012 13:19:38 -0600

I was looking through the implementation of clojure.pprint.* and found that it still uses the old-style metadata to mark vars as private - ^{:private true} instead of ^:private.

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

FWIW, there are some other namespaces which use the old-style metadata as well; I am willing to fix those as well.

[CLJ-849] Add a pseudo-variable containing the current line number

Wed, 14 Nov 2012 15:44:21 -0600

Add a pseudo-variable (similar to *file*), containing the current line number. This should be available during AOT compilation. The name "*line-number*" might be good.

It will be useful for diagnostic log messages. Using exception stack traces has poor runtime performance and the line number should be available to the compiler at minimal cost.

[CLJ-99] GC Issue 95: max-key and min-key evaluate k multiple times for arguments

Thu, 15 Nov 2012 21:36:54 -0600

Reported by H.Duerer, Mar 13, 2009

max-key or min-key will evaluate (k value) multiple times for arguments if
more than 2 arguments are passed.

This is undesirable if k is expensive to calculate.

Something like the code below would avoid these double calculations (at the
price of generating more ephemeral garbage)

(defn max-key
  "Returns the x for which (k x), a number, is greatest."
  ([k x] x)
  ([k x y] (if (> (k x) (k y)) x y))
  ([k x y & more]
     (second (reduce (fn [x y] (if (> (first x) (first y)) x y))
                     (map #(vector (k %) %) (cons x (cons y more)))))))

[CLJ-1113] `reductions` reducer

Fri, 23 Nov 2012 08:22:37 -0600

It would be nice to have a reducers implementation of the core `reductions` function.

Initial implementation attempt included. This version requires an initial reduction value parameter (vs using (f)) and includes that initial value in the final reduction. I'm not certain either of these decisions is optimal, but results in a function which most closely mimics `clojure.core/reductions`.

[CLJ-1049] Make reducer/folder support reduce-kv

Sun, 23 Sep 2012 20:34:21 -0500

Currently, although rfn makes an effort to support reduce-kv, it is wasted effort since the return values of reducer and folder don't satisfy IKVReduce.

I have a working patch for this, it's quite small. I have printed a CA but not sent it, so I won't reveal the patch yet...

This also applies to ClojureScript.

[CLJ-1056] defprotocol: invalid method overload syntax getting accepted

Thu, 29 Nov 2012 16:03:11 -0600

The compiler accepts both of these erroneous forms which while silly, are not imposible to come up with.

(defprotocol Foo (f ([this]) ([this arg])))
(defprotocol Bar (m [this]) (m [this arg]))

[CLJ-1090] Indirect function calls through Var instances fail to clear locals

Fri, 30 Nov 2012 14:26:45 -0600

If you make a function call indirectly by invoking a Var object (which derefs itself and invokes the result), the invocation parameters remain in the thread's local stack for the duration of the function call, even though they are needed only long enough to be passed into the deref'd function. As a result, passing a lazy seq into a function invoked in its Var form may run out of memory if the seq is forced inside that function. For example:

(defn total [xs] (reduce + 0 xs))
(total (range 1000000000)) ; this works, though takes a while
(#'total (range 1000000000)) ; this dies with out of memory error

I can provide a patch if it would be useful. The fix should be trivial, something along the lines of wrapping each argN in clojure/lang/Var.java inside a Util.ret1(argN, argN = null) as is done in RestFn.java.

[CLJ-1102] Better handling of exceptions with empty stack traces

Fri, 30 Nov 2012 14:57:46 -0600

I don't know what I did to cause some exceptions to be thrown while running Clojure tests that return a length 0 array from (.getStackTrace throwable), but according to the Java docs this is legal. I searched all places in the Clojure code that call .getStackTrace and found two that don't handle this correctly, one of which causes an ArrayOutOfBoundsException (that is the one I found during my testing).

[CLJ-1103] Make conj assoc dissoc and transient versions handle args similarly

Sun, 9 Dec 2012 17:30:00 -0600

A discussion came up in the Clojure Google group about conj giving an error when taking only a coll as an argument, as opposed to disj which works for this case:

https://groups.google.com/forum/?fromgroups=#!topic/clojure/Z9mFxsTYTqQ

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

conj handles an arbitrary number of arguments, but conj! does not.
assoc checks for a final key with no value specified (~~CLJ-1052~~), but assoc! did not.

[CLJ-1124] for-as

Mon, 10 Dec 2012 23:33:43 -0600

A common pattern in programming is building up some data structure step by step:

In Python:

[code]
x = {0: 1}
for item in stuff:
x[item] = item * x.get(item - 1, 0)
[/code]
etc.

In an imperative for loop this is easy since we have easy access to the "current" data structure being built up.

I propose the addition of a function for-as similar to as-> except the value of the last loop iteration is bound to the name.

So we can write the above as:

[code]
(last (for-as [x {0 1}]
[item stuff]
(assoc x item (* item (get x (- item 1) 0)))))
[/code]

An (un-optimized) implementation might be something like:

[code]
(defmacro reduce-for [[res init] for-seq-exprs body-expr]
`(reduce #(%2 %1) ~init
(for ~for-seq-exprs
(fn [~res]
~body-expr))))
[/code]

Note: reduce-for does not return a seq, instead it returns the result of the last loop body iteration.

[CLJ-1128] Improve merge-with

Thu, 13 Dec 2012 17:41:39 -0600

Set a first map as an initial value for reduce to
avoid merge-entry (series of contains? calls and etc) call on the first map.

[CLJ-1119] inconsistent behavior of lazy-seq w/ macro & closure on excptions

Sun, 16 Dec 2012 04:06:49 -0600

lazy-seq seems to evaluate inconsistently when body includes a macro and throws and exception. 1st evalutation throws the exceptions, subsequent ones return empty sequence.

demo code:

(defn gen-lazy []
(let [coll [1 2 3]]
(lazy-seq
(when-let [s (seq coll)]
(throw (Exception.))))))

(def lazy (gen-lazy))

(try
(println "lazy:" lazy)
(catch Exception ex
(println ex)))

(try
(println "lazy, again:" lazy)
(catch Exception ex
(println ex)))

It should throw an exception both times but only does on 1st. Generally speaking an expression shouldn't evaluate to different things depending on whether it's been evaluated before.

When removing the closure ...

(defn gen-lazy []
(lazy-seq
(when-let [s (seq [1 2 3])]
(throw (Exception.)))))

... or removing the when-let macro ...

(defn gen-lazy []
(let [coll [1 2 3]]
(lazy-seq
(seq coll)
(throw (Exception.)))))

It works i.e. consistently throws the exception, so seems to be some interaction between the closure and the macro at work here. This particular combination is used in the 'map' function.

[CLJ-1132] For record type Rec, (instance? Rec (map->Rec {...})) need not return true, though (instance? Rec (Rec. ...)) does.

Tue, 18 Dec 2012 10:58:29 -0600

(defrecord Rec ...)

(instance? Rec (Rec. ...)) ;=> true
(instance? Rec (map->Rec {...})) ;=> can be false

This occurs when the code is wrapped in a tomcat servlet by `lein ring
uberwar`, but not when run at the REPL or under Jetty, say.

Although produced under ring, this seems to me to be a general problem
with the map-> constructor, as (true? (instance? Rec (map->Rec {...})))
should be an invariant, regardless of the environment or context.
The problem seems to arise in some aspect of the class loading process:

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

The map->Rec delegates to the create method, which seems to be where the problem lies.

The record namespace is AOT compiled, properly I think/hope, and the requisite classes
imported as they should be.

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

Again, I've only been able to reproduce the problem under Tomcat,
not under Jetty or at the REPL.

[CLJ-1133] Certain actions on mutable fields in deftype lead to very strange error messages

Wed, 19 Dec 2012 01:20:28 -0600

Consider the following code:

(definterface Test
(^void fail []))

(deftype TestImpl
[^{:unsynchronized-mutable true :tag int} x]
Test
(fail [this]
(set! x (dec x))))

Its compilation fails with the following message:
CompilerException java.lang.VerifyError: (class: test/TestImpl, method: fail signature: ()V) Expecting to find integer on stack, compiling.../test.clj:27)

The following code works:

(definterface Test
(^void fail []))

(deftype TestImpl
[^{:unsynchronized-mutable true :tag int} x]
Test
(fail [this]
(set! x (int (dec x)))))

The only change here is that I have wrapped (dec x) form into (int) call.

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

I'm using Clojure 1.4.0 and have experienced this problem on Archlinux x86_64 and Windows 7 x86_64.

Full stack trace of the error, in case it would be helpful:

java.lang.VerifyError: (class: test/TestImpl, method: fail signature: ()V) Expecting to find integer on stack, compiling.../test.clj:27)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:6462)
at clojure.lang.Compiler.analyze(Compiler.java:6262)
at clojure.lang.Compiler.analyze(Compiler.java:6223)
at clojure.lang.Compiler$BodyExpr$Parser.parse(Compiler.java:5618)
at clojure.lang.Compiler$FnMethod.parse(Compiler.java:5054)
at clojure.lang.Compiler$FnExpr.parse(Compiler.java:3674)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:6453)
at clojure.lang.Compiler.analyze(Compiler.java:6262)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:6443)
at clojure.lang.Compiler.analyze(Compiler.java:6262)
at clojure.lang.Compiler.access$100(Compiler.java:37)
at clojure.lang.Compiler$DefExpr$Parser.parse(Compiler.java:518)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:6455)
at clojure.lang.Compiler.analyze(Compiler.java:6262)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:6443)
at clojure.lang.Compiler.analyze(Compiler.java:6262)
at clojure.lang.Compiler.analyze(Compiler.java:6223)
at clojure.lang.Compiler$BodyExpr$Parser.parse(Compiler.java:5618)
at clojure.lang.Compiler$LetExpr$Parser.parse(Compiler.java:5919)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:6455)
at clojure.lang.Compiler.analyze(Compiler.java:6262)
at clojure.lang.Compiler.analyze(Compiler.java:6223)
at clojure.lang.Compiler$BodyExpr$Parser.parse(Compiler.java:5618)
at clojure.lang.Compiler$FnMethod.parse(Compiler.java:5054)
at clojure.lang.Compiler$FnExpr.parse(Compiler.java:3674)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:6453)
at clojure.lang.Compiler.analyze(Compiler.java:6262)
at clojure.lang.Compiler.eval(Compiler.java:6508)
at clojure.lang.Compiler.load(Compiler.java:6952)
at clojure.lang.Compiler.loadFile(Compiler.java:6912)
at clojure.lang.RT$3.invoke(RT.java:307)
at test$eval3224.invoke(NO_SOURCE_FILE:43)
at clojure.lang.Compiler.eval(Compiler.java:6511)
at clojure.lang.Compiler.eval(Compiler.java:6477)
at clojure.core$eval.invoke(core.clj:2797)
at clojure.main$repl$read_eval_print__6405.invoke(main.clj:245)
at clojure.main$repl$fn__6410.invoke(main.clj:266)
at clojure.main$repl.doInvoke(main.clj:266)
at clojure.lang.RestFn.invoke(RestFn.java:421)
at clojure.main$repl_opt.invoke(main.clj:332)
at clojure.main$main.doInvoke(main.clj:428)
at clojure.lang.RestFn.invoke(RestFn.java:397)
at clojure.lang.Var.invoke(Var.java:411)
at clojure.lang.AFn.applyToHelper(AFn.java:159)
at clojure.lang.Var.applyTo(Var.java:532)
at clojure.main.main(main.java:37)
Caused by: java.lang.VerifyError: (class: test/TestImpl, method: fail signature: ()V) Expecting to find integer on stack
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:264)
at clojure.lang.RT.classForName(RT.java:2039)
at clojure.lang.Compiler$HostExpr.maybeClass(Compiler.java:957)
at clojure.lang.Compiler$HostExpr.access$400(Compiler.java:736)
at clojure.lang.Compiler$NewExpr$Parser.parse(Compiler.java:2473)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:6455)
... 45 more

[CLJ-835] defmulti doc string doesn't mention needing to be passed a var for the value of :hierarchy

Wed, 19 Dec 2012 07:59:17 -0600

The :hierarchy option for defmulti should be passed a var, but this is not mentioned in the doc string.

The error message from passing the hierarchy directly is rather cryptic:

Evaluation aborted on java.lang.ClassCastException: clojure.lang.PersistentArrayMap cannot be cast to clojure.lang.IRef (SOURCE_FORM_44:19).

[CLJ-1137] Metadata on a def gets evaluated twice

Fri, 21 Dec 2012 11:32:28 -0600

Metadata on the symbol of a def special form is evaluated twice.

(def ^{:foo (println "HA")} a [])

prints out HA HA. Offending line is in Compiler$DefExpr, fixed.

[CLJ-1120] Introduce ex-message and ex-cause to abstract away the platform in dealing with ExceptionInfo

Fri, 21 Dec 2012 23:03:36 -0600

As described in the title. See ~~CLJS-429~~.

[CLJ-1104] Concurrent with-redefs do not unwind properly, leaving a var permanently changed

Fri, 21 Dec 2012 23:05:10 -0600

On 1.4 and latest master:

user> (defn ten [] 10)
#'user/ten
user> (doall (pmap #(with-redefs [ten (fn [] %)] (ten)) (range 20 100)))
(20 21 22 23 24 25 34 27 28 29 30 31 32 33 34 35 36 37 38 39 39 35 42 43 44 45 48 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 79 87 88 89 90 91 92 93 94 95 97 92 98 99)
user> (ten)
79

Not sure if this is a bug per se, but the doc doesn't mention lack of concurrency safety and my expectation was that the original value would always be restored after any (arbitrarily interleaved) sequence of with-redefs calls.

[CLJ-1134] star-directive in clojure.pprint/cl-format with an at-prefix ("~n@*") do not obey its specifications

Wed, 26 Dec 2012 19:57:30 -0600

The star-directive in clojure.pprint/cl-format with an at-prefix (~n@*) does not obey its specifications according to Common Lisp the Language, 2nd Edition. There are two bugs within ~n@* as of right now:

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

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

Inside a clean Clojure repl, perform these steps:

user=> (require '[clojure.pprint :refer [cl-format]])
nil
user=> (cl-format nil "~D ~3@*~D" 0 1 2 3)
"0 0"                                           ;; Expected: "0 3"
user=> (cl-format nil "~D~D~D~D ~@*~D" 0 1 2 3)
"0123 1"                                        ;; Expected: "0123 0"

What is the expected output? What do you see instead?

The expected output is "0 3" and "0123 0", but is "0 0" and "0123 1" as shown above.

What version are you using?

Tested on both 1.4.0 and 1.5.0-beta2, both have the defect described.

Please provide any additional information below.

The format strings which reproduces the problem has been compared with the format function from the Common Lisp implementations SBCL, CLisp and Clozure. All of them print the expected output.

[CLJ-1010] A left-to-right-variant of `comp`

Thu, 14 Jun 2012 18:27:23 -0500

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.

I would be great if there was an alternative `comp*` (or whatever) function which is just like `comp` but composes left-to-right.

[CLJ-1094] Zero-arity versions of every-pred and some-fn

Thu, 25 Oct 2012 07:12:35 -0500

This patch adds zero-arity versions of every-pred and some-fn with these semantics.

(every-pred) === (constantly true)
(some-fn)    === (constantly nil)

These variants are useful in situations like the following:

;; compute-preds-for may return zero or many predicate fns
(let [preds (compute-preds-for something)]
  (filter (apply every-pred preds) some-coll))

[CLJ-1112] Var loading-verbosely should initialize from a JVM system property

Thu, 22 Nov 2012 02:14:32 -0600

I often find myself adding :verbose to a (require) or (use) clause of my (ns) in order to debug problems (especially macros, or bad namespace declarations). It would be very nice if I could define a JVM system property (say -Dclojure.load-verbosely=true) to default loading-verbosely to true for a REPL session, or as part of a build.

Sometimes I just like to see that namespaces load as a measure of progress, when starting an application, or when running a set of tests.

[CLJ-1130] Invoking a static method with the wrong number of arguments results in a NoSuchFieldException, rather than a proper message that the arguments could not be matched to the method

Sun, 6 Jan 2013 18:44:47 -0600

My code inadventently invoked a method that expected a single parameter, but passed no parameters.

The exception:

Exception in thread "main" java.lang.NoSuchFieldException: getService, compiling:(com/annadaletech/nexus/services/registry.clj:168)
	at clojure.lang.Compiler.analyzeSeq(Compiler.java:6462)
	at clojure.lang.Compiler.analyze(Compiler.java:6262)
	at clojure.lang.Compiler.analyzeSeq(Compiler.java:6443)
	at clojure.lang.Compiler.analyze(Compiler.java:6262)
	at clojure.lang.Compiler.access$100(Compiler.java:37)
	at clojure.lang.Compiler$LetExpr$Parser.parse(Compiler.java:5883)
....
Caused by: java.lang.NoSuchFieldException: getService
	at java.lang.Class.getField(Class.java:1520)
	at clojure.lang.Compiler$StaticFieldExpr.<init>(Compiler.java:1180)
	at clojure.lang.Compiler$HostExpr$Parser.parse(Compiler.java:923)
	at clojure.lang.Compiler.analyzeSeq(Compiler.java:6455)
	... 78 more

That threw me for a bit; really, it looks like the compiler is attempting to access a field and invoke it as an IFn. However, a proper message would be "getService() requires 1 parameter, not 0" (or something to that effect). Even "invalid number of parameters for SmashRuntime/getService()" would be better.

[CLJ-1030] Misleading ClassCastException when coercing a String to int

Sun, 6 Jan 2013 20:52:40 -0600

Observed behaviour

(int "0") =>
java.lang.ClassCastException: java.lang.String cannot be cast to java.lang.Character

Expected behaviour
(int "0") =>
java.lang.ClassCastException: java.lang.String cannot be cast to java.lang.Integer
or
IllegalArgumentException

[CLJ-891] make (symbol foo "bar") work with foo being a namespace

Fri, 2 Mar 2012 16:53:07 -0600

I've run across the need to do (symbol ns "bar") a few times, and the existing approach (symbol (name (ns-name ns)) "bar") just doesn't seem like it ought to be the only way to do the job. Includes a patch to make this work, by adding a new arity to Symbol.intern().

Some discussion on this idea, here: https://groups.google.com/forum/#!topic/clojure/n25aZ5HA7hc/discussion

[CLJ-1086] Support arity-1 for ->>

Sat, 12 Jan 2013 18:48:06 -0600

Currently (as of Clojure 1.4) ->> doesn't support arity-1, though -> does. Arity-1 for ->> would be useful to let somebody comment out forms as follows:

(->> foo
  #_(bar baz)
  #_quux)

Discussion: https://groups.google.com/forum/?fromgroups=#!topic/clojure/_IVl0Tb7Au4

My name on contributor list page http://clojure.org/contributing is: Shantanu Kumar

[CLJ-1033] pr-str and read-string don't handle @ symbols inside keywords properly

Sun, 13 Jan 2013 22:58:37 -0600

user=> (read-string (pr-str {(keyword "key@other") :stuff}))
RuntimeException Map literal must contain an even number of forms  clojure.lang.Util.runtimeException (Util.java:170)

pr-str emits "{:key@other :stuff}", which read-string fails to interpret correctly. Either pr-str needs to escape the @ symbol, or read-string needs to handle the symbol inside a keyword.

Background: I'm passing a map with email addresses as keys through Storm bolts, which require a thrift-serializable form. Using the pr-str/read-string combo fails on these keys, so I've fallen back to JSON serialization.

[CLJ-1149] Unhelpful error message from :use (and use function) when arguments are malformed

Thu, 17 Jan 2013 18:37:27 -0600

the following exception happens when you have something like this(bad):

(ns runtime.util-test
(:use [midje.sweet :reload-all]))

as opposed to any of these(correct):

(ns runtime.util-test
(:use midje.sweet :reload-all))

(ns runtime.util-test
(:use [midje.sweet] :reload-all))

and the exception is:
Exception in thread "main" java.lang.IllegalArgumentException: No value supplied for key: true
at clojure.lang.PersistentHashMap.create(PersistentHashMap.java:77)
at clojure.core$hash_map.doInvoke(core.clj:365)
at clojure.lang.RestFn.applyTo(RestFn.java:137)
at clojure.core$apply.invoke(core.clj:617)
at clojure.core$load_lib.doInvoke(core.clj:5352)
at clojure.lang.RestFn.applyTo(RestFn.java:142)
at clojure.core$apply.invoke(core.clj:619)
at clojure.core$load_libs.doInvoke(core.clj:5403)
at clojure.lang.RestFn.applyTo(RestFn.java:137)
at clojure.core$apply.invoke(core.clj:621)
at clojure.core$use.doInvoke(core.clj:5497)

Note that this is similar to the equally unhelpful message shown in http://dev.clojure.org/jira/browse/CLJ-1140 although that is a different root cause.

Probably best to enhance the `use` function to validate its arguments before trying to apply hash-map?

[CLJ-764] (partition 0 seq) and (parition-all 0 seq) are infinite sequences of empty sequences

Mon, 21 Jan 2013 05:40:07 -0600

(partition n seq) and (partition-all n seq) are implemented by taking n and dropping n from seq. When n=0 this becomes an infinite sequence of empty sequences.

While conceptionally this makes sense, I think practically it may surprise people, and perhaps it should return an empty sequence or a sequence of a single empty sequence.

[CLJ-1148] adds docstring support to defonce, and stops it from stomping existing metadata

Thu, 17 Jan 2013 17:16:40 -0600

Two issues here:

1) defonce doesn't support docstrings, although def does, so it would be nice to bring the two in line with each other

2) defonce can stomp metadata, like this:

(defonce ^:private foo 5)
#'user/foo
(meta #'foo) --> the private is there
(defone foo 10)
foo is still 5
(meta #'foo) --> the private has been lost

[CLJ-1082] Subvecs of primitive vectors cannot be reduced

Sat, 26 Jan 2013 07:29:55 -0600

I could reproduce on current 10/05 git.

Reduce doesn't work on subvecs of primitive vectors.
Root cause seems to be that RT/subvec and APersistentVector$SubVector make assumptions about implementation

If reduce on a subvec doesn't work then neither will nice ops like fold.

How to cause:

(let [prim-vec (into (vector-of :long) (range 10000))]
(reduce + (subvec prim-vec 1 500)))

->> ClassCastException clojure.core.Vec cannot be cast to clojure.lang.PersistentVector clojure.lang.APersistentVector$SubVector.iterator (APersistentVector.java:523)

[CLJ-1080] Eliminate many uses of reflection in Clojure code

Thu, 7 Feb 2013 08:54:50 -0600

There are dozens of uses of reflection in Clojure code that can be eliminated by adding suitable type hints. This patch adds the necessary type hints for most of those.

[CLJ-1159] clojure.java.io/delete-file doesn't return the status of the deletion(true/false)

Sun, 10 Feb 2013 14:21:28 -0600

initially reported it here(somehow):
https://groups.google.com/d/msg/clojure/T9Kvr0IL0kg/wcKBfR9w_1sJ

Basically clojure.java.io/delete-file doesn't ever return false (even when silently is true, it returns the value of silently), it's due to how it's implemented - but it's obvious from the code, so I'll stop here.

Thanks.

PS: this is what I'm using as my current workaround:
(defn delete-file
"
an implementation that returns the true/false status
which clojure.java.io/delete-file doesn't do(tested in 1.5.0-RC14)
"
[f & [silently]]
(let [ret (.delete (clojure.java.io/file f))]
(cond (or ret silently)
ret
:else
(throw (java.io.IOException. (str "Couldn't delete " f)))
)
)
)

I'm sure you guys can find a better way, but as a clojure newbie(really!) that's what I have.