Re: puzzlement over lazy sequences
On Sep 12, 2011, at 11:28 PM, Ken Wesson wrote: > But if, as you say, take, drop, etc. work for larger n, it should be > easy to make nth work with larger n and non-random-access seqs, just > by changing the non-random-access case to (first (drop n the-seq)). I'd be rather surprised if nth suddenly started giving linear performance on arrays for large values of n. If nth can't be made to work in constant time on arrays for n > 2**31, then I'd favor the IllegalArgumentException approach. One can always do (first (drop …)) manually if linear performance is acceptable. -- 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: Generating Bash scripts from Clojure
Hi, Check out Stevedore: https://github.com/pallet/stevedore Example: http://hugoduncan.org/post/2010/shell_scripting_in_clojure_with_pallet.xhtml User group: http://groups.google.com/group/pallet-clj Thanks, Ambrose On Tue, Sep 13, 2011 at 1:09 PM, Denis Labaye wrote: > Hi, > > I have to write a bunch of Bash scripts, and not a lot of time :) > The final script would perform a full install, provisionning, sanity > checks, ... in one command. > > I wonder if I could generate them using Clojure. > > Of course the output script(s) won't have the Clojure runtime. > > Any advices / thoughts? > > Thanks, > > Denis > > -- > 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: debugging
Eclipse with CounterClockwise is ok (relatively speaking). With it one can do the usual: - breakpoints (no conditional) - stepping in/out - examine variables from different call frames But thats pretty much what it can do now. Neither Changing variable's value nor expression evaluation works, and pretty much anything that tries to eval code on the fly fails if putting Clojure code as input. It just doesn't understand Clojure yet. And on top of that Run-to-line doesn't work either. Hopefully that will change. The stepping in/out are at times very annoying as well as F6 - "Step Over" for some reason always takes me to codes in clojure.lang and clojure.core. Which is a hassle to step out as it takes multiple step outs to get back to where I was. It would be wonderful if the debugger is as good as the one for Java. Joseph On Sep 11, 7:31 am, Jonathan Fischer Friberg wrote: > Sort of. > > http://georgejahad.com/clojure/cdt.html > > Jonathan > > On Sat, Sep 10, 2011 at 5:36 PM, Dennis Haupt wrote: > > > > > > > > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > hi there, > > > what's the currently best way to debug a clojure program? > > ideally, i want to see all vars, symbols, functions etc. that are in > > the current scope and be able evaluate expressions on the fly > > > a "start repl here and stop program until repl is closed" would be > > near perfect. does such a thing exist? > > > - -- > > > -BEGIN PGP SIGNATURE- > > Version: GnuPG v2.0.14 (MingW32) > > Comment: Using GnuPG with Mozilla -http://enigmail.mozdev.org/ > > > iQIcBAEBAgAGBQJOa4QBAAoJENRtux+h35aG1Z4P/07rnp52lJFb6HqrKCNoPkFE > > EZ4a1TxR1YYI8cBh6olcbdSxe/urFbT3JuQeR0v0/f1u/LjGzve00L+qbw3++f1v > > +yC35BAomMh5aFDJk1v5hjP63hP+/BLt+eHA2MW+wgrHtHIArS1JuE9keJwhZsVT > > W6F0AiVbbyedYieqVOhi7S8cn/0vrbVR9vaiDFytaW3ijihAMqt37pSRV8ptIGFo > > bGJuGBt6uQFpuyM+6/3c4gUcf5wtLX7/515PVhxPqO5aLQrjHfk+fRj+++XQPxkX > > WjCvd/Fl0Lkd0HbBX0TQyZwDKqYqJ7XXEfHIto7nMHwf9FVA0PWODfoYxkGlQnjX > > wrXMouddA6S0MrdhtD4TwqBiYbWAINJP9uUCIMRtDYWkmmOEDK43VoZk9qk37H+W > > ZKaCbrruaG0PYHlLxbPa5wapFb94KzgvZ2UFYN0XbKiFl4Tha2a86QS5ZI0jHpw2 > > dmhBScFloWRbtZ3Rocwq8gBGyCJxE5u5qYHCELnC3a9e/LXPPyyO5d099QEUG4uM > > H2u4FGbOSdn8Le+YWc0slcYueDQkZqdlFkrXFQ+vcNUzQZLZLNcVAgkZ62NhGnX8 > > Vdq1F9zKxp91JjCrhq3VHyNYg0yte3Ygzx00U/tbepkCbhoLV+yp0KGEF5Mrxad7 > > /4IpYf7B0AO7QvgRcQnU > > =tERq > > -END PGP SIGNATURE- > > > -- > > 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
Generating Bash scripts from Clojure
Hi, I have to write a bunch of Bash scripts, and not a lot of time :) The final script would perform a full install, provisionning, sanity checks, ... in one command. I wonder if I could generate them using Clojure. Of course the output script(s) won't have the Clojure runtime. Any advices / thoughts? Thanks, Denis -- 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: puzzlement over lazy sequences
On Mon, Sep 12, 2011 at 11:55 AM, Stuart Halloway wrote: > I'm guessing there are similar bugs in drop, take, and so forth with > large n and large (or infinite) seqs. They should all be fixed. > > The other fns are ok, thanks to their separate heritage. drop, take, et al > are sequence functions, and proceed iteratively. > nth is of a different lineage. It was designed to target collections that > support constant time-lookup. Collection-y things in the Java world provide > APIs that take int, not long, because that is what arrays do at the bottom. > FWIW, Sun (now Oracle) considers this a low-priority > problem: http://bugs.sun.com/bugdatabase/view_bug.do;jsessionid=5d84e2e6a65a5c03eacaafb73e91?bug_id=4963452. > nth has a doc bug: it should be documented as a function of a collection and > a 32-bit int. A patch updating the docstring, and even enforcing it with an > IllegalArgumentException, would be welcome. (George: want to write your > first patch? :-) ) > Stu > Stuart Halloway > Clojure/core > http://clojure.com The Clojure collections aren't just flat arrays, though, are they? They're trees of arrays of 32 items, and the trees can in principle have arbitrary depth. So the 2^31 limit on Java arrays doesn't impact the Clojure collections, it seems. And nth should therefore work for larger n, on all of them. But if, as you say, take, drop, etc. work for larger n, it should be easy to make nth work with larger n and non-random-access seqs, just by changing the non-random-access case to (first (drop n the-seq)). -- 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
Re: How to compose futures?
I'm low on time but I will throw a few rocks in the pool here. Composition of futures / asynchronous tasks leads you towards dataflow concurrency (a trend in the making). People are dipping their toes in this all over right now but it needs further pushing. imho this is going to be big in 3-5 years. For me the core characteristics / benefits of dataflow are: - you only run tasks in cpu-hot threads when they are ready to run - you never block in those threads - if you need to block for data, you swap out (some form of continuation or paused task is required for this) - a pool of IO threads either sits to block for data or better is notified by an event that there is work to do - a scheduler must understand a) when a task's inputs are fulfilled and it can be run and b) schedule tasks to run in optimal ways See: - Scala Akka's dataflow support - built over the actor core http://vasilrem.com/blog/software-development/scatter-gather-with-akka-dataflow/ - GPars in Groovy http://www.gpars.org/guide/guide/7.%20Dataflow%20Concurrency.html http://www.jroller.com/vaclav/entry/add_one_function_to_my - Clojure core support for promises http://clojuredocs.org/clojure_core/clojure.core/promise - Zach Tellman's Clojure work in Lamina with async programming https://github.com/ztellman/lamina/wiki/Async-Programming - Alexey Radul and Gerald Sussman's work on Propagators in Scheme http://web.mit.edu/~axch/www/art.pdf - we've built our own version with some special considerations at Revelytix, which David McNeil will be talking about at the conj and I will be talking about at Devoxx. We use Clojure of course and leverage fork/join for compute threads. I think Clojure is uniquely poised to take advantage of these ideas due to the flexibility of its syntax wrt control structures and delayed computation and the availability of high-class portable concurrency libraries in Java. Having a great scheduler is a hard and tricky problem. Alex On Sep 11, 11:18 pm, Kevin Downey wrote: > Clojure's concurrency primitives are built on the functionality > provided by java.util.concurrent and I think solutions for > asynchronous composition should also be built on java.util.concurrent. > Agents are identities over a series of results from asynchronous > function application. Nothing about composable async tasks there. > > I don't think java has a nice solution we can just use, but all the > bits we need are there. die-geister is sort of a rough sketch of what > could be built, it needs better control over which thread pool tasks > are schedule on, and most of the custom types it uses should just be > Futures. > > http://channel9.msdn.com/events/PDC/PDC10/FT09 > > http://medianetwork.oracle.com/media/show/17013(this is my favorite > video, because it is the only one I've seen that talks at least a > little about how the new Task<>s are scheduled) > > http://tomasp.net/academic/joinads/joinads.pdf > > > > > > > > > > On Sun, Sep 11, 2011 at 2:22 PM, Sean Corfield wrote: > > On Sun, Sep 11, 2011 at 1:29 AM, Laurent PETIT > > wrote: > >> now that I've stepped back a little bit and acknowledged my ignorance > >> (while > >> working on it : currently reading "Java concurrency in practice" :-) ) > > > Kevin pulled me up on this too (in IRC) and pointed me at the Java > > solution. As it happened I decided to avoid an async solution in the > > end (the speed up wasn't worth the complexity of adding concurrency > > in my situation - which I didn't know for sure until I'd tried both > > approaches). > > >> This remains me of the "viscosity" smell : if it's way easier to do the > >> wrong thing than it is to do the right thing, expect people to do the wrong > >> one. > > > Yes, it seems that this is a common enough need that it would be nice > > to have an idiomatic Clojure library to implement this, perhaps as > > part of new contrib? > > > Kevin, I'd be particularly interested in your thoughts on that since I > > understand you feel the Java solution is already pretty clean and > > simple? > > -- > > Sean A Corfield -- (904) 302-SEAN > > An Architect's View --http://corfield.org/ > > World Singles, LLC. --http://worldsingles.com/ > > Railo Technologies, Inc. --http://www.getrailo.com/ > > > "Perfection is the enemy of the good." > > -- Gustave Flaubert, French realist novelist (1821-1880) > > > -- > > 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 > > -- > And what is good, Phaedrus, > And what is not good— > Need we ask anyone to tell us these things? -- You received this message because you are subscribed to the G
Re: Clojure sort: is it specified to be stable for all targets?
In general, if it's not specified in the doc string, then it's not a promise. That said, the implementation of `sort` in Clojure on the JVM uses java.util.Arrays#sort, which is specified to be stable. I would generally expect a language built-in `sort` routine to be stable, so take that for what it's worth. -Stuart Sierra clojure.com -- 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: Migration to 1.3 for mortals
> Since the new, separated contrib libraries are supposed to be > compatible with Clojure 1.2, you could perhaps also start migrating > one lib at a time at your leisure. This might even enable you to > contribute to a migration document. > Yes, this is what I am hoping people will do. Move to the new libraries first, then switch over to Clojure 1.3. -Stuart Sierra clojure.com -- 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
Overtone 0.3 released
Hey everyone, I've just pushed out a shiny new Overtone release to Clojars. Although it's only been a little over a month since the last release, there's been quite a lot of work committed that it definitely warranted a new number and a little release party! So update your music project dependencies to 0.3.0, sync your deps and start playing with the new functionality. A great place to start is the new algorithmic piano example: https://github.com/overtone/overtone/blob/master/test/example/extemp_piano.clj So, what's happened? Well, the key highlights are: * An example system * Binary/Unary UGen documentation * The unification of Binary/Unary UGen calling semantics with standard UGen fns. * A selection of interesting new algo/music fns * Useful UGen documentation lookup fns: ug-doc, find-ug, find-ug-doc More detailed highlights are as follows: https://github.com/overtone/overtone/blob/master/CHANGELOG.md Enjoy! Sam --- http://sam.aaron.name -- 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: Newbie question: How to add external clojure jars properly in Eclipse.
hi Laurent, Sorry for going silent for several days the usual excuse, work deadline, families etc Anyway, really appreciate ur jumping in and try to give me a hand. I finally found out why: 1.) I have to indicate in Eclipse that the user library, that pointed to the jar downloaded from Maven repo should be a system library. 2.) I was having (use clojure.java.jdbc) instead of (use `clojure.java.jdbc) <== note the single quote in front of clojure. As soon as I put that in together with (1) above, it started recognizing the library. Also I found out from the doc its better to use (require) with :as. So now I have: (ns com.joseph.MyJdbc001 (:require [clojure.java.jdbc :as jdbc]) (:require [clojure.set :as set]) ) And everything works. Thanks, Joseph -- 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: Misleading Exception due to function name containing ->
Just some more, maybe even simpler examples: Clojure 1.3.0-master-SNAPSHOT user=> (defn foo>>bar [] "") user=> (foo>>bar "a") ArityException Wrong number of args (1) passed to: user$foo-GT clojure.lang.AFn.throwArity (AFn.java:439) user=> (defn foo++bar [a] "") user=> (foo++bar) ArityException Wrong number of args (0) passed to: user$foo-PLUS clojure.lang.AFn.throwArity (AFn.java:439) (some output omitted) These show how, '_' was translated back to '-' in AFn.java which also can lead to unexpected results: user=> (defn foo_bar [a] "") user=> (foo_bar) ArityException Wrong number of args (0) passed to: user$foo-bar clojure.lang.AFn.throwArity (AFn.java:439) Cheers, Stefan -- 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: Strategy direction for ClojureScript regarding Google Dash?
> I think it's probably too early to speculate, but does the clojure/ > core team have any thoughts on how Google Dash might affect > ClojureScript? Given that ClojureScript currently compiles to Closure > Javascript, can we then compile that into Dash for performance > enhancements? I think the problem right now is...no one really knows what on earth Dart really is. I heard about this over the weekend and have been trying to read up on it, but so far the only information we have about Dart is from off-hand comments by developers from Google. So let's rephrase your original question "Does anyone know how ClojureScript could be affected by a language we know nothing about, by optimizing it in ways that are not defined, to run on platforms that have not been written yet?" In answer to your question: yes, no, and perhaps maybe. Timothy -- 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
Strategy direction for ClojureScript regarding Google Dash?
I think it's probably too early to speculate, but does the clojure/ core team have any thoughts on how Google Dash might affect ClojureScript? Given that ClojureScript currently compiles to Closure Javascript, can we then compile that into Dash for performance enhancements? http://css.dzone.com/news/google-dart-%E2%80%9Cultimately -- 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: Misleading Exception due to function name containing ->
Hi, On Monday, September 12, 2011 8:07:22 PM UTC+2, Chouser wrote: > > > https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/AFn.java#L436 > looks like a subtle bug, doesn't it? The compiler translates '-' to '_' (Compiler.java:2619) and '>' to '_GT_' (Compiler.java:2623). Together they form the suffix-indicator '__' which leads to a wrong stripping of the suffix. At least, that's how I read the code. Regards, Stefan -- 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: Misleading Exception due to function name containing ->
On Mon, Sep 12, 2011 at 11:39 AM, Sean Corfield wrote: > On Mon, Sep 12, 2011 at 8:16 AM, Stefan Kamphausen > wrote: >> Maybe the example becomes clearer with a little less foo and a little more >> bar and baz: >> >> shell> lein repl >> REPL started; server listening on localhost port 64913 >> user=> (defn foo [arg] "foo") >> #'user/foo >> user=> (defn bar->baz [a b] "bar->baz") >> #'user/bar->baz >> user=> (foo (bar->baz "a")) >> java.lang.IllegalArgumentException: Wrong number of args (1) passed to: >> user$bar (NO_SOURCE_FILE:0) > > It is reporting the correct function but not reporting the name > correctly (I just tried a similar example before I saw Stefan's post). https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/AFn.java#L436 --Chouser -- 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: puzzlement over lazy sequences
> I'm guessing there are similar bugs in drop, take, and so forth with > large n and large (or infinite) seqs. They should all be fixed. The other fns are ok, thanks to their separate heritage. drop, take, et al are sequence functions, and proceed iteratively. nth is of a different lineage. It was designed to target collections that support constant time-lookup. Collection-y things in the Java world provide APIs that take int, not long, because that is what arrays do at the bottom. FWIW, Sun (now Oracle) considers this a low-priority problem: http://bugs.sun.com/bugdatabase/view_bug.do;jsessionid=5d84e2e6a65a5c03eacaafb73e91?bug_id=4963452. nth has a doc bug: it should be documented as a function of a collection and a 32-bit int. A patch updating the docstring, and even enforcing it with an IllegalArgumentException, would be welcome. (George: want to write your first patch? :-) ) Stu Stuart Halloway Clojure/core http://clojure.com -- 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: Misleading Exception due to function name containing ->
On Mon, Sep 12, 2011 at 8:16 AM, Stefan Kamphausen wrote: > Maybe the example becomes clearer with a little less foo and a little more > bar and baz: > > shell> lein repl > REPL started; server listening on localhost port 64913 > user=> (defn foo [arg] "foo") > #'user/foo > user=> (defn bar->baz [a b] "bar->baz") > #'user/bar->baz > user=> (foo (bar->baz "a")) > java.lang.IllegalArgumentException: Wrong number of args (1) passed to: > user$bar (NO_SOURCE_FILE:0) It is reporting the correct function but not reporting the name correctly (I just tried a similar example before I saw Stefan's post). -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ Railo Technologies, Inc. -- http://www.getrailo.com/ "Perfection is the enemy of the good." -- Gustave Flaubert, French realist novelist (1821-1880) -- 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: Misleading Exception due to function name containing ->
Maybe the example becomes clearer with a little less foo and a little more bar and baz: shell> lein repl REPL started; server listening on localhost port 64913 user=> (defn foo [arg] "foo") #'user/foo user=> (defn bar->baz [a b] "bar->baz") #'user/bar->baz user=> (foo (bar->baz "a")) java.lang.IllegalArgumentException: Wrong number of args (1) passed to: user$bar (NO_SOURCE_FILE:0) ;-) Stefan -- 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: Misleading Exception due to function name containing ->
On 12 September 2011 15:49, Christina Conway wrote: > user=> (defn foo [a] "") > #'user/foo > user=> (defn foo->foo2 [a b] "") > #'user/foo->foo2 > user=> (foo (foo->foo2 "a")) > java.lang.IllegalArgumentException: Wrong number of args (1) passed to: > user$foo (NO_SOURCE_FILE:0) > > This example illustrates the problem. The exception indicates that the foo > function has the wrong number of arguments. > But it has one argument which is correct. It is actually the foo->foo2 > function which should have two arguments but has one. > > I am using clojure 1.2. I can confirm this using Clojure 1.2.1. Even more simple than the above: user=> (defn foo->foo2 [a b] "") #'user/foo->foo2 user=> (foo->foo2 1) java.lang.IllegalArgumentException: Wrong number of args (1) passed to: user$foo (NO_SOURCE_FILE:0) -- Michael Wood -- 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: Migration to 1.3 for mortals
Hi On 12 September 2011 11:43, Jan Rychter wrote: > On Sep 10, 9:31 pm, Sean Corfield wrote: >> On Sat, Sep 10, 2011 at 9:46 AM, Jan Rychter wrote: >> > If you use Clojure to build an application that you subsequently >> > launch and maintain, it is pretty much a given that you use contrib. >> > Lots of it, in fact. >> >> I think that depends on when you started building stuff with Clojure. >> I get the impression quite a bit of old contrib grew up to provide >> functionality not in Clojure's core and I see quite a few pieces of >> old contrib that are explicitly deprecated because functions moved to >> Clojure 1.2 (c.c.string, for example, mostly moved to clojure.string >> long before Clojure 1.3 got under way). I suspect that folks who >> started with Clojure long ago and are relying heavily on old contrib, >> are probably relying on those old deprecated namespaces and functions >> and have simply avoided updating their code to use the newer, >> supported namespaces. I think the break in contrib coming with 1.3 >> will be good for the Clojure ecosystem overall because it will force a >> lot of folks to clean up their code :) > > Just to clarify, I am not against change, quite the opposite — I'd > much rather see a quickly evolving Clojure ecosystem than one mired in > legacy code. I will gladly rework my code regularly so that it works > with newer releases. I'd just like to see the process somewhat > documented. > > I think I've said all there was to be said in this discussion, so I'll > shut up now and wait for better documentation or a migration guide. In > the meantime, we'll stick to Clojure 1.2 together with our patched-up > monolithic contrib. Since the new, separated contrib libraries are supposed to be compatible with Clojure 1.2, you could perhaps also start migrating one lib at a time at your leisure. This might even enable you to contribute to a migration document. Just a thought :) -- Michael Wood -- 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: Thoughts on CUDA + Clojure
> In my opinion It would be wiser to target OpenCL first. So this effort > will not depend on particular hardware vendor. Sadly, I've found yet another limitation of OpenCL over the weekend. Apparently OpenCL doesn't support GPU function pointers. Without function pointers, and with OpenCL only supporting C99, we're left with no way to implement a OOP type system. Until that changes OpenCL is out of the question. I wish it wasn't but the feature set for OpenCL just isn't there. In addition to this, I've been reading that cross platform OpenCL support is spotty at the moment. So what runs well on a ATI card may run terribly on a Intel driver, etc. Timothy -- 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: Thoughts on CUDA + Clojure
On Fri, Sep 9, 2011 at 1:43 AM, Timothy Baldridge wrote: > I've been kicking around an idea for some time, of starting a > Clojure->CUDA compiler. I would like to start a discussion about this > to figure out what some possible solutions are. First of all let me > start a simple fact list: > > CUDA (for those who don't know) is NVIDIA's technology for writing > general use code for modern GPUs. The current system uses a subset of > C++ as it's input. The code looks like small functions/classes that > are executed for each thread of the GPU. These threads can number in > the thousands, and the GPU commonly executes hundreds of these at one > time. So, basically we're talking of running pmap on a system will > 512+ cores. > > CUDA 4.0 supports some very advanced C++ features. As of 4.0 CUDA > supports virtual functions, and new/deleteyes...your GPU code can > allocate memory on the fly (if you have a GeForce 4xx or greater). > > My idea is to make a subset of Clojure translatable to CUDA. So you > would create input data in native memory, the the Clojure functions > would be translated to CUDA C++, then to CUDA binaries where they > would be executed in the CPU. > > A very simple approach would be to take the view that may Clojure->SQL > frameworks do, and simply do a translation. In this method all CUDA > Clojure functions would take only arrays and scalar values as inputs, > and the functions would read data from arrays, and output them to > arrays. No sequences, on-the-fly allocation, or any such thing would > be allowed. On top of that, all input and output data must be of the > same type, so no mixing doubles and floats, or ints and longs. All > data must be resolved to staticlly defined types, and mutating the > variable's type on the fly is not allowed. > > The more complex approach would be to use something like ClojureScript > to compile core.clj to CUDA, and actually run a subset of Clojure on > the GPU. In this case we would have to come up with a simple type > system, and then rewrite the ClojureScript compiler to output C++ code > instead of JS. In addition, some sort of simple GC (reference > counting?) would have to be developed. The result would be slower > than my first approach, but would be much more flexible. > > > > So in the first version we have a simple to create system, but we > can't use many of the functions we are familiar with in CUDA. > > In the second method, we have a slower, but much more powerful system > that would integrate much more tightly with existing code. > > > > Any thoughts? Besides that I'm crazy... > > Timothy > In my opinion It would be wiser to target OpenCL first. So this effort will not depend on particular hardware vendor. AFAIK OpenCL is already supported by Intel, AMD and Nvidia. Although being a common denominator OpenCL may lack some toys already available in CUDA. Just saying ... -- Petr Gladkikh -- 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: Misleading Exception due to function name containing ->
user=> (defn foo [a] "") #'user/foo user=> (defn foo->foo2 [a b] "") #'user/foo->foo2 user=> (foo (foo->foo2 "a")) java.lang.IllegalArgumentException: Wrong number of args (1) passed to: user$foo (NO_SOURCE_FILE:0) This example illustrates the problem. The exception indicates that the foo function has the wrong number of arguments. But it has one argument which is correct. It is actually the foo->foo2 function which should have two arguments but has one. I am using clojure 1.2. Thanks, cc On 12 September 2011 14:00, Chouser wrote: > On Fri, Sep 9, 2011 at 4:47 AM, Christina Conway > wrote: > > A function name contains the characters -> > > e.g. foo->fn > > The function causes an exception. > > However the exception is not reported on the function but on another > > function called before it. > > java.lang.IllegalArgumentException: Wrong number of args (1) passed > > to: datetime$other-fn > > > > If the > character is removed from the function name > > e.g. foo-fn > > then the same exception is thrown but on the function itself: > > java.lang.IllegalArgumentException: Wrong number of args (1) passed > > to: datetime$foo-fn > > > > If the - character is removed from the function name > > e.g. foo>fn > > then the exception is thrown on the function as follows: > > java.lang.IllegalArgumentException: Wrong number of args (1) passed > > to: datetime$foo-GT-fn > > > > The foo->fn function is compiled to a .class file as: > > foo__GT_fn.class > > The foo>fn function is compiled to a .class file as: > > foo_GT_fn.class > > The foo-fn function is compiled to a .class file as: > > foo_fn.class > > > > Has anybody else encountered this with function names containing ->. > > Is this a bug? > > I was unable to reproduce the problem: > > user=> (defn foo->fn [] (throw (Exception. "bad thing"))) > #'user/foo->fn > user=> (defn other-fn [] (foo->fn)) > #'user/other-fn > user=> (other-fn) > Exception bad thing user/foo->fn (NO_SOURCE_FILE:1) > > Perhaps you can post a minimal example that demonstrates the problem. > Also, what version of Clojure are you using? > > --Chouser > > -- > 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: Misleading Exception due to function name containing ->
On Fri, Sep 9, 2011 at 4:47 AM, Christina Conway wrote: > A function name contains the characters -> > e.g. foo->fn > The function causes an exception. > However the exception is not reported on the function but on another > function called before it. > java.lang.IllegalArgumentException: Wrong number of args (1) passed > to: datetime$other-fn > > If the > character is removed from the function name > e.g. foo-fn > then the same exception is thrown but on the function itself: > java.lang.IllegalArgumentException: Wrong number of args (1) passed > to: datetime$foo-fn > > If the - character is removed from the function name > e.g. foo>fn > then the exception is thrown on the function as follows: > java.lang.IllegalArgumentException: Wrong number of args (1) passed > to: datetime$foo-GT-fn > > The foo->fn function is compiled to a .class file as: > foo__GT_fn.class > The foo>fn function is compiled to a .class file as: > foo_GT_fn.class > The foo-fn function is compiled to a .class file as: > foo_fn.class > > Has anybody else encountered this with function names containing ->. > Is this a bug? I was unable to reproduce the problem: user=> (defn foo->fn [] (throw (Exception. "bad thing"))) #'user/foo->fn user=> (defn other-fn [] (foo->fn)) #'user/other-fn user=> (other-fn) Exception bad thing user/foo->fn (NO_SOURCE_FILE:1) Perhaps you can post a minimal example that demonstrates the problem. Also, what version of Clojure are you using? --Chouser -- 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: Clojure in Emacs Seemingly Impossible
+1 On Sep 11, 4:04 pm, David Nolen wrote: > As an avid Emacs user - don't bother. If you just want a no hassle > environment that supports Clojure development use Clooj. Steps - > > 1) Download > 2) Double-click > > https://github.com/arthuredelstein/clooj > > David > > > > On Sat, Sep 10, 2011 at 1:29 PM, Curran wrote: > > Greetings, > > > I would greatly appreciate any guidance on where to find a working and > > complete set of instructions for how to set up Emacs with swank- > > clojure. I am in Ubuntu. > > > I have followed exactly every step of the instructions on this page > >http://dev.clojure.org/display/doc/Getting+Started+with+Emacs, and > > also (with a fresh install of Emacs) the version using Git in the > > comment on that page by Martin Blais. With both methods, when I > > execute "M-x clojure-jack-in", the message "Starting swank server" > > appears and hangs. Swank never starts, the message never changes, and > > I don't see any error messages anywhere (not sure where to look, maybe > > I'm missing them?). > > > I really would like to use Clojure for a significant project, but if I > > can't get the dev environment working I'm hosed. > > > Also, if I can't get Emacs going, would anyone suggest an alternative > > development tool? (I know there are lots, but I don't know which to > > try first). > > > Thank you very much. > > > Best regards, > > Curran > > > -- > > 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- Hide quoted text - > > - Show quoted text - -- 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: puzzlement over lazy sequences
On Mon, Sep 12, 2011 at 12:54 AM, Alan Malloy wrote: > Integer overflow. > > user> (mod 9876543210 (bigint (Math/pow 2 32))) > 1286608618 Oops. But nth can probably be fixed while keeping good performance: (defn- small-drop [s n] (loop [n (int n) s (seq s)] (if (zero? n) s (recur (dec n) (next s) (def pow231 (bigint (Math/pow 2 31))) (defn my-nth [s n] (let [s (small-drop s (rem n pow231))] (loop [n (quot n pow231) s s] (if s (if (zero? n) (first s) (recur (dec n) (small-drop s pow231))) Given a bigint n, this does only two arithmetic operations on bigints at the start and one possibly-bigint dec every 2^31 items, instead of doing a bigint dec every single item. So it should be nearly as fast for large n as for small n, per item. I'm guessing there are similar bugs in drop, take, and so forth with large n and large (or infinite) seqs. They should all be fixed. Note: the above code is untested, and (nth n too-short-a-seq) returns nil. For further speed you'd want small-drop to use an unchecked dec. You'd also want my-nth to punt to the special implementations for vectors and other random-access seqables, and maybe change the behavior on long seqs. -- 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
Re: Misleading Exception due to function name containing ->
Thanks for the suggestion BG. I tried using clj-stacktrace but the function name is still not displayed correctly in the trace. Regards, cc On 11 September 2011 13:53, Baishampayan Ghose wrote: > > The foo->fn function is compiled to a .class file as: > > foo__GT_fn.class > > The foo>fn function is compiled to a .class file as: > > foo_GT_fn.class > > The foo-fn function is compiled to a .class file as: > > foo_fn.class > > > > Has anybody else encountered this with function names containing ->. > > Is this a bug? > > This name munging is normal and is done because characters like >, -, > * etc. are not allowed in Java class file names. > > Try using https://github.com/mmcgrana/clj-stacktrace for better > stack-traces. That library will munge the names back into their > original forms for better readability. > > Regards, > BG > > -- > Baishampayan Ghose > b.ghose at gmail.com > > -- > 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: Migration to 1.3 for mortals
On Sep 10, 9:31 pm, Sean Corfield wrote: > On Sat, Sep 10, 2011 at 9:46 AM, Jan Rychter wrote: > > If you use Clojure to build an application that you subsequently > > launch and maintain, it is pretty much a given that you use contrib. > > Lots of it, in fact. > > I think that depends on when you started building stuff with Clojure. > I get the impression quite a bit of old contrib grew up to provide > functionality not in Clojure's core and I see quite a few pieces of > old contrib that are explicitly deprecated because functions moved to > Clojure 1.2 (c.c.string, for example, mostly moved to clojure.string > long before Clojure 1.3 got under way). I suspect that folks who > started with Clojure long ago and are relying heavily on old contrib, > are probably relying on those old deprecated namespaces and functions > and have simply avoided updating their code to use the newer, > supported namespaces. I think the break in contrib coming with 1.3 > will be good for the Clojure ecosystem overall because it will force a > lot of folks to clean up their code :) Just to clarify, I am not against change, quite the opposite — I'd much rather see a quickly evolving Clojure ecosystem than one mired in legacy code. I will gladly rework my code regularly so that it works with newer releases. I'd just like to see the process somewhat documented. I think I've said all there was to be said in this discussion, so I'll shut up now and wait for better documentation or a migration guide. In the meantime, we'll stick to Clojure 1.2 together with our patched-up monolithic contrib. thanks, --J. -- 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
trace-forms macro
Hello, I made a small macro, if anyone is interested. https://gist.github.com/1209498 It wraps one or more forms and if an exception is thrown, prints the form that caused it, and throws the exception itself. Examples: user=> (trace-forms 3) 3 user=> (trace-forms (+ 6 (/ 9 0))) java.lang.ArithmeticException: Divide by zero (NO_SOURCE_FILE:9) Form failed: (/ 9 0) Form failed: (+ 6 (/ 9 0)) user=> (trace-forms (let [a 0 b (/ 9 a)] b)) java.lang.ArithmeticException: Divide by zero (NO_SOURCE_FILE:75) Form failed: (/ 9 a) Form failed: (let* [a 0 b (/ 9 a)] b) Form failed: (let [a 0 b (/ 9 a)] b) Issues: user=> (trace-forms (let [b (/ 9 a)] b)) java.lang.Exception: Unable to resolve symbol: a in this context (NO_SOURCE_FILE:94) user=> (trace-forms (let [a (java.lang.DoesNotExist.)] a)) java.lang.ClassNotFoundException: java.lang.DoesNotExist (NO_SOURCE_FILE:93) Thoughts? Jonathan -- 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: Exceptions in Haskell and in Clojure
Incidentally, I was just working on such a thing. I'll send it in a new thread. Jonathan On Sun, Sep 11, 2011 at 7:03 PM, Michael Jaaka wrote: > Couldn't match expected type `(t, t1)' > against inferred type `(t2, t3, t4)' > In the expression: (8, 11, 5) > In the expression: [(1, 2), (8, 11, 5), (4, 5)] > In the definition of `it': it = [(1, 2), (8, 11, 5), (4, 5)] > > > This was excerpt from Haskell exception, will Clojure have ever > something like this? > > -- > 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: What's wrong with my *print-dup* persistence?
Chouser writes:
> I haven't tried all the above, but I had a couple thoughts that might help:
>
> First, inside #=(), arguments aren't evaluated. They act as if quoted:
>
> #=(+ 1 (+ 2 4))
> ; ClassCastException clojure.lang.PersistentList cannot be cast to
> java.lang.Number clojure.lang.Numbers.add (Numbers.java:126)
>
> The list (+ 2 4) is passed as a list to the outer +, which fails
> because it's expecting a number not a list. So one alternative would
> be:
>
> #=(+ 1 #=(+ 2 4))
> ;=> 7
I'm unable to programmatically generate nested #=() forms. :-(
user> (str "#=" `(1 "#=" (+ 2 3)))
"#=(1 \"#=\" (clojure.core/+ 2 3))"
How would I do so?
> But please consider another alternative:
>
> (+ 1 (+ 2 4))
> ;=> 7
>
> That is, if you're going to be evaluating a large amount of code while
> reading your data back into memory, why not just go ahead and eval it
> instead of just reading it?
>
> (read-string "#=(+ 1 #=(+ 2 4))")
> vs.
> (eval (read-string "(+ 1 (+ 2 4))"))
I've tried spitting out forms without the #=, and that basically does
the trick for my objects.
"(de.uni-koblenz.funtg.core/vertex
(de.uni-koblenz.funtg.core/*serialization-bindings*
\"c06de1c7-f4ec0906-21cfbc86-28c31aa1\")
1)"
That can be loaded back with `load-string' or (eval (read-string ...))
[if the right graph is bound by *serialization-bindings*, of course].
However, my intent is to be able so seamlessly load and store any data
structure build upon clojure data structures mixed with vertices and
edges. The approach fails if I try to write/read something like that
#{1 2 (take 3 (vseq (rg)))}
where vseq is the lazy seq of a graph's vertices. Writing that results
in a string like
"#{1 2 ((vertex (*serialization-bindings* ...) 1)
(vertex (*serialization-bindings* ...) 2)
(vertex (*serialization-bindings* ...) 3))}"
and clearly when evaling, the result of the first vertex call [a vertex]
will be treated as a function, which it is not.
Reading a form with nested #= works just fine (namespace stripped for
brevity):
"#{1 2 (#=(vertex #=(*serialization-bindings*
\"c06de1c7-f4ec0906-21cfbc86-28c31aa1\") 1)
#=(vertex #=(*serialization-bindings*
\"c06de1c7-f4ec0906-21cfbc86-28c31aa1\") 2)
#=(vertex #=(*serialization-bindings*
\"c06de1c7-f4ec0906-21cfbc86-28c31aa1\") 3))}
So currently it seems to me that writing those nested #=() forms is the
most practical way. But I'm open for other suggestions as well.
Bye,
Tassilo
--
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: java interop not possible in #=(..) reader syntax?
Hi! >> Hm, but even without the reader #=(..) syntax, there's some strangeness: >> >> --8<---cut here---start->8--- >> user> (. java.util.Date newInstance) >> ; Evaluation aborted. >> java.lang.NoSuchFieldException: newInstance >> [Thrown class java.lang.RuntimeException] >> user> (. (identity java.util.Date) newInstance) >> Reflection warning, NO_SOURCE_FILE:1 - reference to field newInstance can't >> be resolved. >> # >> --8<---cut here---end--->8--- >> >> Why do I have to use identity here? > > This used to be Clojure FAQ #1, when no other syntax was available. > newInstance is an instance method of the class Class, so these days > the best way to call it is (.newInstance java.util.Date). If you want > a static method of class Date, do something like (java.util.Date/UTC 1 > 2 3 4 5 6). These are "modern" syntax. > > It's generally best not to use the older form (. foo bar) as it can be > ambiguous. But just so you know what's going on... If Clojure finds > that foo is a class name, it assumes that bar is a static method or > field of class bar. When if can't find a foo in bar, it gives you the > error above. By wrapping foo in 'identity' you're making it clear to > the compiler that the first arg to . is an expression not a class > name, so it then looks for an instance method or field. Thanks for the clarifications. :-) Bye, Tassilo -- 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
