Re: Stanford AI Class
Hmm, I don't know if people will ever see Lisp as an AI Language though (kidding). My personal experience was that I learned Common Lisp in the context of an AI course in college. I was pretty excited about learning the language, so I read The Little Lisper the summer before taking the course. At least in my experience, it was not a distraction at all, but a big plus, and definitely life-changing. On Sun, Aug 14, 2011 at 6:37 PM, Jeff Heon jfh...@gmail.com wrote: I think we all agree that Lisp would be ideal for AI, given a medium or long-term exposure, but for an introductory class to varied branches of AI, we could do worse than Python, an easy to read language with various numerical and AI libraries (PyEvolve, for example. http://pyevolve.sourceforge.net/0_6rc1/). And it's dead simple to start using it with IDLE or the REPL. After all, the class is not about teaching Python or Lisp, it's about teaching AI concepts. Even Java has been used this gentle introduction to genetic programming: http://www.gp-field-guide.org.uk/. In fact, it might be even better to start with a no-brainer language like Python. Also if I may digress a bit, we have a tendency to forget that what works for us best might not be what works best for other. Lisp simply is not for everybody, maybe not even for most people, and that's ok. On Aug 13, 1:36 pm, Lee Spector lspec...@hampshire.edu wrote: On the other hand I prefer to work in Lisp (Common Lisp, Scheme, Clojure), but my main project these days involves evolving Push programs rather than Lisp programs, for a bunch of reasons related to evolvability -- seehttp://hampshire.edu/lspector/push.htmlif you really want to know. I prefer to work in Lisps because they make it simpler to write code that manipulates program-like structures (however they end up being executed) and because I like Lisps better than most other languages for a slew of other reasons. But my evolved code is executed on a Push interpreter implemented in the host language and there are Push-based GP systems in many languages (C++, Java, Javascript, Python, several Lisps). The language choice really just affects software engineering and workflow issues, not the fundamental power of the system to evolve/learn. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Small bug in clojure.core/bases?
Hi, Am Mittwoch, 10. August 2011 22:15:48 UTC+2 schrieb Alf: When calling bases on an inteface it returns an array. Should this not be a seq? Would that make a difference? You can pass an array where you'd expect a sequence. Sincerely Meikel -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Exception calling nth on Sets
Hi, Am Sonntag, 14. August 2011 18:59:57 UTC+2 schrieb Despite: In Clojurescript, calling rand-nth on an empty Set results in an Index out of bounds exception, whereas calling it on an empty Vector results in nil. Returning nil for vectors is almost certainly a bug as it should throw an exception according to the docstring of nth. Sincerely Meikel -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Small bug in clojure.core/bases?
I think a function should generally return the same types for different input. A seq and a Java array are two very different things even though Clojure often lets us pass both to the same functions. It seemed like a small fix, but I guess not everyone agrees. Like a wrote, I think this is small bug. I was just playing around with the function at the repl, and the behavior surprised me, so I thought I would mention it on the mailing list. user= (bases java.util.List) #Class[] [Ljava.lang.Class;@315b0333 user= (bases java.util.ArrayList) (java.util.AbstractList java.util.List java.util.RandomAccess java.lang.Cloneable java.io.Serializable) Cheers, Alf On Mon, Aug 15, 2011 at 08:03, Meikel Brandmeyer (kotarak) m...@kotka.de wrote: Hi, Am Mittwoch, 10. August 2011 22:15:48 UTC+2 schrieb Alf: When calling bases on an inteface it returns an array. Should this not be a seq? Would that make a difference? You can pass an array where you'd expect a sequence. Sincerely Meikel -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Small bug in clojure.core/bases?
Hi, Am Montag, 15. August 2011 11:25:33 UTC+2 schrieb Alf: I think a function should generally return the same types for different input. A seq and a Java array are two very different things even though Clojure often lets us pass both to the same functions. It seemed like a small fix, but I guess not everyone agrees. No issue. Just thought you might have a specific use case where this is an issue. Sincerely Meikel -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Exception calling nth on Sets
I should have done a comparison to original Clojure first. In Clojure, rand-nth on an empty vector does throw an exception, as Meikel says. As does any use of nth with a bad index and no not-found parameter. So that seems to be a bug. But, nth on a set never works in Clojure, throwing java.lang.UnsupportedOperationException: nth not supported on this type: PersistentHashSet. So, the fact that it works at all in Clojurescript seems to be a bug as well. On Aug 15, 1:13 am, Meikel Brandmeyer (kotarak) m...@kotka.de wrote: Hi, Am Sonntag, 14. August 2011 18:59:57 UTC+2 schrieb Despite: In Clojurescript, calling rand-nth on an empty Set results in an Index out of bounds exception, whereas calling it on an empty Vector results in nil. Returning nil for vectors is almost certainly a bug as it should throw an exception according to the docstring of nth. Sincerely Meikel -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: ClojureScript mailing list?
On Thu, Jul 28, 2011 at 12:36:08PM -0500, Devin Walters spake thus: I don't think there has been a significant enough influx of mail on the list to warrant the creation of a new, separate list. There are so many similarities between the two that I think we'd run into situations where people felt that the ClojureScript list was getting too much Clojure in it. The division between the two is thin enough to make me think we should keep one list. In addition, almost all of the mail I've seen on the Clojure list has been relevant to both Clojure and ClojureScript in general. There are some exceptions for items I believe fit the clojure-dev list better, and some exceptions for items I don't believe fit this (or any) list at all, but I have a feeling these are just some minor growing pains that will work themselves out as time goes on. After all, the announcement is pretty fresh. Let's let the dust settle a bit before we go and try to grow another head. Devin I'll inc /that/. -Al -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: is my understanding correct for function identity?
Another function in the same way is 'const :: a - b - a' (on haskell,
but easy to make in clojure if it doesn't exist) which
disregards the second argument and always returns the first.
This example is in haskell, but let's say that you're creating a
histogram, meaning that you go through a list of values, and increase
their value in a map. Hello would result in {'h' : 1, 'e' : 1, 'l' :
2, 'o' : 1}. You would reduce over the string, and add the key to the
map with a value of one. If the key already exists, you increase the old
value with one. The type signature for insertWith is '(a - a - a) - k
- a - Map k a - Map k a' meaning that it takes a function with two
parameters, a key, a value and a map and returns a new map. The two
parameters are new and old values of the key if the key existed
beforehand. We could give a function like (\a b - succ b) which
increases the latter value (in clojure it would be #(inc %2)), or we
could give a 'const succ' which would do it automatically.
--
Mats Rauhala
MasseR
pgprBfQtlq5Oi.pgp
Description: PGP signature
Re: Small bug in clojure.core/bases?
On Aug 10, 2011 1:16 PM, Alf Kristian Støyle alf.krist...@gmail.com
wrote:
I think I found a small bug in clojure.core/bases. Extending the
existing unit test reveals it:
(deftest test-bases
(are [x y] (= x y)
(bases java.lang.Math)
(list java.lang.Object)
(bases java.lang.Integer)
(list java.lang.Number java.lang.Comparable) )
(is (seq? (bases java.util.List
Test output is:
FAIL in (test-bases) (java_interop.clj:143)
expected: (seq? (bases java.util.List))
actual: (not (seq? #Class[] [Ljava.lang.Class;@363256a5))
When calling bases on an inteface it returns an array. Should this not
be a seq?
An easy fix though, 'seq' the else part:
(defn bases
Returns the immediate superclass and direct interfaces of c, if any
{:added 1.0
:static true}
[^Class c]
(when c
(let [i (.getInterfaces c)
s (.getSuperclass c)]
(not-empty
(if s (cons s i) (seq i))
Should I file a bug, submit a pull request, or is the behavior intended?
Cheers,
Alf
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with
your first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
syntax quoting and namespaces misbehaving in test?
I don't understand why this test would fail - can anyone explain why? (ns learn.clojure.test.core (:use [clojure.test])) (deftest namespaces (in-ns 'my.new.namespace) (is (= my.new.namespace (str *ns*))) (is (= `anything 'my.new.namespace/anything))) expected: (= (quote learn.clojure.test.core/anything) (quote my.new.namespace/anything)) actual: (not (= learn.clojure.test.core/anything my.new.namespace/ anything)) When I try this on the REPL, it seems to work as expected: user= (in-ns 'my.new.namespace) #Namespace my.new.namespace my.new.namespace= `anything my.new.namespace/anything Thanks! -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Small bug in clojure.core/bases?
I think a function should generally return the same types for different input. A seq and a Java array are two very different things even though Clojure often lets us pass both to the same functions. It seemed like a small fix, but I guess not everyone agrees. That's clearly a bug; they forgot to seq one of the two possible return values. File a bug and add a patch. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Clojure-CLR, CLASSPATH, clojure.load.path and Cygwin
I understand that the 1.3 beta plans to add an environment variable named clojure.load.path to provide a CLASSPATH mechanism for Clojure on the CLR. Although I use Windows, I have installed cygwin because I prefer the Unix tool set to that provided by Windows. Although a Windows console allows one to set environment variables like clojure.load.path, the bash shell does not. How do we plan to support an alternative name that can be used by people running Clojure-CLR from within cygwin? Thanks. Have a great day! -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Small bug in clojure.core/bases?
Thanks. Submitted an issue to Jira, and I guess I will just see how it goes. http://dev.clojure.org/jira/browse/CLJ-828 Cheers Alf On Mon, Aug 15, 2011 at 16:26, Armando Blancas armando_blan...@yahoo.com wrote: I think a function should generally return the same types for different input. A seq and a Java array are two very different things even though Clojure often lets us pass both to the same functions. It seemed like a small fix, but I guess not everyone agrees. That's clearly a bug; they forgot to seq one of the two possible return values. File a bug and add a patch. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: syntax quoting and namespaces misbehaving in test?
On Aug 15, 6:16 am, Richard Rattigan ratti...@gmail.com wrote: I don't understand why this test would fail - can anyone explain why? (ns learn.clojure.test.core (:use [clojure.test])) (deftest namespaces (in-ns 'my.new.namespace) (is (= my.new.namespace (str *ns*))) (is (= `anything 'my.new.namespace/anything))) expected: (= (quote learn.clojure.test.core/anything) (quote my.new.namespace/anything)) actual: (not (= learn.clojure.test.core/anything my.new.namespace/ anything)) When I try this on the REPL, it seems to work as expected: user= (in-ns 'my.new.namespace) #Namespace my.new.namespace my.new.namespace= `anything my.new.namespace/anything The syntax quoting happens at read time, before in-ns is executed. You can do something similar at the repl: user= (do (in-ns 'tmp) `foo) user/foo -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Trouble embedding clojurescript in server application
I've been exchanging emails and software packages back and forth with
ibdknox who has been trying to help, and the whole thing is really
weird. I've done my tests on two different computers (both running
Ubuntu Natty 11.04 x64), and I get the exact same error on both.
ibdknox is testing on his side. I've sent him my compiled packages,
which fails in the same way on his side (on a Mac OSX), but which work
when he simply does rm -rf resources lein clean lein run. He
has sent me his packages, which work when I run them precompiled, but
fail like my initial report when I rebuild his stuff with the same
commands.
java -version on my side outputs:
java version 1.6.0_26
Java(TM) SE Runtime Environment (build 1.6.0_26-b03)
Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02, mixed mode)
I'm not sure which version ibdknox runs, but normally Mac OSX is
lagging as far as java releases go.
Anyway, if somebody else not on Mac OSX, or preferrably somebody with
access to both Linux and OSX, could give it a try, it would be
appreciated. Remember to remove the resources directory to force
recompilation of the clojurescript file (cljs) on startup.
ibdknox' compiled package which works can be downloaded from my server
on:
http://kjeldahl.net/myapp.zip
Thanks,
Marius K.
On Aug 14, 12:13 pm, kjeldahl mariusauto-googlegro...@kjeldahl.net
wrote:
I've tried getting clojurescript to run in both my own application,
and also tested getting it embedded using noir and noir-cljs, but I'm
not having much luck. Essentially, whenever the build method gets
called, clojurescript outputs the following errors (except for the
line starting with src-dir below, which is debug output which shows
what the build method gets fed):
Starting server...
src-dir: src/ opts: {:output-dir resources/public/cljs/, :output-
to resources/public/cljs/bootstrap.js, :optimizations :simple}
WARNING: Use of undeclared Var cljs.core/defn at line 15
WARNING: Use of undeclared Var cljs.core/truth_ at line 15
WARNING: Use of undeclared Var cljs.core/x at line 15
and many similar lines. There's only one cljs file in the path, and
it's the simple hello example from the QuickStart clojurescript github
page.
If anybody with a clue could help me figure out how to fix or work
around this it would be greatly appreciated.
Thanks,
Marius K.
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: syntax quoting and namespaces misbehaving in test?
Okay, that makes sense - although it does seem potentially confusing. Thanks! On Aug 15, 1:42 pm, Alan Malloy a...@malloys.org wrote: On Aug 15, 6:16 am, Richard Rattigan ratti...@gmail.com wrote: I don't understand why this test would fail - can anyone explain why? (ns learn.clojure.test.core (:use [clojure.test])) (deftest namespaces (in-ns 'my.new.namespace) (is (= my.new.namespace (str *ns*))) (is (= `anything 'my.new.namespace/anything))) expected: (= (quote learn.clojure.test.core/anything) (quote my.new.namespace/anything)) actual: (not (= learn.clojure.test.core/anything my.new.namespace/ anything)) When I try this on the REPL, it seems to work as expected: user= (in-ns 'my.new.namespace) #Namespace my.new.namespace my.new.namespace= `anything my.new.namespace/anything The syntax quoting happens at read time, before in-ns is executed. You can do something similar at the repl: user= (do (in-ns 'tmp) `foo) user/foo -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: syntax quoting and namespaces misbehaving in test?
I'm finding that namespaces don't seem to behave as I expect intuitively, or according to the reference. It's quite possible I'm in the wrong here though, as I'm just kicking clojure's tires at this point. Here is the relevant doc: http://clojure.org/special_forms (def symbol init?) Creates and interns or locates a global var with the name of symbol and a namespace of the value of the current namespace (*ns*). In the test below, which succeeds, the var does not appear to end up in the current namespace per this definition. Am I misinterpreting something, or is this a deviation from the spec/reference? (ns learn.clojure.test.core (:use [clojure.test])) (deftest namespace2 (in-ns 'my.new.namespace) ;confirm the current namespace (is (= my.new.namespace (str *ns*))) ;attempt to def a var in the current namespace (def anything 10) ;the var is not defined in the current namespace (is (nil? (ns-resolve *ns* 'anything))) ;the var is however definined in the orginal namespace (is (not (nil? (ns-resolve (find-ns 'learn.clojure.test.core) 'anything (is (= 10 learn.clojure.test.core/anything))) On Aug 15, 1:42 pm, Alan Malloy a...@malloys.org wrote: On Aug 15, 6:16 am, Richard Rattigan ratti...@gmail.com wrote: I don't understand why this test would fail - can anyone explain why? (ns learn.clojure.test.core (:use [clojure.test])) (deftest namespaces (in-ns 'my.new.namespace) (is (= my.new.namespace (str *ns*))) (is (= `anything 'my.new.namespace/anything))) expected: (= (quote learn.clojure.test.core/anything) (quote my.new.namespace/anything)) actual: (not (= learn.clojure.test.core/anything my.new.namespace/ anything)) When I try this on the REPL, it seems to work as expected: user= (in-ns 'my.new.namespace) #Namespace my.new.namespace my.new.namespace= `anything my.new.namespace/anything The syntax quoting happens at read time, before in-ns is executed. You can do something similar at the repl: user= (do (in-ns 'tmp) `foo) user/foo -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: syntax quoting and namespaces misbehaving in test?
deftest is a macro. Macros are expanded at compile time. So, in this case, at compile time, a function called namespace2 is def'd with meta data :test set to the body of your deftest. All of that body is namespace resolved in macro expansion, before in-ns is ever executed (which happens when you actually call the namespace2 function created by the macro). Put another way, (def anything 10) is namespace resolved to (def learn.clojure.test.core/anything 10) at macro expansion time (compile time), before the test function is ever called, and thereby before in-ns is ever executed. Hope this helps. - Mark On Mon, Aug 15, 2011 at 5:07 PM, Richard Rattigan ratti...@gmail.com wrote: I'm finding that namespaces don't seem to behave as I expect intuitively, or according to the reference. It's quite possible I'm in the wrong here though, as I'm just kicking clojure's tires at this point. Here is the relevant doc: http://clojure.org/special_forms (def symbol init?) Creates and interns or locates a global var with the name of symbol and a namespace of the value of the current namespace (*ns*). In the test below, which succeeds, the var does not appear to end up in the current namespace per this definition. Am I misinterpreting something, or is this a deviation from the spec/reference? (ns learn.clojure.test.core (:use [clojure.test])) (deftest namespace2 (in-ns 'my.new.namespace) ;confirm the current namespace (is (= my.new.namespace (str *ns*))) ;attempt to def a var in the current namespace (def anything 10) ;the var is not defined in the current namespace (is (nil? (ns-resolve *ns* 'anything))) ;the var is however definined in the orginal namespace (is (not (nil? (ns-resolve (find-ns 'learn.clojure.test.core) 'anything (is (= 10 learn.clojure.test.core/anything))) On Aug 15, 1:42 pm, Alan Malloy a...@malloys.org wrote: On Aug 15, 6:16 am, Richard Rattigan ratti...@gmail.com wrote: I don't understand why this test would fail - can anyone explain why? (ns learn.clojure.test.core (:use [clojure.test])) (deftest namespaces (in-ns 'my.new.namespace) (is (= my.new.namespace (str *ns*))) (is (= `anything 'my.new.namespace/anything))) expected: (= (quote learn.clojure.test.core/anything) (quote my.new.namespace/anything)) actual: (not (= learn.clojure.test.core/anything my.new.namespace/ anything)) When I try this on the REPL, it seems to work as expected: user= (in-ns 'my.new.namespace) #Namespace my.new.namespace my.new.namespace= `anything my.new.namespace/anything The syntax quoting happens at read time, before in-ns is executed. You can do something similar at the repl: user= (do (in-ns 'tmp) `foo) user/foo -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: syntax quoting and namespaces misbehaving in test?
Is it? That's neat; I guess I've never thought about how the compiler treats def. Thanks for the explanation. On Aug 15, 3:03 pm, Mark Rathwell mark.rathw...@gmail.com wrote: deftest is a macro. Macros are expanded at compile time. So, in this case, at compile time, a function called namespace2 is def'd with meta data :test set to the body of your deftest. All of that body is namespace resolved in macro expansion, before in-ns is ever executed (which happens when you actually call the namespace2 function created by the macro). Put another way, (def anything 10) is namespace resolved to (def learn.clojure.test.core/anything 10) at macro expansion time (compile time), before the test function is ever called, and thereby before in-ns is ever executed. Hope this helps. On Mon, Aug 15, 2011 at 5:07 PM, Richard Rattigan ratti...@gmail.com wrote: I'm finding that namespaces don't seem to behave as I expect intuitively, or according to the reference. It's quite possible I'm in the wrong here though, as I'm just kicking clojure's tires at this point. Here is the relevant doc: http://clojure.org/special_forms (def symbol init?) Creates and interns or locates a global var with the name of symbol and a namespace of the value of the current namespace (*ns*). In the test below, which succeeds, the var does not appear to end up in the current namespace per this definition. Am I misinterpreting something, or is this a deviation from the spec/reference? (ns learn.clojure.test.core (:use [clojure.test])) (deftest namespace2 (in-ns 'my.new.namespace) ;confirm the current namespace (is (= my.new.namespace (str *ns*))) ;attempt to def a var in the current namespace (def anything 10) ;the var is not defined in the current namespace (is (nil? (ns-resolve *ns* 'anything))) ;the var is however definined in the orginal namespace (is (not (nil? (ns-resolve (find-ns 'learn.clojure.test.core) 'anything (is (= 10 learn.clojure.test.core/anything))) -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: syntax quoting and namespaces misbehaving in test?
Just to be clear, it is namespace resolved because of syntax quote: (defmacro deftest [name body] (when *load-tests* `(def ~(vary-meta name assoc :test `(fn [] ~@body)) (fn [] (test-var (var ~name)) On Mon, Aug 15, 2011 at 7:23 PM, Alan Malloy a...@malloys.org wrote: Is it? That's neat; I guess I've never thought about how the compiler treats def. Thanks for the explanation. On Aug 15, 3:03 pm, Mark Rathwell mark.rathw...@gmail.com wrote: deftest is a macro. Macros are expanded at compile time. So, in this case, at compile time, a function called namespace2 is def'd with meta data :test set to the body of your deftest. All of that body is namespace resolved in macro expansion, before in-ns is ever executed (which happens when you actually call the namespace2 function created by the macro). Put another way, (def anything 10) is namespace resolved to (def learn.clojure.test.core/anything 10) at macro expansion time (compile time), before the test function is ever called, and thereby before in-ns is ever executed. Hope this helps. On Mon, Aug 15, 2011 at 5:07 PM, Richard Rattigan ratti...@gmail.com wrote: I'm finding that namespaces don't seem to behave as I expect intuitively, or according to the reference. It's quite possible I'm in the wrong here though, as I'm just kicking clojure's tires at this point. Here is the relevant doc: http://clojure.org/special_forms (def symbol init?) Creates and interns or locates a global var with the name of symbol and a namespace of the value of the current namespace (*ns*). In the test below, which succeeds, the var does not appear to end up in the current namespace per this definition. Am I misinterpreting something, or is this a deviation from the spec/reference? (ns learn.clojure.test.core (:use [clojure.test])) (deftest namespace2 (in-ns 'my.new.namespace) ;confirm the current namespace (is (= my.new.namespace (str *ns*))) ;attempt to def a var in the current namespace (def anything 10) ;the var is not defined in the current namespace (is (nil? (ns-resolve *ns* 'anything))) ;the var is however definined in the orginal namespace (is (not (nil? (ns-resolve (find-ns 'learn.clojure.test.core) 'anything (is (= 10 learn.clojure.test.core/anything))) -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: syntax quoting and namespaces misbehaving in test?
I either disagree or don't understand. The deftest macro doesn't touch your body arg; it's expanded as-is. For example, (let [x 'foo] `(inc ~x)) doesn't result in foo getting qualified, and most macros behave the same way. On Aug 15, 4:36 pm, Mark Rathwell mark.rathw...@gmail.com wrote: Just to be clear, it is namespace resolved because of syntax quote: (defmacro deftest [name body] (when *load-tests* `(def ~(vary-meta name assoc :test `(fn [] ~@body)) (fn [] (test-var (var ~name)) On Mon, Aug 15, 2011 at 7:23 PM, Alan Malloy a...@malloys.org wrote: Is it? That's neat; I guess I've never thought about how the compiler treats def. Thanks for the explanation. On Aug 15, 3:03 pm, Mark Rathwell mark.rathw...@gmail.com wrote: deftest is a macro. Macros are expanded at compile time. So, in this case, at compile time, a function called namespace2 is def'd with meta data :test set to the body of your deftest. All of that body is namespace resolved in macro expansion, before in-ns is ever executed (which happens when you actually call the namespace2 function created by the macro). Put another way, (def anything 10) is namespace resolved to (def learn.clojure.test.core/anything 10) at macro expansion time (compile time), before the test function is ever called, and thereby before in-ns is ever executed. Hope this helps. On Mon, Aug 15, 2011 at 5:07 PM, Richard Rattigan ratti...@gmail.com wrote: I'm finding that namespaces don't seem to behave as I expect intuitively, or according to the reference. It's quite possible I'm in the wrong here though, as I'm just kicking clojure's tires at this point. Here is the relevant doc: http://clojure.org/special_forms (def symbol init?) Creates and interns or locates a global var with the name of symbol and a namespace of the value of the current namespace (*ns*). In the test below, which succeeds, the var does not appear to end up in the current namespace per this definition. Am I misinterpreting something, or is this a deviation from the spec/reference? (ns learn.clojure.test.core (:use [clojure.test])) (deftest namespace2 (in-ns 'my.new.namespace) ;confirm the current namespace (is (= my.new.namespace (str *ns*))) ;attempt to def a var in the current namespace (def anything 10) ;the var is not defined in the current namespace (is (nil? (ns-resolve *ns* 'anything))) ;the var is however definined in the orginal namespace (is (not (nil? (ns-resolve (find-ns 'learn.clojure.test.core) 'anything (is (= 10 learn.clojure.test.core/anything))) -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Trouble embedding clojurescript in server application
I can confirm the problem. Same java (ubuntu) version here. To reproduce the problem please try: 1. Create a new Noir project as described at https://github.com/ibdknox/noir : lein plugin install lein-noir 1.1.0 lein noir new my-website cd my-website lein run Check localhost:8080/welcome 2. Add noir-cljs as described at https://github.com/ibdknox/noir-cljs : In your Noir project add the following dependency [org.clojure/clojure 1.3.0-beta1] [noir 1.1.1-SNAPSHOT] [noir-cljs 0.1.0-SNAPSHOT] Then in your server.clj require noir.util.cljs and add the middleware: (server/add-middleware noir.util.cljs/wrap-cljs) Then do a `lein clean` and a `lein deps`. Try with `lein run`. I needed to create `resources/public/cljs` to get it running. 3. Create a cljs file in the src directory. `lein run` should trigger a compile. Every page reload should also trigger a recompile if the cljs changed. 4. Do a `lein clean`. At least for me, at this point `lein run` shows the reported output. After a `lein clean lein run` in the myapp project I found these new files in classes: # classes/cljs/ # classes/hiccup/form_helpers$check_box.class # classes/hiccup/form_helpers$drop_down.class # classes/hiccup/form_helpers$file_upload.class # classes/hiccup/form_helpers$form_to.class # classes/hiccup/form_helpers$hidden_field.class # classes/hiccup/form_helpers$input_field.class # classes/hiccup/form_helpers$label.class # classes/hiccup/form_helpers$loading__4531__auto__.class # classes/hiccup/form_helpers$make_id$fn__3353.class # classes/hiccup/form_helpers$make_id.class # classes/hiccup/form_helpers$make_name$fn__3348.class # classes/hiccup/form_helpers$make_name.class # classes/hiccup/form_helpers$password_field.class # classes/hiccup/form_helpers$radio_button.class # classes/hiccup/form_helpers$reset_button.class # classes/hiccup/form_helpers$select_options$iter__3362__3366$fn__3367$fn__3368.class # classes/hiccup/form_helpers$select_options$iter__3362__3366$fn__3367.class # classes/hiccup/form_helpers$select_options$iter__3362__3366.class # classes/hiccup/form_helpers$select_options.class # classes/hiccup/form_helpers$submit_button.class # classes/hiccup/form_helpers$text_area.class # classes/hiccup/form_helpers$text_field.class # classes/hiccup/form_helpers$with_group.class # classes/hiccup/form_helpers__init.class # classes/myapp/server$_main.class # classes/myapp/server__init.class # classes/myapp/views/ # classes/noir/content/pages$GET__.class # classes/noir/content/pages$fn__3395.class # classes/noir/content/pages$header.class # classes/noir/content/pages$loading__4531__auto__.class # classes/noir/content/pages$logo.class # classes/noir/content/pages__init.class # classes/noir/util/cljs$compile_cljs.class # classes/noir/util/cljs$ext_filter$fn__3322.class # classes/noir/util/cljs$ext_filter.class # classes/noir/util/cljs$files_updated_QMARK_.class # classes/noir/util/cljs$find_cljs.class # classes/noir/util/cljs$loading__4531__auto__.class # classes/noir/util/cljs$newer_QMARK_.class # classes/noir/util/cljs$wrap_cljs$fn__3330.class # classes/noir/util/cljs$wrap_cljs.class # classes/noir/util/cljs__init.class HTH, Jan java version 1.6.0_26 Java(TM) SE Runtime Environment (build 1.6.0_26-b03) Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02, mixed mode) http://kjeldahl.net/myapp.zip -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: syntax quoting and namespaces misbehaving in test?
You are correct, I must have messed something up in my expansions. From the below, however, it looks like a var is being declared just by having the macro called, but not bound to the value: user (defmacro foo [name body] `(def ~name ~(identity `(fn [] ~@body #'user/foo user (foo xx (in-ns 'foo.core) (def anything3 10)) #'user/xx user anything3 Var user/anything3 is unbound. [Thrown class java.lang.IllegalStateException] user anything4 Unable to resolve symbol: anything4 in this context [Thrown class java.lang.Exception] On Mon, Aug 15, 2011 at 8:56 PM, Alan Malloy a...@malloys.org wrote: I either disagree or don't understand. The deftest macro doesn't touch your body arg; it's expanded as-is. For example, (let [x 'foo] `(inc ~x)) doesn't result in foo getting qualified, and most macros behave the same way. On Aug 15, 4:36 pm, Mark Rathwell mark.rathw...@gmail.com wrote: Just to be clear, it is namespace resolved because of syntax quote: (defmacro deftest [name body] (when *load-tests* `(def ~(vary-meta name assoc :test `(fn [] ~@body)) (fn [] (test-var (var ~name)) On Mon, Aug 15, 2011 at 7:23 PM, Alan Malloy a...@malloys.org wrote: Is it? That's neat; I guess I've never thought about how the compiler treats def. Thanks for the explanation. On Aug 15, 3:03 pm, Mark Rathwell mark.rathw...@gmail.com wrote: deftest is a macro. Macros are expanded at compile time. So, in this case, at compile time, a function called namespace2 is def'd with meta data :test set to the body of your deftest. All of that body is namespace resolved in macro expansion, before in-ns is ever executed (which happens when you actually call the namespace2 function created by the macro). Put another way, (def anything 10) is namespace resolved to (def learn.clojure.test.core/anything 10) at macro expansion time (compile time), before the test function is ever called, and thereby before in-ns is ever executed. Hope this helps. On Mon, Aug 15, 2011 at 5:07 PM, Richard Rattigan ratti...@gmail.com wrote: I'm finding that namespaces don't seem to behave as I expect intuitively, or according to the reference. It's quite possible I'm in the wrong here though, as I'm just kicking clojure's tires at this point. Here is the relevant doc: http://clojure.org/special_forms (def symbol init?) Creates and interns or locates a global var with the name of symbol and a namespace of the value of the current namespace (*ns*). In the test below, which succeeds, the var does not appear to end up in the current namespace per this definition. Am I misinterpreting something, or is this a deviation from the spec/reference? (ns learn.clojure.test.core (:use [clojure.test])) (deftest namespace2 (in-ns 'my.new.namespace) ;confirm the current namespace (is (= my.new.namespace (str *ns*))) ;attempt to def a var in the current namespace (def anything 10) ;the var is not defined in the current namespace (is (nil? (ns-resolve *ns* 'anything))) ;the var is however definined in the orginal namespace (is (not (nil? (ns-resolve (find-ns 'learn.clojure.test.core) 'anything (is (= 10 learn.clojure.test.core/anything))) -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: syntax quoting and namespaces misbehaving in test?
Wow, forget everything I said, this has nothing to do with macro expansion. Looks more like inside a function you can only def something in the same namespace as the function: user (defn ff [] (in-ns 'foo.core2) (def anything5 10)) #'user/ff user anything5 Var user/anything5 is unbound. [Thrown class java.lang.IllegalStateException] user (ff) #'user/anything5 foo.core2 (in-ns 'foo.core2) #Namespace foo.core2 foo.core2 (def anything6 10) #'foo.core2/anything6 On Mon, Aug 15, 2011 at 9:36 PM, Mark Rathwell mark.rathw...@gmail.com wrote: You are correct, I must have messed something up in my expansions. From the below, however, it looks like a var is being declared just by having the macro called, but not bound to the value: user (defmacro foo [name body] `(def ~name ~(identity `(fn [] ~@body #'user/foo user (foo xx (in-ns 'foo.core) (def anything3 10)) #'user/xx user anything3 Var user/anything3 is unbound. [Thrown class java.lang.IllegalStateException] user anything4 Unable to resolve symbol: anything4 in this context [Thrown class java.lang.Exception] On Mon, Aug 15, 2011 at 8:56 PM, Alan Malloy a...@malloys.org wrote: I either disagree or don't understand. The deftest macro doesn't touch your body arg; it's expanded as-is. For example, (let [x 'foo] `(inc ~x)) doesn't result in foo getting qualified, and most macros behave the same way. On Aug 15, 4:36 pm, Mark Rathwell mark.rathw...@gmail.com wrote: Just to be clear, it is namespace resolved because of syntax quote: (defmacro deftest [name body] (when *load-tests* `(def ~(vary-meta name assoc :test `(fn [] ~@body)) (fn [] (test-var (var ~name)) On Mon, Aug 15, 2011 at 7:23 PM, Alan Malloy a...@malloys.org wrote: Is it? That's neat; I guess I've never thought about how the compiler treats def. Thanks for the explanation. On Aug 15, 3:03 pm, Mark Rathwell mark.rathw...@gmail.com wrote: deftest is a macro. Macros are expanded at compile time. So, in this case, at compile time, a function called namespace2 is def'd with meta data :test set to the body of your deftest. All of that body is namespace resolved in macro expansion, before in-ns is ever executed (which happens when you actually call the namespace2 function created by the macro). Put another way, (def anything 10) is namespace resolved to (def learn.clojure.test.core/anything 10) at macro expansion time (compile time), before the test function is ever called, and thereby before in-ns is ever executed. Hope this helps. On Mon, Aug 15, 2011 at 5:07 PM, Richard Rattigan ratti...@gmail.com wrote: I'm finding that namespaces don't seem to behave as I expect intuitively, or according to the reference. It's quite possible I'm in the wrong here though, as I'm just kicking clojure's tires at this point. Here is the relevant doc: http://clojure.org/special_forms (def symbol init?) Creates and interns or locates a global var with the name of symbol and a namespace of the value of the current namespace (*ns*). In the test below, which succeeds, the var does not appear to end up in the current namespace per this definition. Am I misinterpreting something, or is this a deviation from the spec/reference? (ns learn.clojure.test.core (:use [clojure.test])) (deftest namespace2 (in-ns 'my.new.namespace) ;confirm the current namespace (is (= my.new.namespace (str *ns*))) ;attempt to def a var in the current namespace (def anything 10) ;the var is not defined in the current namespace (is (nil? (ns-resolve *ns* 'anything))) ;the var is however definined in the orginal namespace (is (not (nil? (ns-resolve (find-ns 'learn.clojure.test.core) 'anything (is (= 10 learn.clojure.test.core/anything))) -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send
Re: Clojure-CLR, CLASSPATH, clojure.load.path and Cygwin
On Mon, Aug 15, 2011 at 11:13 AM, mrwizard82d1 mrwizard8...@gmail.com wrote: I understand that the 1.3 beta plans to add an environment variable named clojure.load.path to provide a CLASSPATH mechanism for Clojure on the CLR. Although I use Windows, I have installed cygwin because I prefer the Unix tool set to that provided by Windows. Although a Windows console allows one to set environment variables like clojure.load.path, the bash shell does not. Are you sure there isn't some form of quoting or escaping that will make that name acceptable to bash? Failing that, can you invoke Windows's setenv from within bash? If it's a .com or .exe it should be possible but if it's a cmd.exe builtin command like dir you'd probably be SOL. (You can invoke cmd.exe with a command to execute, but I expect if that command is setenv the environment change will be popped when cmd.exe exits.) Failing that, too, you could resort to cobbling together your own setenv.exe using Windows APIs and gcc to invoke from your launch script. -- Protege: What is this seething mass of parentheses?! Master: Your father's Lisp REPL. This is the language of a true hacker. Not as clumsy or random as C++; a language for a more civilized age. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
defining tests for an api to be called by the implementations
I am working on an api that has an interface and two distinct implementations lets call them: foo and bar. I have a testing routine with a bunch of functions that each call a function to get a clean instance of an implementation, initializes it with some data and then interrogate it. with the exception of calling (new-foo) or (new-bar), foo and bar can be tested identically. I would like to be able to define tests in a namespace for the api, then have a test-foo namespace that calls those tests with *new-test-instance* bound to new-foo. likewise for new bar. because I would like the exact same tests run, the whole point is these things should behave the same at the API level. I don't want to have to copy and paste all my tests and make sure I keep them synchronized, that seems like an error waiting to happen. I can define the tests in test-api with deftest but doing so will cause the test to be run there (when I call mvn clojure:test), and as there is no implementation they will of course fail. I can block test- api from calling it's tests with: (defn test-ns-hook []) but then the tests become a pain to call from another namespace. surely there is a way to do this? in test-api with the blocking test-ns-hook, I tried (def the-tests [ (deftest test-1 ) ]) then in test-foo I tried (defn test-ns-hook [] (dorun (map (fn [x] (binding [project.test-api/*new-test-instance* (fn [] (new-foo))] (x))) project.test-api/the-tests))) that doesn't work I keep seeing this: Uncaught exception, not in assertion. expected: nil actual: java.lang.NoClassDefFoundError: org/slf4j/impl/ StaticLoggerBinder ... except if I put that exact same test-ns-hook implementation into the repl and call (run-tests) everything checks out *exactly* as expected. I have spent way too many hours on this... help? Kevin -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: defining tests for an api to be called by the implementations
On Aug 15, 10:16 pm, Kevin Livingston kevinlivingston.pub...@gmail.com wrote: I am working on an api that has an interface and two distinct implementations lets call them: foo and bar. I have a testing routine with a bunch of functions that each call a function to get a clean instance of an implementation, initializes it with some data and then interrogate it. with the exception of calling (new-foo) or (new-bar), foo and bar can be tested identically. I would like to be able to define tests in a namespace for the api, then have a test-foo namespace that calls those tests with *new-test-instance* bound to new-foo. likewise for new bar. because I would like the exact same tests run, the whole point is these things should behave the same at the API level. I don't want to have to copy and paste all my tests and make sure I keep them synchronized, that seems like an error waiting to happen. I can define the tests in test-api with deftest but doing so will cause the test to be run there (when I call mvn clojure:test), and as there is no implementation they will of course fail. I can block test- api from calling it's tests with: (defn test-ns-hook []) but then the tests become a pain to call from another namespace. surely there is a way to do this? (defn test-ns-hook [] (when (bound? #'api-instance) ...))? in test-api with the blocking test-ns-hook, I tried (def the-tests [ (deftest test-1 ) ]) then in test-foo I tried (defn test-ns-hook [] (dorun (map (fn [x] (binding [project.test-api/*new-test-instance* (fn [] (new-foo))] (x))) project.test-api/the-tests))) that doesn't work I keep seeing this: Uncaught exception, not in assertion. expected: nil actual: java.lang.NoClassDefFoundError: org/slf4j/impl/ StaticLoggerBinder ... except if I put that exact same test-ns-hook implementation into the repl and call (run-tests) everything checks out *exactly* as expected. I have spent way too many hours on this... help? Kevin -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
