<< Back to previous view

[TBENCH-16] Add performance testing for STM Created: 23/Feb/12  Updated: 23/Feb/12

Status: Open
Project: test.benchmark
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Enhancement Priority: Minor
Reporter: Stefan Kamphausen Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: performance, test
Environment:

64bit Linux, Quad-core


Attachments: File stm-perf-TBENCH-16.diff    

 Description   

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



 Comments   
Comment by Stefan Kamphausen [ 23/Feb/12 2:38 PM ]

Patch which adds an stm-namespace containing a collection of performance test functions.





[LOGIC-44] ex* could expand macros in patterns Created: 19/Jul/12  Updated: 17/Mar/13

Status: Open
Project: core.logic
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Enhancement Priority: Minor
Reporter: Joe Osborn Assignee: David Nolen
Resolution: Unresolved Votes: 0
Labels: enhancement, patch, test

Attachments: Text File exstar-macros.patch    
Patch: Code and Test

 Description   

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.



 Comments   
Comment by David Nolen [ 19/Jul/12 4:41 PM ]

I'm surprised that this doesn't already work. We have support for unifying expressions in the pattern already. Look at line 1230 in tests.clj in the master branch.

So this should just work, no need to explicitly support macros as far as I can tell. If it's not working, then there's a bug.

Comment by Joe Osborn [ 19/Jul/12 5:18 PM ]

At least on 0.7.5, matching against a macro gives a runtime error:

Exception in thread "main" java.lang.ClassCastException: clojure.core.logic.LVar cannot be cast to clojure.lang.IFn
	at rl.core$glyph_$fn__123$fn__144$fn__165$fn__166$_inc__167$fn__168.invoke(core.clj:61)
	at clojure.core.logic.Substitutions.bind(logic.clj:211)
	at rl.core$glyph_$fn__123$fn__144$fn__165$fn__166$_inc__167.invoke(core.clj:58)
	at clojure.core.logic$fn__1056$_inc__1057.invoke(logic.clj:1160)
	at clojure.core.logic$fn__1056$_inc__1057.invoke(logic.clj:1160)
	at clojure.core.logic$fn__898$_inc__899.invoke(logic.clj:823)
	at clojure.core.logic$fn__890$fn__891.invoke(logic.clj:828)

Using a fn instead of a macro gives the same:

Exception in thread "main" java.lang.ClassCastException: clojure.core.logic.LVar cannot be cast to clojure.lang.IFn
	at rl.core$drawable_$fn__235$fn__248$fn__249$_inc__250$fn__251.invoke(core.clj:67)
	at clojure.core.logic.Substitutions.bind(logic.clj:211)
	at rl.core$drawable_$fn__235$fn__248$fn__249$_inc__250.invoke(core.clj:65)
	at clojure.core.logic$fn__1056$_inc__1057.invoke(logic.clj:1160)
	at clojure.core.logic$fn__894$_inc__895.invoke(logic.clj:826)
	at clojure.core.logic$fn__1056$_inc__1057.invoke(logic.clj:1160)
	at clojure.core.logic$fn__898$_inc__899.invoke(logic.clj:823)
	at clojure.core.logic$fn__898$_inc__899.invoke(logic.clj:823)
	at clojure.core.logic$fn__898$_inc__899.invoke(logic.clj:823)
	at clojure.core.logic$fn__890$fn__891.invoke(logic.clj:828)

Here's (glyph-) for reference (don't mind all the extra [], I have a weird key/value thing because of some conveniences for maintaining fact identity in a temporal database):

(defna glyph- [Key Val]
	([[Thing] [Glyph]] (thing- [Thing]) (on-fire_ *turn* [Thing]) (== Glyph \δ))
	([[Thing] [Glyph]] (thing- [Thing]) (fresh [Type] (type- [Thing] [Type]) (glyph- [Type] [Glyph])))
	([[(type-enum :player)] [Glyph]] (== Glyph \@))
	([[(type-enum :dragon)] [Glyph]] (== Glyph \D))
	([[Type] [Glyph]] (== Glyph \?)))

and type-enum as a macro:

