Clojure JIRA

[TBENCH-16] Add performance testing for STM

Thu, 23 Feb 2012 14:38:00 -0600

Write a test-suite to detect regressions in STM performance.

[LOGIC-44] ex* could expand macros in patterns

Sun, 17 Mar 2013 19:05:17 -0500

So, tagged data structures are probably interesting in a relational context. Say you have a relation with some default logic about dogs:

(defna friendlyo [Dog-Or-Breed]
    ([:Spot] succeed)
    ([:Spike] fail)
    ([Other-Dog] (fresh [Breed] (dog-breed Other-Dog Breed) (friendlyo Breed)))
    ([(breed :miniature-dachshund)] fail)
    ([(breed :golden-retriever)] succeed)
    ;. . .)

Assume there's a (defmacro breed [t] `[:breed ~t]).

That's nicer than having to drop [:breed :golden-retriever] in there or whatever, since it's compile-time-checkable, less error-prone, reduces duplication, etc.

This little patch makes ex* expand macros in patterns so it doesn't treat e.g. (breed :golden-retriever) as introducing a new LVar called "breed". Test also provided.

[JDBC-59] Support Postgres in the test suite

Sun, 26 May 2013 10:19:52 -0500

The README for c.j.j currently indicates postgres support with instructions on how to run the tests against it; however, the tests fail if you do. There are two reasons:

float-or-double needs a postgres case or it fails because of equality classes
the postgresql jdbc driver's .getGeneratedKeys() implementation returns all columns in the row, not just the auto-generated keys.

A patch is attached: postgres-test-support.diff (05/25/2013)

[CLJS-485] clojure.string/replace ignores regex flags

Tue, 12 Mar 2013 10:36:36 -0500

The replace function in namespace clojure.string ignores regex flag provided in the match pattern. For example:

CLJS

clojure.string/replace "I am NOT matched" #"(?i)not " "")
=> "I am NOT matched"

CLJ

clojure.string/replace "I am NOT matched" #"(?i)not " "")
=> "I am matched"

The attached patch fixes this by parsing the m and i flags, if set, from the match object, instead of explicitly setting only "g".

[CLJS-260] Add clojure.core/shuffle implementation

Sun, 20 May 2012 22:28:09 -0500

I added a simple implementation of clojure.core/shuffle, which uses goog.array's Fisher-Yates for its implementation. Included in the patch is a test to make sure it works.

[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-990] Implement clojure.core.reducers/mapcat and some initial reducers tests

Fri, 1 Mar 2013 09:49:21 -0600

The first patch implements a reducers equivalent of clojure.core/mapcat, and the second patch adds a new reducers.clj to the clojure tests that checks that map, mapcat, filter, and reduce are equivalent in clojure.core and clojure.core.reducers.

[CLJ-982] Implement an interface? predicate to balance class?

Sat, 9 Jun 2012 09:08:46 -0500

clojure.core implements a class? predicate to detect if a thing is an instance of java.lang.Class. The attached patch implements interface? to further distinguish classes that are also interfaces. This gives us Clojure api for e.g., enumerating all interfaces a thing's base class implements; as in, (filter #(interface? %) (supers (class my-thing))).

[CLJ-964] test-clojure/rt.clj has undeclared dependency on clojure.set

Sat, 18 Aug 2012 07:12:53 -0500

In test-clojure/rt.clj, the test last-var-wins-for-core evaluates #'clojure.set/subset?. This fails unless clojure.set has been loaded. In the normal run of the test suite, this dependency is satisfied by test-clojure/core-set being loaded first.

[CLJ-879] Allow :require to support a :refer clause

Fri, 17 Feb 2012 14:18:28 -0600

There's been discussion previously about the complexity of the ns
macro. In particular the fact that :use causes all vars to be referred
by default is widely seen as unfortunate, and the distinction between
use and require is a source of conceptual overhead for people new to
the language.

We can't change the fact that :use refers everything by default
without breaking lots of existing code. But it would be possible to
enhance :require to support referring specified vars, leaving us free
to deprecate or otherwise discourage the use of :use.

Clojure-dev thread discussing this: http://groups.google.com/group/clojure-dev/browse_thread/thread/91b708ddb909affd