(defmacro type-enum [v] `[:enum :type ~v])

and as a fn:

(defn type-enum [v] [:enum :type ~v])

I'll mess around and see if my example works in HEAD.

Comment by Joe Osborn [ 19/Jul/12 5:37 PM ]

Same exception with this test case in HEAD (sorry for all the facts):

(defrel thing- [Thing])
(defrel type- [Thing] [Type])
(fact thing- [0])
(fact thing- [1])
(fact thing- [2])
(fact type- [0] [:player])
(fact type- [1] [:dragon])
(fact type- [2] [:pig])
(defn type-enum [t] [:type t])
(defna drawable- [Key]
  ([[Thing]] (thing- [Thing]) (fresh [Type] (type- [Thing] [Type]) (drawable- [Type])))
  ([[(type-enum :player)]] succeed)
  ([[(type-enum :dragon)]] succeed))

(deftest do-fns-work
	(is (= (run* [q] (drawable- [q])) '(0 1))))

Now that I look at it, I may be expecting a wrong-format return value, but the point is that I don't even get that far.

Using the REPL, I checked out how (defna drawable- . . .) expands (tidied up slightly):

(def drawable- (clojure.core/fn ([Key] 
  (clojure.core.logic/conda 
	  ((clojure.core.logic/fresh [Thing] (clojure.core.logic/== [Thing] Key) (thing- [Thing]) (fresh [Type] (type- [Thing] [Type]) (drawable- [Type])))) 
		((clojure.core.logic/fresh [type-enum] 
		  (clojure.core.logic/== [(type-enum :player)] Key) succeed))
		((clojure.core.logic/fresh [type-enum] 
		  (clojure.core.logic/== [(type-enum :dragon)] Key) succeed))))))

Note the (clojure.core.logic/fresh [type-enum] . . .) forms, which are exactly what I would not want to see in this case.

I'm not really sure why this doesn't work here yet works for the matche test case.

Comment by David Nolen [ 19/Jul/12 5:47 PM ]
[(type-enum :dragon)]

This pattern make it seem like you want to match:

[[:type :dragon]]

Note extra level of brackets here. Is this the case?

Even so I agree that the expansion doesn't look quite right. We should never descend into a seq form like that.

Comment by Joe Osborn [ 19/Jul/12 5:57 PM ]

Yes, that's exactly the desired outcome in this case--a tagged value in my naive interpretation. Is the reason it fails whereas the test on :1230 doesn't the fact that it's producing a vector and not a list? Changing the fn to return a list instead of a vector didn't seem to help.

My patch, fwiw, doesn't exhibit that behavior (at least for macros, haven't tested it with fns).

Comment by David Nolen [ 19/Jul/12 9:11 PM ]

What I mean is don't you want the following instead?

(defna drawable- [Key]
  ([[Thing]] (thing- [Thing]) (fresh [Type] (type- [Thing] [Type]) (drawable- [Type])))
  ([(type-enum :player)] succeed)
  ([(type-enum :dragon)] succeed))

Note that I removed a layer of square brackets.

Comment by Joe Osborn [ 20/Jul/12 10:28 AM ]

Nope! I actually want both. I'm doing some temporal logic stuff and I wanted some conveniences for "updating" a fluent, so I wanted to distinguish between the "key part" and the "value part" of the arguments. It looks silly for facts with no "value part", but it lets me write procedures and fns something like this:

(defrel heldo Time Fluent)
(defrel ¬heldo Time Fluent)
(declare fluent-obtainedo) ; most recent 'held' not terminated by a '¬held', or fail
(defn alter-fluent [Time Rel Key NewVal]
  ;todo: error check, ensure old != new, old obtains, new does not obtain
  (doseq [old-val (run* [old-val] (fluent-obtainedo Time [Rel Key old-val]))]
    (fact ¬heldo Time [Rel Key old-val]))
  (fact heldo Time [Rel Key NewVal]))
. . .
(fact heldo 0 ['pos [0] [0 0]])
. . .
(alter-fluent 1 'pos [0] [1 1])

And I write all the non-temporal fluents that way too for consistency and to help prevent mistakes.

Comment by David Nolen [ 20/Jul/12 2:58 PM ]

I'll try to give a closer look at this issue over the weekend.

Comment by David Nolen [ 17/Mar/13 7:05 PM ]

We're thinking about a more general solution here: http://github.com/clojure/core.logic/wiki/Better-syntax-support





[JDBC-59] Support Postgres in the test suite Created: 25/May/13  Updated: 26/Jul/13  Resolved: 26/May/13

Status: Resolved
Project: java.jdbc
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Enhancement Priority: Major
Reporter: Dan Dillinger Assignee: Sean Corfield
Resolution: Completed Votes: 0
Labels: patch, test

Attachments: File postgres-test-support.diff    

 Description   

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)



 Comments   
Comment by Sean Corfield [ 26/May/13 10:19 AM ]

Applied patch. Thanx!





[CLJS-1282] Add a :pprint option to the default reporter in cljs.test Created: 22/May/15  Updated: 28/Jun/15

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: 0.0-3269
Fix Version/s: None

Type: Enhancement Priority: Minor
Reporter: Sebastian Bensusan Assignee: Sebastian Bensusan
Resolution: Unresolved Votes: 0
Labels: test

Attachments: Text File cljs_1282.patch     Text File cljs_1282_v02.patch    

 Description   

Now that cljs.pprint has landed, cljs.test could report failures and exceptions with it. The exact API is TBD.



 Comments   
Comment by Sebastian Bensusan [ 22/Jun/15 4:00 PM ]

The :cljs.test/pprint reporter is implemented as a small deviation from the :cljs.test/default reporter.

The API is equivalent to that of custom reporters:

(run-tests
  (empty-env :cljs.test/pprint)
  'my-test.namespace)
Comment by David Nolen [ 24/Jun/15 5:51 AM ]

Looks good mostly but small typo: `print-comparisson` instead of `print-comparison`.

Comment by Sebastian Bensusan [ 28/Jun/15 5:13 PM ]

Added the rebased file with the typo corrected.





[CLJS-1226] Add on-testing-complete hook Created: 27/Apr/15  Updated: 13/May/15  Resolved: 12/May/15

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: 0.0-3269
Fix Version/s: 0.0-3308

Type: Enhancement Priority: Minor
Reporter: Sebastian Bensusan Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: cljs, enhancement, test

Attachments: Text File cljs_1226.patch     Text File cls_1226_v2.patch    
Patch: Code

 Description   

When a test runner runs async tests created with cljs.test/async there is no reliable way to return the control from the async code in the test suite to the test runner. This is problematic since the test script might need the tests results to proceed or terminate.

A function to be called after all tests are done is proposed: cljs.test/*on-testing-complete-fn* and it would take the test summary as its only argument

It can be set by the user by calling cljs.test/set-on-testing-complete! which should be callable from JS (^:export)

Notes:
In the patch, the function cljs.test/successful? also has the ^:export metadata to be called from JS test runners.
The code was tested manually with V8, Spidermonkey, Nashorn, SlimerJs, and PhantomJS but not with JavaScript Core.



 Comments   
Comment by Jenan Wise [ 01/May/15 2:40 PM ]

Rather than relying on a global, what about if run-tests took a callback? It would differentiate the API from clojure.test but they are already different due to the env arg and nil return value.

Comment by Sebastian Bensusan [ 01/May/15 2:59 PM ]

It is currently in a global to allow easy access from outside cljs (js runners). By having it to pass it to run-tests it would be harder to make reusable test runners from outside cljs/ Said runners would have to know both the ns to run (TBD in each project) and the callback (what we want to reuse, i.e. phantom.exit(0))

Comment by David Nolen [ 05/May/15 7:02 AM ]

Is there any particular reason to not invoke do-report with a suitable dispatch value instead of adding a new function here?

Comment by Sebastian Bensusan [ 05/May/15 7:29 AM ]

I'm not sure that I understand. I thought do-report and report were meant for printing out the summary as a report. This on-testing-complete hook should allow the caller to do whatever he/she wants after all tests are done. Do you want to allow the caller to specify how report works for some new dispatch value by adding:

(defmethod report [::default :on-testing-complete] [m]
..custom-code)

Comment by David Nolen [ 05/May/15 7:32 AM ]

The purpose of report is just side effects, printing is only one possibility. Note there are several testing events that aren't even really used by the standard reporter.

Comment by Leon Grapenthin [ 05/May/15 12:37 PM ]

IMHO if you want to run anything synchronously before after or between tests, you should use fixtures or if necessary compose the desired blocks yourself.

At least making the latter possible is why I made run-block and the block builder fns public.

You can easily run

(run-block (concat (run-tests-block 'a-ns-to-be-tested 'another-ns-to-be-test )
[(fn []
;; your continuation code here
)]))

This is a reliable way to pick up control after testing.

This patch only affects testing done via run-tests. E. g. on-testing-complete-fn won't be invoked if a user invoked test-ns and testing is complete. You could hack it into the block composer in test-ns, but still users composing blocks in the way mentioned above couldn't rely on it being invoked.

Comment by Sebastian Bensusan [ 11/May/15 10:25 AM ]

I followed Leon's suggestions and used run-block to make my own test-block. The only problem is that my continuation function doesn't get the summary/env as an argument. From what I understood I could pass env as an argument to run-tests but it would get cleared right before my continuation function. I don't know how to work around this yet.

If you think my solution is a correct use of the cljs.test API then this patch isn't needed. If you believe that run-tests should report on-testing-done I'd be happy to submit a new patch adding a new event to the report event system. Then I could get the summary/env from a custom report method as David suggested.

Comment by David Nolen [ 11/May/15 10:37 AM ]

I would not consider anything at the level of run-block part of the public API nor anything that anyone should be looking into. This stuff may change.

Please add a real reporting hook thanks.

Comment by Sebastian Bensusan [ 12/May/15 5:39 AM ]

Added :end-run-test event to cljs.test and a dummy event handler for it.

Comment by David Nolen [ 12/May/15 3:04 PM ]

fixed https://github.com/clojure/clojurescript/commit/31736450c6ca951c63bb685d744c11074fbfe323

Comment by Leon Grapenthin [ 12/May/15 4:09 PM ]

For API consistency this should also be in the blocks of `test-all-vars` in `test-ns`, `test-var` and `test-vars`.

Comment by David Nolen [ 12/May/15 4:24 PM ]

Happy to see a new ticket + patch that addresses the consistency issue.

Comment by Sebastian Bensusan [ 13/May/15 2:51 AM ]

Leon, I filled CLJS-1267 to address your point. Feel free to add any other API inconsistencies that :end-run-tests introduced.





[CLJS-993] binding macro returns non-nil with empty body Created: 30/Jan/15  Updated: 30/Jan/15  Resolved: 30/Jan/15

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Minor
Reporter: Stefano Pugnetti Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: binding, test
Environment:

Ubuntu Linux 12.04
Clojurescript 0.0-2740



 Description   

In Clojure the binding macro returns nil when called with an empty body. In Clojurescript it returns a non empty object.

In this repository
https://github.com/stepugnetti/binding-issue
I've put a simple project in which the two behaviors are compared. The same code

(defn foo []
  (if (= nil (binding [*test-var* 1]))
    (.log js/console "Ok!")
    (.log js/console "Too bad!")))

can be run with
1) Clojure: lein run
2) Clojurescript: lein cljsbuild once main && node target/binding-issue.js

I was expecting the same result (nil)...

See discussion at https://groups.google.com/forum/#!topic/clojurescript/anbDq9pjvEs



 Comments   
Comment by David Nolen [ 30/Jan/15 5:47 PM ]

fixed https://github.com/clojure/clojurescript/commit/996f33e5250712072eaefb5eff13bb9372d5e1b6





[CLJS-974] Clean compile/build fails to resolve namespaces for cljs.test Created: 12/Jan/15  Updated: 13/Jan/15  Resolved: 13/Jan/15

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Major
Reporter: Denis Johnson Assignee: Unassigned
Resolution: Declined Votes: 0
Labels: cljs, test
Environment:

Linux Ubuntu 14.04
Java 1.7.0_17 Java HotSpot(TM) 64-Bit Server VM
leiningen 2.5.1
Intellij 13.1.6 with latest cursive 0.1.43 plugin

:dependencies
[[org.clojure/clojure "1.6.0"]
[org.clojure/clojurescript "0.0-2665"]
[reagent "0.5.0-alpha"]
[alandipert/storage-atom "1.2.3"]
[com.andrewmcveigh/cljs-time "0.3.0"]]
:plugins [[lein-cljsbuild "1.0.3"]]


Attachments: File test_suite.cljs    

 Description   

Clean compile gives the following error for a valid namespace for runner/suite (see attachment).
Same namespace works fine using cemerick/clojurescript.test
NOTE 1: if compiled using "cljsbuild auto test" after giving failure, if you delete the test/test-suite.cljs the compile completes successfully, if then you revert the file it also recompiles successfully and tests run as expected.
NOTE 2: Happens all the time on my machine but other devs on Windows platform don't seem to get this issue. The only difference I can see is I use leiningen checkouts feature to point at our other local repos and these are project dependencies. I have tested with removing the checkouts folder with change in behaviour so I doubt it is related.

Deleting files generated by lein-cljsbuild.
Compiling ClojureScript.
Compiling "compiled/test.js" from ["src" "test"]...
Compiling "compiled/test.js" failed.
clojure.lang.ExceptionInfo: failed compiling file:test/test_suite.cljs
core.clj:4403 clojure.core/ex-info
compiler.clj:1039 cljs.compiler/compile-file
compiler.clj:1069 cljs.compiler/compile-root
closure.clj:358 cljs.closure/compile-dir
closure.clj:398 cljs.closure/eval3160[fn]
closure.clj:306 cljs.closure/eval3096[fn]
closure.clj:412 cljs.closure/eval3147[fn]
closure.clj:306 cljs.closure/eval3096[fn]
compiler.clj:44 cljsbuild.compiler.SourcePaths/fn
core.clj:2557 clojure.core/map[fn]
LazySeq.java:40 clojure.lang.LazySeq.sval
LazySeq.java:49 clojure.lang.LazySeq.seq
RT.java:484 clojure.lang.RT.seq
core.clj:133 clojure.core/seq
core.clj:624 clojure.core/apply
core.clj:2586 clojure.core/mapcat
RestFn.java:423 clojure.lang.RestFn.invoke
compiler.clj:44 cljsbuild.compiler/cljsbuild.compiler.SourcePaths
closure.clj:1018 cljs.closure/build
closure.clj:972 cljs.closure/build
compiler.clj:58 cljsbuild.compiler/compile-cljs[fn]
compiler.clj:57 cljsbuild.compiler/compile-cljs
compiler.clj:159 cljsbuild.compiler/run-compiler
form-init1706317005734214457.clj:1 user/eval3512[fn]
form-init1706317005734214457.clj:1 user/eval3512[fn]
LazySeq.java:40 clojure.lang.LazySeq.sval
LazySeq.java:49 clojure.lang.LazySeq.seq
RT.java:484 clojure.lang.RT.seq
core.clj:133 clojure.core/seq
core.clj:2855 clojure.core/dorun
core.clj:2871 clojure.core/doall
form-init1706317005734214457.clj:1 user/eval3512
Compiler.java:6703 clojure.lang.Compiler.eval
Compiler.java:6693 clojure.lang.Compiler.eval
Compiler.java:7130 clojure.lang.Compiler.load
Compiler.java:7086 clojure.lang.Compiler.loadFile
main.clj:274 clojure.main/load-script
main.clj:279 clojure.main/init-opt
main.clj:307 clojure.main/initialize
main.clj:342 clojure.main/null-opt
main.clj:420 clojure.main/main
RestFn.java:421 clojure.lang.RestFn.invoke
Var.java:383 clojure.lang.Var.invoke
AFn.java:156 clojure.lang.AFn.applyToHelper
Var.java:700 clojure.lang.Var.applyTo
main.java:37 clojure.main.main
Caused by: clojure.lang.ExceptionInfo: No such namespace: test.model.dimension-glossary-test at line 1 test/test_suite.cljs
core.clj:4403 clojure.core/ex-info
analyzer.clj:297 cljs.analyzer/error
analyzer.clj:294 cljs.analyzer/error
analyzer.clj:1095 cljs.analyzer/analyze-deps
analyzer.clj:1280 cljs.analyzer/eval1561[fn]
MultiFn.java:249 clojure.lang.MultiFn.invoke
analyzer.clj:1609 cljs.analyzer/analyze-seq
analyzer.clj:1696 cljs.analyzer/analyze[fn]
analyzer.clj:1689 cljs.analyzer/analyze
compiler.clj:948 cljs.compiler/compile-file*[fn]
compiler.clj:906 cljs.compiler/with-core-cljs
compiler.clj:927 cljs.compiler/compile-file*
compiler.clj:1033 cljs.compiler/compile-file



 Comments   
Comment by David Nolen [ 13/Jan/15 7:31 AM ]

Please report cljsbuild bugs with the cljsbuild project thanks.





[CLJS-973] cljs.test ignores some deftest names Created: 12/Jan/15  Updated: 15/Jan/15  Resolved: 15/Jan/15

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Minor
Reporter: Denis Johnson Assignee: Unassigned
Resolution: Not Reproducible Votes: 0
Labels: cljs, test
Environment:

Linux Ubuntu 14.04
Java 1.7.0_17 Java HotSpot(TM) 64-Bit Server VM
leiningen 2.5.1

:dependencies
[[org.clojure/clojure "1.6.0"]
[org.clojure/clojurescript "0.0-2665"]
[reagent "0.5.0-alpha"]
[alandipert/storage-atom "1.2.3"]
[com.andrewmcveigh/cljs-time "0.3.0"]]
:plugins [[lein-cljsbuild "1.0.3"]]



 Description   

examples:

  • ignores: (deftest test:change-step-contiguous-forward> ....)
  • works: (deftest test:change-current-step ...) ignores: (deftest test-change-current-step ...)


 Comments   
Comment by David Nolen [ 15/Jan/15 1:26 AM ]
(deftest test:change-current-step: ...)
(deftest test:change-current-step@ ...)

Removed these two from ticket description these are not valid Clojure symbols see http://clojure.org/reader

Comment by David Nolen [ 15/Jan/15 1:37 AM ]

I tested the remaining names could not reproduce. Please only reopen this ticket if a full minimal case is provided.





[CLJS-485] clojure.string/replace ignores regex flags Created: 12/Mar/13  Updated: 01/Jun/15

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: 0.0-3269
Fix Version/s: Next

Type: Defect Priority: Minor
Reporter: Esa Virtanen Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: bug, patch, test

Attachments: Text File 0001-Take-regex-flags-m-i-into-account-in-clojure.string-.patch    
Patch: Code and Test

 Description   

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".



 Comments   
Comment by Chas Emerick [ 19/Mar/14 9:29 AM ]

I can confirm the bug. The attached patch applies cleanly, and works as expected.

Esa, sorry for the long delay (this one must have slipped through the cracks)! Could you please submit a contributor's agreement, so that your patch can be merged? More info is here:

http://clojure.org/contributing





[CLJS-260] Add clojure.core/shuffle implementation Created: 17/May/12  Updated: 27/Jul/13  Resolved: 20/May/12

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Enhancement Priority: Minor
Reporter: Evan Mezeske Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: enhancement, patch,, test

Attachments: Text File 0001-Add-clojure.core-shuffle-and-a-test.patch     Text File shuffle.patch     Text File shuffle.v2.patch    
Patch: Code and Test

 Description   

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.



 Comments   
Comment by David Nolen [ 17/May/12 7:07 PM ]

Why don't you return a vector like Clojure does?

Comment by Evan Mezeske [ 17/May/12 7:11 PM ]

Return a vector like Clojure.

Comment by David Nolen [ 18/May/12 9:23 PM ]

The patch is not correctly formatted with attribution.

Comment by Evan Mezeske [ 20/May/12 4:24 PM ]

Use git format-patch instead of git diff, to hopefully provide the right patch format.

Comment by David Nolen [ 20/May/12 10:28 PM ]

fixed, http://github.com/clojure/clojurescript/commit/b06905863a9b0ce3618634d8fe0effb3aefd4063





[CLJ-1678] Update failing tests for IBM JDK 1.7 and 1.8 Created: 19/Mar/15  Updated: 20/Mar/15

Status: Open
Project: Clojure
Component/s: None
Affects Version/s: Release 1.6, Release 1.7
Fix Version/s: None

Type: Defect Priority: Minor
Reporter: Andy Fingerhut Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: test
Environment:

IBM JDK 1.7 and 1.8


Approval: Triaged

 Description   

For Sun/Oracle JDKs, and IBM JDK 1.6, we have this:

user=> (.hashCode 9223372039002259457N)
1

For IBM JDKs 1.7 and 1.8, it changed to this (I do not know why):

user=> (.hashCode 9223372039002259457N)
33

This causes a few example-based tests in Clojure to fail when run on those IBM JDK versions. There does not appear to be any bug in Clojure here. Those tests were written with particular constant values that are different, but have equal .hashCode values, to test Clojure's code generated that selects between branches in a case. In particular, these tests in control.clj fail:

;; line 386 in Clojure 1.6.0 and 1.7.0-master-SNAPSHOT as of Mar 19 2015:
    (is (== (.hashCode 1) (.hashCode 9223372039002259457N)))

;; and later on line 423 in the same file:
  (testing "test warn for hash collision"
    (should-print-err-message
     #"Performance warning, .*:\d+ - hash collision of some case test constants; if selected, those entries will be tested sequentially..*\r?\n"
     (case 1 1 :long 9223372039002259457N :big 2)))

There are other tests in the same file with the same constant 9223372039002259457N that do not fail with IBM JDKs 1.7 and 1.8, but they do not test hash collisions as they were intended to.

Some possibilities for what could be changed:

1. Pick a different pair of number other than 1 and 9223372039002259457N when running tests on IBM JDKs 1.7 and 1.8, so that the hash values do collide. For example, 33 and 9223372039002259457N.

2. skip these tests completely when running on IBM JDKs 1.7 and 1.8.



 Comments   
Comment by Alex Miller [ 20/Mar/15 4:03 AM ]

I think my preference would be to skip these tests for the ibm jdk.





[CLJ-1667] Socket test can fail if hard-coded port is unavailable Created: 26/Feb/15  Updated: 27/Mar/15  Resolved: 27/Mar/15

Status: Closed
Project: Clojure
Component/s: None
Affects Version/s: Release 1.7
Fix Version/s: Release 1.7

Type: Defect Priority: Minor
Reporter: Alex Miller Assignee: Stuart Halloway
Resolution: Completed Votes: 0
Labels: io, test

Attachments: Text File socket-test.patch    
Patch: Code
Approval: Ok

 Description   

I was unable to run the Clojure tests due to this problem. There is a test that hardcodes a port and something else on my machine happened to be using that port.

The patch avoids binding a hard-coded port in the test.

Patch: socket-test.patch

Screened by:



 Comments   
Comment by Andy Fingerhut [ 26/Feb/15 11:31 AM ]

I used to try running the prescreen tests in parallel for two different JDKs on the same machine, and I probably stopped doing that because of this. My use case is a very unusual one, and not a good reason to change this by itself, but my use case certainly made this conflict happen regularly.

Comment by Alex Miller [ 26/Feb/15 11:57 AM ]

No good reason not to fix it! Silly test.





[CLJ-1643] Generative test for sequence implementations Created: 15/Jan/15  Updated: 15/Jan/15

Status: Open
Project: Clojure
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Enhancement Priority: Major
Reporter: Michael Blume Assignee: Michael Blume
Resolution: Unresolved Votes: 0
Labels: generative-test, test

Attachments: Text File clj-1643-gen-seq-test-v1.patch    
Patch: Code and Test
Approval: Triaged

 Description   

This is an attempt to write a minimal-foreknowledge failing test for CLJ-1633. By minimal-foreknowledge, I mean a test that fails in the presence of the bug, but which one could imagine writing without intimate knowledge of the details of the bug. I suspect that looking for tests like this is a good way to find gaps in test coverage, and produce tests that will uncover novel regressions later on.

Approach: Generate a single list of operations that could be performed on a sequence, changing that sequence. Make two copies of that operation list, and insert what should be identity-preserving operations into each. Run the two lists of operations and verify that the final results are the same.

With CLJ-1633 unfixed, we get this output:

[java] Testing clojure.test-clojure.sequences
     [java]
     [java] FAIL in (seq-gentest) (sequences.clj:135)
     [java] {:acts1 (->> nil (cons :foo) (cons :foo) into-array next (apply list)),
     [java]  :acts2 (->> nil (cons :foo) (cons :foo) next),
     [java]  :result1 (:foo :foo),
     [java]  :result2 (:foo),
     [java]  :pass false}
     [java]
     [java] expected: (:result res)
     [java]   actual: false





[CLJ-1635] Make distinct/dedupe/interpose transducer tests play nicely with new reporting Created: 09/Jan/15  Updated: 20/Feb/15  Resolved: 20/Feb/15

Status: Closed
Project: Clojure
Component/s: None
Affects Version/s: None
Fix Version/s: Release 1.7

Type: Enhancement Priority: Minor
Reporter: Michael Blume Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: test, transducers

Attachments: Text File clj-1635.patch    
Patch: Code and Test
Approval: Ok

 Description   

Fix interaction between CLJ-1601 (which introduced new transducers) and CLJ-1621 (which improved transducer tests) to improve test reporting for these new transducer arities as well.

Note from Alex M: I goofed these while rebasing CLJ-1601 after CLJ-1621 went in.

Patch: clj-1635.patch

Screened by: Alex Miller



 Comments   
Comment by Alex Miller [ 09/Jan/15 2:31 PM ]

My fault in the integration process! We'll try to get it fixed in 1.7. Thanks...





[CLJ-1528] clojure.test/inc-report-counter is not thread safe Created: 19/Sep/14  Updated: 04/May/15

Status: Open
Project: Clojure
Component/s: None
Affects Version/s: Release 1.7
Fix Version/s: None

Type: Defect Priority: Critical
Reporter: Alexander Redington Assignee: Alexander Redington
Resolution: Unresolved Votes: 1
Labels: ft, test
Environment:

OS X, Clojure 1.7, Macbook pro


Attachments: File fix-CLJ-1528.diff    
Patch: Code
Approval: Triaged

 Description   

clojure.test/inc-report-counter function combines dereferencing the report-counters ref and operating on the previous state of the ref, leading to race conditions during concurrent use.

(dosync (commute *report-counters* assoc name
                 (inc (or (*report-counters* name) 0))))

Approach: Rewrite update function to be entirely in terms of the old state:

(dosync (commute *report-counters* update-in [name] (fnil inc 0)))

Patch: fix-CLJ-1528.diff
Screened by: Alex Miller



 Comments   
Comment by Alexander Redington [ 19/Sep/14 10:58 AM ]

Fixes 1528





[CLJ-1397] exception testing broken over map Created: 01/Apr/14  Updated: 01/Apr/14  Resolved: 01/Apr/14

Status: Closed
Project: Clojure
Component/s: None
Affects Version/s: Release 1.5
Fix Version/s: None

Type: Defect Priority: Major
Reporter: MG Assignee: Unassigned
Resolution: Declined Votes: 0
Labels: test
Environment:

Linux ... 3.2.0-56-generic-pae #86-Ubuntu SMP ... i686 i686 i386 GNU/Linux



 Description   

Expected: Tests pass
Actual: Two tests fail
To reproduce, run the following test file:

(ns pe.test-test
(:require [clojure.test :refer :all]))
(defn throwexc [m] (throw (Exception. m)))
(defn throwass [m] (assert false m))
(defn nestexc [] (throwexc "exc"))
(defn nestass [] (throwass "ass"))
(defn nestmapexc [] (map throwexc '("a" "b" "c")))
(defn nestmapass [] (map throwass '("a" "b" "c")))
(deftest exceptions-and-assertions-test
(testing "throwing"
(is (thrown? Exception (throwexc "exc")))
(is (thrown? AssertionError (throwass "ass"))))
(testing "nesting"
(is (thrown? Exception (nestexc)))
(is (thrown? AssertionError (nestass))))
(testing "nesting over map"
(is (thrown? Exception (nestmapexc)))
(is (thrown? AssertionError (nestmapass)))))



 Comments   
Comment by MG [ 01/Apr/14 7:25 AM ]

Clarification: The two assertions in "nesting over map" fails, the other four assertions succeed.

Comment by Nicola Mometto [ 01/Apr/14 7:30 AM ]

map is lazy, the exception is never thrown because the sequence is never realized.
either wrap the map in a dorun or use a doseq instead of a map.
map should not be used for side-effecting





[CLJ-1379] Quoting of :actual form is incorrect in clojure.test :pass type maps Created: 12/Mar/14  Updated: 12/Mar/14

Status: Open
Project: Clojure
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Minor
Reporter: Hugo Duncan Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: test
Environment:

All clojure versions


Attachments: File fix-quoting-in-pass-case.diff    
Patch: Code

 Description   

The function symbol is not correctly quoted in the construction of the :actual value in a :pass type map for clojure.test.

It currently produces (list = 1 1) instead of (list '= 1 1) for an (is (= 1 1)) test.

I haven't been able to come up with a workaround for this.






[CLJ-990] Implement clojure.core.reducers/mapcat and some initial reducers tests Created: 10/May/12  Updated: 01/Mar/13  Resolved: 10/May/12

Status: Closed
Project: Clojure
Component/s: None
Affects Version/s: Release 1.5
Fix Version/s: Release 1.5

Type: Enhancement Priority: Minor
Reporter: Tassilo Horn Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: patch, test

Attachments: Text File 0001-Implement-clojure.core.reducers-mapcat.patch     Text File 0002-Add-initial-reducers-tests.patch    
Patch: Code and Test

 Description   

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.



 Comments   
Comment by Rich Hickey [ 10/May/12 7:44 PM ]

applied - thanks!





[CLJ-982] Implement an interface? predicate to balance class? Created: 04/May/12  Updated: 09/Jun/12  Resolved: 08/Jun/12

Status: Closed
Project: Clojure
Component/s: None
Affects Version/s: Release 1.5
Fix Version/s: None

Type: Enhancement Priority: Trivial
Reporter: David Rupp Assignee: Unassigned
Resolution: Declined Votes: 0
Labels: enhancement, patch, test
Environment:

Any


Attachments: File drupp-add-interface-predicate.diff    
Patch: Code and Test

 Description   

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))).



 Comments   
Comment by Stuart Halloway [ 08/Jun/12 12:28 PM ]

I would prefer to see this, and other interop/reflective items, in a separate contrib lib.

Comment by David Rupp [ 09/Jun/12 9:08 AM ]

Thanks for the feedback, Stu. Is there an existing contrib lib for stuff like this? Or should I create one?





[CLJ-964] test-clojure/rt.clj has undeclared dependency on clojure.set Created: 31/Mar/12  Updated: 18/Aug/12  Resolved: 18/Aug/12

Status: Closed
Project: Clojure
Component/s: None
Affects Version/s: Release 1.3, Release 1.4
Fix Version/s: Release 1.5

Type: Defect Priority: Trivial
Reporter: David Miller Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: test

Attachments: Text File clj-964-add-require-of-clojure-set-patch1.txt    
Patch: Code
Approval: Ok

 Description   

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.



 Comments   
Comment by Andy Fingerhut [ 31/Mar/12 8:47 PM ]

clj-964-add-require-of-clojure-set-patch1.txt dated March 31, 2012 applies cleanly as of latest master. It simply adds a require of clojure.set to test_clojure/rt.clj. I verified that if that test was the only one, it does fail without the require, and passes with it. I also verified that every other test file succeeds on its own without any further changes.

Comment by Aaron Bedra [ 14/Aug/12 8:30 PM ]

Patch applies cleanly against 4004d267e124f12b65b0d7fb6522f32a75e3c4fb. Submitter is a confirmed CA signer.





[CLJ-879] Allow :require to support a :refer clause Created: 17/Nov/11  Updated: 17/Feb/12  Resolved: 17/Feb/12

Status: Closed
Project: Clojure
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Enhancement Priority: Minor
Reporter: Phil Hagelberg Assignee: Phil Hagelberg
Resolution: Completed Votes: 9
Labels: patch,, test

Attachments: Text File 0001-Allow-require-to-take-a-refer-option.patch    
Patch: Code and Test
Approval: Ok

 Description   

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



 Comments   
Comment by Phil Hagelberg [ 25/Nov/11 2:52 PM ]

Patch containing implementation, test, and documentation.

Comment by Phil Hagelberg [ 06/Jan/12 2:21 PM ]

Any chance we could get some discussion going on this?

Comment by Devin Torres [ 14/Jan/12 1:12 AM ]

I'd love to see this discussed.

Comment by Phil Hagelberg [ 27/Jan/12 4:42 PM ]

So... how about it? Thoughts?

Comment by Kevin Downey [ 17/Feb/12 11:30 AM ]

patch still applies cleanly to master, tests pass

there is a warning when you run the tests though:

[java] Testing clojure.test-clojure.keywords
[java]
[java] Testing clojure.test-clojure.load
[java] WARNING: with-bindings already refers to: #'clojure.core/with-bindings in namespace: clojure.test-clojure.require-scratch, being replaced by: #'clojure.main/with-bindings
[java]
[java] Testing clojure.test-clojure.logic
[java]
[java] Testing clojure.test-clojure.macros

Comment by Stuart Sierra [ 17/Feb/12 1:36 PM ]

Vetted. Patch is good, although it needs docstring updates in 'require'

Comment by Stuart Sierra [ 17/Feb/12 1:55 PM ]

Not Vetted. I can't remember what the names mean. Ready for Rich. That's "Test" right?

Comment by Stuart Sierra [ 17/Feb/12 1:59 PM ]

My mistake. The docstring is included in 'require', but not in 'refer', which also changed. But the public API of 'refer' did not change. So this patch is good.

Comment by Stuart Sierra [ 17/Feb/12 2:08 PM ]

Not "Test." Screened. The patch is Screened. I hate this.

Comment by Stuart Sierra [ 17/Feb/12 2:18 PM ]

Patch applied.





[ASYNC-124] put! into channel that has mapcat transducer fails to dispatch more than one waiting takes Created: 30/May/15  Updated: 30/May/15

Status: Open
Project: core.async
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Critical
Reporter: Jozef Wagner Assignee: Jozef Wagner
Resolution: Unresolved Votes: 0
Labels: patch, test
Environment:

Clojure 1.7.0-RC1, latest core.async head (May 2015)


Attachments: Text File async-124-2.patch     Text File async-124.patch    

 Description   

This issue is similar to one that has caused the revert of ASYNC-103. When channel has multiple pending takes, one put will dispatch only one take, even if transducer attached to the channel produces multiple values.

(let [xf (mapcat #(range % (+ % 5)))
        c (chan 10 xf)]
    (dotimes [x 5]
      (take! c #(println x %)))
    (put! c 10)
    (put! c 15))

The output of the above code is

0 10
1 11

but it should be

0 10
1 11
2 12
3 13
4 14

Note that if we change the order and execute puts before takes, the result will be as expected



 Comments   
Comment by Jozef Wagner [ 30/May/15 10:30 AM ]

patch with test

Comment by Jozef Wagner [ 30/May/15 10:32 AM ]

Note that with attached patch the actual dispatch/run on takes happens before (.unlock mutex) and before (when done? (abort this)) are called.

Also note that added test only works with 1.7.0 version of clojure

Comment by Jozef Wagner [ 30/May/15 12:46 PM ]

Added new patch async-124-2.patch that dispatches after unlocking and aborting. Test was also changed as it had race condition.





Generated at Wed Jul 01 14:45:52 CDT 2015 using JIRA 4.4#649-r158309.