lazy-xml defect (?)
I am trying to track down and solve the issues Phil Hazelden reported on Hacker News [1]. I suspect that the XML issue was this one: It appears that the code has moved on since this report-- the emit-element fn mentions a :pad option but I don't see it being used anywhere. Is there an issue here we should open a ticket for? Thanks, Stu [1] http://news.ycombinator.com/item?id=1453664 [2] http://groups.google.com/group/clojure/browse_thread/thread/444140d86f2fb9cb/7d4b6e03ebe59410?hl=en_USlnk=gstq=hazelden#7d4b6e03ebe59410 -- 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: Compiling a namespace causes subsequent uses of it to fail.
I think the behavior you are seeing here is reasonable. When you mix compilation and dynamic access to vars, you need to reason carefully about the order in which things will happen. More usefully: you can write a test in your var-get expression that will make it do what you want in all scenarios. Just add a bound? test before trying to get the value out of variable. Sorry this was missed earlier. Cheers, Stu (ns testcomp) (var-get (or (ns-resolve *ns* 'foo) (intern *ns* 'foo :foo))) ;; foo ;(1) ;; (println foo) ;(2) ;; (do foo 3);(3) ;; (fn [] foo) ;(4) ;; ((fn [] foo)) ;(5) ;; ((fn [] (println foo))) ;(6) With (1)-(6) all commented out, behaviour is as expected: you can compile and use testcomp, and foo is bound to :foo. With any of (1)-(3) uncommented, you can use testcomp with no problems as long as it's uncompiled. If you compile it and subsequently attempt to use it, you get an ExceptionInInitializerError caused by an IllegalStateException due to Var testcomp/foo being unbound. What seems to be happening (according to my limited understanding of compilation) is that testcomp__init.class contains a reference to foo which causes it to be interned (but unbound) before the body code is run. ns-resolve then sees this Var, returns it, and var-get raises an exception. With (1)-(3) commented out, (4)-(6) can be uncommented and expected behaviour returns. testcomp__init.class no longer contains a reference to foo (I checked with grep). I'm doing something like this in a library, and (5)/(6) provide a workaround, but is this something that can be fixed at the language level? I recognise it's not an issue that will commonly be run into, and that the complexities of compilation might make it unavoidable. java version 1.6.0_14, clojure commit 5f1e6ed540eab11281b7bfb19f831b7e445ed0d0 (1 Sep 09). --~--~-~--~~~---~--~~ 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: slow raw io
I am seeing more like 1.8 seconds for the raw version, vs. 2.8 seconds for slurp (master branch). Can you post a complete example (including the clj script you use, and what version of Clojure), so we can be apples-to-apples? Stu For the record, this program runs in 3.3 seconds so I guess that points to the implementation of slurp: (import '[java.io BufferedReader InputStreamReader]) (let [reader (BufferedReader. (InputStreamReader. System/in)) file-data (StringBuffer.) buffer (char-array 4096)] (loop [total 0] (let [num-read (.read reader buffer)] (if (not= -1 num-read) (do (.append file-data buffer 0 num-read) (recur (+ total num-read))) (println total) -- 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: slow raw io
On my laptop (Mac) the biggest difference here has nothing to do with buffering
in slurp. It is whether you use System/in (fast) or *in* (slow). The latter is
a LineNumberingPushbackReader.
Can you check and confirm? When I slurp System/in it is more than twice as fast
as slurping *in*.
I believe the next-biggest perf issue is how StringBuilders grow. I suspect
that the 4096 buffer is making them grow more efficiently.
Stu
Another example. I'm running this on a Ubuntu 10.04 laptop with this
java:
java version 1.6.0_18
OpenJDK Runtime Environment (IcedTea6 1.8) (6b18-1.8-0ubuntu1)
OpenJDK 64-Bit Server VM (build 14.0-b16, mixed mode)
and this command line:
java -Xmx3G -server clojure.main cat2.clj
(require '[clojure.java.io :as jio])
(defn- normalize-slurp-opts
[opts]
(if (string? (first opts))
(do
(println WARNING: (slurp f enc) is deprecated, use (slurp
f :encoding enc).)
[:encoding (first opts)])
opts))
(defn slurp2
Reads the file named by f using the encoding enc into a
string
and returns it.
{:added 1.0}
([f opts]
(let [opts (normalize-slurp-opts opts)
data (StringBuffer.)
buffer (char-array 4096)]
(with-open [#^java.io.Reader r (apply jio/reader f opts)]
(loop [c (.read r buffer)]
(if (neg? c)
(str data)
(do
(.append data buffer 0 c)
(recur (.read r buffer)
(time
(with-open [f (java.io.FileReader. words)]
(println (count (slurp f)
(time
(with-open [f (java.io.FileReader. words)]
(println (count (slurp2 f)
I get this output:
$ java -Xmx3G -server clojure.main cat2.clj
279440100
Elapsed time: 17094.007487 msecs
279440100
Elapsed time: 5233.097287 msecs
So at least in my environment there seems to be a big difference
between slurp2 with an explicit buffer and the core/slurp one, which
appears to be reading a character at a time from a BufferedReader
stream.
--
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: clojure.xml/parse cannot handle filenames containing #
clojure.xml/parse is not documented to handle filenames-as-strings at all. It treats strings as URIs, deferring to the host (JVM) notion of URI as implemented in the underlying API. I can certainly see why this would be confusing! Is there a way to make it better without violating the expectations of someone who knows the Java API and expects strings to be treated as URIs? Stu (clojure.xml/parse test1.log) works correctly, output omitted (clojure.xml/parse test#1.log) Premature end of file. [Thrown class org.xml.sax.SAXParseException] $ mv test\#1.log test2.log (clojure.xml/parse test2.log) works correctly, output omitted test#1.log is a copy of test1.log Confirmed on Linux and Mac OS -- 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: Question about every?
You are correct. The struct is a single message. The messages object holds a
ref to N of them (initially an empty vector).
Individual messages are added by alter ... conj in add-message.
Stu
Ok, then I understand why it didn't work, but that means that the
struct (that is sent by the add-message function) is put in a sequence
somewhere on the way to being validated. Is this right, and where does
this happen?
;All the relevant code
(defstruct message :sender :text)
(def validate-message-list
(partial every? #(and (:sender %) (:text %
(def messages (ref [] :validator validate-message-list))
(defn add-message [msg]
(dosync (alter messages conj msg)))
(add-message (struct message mm first message))
On Jun 23, 12:58 pm, Stuart Halloway stuart.hallo...@gmail.com
wrote:
Hi Michele,
Pass a sequence of maps, not just a map:
(every? #(:x %) [{:x s}])
- true
Cheers,
Stu
In the book Programming Clojure (p2_0, pdf, page 185) Adding
Validation to Refs there is this code:
(def validate-message-list (partial every? #(and (:sender %) (:text
%
This works fine as a validator, but when I try the code directly - not
as a validator - it returns false. I also tested with a simple if to
see the difference.
(every? #(:x %) {:x s})
- false
(if (#(:x %) {:x s}) TRUE FALSE)
- TRUE
What do I not understand?
--
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: Duplicate key bug in hash-maps
Duplicate key prevention is a feature added in commit
c733148ba0fb3ff7bbab133f5375422972e62d08.
Stu
I tried Clojure via Githhub today.
Anyone notice this bug that hadn't existed in Version 1.1
user= #{:item1 {:a A :b B} :item2 {:a A :b B}}
java.lang.IllegalArgumentException: Duplicate key: {:a A, :b B}
Tim
--
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: code review request: clojure.java.io
No one spoke up for it. Sorry I'm so late to this particular discussion :-/ Why was to-byte-array left behind? It is a bit of an oddball function, insofar as it doesn't fit into IOFactory or Coercions, but seems to me like a natural cousin to copy. - Chas On May 11, 2010, at 12:16 PM, Stuart Halloway wrote: Assembla Ticket #311 [1] calls for the promotion of clojure.contrib.io into clojure (as clojure.java.io). I have attached a patch, and am requesting comments and code review from the community. Reasons you want to take time from your day to read this code: (1) It's important. This isn't just a copy/paste from contrib, there are several design changes (documented in the ticket). (2) It's interesting, demonstrating use of Clojure 1.2 protocols. (3) If you are new to Clojure, it isn't that scary. It's just I/O. :-) Thanks! Stu [1] https://www.assembla.com/spaces/clojure/tickets/311-clojure-java-io-namespace -- 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: slow raw io
Hi Peter, You are on the contributors list, so I just need to know your account name on Assembla to activate your ability to add tickets, patches, etc. Let me know your account name (which needs to be some permutation of your real name, not a nick). Thanks, Stu I put a self-contained test up here: http://gist.github.com/452095 To run it copy this to slurptest.clj and run these commands java clojure.main slurptest.clj makewords 100 (100 seems good for macs, 300 for linux) java -Xmx3G -Xms3G clojure.main slurptest.clj slurp| slurp2 Trying either slurp or slurp2. I see big timing differences on both macs and linux machines but it would be interesting to see if other people do too. Looking at core's slurp, the problem is that it reads one character at a time from the reader. The underlying reader being buffered or not, reading one character at a time is not good for performance. The attached patch brings it back down do the speed of slurp2 (How do I actually create a ticket on assembla? I couldn't find a way to do that; just browse individual tickets. I can't change tickets either; perhaps editing is not publicly allowed?). Anyways, some performance for FreeBSD 8/x86-64 with: openjdk6: 15 seconds slurp, 3.0 seconds slurp2 openjdk7 (fastdebug): 14.5 seconds slurp, 2.0 seconds slurp2 And slurp2 as a function of buffer size (single run each): 1: 17.8 seconds 128: 2.92 seconds 1024: 2.88 seconds 4096: 3.12 seconds -- / Peter Schuller -- 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=enslurp-buffer-size.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
Re: Duplicate key bug in hash-maps
Duplicate keys in maps/sets are disallowed in literals and factory functions,
where data is generally literal inline and therefore likely represents coder
error:
; all disallowed
#{:a :a}
{:a 1 :a 2}
(hash-map :a 1 :a 2)
(hash-set :a :a)
They are allowed in other contexts, where the data could come from anywhere:
; dumb, but these forms not generally called with a literal
(set [:a :a])
(into #{} [:a :a])
I find this behavior consistent and easy to explain, but I was involved in the
design conversation so maybe I have participant blindness. :-)
Stu
On Fri, 25 Jun 2010 15:36:31 +0200
Michael Wood esiot...@gmail.com wrote:
On 25 June 2010 12:27, Tim Robinson tim.blacks...@gmail.com wrote:
I tried Clojure via Githhub today.
Anyone notice this bug that hadn't existed in Version 1.1
user= #{:item1 {:a A :b B} :item2 {:a A :b B}}
java.lang.IllegalArgumentException: Duplicate key: {:a A, :b B}
You're trying to put duplicate values into a set.
So? Most places, putting a value that's already in a set into the set
is a nop. Even in clojure that exhibits the above behavior:
user= #{:a :a}
java.lang.IllegalArgumentException: Duplicate key: :a
user= (set [:a :a])
#{:a}
user= (conj #{:a} :a)
#{:a}
user=
Apparently, duplicate keys in sets are only disallowed in set
literals. Arguably, that must be a mistake on the users part, but
it sure seems to clash with the behavior of sets elsewhere.
mike
--
Mike Meyer m...@mired.org http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.
O ascii ribbon campaign - stop html mail - www.asciiribbon.org
--
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: Duplicate key bug in hash-maps
I think there are two important considerations in favor of how it works now:
(1) The common case presumptions (which admittedly may need to be learned).
(2) The need for both flavors. If there wasn't a flavor that rejected duplicate
keys, somebody would surely ask for it.
Add to these considerations the names of the functions already in play, and you
get the implementation you see.
On Fri, 25 Jun 2010 10:31:57 -0400
Stuart Halloway stuart.hallo...@gmail.com wrote:
Duplicate keys in maps/sets are disallowed in literals and factory
functions, where data is generally literal inline and therefore likely
represents coder error:
; all disallowed
#{:a :a}
{:a 1 :a 2}
(hash-map :a 1 :a 2)
(hash-set :a :a)
Maps I can see being an error - you lose data in the process.
However, since you can plug variables of unknown provenance into
either the constructor or the literal, that's liable to create a nasty
surprise for someone at some point.
user= (def a :a)
#'user/b
user= (def b :a)
#'user/b
user= (hash-set a b)
java.lang.IllegalArgumentException: Duplicate key: :a (NO_SOURCE_FILE:6)
user= #{a b}
java.lang.IllegalArgumentException: Duplicate key: :a (NO_SOURCE_FILE:0)
user=
They are allowed in other contexts, where the data could come from anywhere:
It could come from anywhere in the two forbidden contexts as well.
; dumb, but these forms not generally called with a literal
(set [:a :a])
(into #{} [:a :a])
I find this behavior consistent and easy to explain, but I was involved in
the design conversation so maybe I have participant blindness. :-)
My initial reaction was that's a bit odd, but probably a good idea.
However, given that I can use variables inside the literal and
constructor, I'm leaning the other way.
Or is (set [a b c]) idiomatic usage in this case, and (hash-set a b c)
or #{a b c} to be avoided?
mike
--
Mike Meyer m...@mired.org http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.
O ascii ribbon campaign - stop html mail - www.asciiribbon.org
--
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 1.5 RC 4 wants to be Clojure 1.5
Clojure 1.5 RC 4 is now available via Maven Central: http://search.maven.org/#search%7Cga%7C1%7Cg%3A%22org.clojure%22%20AND%20a%3A%22clojure%22%20AND%20v%3A1.5.0* Please test it! -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: the semantic of if-let macro
The docs are clear that the test occurs before the bindings: (doc if-let) - clojure.core/if-let ([bindings then] [bindings then else oldform]) Macro bindings = binding-form test If test is true, evaluates then with binding-form bound to the value of test, if not, yields else Cheers, Stu On Thu, Jan 31, 2013 at 2:43 AM, Mimmo Cosenza mimmo.cose...@gmail.comwrote: On Thursday, January 31, 2013 1:49:40 AM UTC+1, Sean Corfield wrote: but now that you've posted this, I can see some potential for confusion when folks first encounter if-let... Presumably the same confusion could arise for when-let? yes, this is the confusion that you can incur in. mimmo -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
ANN: Simulant: a framework for simulation-based testing
I am pleased to announce the release of Simulant, an open-source framework for simulation-based testing built using Datomic and Clojure: https://github.com/Datomic/simulant Feedback welcome! Stu -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: `let` to automatically add metadata / fn names?
+1 on this line of thought. We are definitely interested in decomplecting dev mode utility from production lean-and-meanness. One question along this path is What options exist in Java/maven land for doing multiple releases of the same artifact with e.g. different performance and debugging characteristics, and how could these be incorporated into the Clojure build in a transparent, easy-to-assess way? Answering the preceding question (or reframing it into a better question) is not blocked waiting on anybody. Have at it! Stu On Fri, Feb 8, 2013 at 9:36 PM, Brian Marick mar...@exampler.com wrote: On Feb 8, 2013, at 7:56 PM, Daniel Glauser danglau...@gmail.com wrote: This sounds like a great idea. I was working with some tests today and it would have been really useful to have some way to query the current function/execution context. Seems like passing that through all lets would go a long way, provided I'm reading this right. It would be very interesting to have a maximally informative mode and a generate really tense code mode. There is tradition behind such an idea. It would be especially interesting if the maximally informative mode had hooks tools could exploit. For example, Midje provides a hack where you can declare records in a way that the contained functions can be mocked: `defrecord-openly`. I expect almost no one uses it, even though it is no different than `defrecord` when in production mode: it's too weird looking. But people would use it if ordinary defrecord methods weren't inlined during development. There's no *semantic* reason why parts of Clojure should *always* be closed to introspection-type actions. It's purely a matter of time constraints on the core team, which I am certainly not in a position to judge. How much core time should be spent on saving anonymous programmers time vs. saving cycles for anonymous apps running on the Amazon cloud? It's a tough tradeoff. Looking for 1/2-time employment as a Clojure programmer Latest book: /Functional Programming for the Object-Oriented Programmer/ https://leanpub.com/fp-oo -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Clojure 1.5 RC 14
Clojure 1.5 RC 14 (fourteen) will be available soon from Maven Central: http://search.maven.org/#search%7Cga%7C1%7Cg%3A%22org.clojure%22%20AND%20a%3A%22clojure%22%20AND%20v%3A1.5.0* Please test it! Thanks, Stu -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: `let` to automatically add metadata / fn names?
It is likely that, once this Pandora's box is opened, there will be more
profiles that just debug yes/no.
It is almost certain that whatever we do must be maven friendly. (Maven is
a de facto standard for 1000x more people than leiningen, and some of them
want to use libs written in Clojure.)
If you are excited about doing this design work, please start a page in
Confluence, and capture your goals, options, tradeoffs, and recommendations.
Stu
On Sat, Feb 9, 2013 at 7:20 PM, vemv v...@vemv.net wrote:
I had something like this in mind:
- There's a set of clojure.core vars that mean something (potentially)
expensive yet convenient, and default to true
- Neither library producers or consumers have ever to touch those
(unless they want fine-grained control for some specific var/context)
- When performing a release to clojars or central, Lein creates two
versions (DEBUG, NO-DEBUG), in which the vars are set to true and
false, respectively
- Then library consumers can specify either [com.example/awesomelib *
1.4.0*], [com.example *1.4.0-DEBUG*], or [com.example *
1.4.0-NO-DEBUG*] in their :dependencies vector, in the corresponding
project.clj.
- If no version directive is specified, DEBUG would be chosen unless
specified otherwise in profiles.clj: {:user {:debug-dependencies false}}
Does it sound good enough?
On Friday, February 8, 2013 6:18:54 PM UTC+1, vemv wrote:
Given that: a) fns can have names for debugging purposes, and b) data
structures can have metadata, wouldn't it be a good idea to let let auto
attach (where possible) the names of the bindings to their corresponding
values?
For example, the improved let I'm thinking of would translate this input:
(ns my.namespace)
(defn do-it
(let [foo (fn [] (throw (Exception.)))
bar {:hello (/ 0 0)}]))
to:
(ns my.namespace)
(defn do-it
(let [foo (fn foo [] (throw (Exception.)))
bar ^{:origin :my.namespace/do-it$let$bar} {:hello (/ 0 0)}]))
This could be used to increase the precision of the stack traces, or in
IDEs/editors for locating the exact source of an exception.
Do you see such a mechanism being incorporated to clojure.core/let -
should I open a ticket?
--
--
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 unsubscribe from this group and stop receiving emails from it, send an
email to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
--
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 unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: Clojure 1.5 RC 14
1972-05-30T18:17:49.692-00:00 #inst 1986-03-14T02:42:42.374-00:00 #inst 2096-01-05T11:11:23.974-00:00 #inst 1997-12-03T18:50:28.444-00:00 #inst 2009-05-12T23:48:54.862-00:00 #inst 2026-02-16T11:51:39.884-00:00 #inst 1978-07-24T14:57:30.134-00:00 #inst 2003-08-21T22:16:56.540-00:00 #inst 2000-04-06T12:22:12.441-00:00 #inst 2002-11-24T01:28:22.121-00:00 #inst 1994-03-25T13:59:33.563-00:00 #inst 2071-07-24T05:23:57.700-00:00 #inst 1973-02-21T21:19:53.593-00:00 #inst 2002-01-15T22:05:02.577-00:00 #inst 2070-11-21T11:43:26.215-00:00 #inst 1981-02-13T22:11:16.246-00:00 #inst 1970-07-22T21:48:11.057-00:00 #inst 1971-01-29T03:41:18.739-00:00 #inst 1999-03-27T23:30:24.423-00:00 #inst 1977-02-06T08:36:28.391-00:00 #inst 2077-10-02T22:12:19.848-00:00 #inst 2033-06-20T08:33:04.929-00:00 #inst 2076-12-24T03:10:57.403-00:00 #inst 1994-02-24T15:51:53.173-00:00 #inst 1971-05-25T22:45:07.225-00:00 #inst 1973-12-18T13:35:59.229-00:00 #inst 2042-10-23T01:45:24.233-00:00 #inst 2038-03-23T00:12:18.445-00:00 #inst 2000-05-08T18:30:51.890-00:00 #inst 1970-03-22T04:27:39.217-00:00 #inst 1980-11-20T20:59:16.421-00:00 #inst 2001-06-29T08:24:25.837-00:00], :read #OutOfMemoryError java.lang.OutOfMemoryError: PermGen space} -Aaron On Feb 9, 2013, at 2:13 PM, Stuart Halloway stuart.hallo...@gmail.com wrote: Clojure 1.5 RC 14 (fourteen) will be available soon from Maven Central: http://search.maven.org/#search%7Cga%7C1%7Cg%3A%22org.clojure%22%20AND%20a%3A%22clojure%22%20AND%20v%3A1.5.0* Please test it! Thanks, Stu -- You received this message because you are subscribed to the Google Groups Clojure Dev group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure-dev+unsubscr...@googlegroups.com. To post to this group, send email to clojure-...@googlegroups.com. Visit this group at http://groups.google.com/group/clojure-dev?hl=en. For more options, visit https://groups.google.com/groups/opt_out. -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- Please correct me if I'm wrong or incomplete, even if you think I'll subconsciously hate it. -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Clojure 1.5 RC 14
I found it, fix coming soon.
Pesky interned keywords.
On Sun, Feb 10, 2013 at 10:31 AM, Aaron Bedra aaron.be...@gmail.com wrote:
I tried it on 3 machines with the following results
Late '11 iMac running OS X 10.8.2: Failed with PermGen error
Mid '12 Macbook Air running OS X 10.8.2: Success
VM Running Arch Linux: Success
So I can't say it is easily reproducible. I'll see if I can find what is
tripping things up on the iMac today.
-Aaron
On Feb 10, 2013, at 8:36 AM, Stuart Halloway stuart.hallo...@gmail.com
wrote:
Aaron:
Were you simply running the test suite via the build? On what hardware
and OS?
Stu
On Sat, Feb 9, 2013 at 9:16 PM, Aaron Bedra aaron.be...@gmail.com wrote:
Yeah, I know what would fix it, but I would like to make sure the right
defaults are in place for folks who pull it down.
-Aaron
On Feb 9, 2013, at 4:29 PM, AtKaaZ atk...@gmail.com wrote:
maybe jvm arg would help
-XX:MaxPermSize=256m
On Sat, Feb 9, 2013 at 11:17 PM, Aaron Bedra aaron.be...@gmail.comwrote:
I just pulled it down locally and got the dreaded PermGen…
[java] java.lang.OutOfMemoryError: PermGen space
[java] at
clojure.test_clojure.edn$types_that_should_roundtrip.invoke(edn.clj:32)
[java] at clojure.lang.AFn.applyToHelper(AFn.java:161)
[java] at clojure.lang.AFn.applyTo(AFn.java:151)
[java] at clojure.core$apply.invoke(core.clj:617)
[java] at
clojure.test.generative.runner$run_iter.invoke(runner.clj:108)
[java] at
clojure.test.generative.runner$run_for$fn__417$fn__418$fn__419$fn__423.invoke(runner.clj:135)
[java] at
clojure.test.generative.runner$run_for$fn__417$fn__418$fn__419.invoke(runner.clj:130)
[java] at
clojure.test.generative.runner$run_for$fn__417$fn__418.invoke(runner.clj:127)
[java] at
clojure.core$binding_conveyor_fn$fn__4130.invoke(core.clj:1836)
[java] at clojure.lang.AFn.call(AFn.java:18)
[java] at
java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
[java] at java.util.concurrent.FutureTask.run(FutureTask.java:138)
[java] at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
[java] at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
[java] at java.lang.Thread.run(Thread.java:680)
[java] clojure.lang.ExceptionInfo: Value cannot roundtrip, see
ex-data {:printed [#inst 2034-04-17T21:03:17.620-00:00 #inst
1979-04-19T20:14:07.477-00:00 #inst 1996-06-20T05:47:52.868-00:00 #inst
1995-08-15T20:51:41.920-00:00 #inst 2029-05-17T14:34:37.906-00:00 #inst
1987-06-05T21:05:23.305-00:00 #inst 1994-06-29T16:17:24.459-00:00 #inst
2035-12-03T09:39:44.754-00:00 #inst 2040-01-31T09:47:29.774-00:00 #inst
1973-06-09T04:53:42.029-00:00 #inst 1996-12-23T17:26:25.607-00:00 #inst
2022-07-01T16:33:57.846-00:00 #inst 1998-10-01T00:21:09.895-00:00 #inst
1973-01-11T17:43:58.457-00:00 #inst 1988-11-03T22:46:53.468-00:00 #inst
1982-01-31T11:34:19.796-00:00 #inst 2011-11-11T10:59:23.168-00:00 #inst
1973-06-07T12:37:22.285-00:00 #inst 1977-12-15T03:32:20.215-00:00 #inst
2047-10-15T13:51:28.327-00:00 #inst 2007-12-16T05:50:59.539-00:00 #inst
1980-05-01T01:58:13.802-00:00 #inst 1980-01-30T04:31:20.418-00:00 #inst
2044-09-16T14:38:34.919-00:00 #inst 1980-08-05T18:06:50.589-00:00 #inst
1978-12-31T11:40:11.800-00:00 #inst 2015-05-08T15:03:27.594-00:00 #inst
1975-06-28T17:24:08.855-00:00 #inst 1975-06-09T07:22:42.892-00:00 #inst
2026-03-20T07:01:01.296-00:00 #inst 2053-02-02T01:33:45.525-00:00 #inst
2002-04-11T18:43:38.347-00:00 #inst 1992-12-10T13:33:55.048-00:00 #inst
2015-04-16T20:53:45.670-00:00 #inst 2013-12-23T20:16:07.506-00:00 #inst
1978-09-02T09:42:03.175-00:00 #inst 1980-06-29T00:54:55.361-00:00 #inst
2061-11-04T22:40:32.484-00:00 #inst 2190-06-05T04:42:38.638-00:00 #inst
2038-03-19T09:05:50.002-00:00 #inst 2033-08-08T13:48:51.747-00:00 #inst
2077-11-18T06:09:19.557-00:00 #inst 1997-02-07T14:02:27.410-00:00 #inst
1988-08-20T07:11:32.623-00:00 #inst 1981-12-06T05:48:21.787-00:00 #inst
1980-08-15T09:40:38.877-00:00 #inst 2022-01-19T16:23:06.638-00:00 #inst
1994-09-09T17:35:55.052-00:00 #inst 1989-09-14T07:24:38.880-00:00 #inst
2050-03-30T21:22:42.054-00:00 #inst 2071-10-09T20:37:08.430-00:00 #inst
2083-04-19T10:25:43.108-00:00 #inst 1978-09-09T18:28:22.366-00:00 #inst
1979-11-03T08:18:42.779-00:00 #inst 1975-10-24T00:59:58.497-00:00 #inst
1974-10-10T14:40:29.360-00:00 #inst 1999-07-14T07:47:47.220-00:00 #inst
2215-11-23T00:36:40.748-00:00 #inst 2077-02-14T19:40:22.712-00:00 #inst
1985-03-14T12:30:49.064-00:00 #inst 2021-08-26T20:51:15.030-00:00 #inst
2013-04-22T10:48:12.278-00:00 #inst 2019-08-31T17:31:05.195-00:00 #inst
1975-04-21T22:13:33.370-00:00 #inst 1984-09-10T23:30:15.313-00:00 #inst
2053-11-10T05:36:02.093-00:00 #inst 1974-01-05T15:17:02.286-00:00 #inst
2058-09-18T08:11:45.895-00:00 #inst 1987-10-26T13:15:29.968-00:00 #inst
2001-10-01T08:12:45.877-00:00 #inst 2003-05
Clojure 1.5 RC 15 coming soon to Maven Central
Please test... Stu -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Clojure in the Field 2013 edition, suggestions wanted
Next week, I will be giving an all-new version of my Clojure in the Field' experience report [1] at DevNexus in Atlanta [2]. I will be drawing in Chas's State of Clojure Survey [3], and on the community success stories page [4], but those only scratch the surface of the wealth of Clojure experience on this list. So I need your help! If you were talking to somebody who was considering Clojure, and who wanted to know what it was like using it in the real world, what are the most important ideas and stories you would want to convey? Thanks! Stu [1] http://www.infoq.com/presentations/Clojure-in-the-Field [2] http://devnexus.com/s/presentations#id-1396 [3] http://cemerick.com/2012/08/06/results-of-the-2012-state-of-clojure-survey/ [4] http://dev.clojure.org/display/community/Clojure+Success+Stories -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
RC 16: Last chance to test against Clojure 1.5 before it ships
If you care about Clojure 1.5 compatibility for your codebase, please test it against RC 16 as soon as possible. You can get the source and build it yourself from [1], or wait for Maven Central [2] to pick up the CI build, which usually takes a few hours. Thanks! Stu [1] https://github.com/clojure/clojure [2] http://bit.ly/WEnjAi -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Clojure 1.5 RC 17 wending through the maven pipes
Only change from RC 16 is http://dev.clojure.org/jira/browse/CLJ-1168. Please test for regression. Stu -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
ANN: Clojure 1.5
We are pleased to announce the release of Clojure 1.5. Getting Clojure: Web: http://clojure.org/downloads Lein/Maven: :dependencies [[org.clojure/clojure 1.5.0]] Note that it will take a few hours for the links above to become live, as the completed build moves into Maven Central. This release includes significant features and bug fixes, documented here: https://github.com/clojure/clojure/blob/master/changes.md The number of Clojure contributors continues to grow. Thanks to all the people whose code is included in this release: Aaron Bedra Alan Malloy Alex Redington Alf Kristian Stoyle Ambrose Bonnaire-Sergeant Andy Fingerhut Brandon Bloom Brenton Ashworth Bronsa Chas Emerick Christophe Grand Colin Jones Cosmin Stejerean Daniel Solano Gómez David Powell David Santiago Ed Bowler Federico Brubacher Gabriel Horner Gary Fredericks Herwig Hochleitner Hubert Iwaniuk Hugo Duncan John Szakmeister Juha Arpiainen Justin Kramer Kevin Downey Laurent Petit Meikel Brandmeyer Michael Fogus Michał Marczyk Michel Alexandre Salim Philip Aston Philip Potter Rich Hickey Scott Lowe Steve Miner Stuart Halloway Stuart Sierra Tassilo Horn Toby Crawley Tom Faulhaber Thanks to all involved! Stu Halloway Clojure/core -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Clojure 1.5.1
Clojure 1.5.1 fixes a memory leak in Clojure 1.5, discussed here: https://groups.google.com/d/msg/clojure-dev/uAFM0Ti4AcQ/GmnKmphF1BgJ Getting Clojure: Web: http://clojure.org/downloads Lein/Maven: :dependencies [[org.clojure/clojure 1.5.1]] Note that it will take a few hours for the links above to become live, as the completed build moves into Maven Central. Thanks, Stu Halloway Clojure/core -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Clojure 1.5.1
Fixed, thanks. Stu On Sun, Mar 10, 2013 at 7:28 PM, ke.mar...@gmail.com wrote: I think there's a typo in the download link on http://clojure.org/downloads: It says http://repo1.maven.org/maven2/org/clojure/clojure/1.5.*0* /clojure-1.5.1.ziphttp://repo1.maven.org/maven2/org/clojure/clojure/1.5.0/clojure-1.5.1.zip whereas it should be http://repo1.maven.org/maven2/org/clojure/clojure/1.5.*1* /clojure-1.5.1.ziphttp://repo1.maven.org/maven2/org/clojure/clojure/1.5.1/clojure-1.5.1.zip (note the 1.5.1 vs. 1.5.0 in the second to last part of the URL) Am Sonntag, 10. März 2013 19:35:34 UTC+1 schrieb stuart@gmail.com: Clojure 1.5.1 fixes a memory leak in Clojure 1.5, discussed here: https://groups.google.com/d/**msg/clojure-dev/uAFM0Ti4AcQ/**GmnKmphF1BgJhttps://groups.google.com/d/msg/clojure-dev/uAFM0Ti4AcQ/GmnKmphF1BgJ Getting Clojure: Web: http://clojure.org/downloads Lein/Maven: :dependencies [[org.clojure/clojure 1.5.1]] Note that it will take a few hours for the links above to become live, as the completed build moves into Maven Central. Thanks, Stu Halloway Clojure/core -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
ANN: Simulant, a library for simulation testing
Wiki/repo: https://github.com/Datomic/simulant/wiki Clojars: https://clojars.org/com.datomic/simulant Presentations: https://github.com/stuarthalloway/presentations/wiki/Simulation-Testing Enjoy! Stu -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
is there a way to use clojure.main/repl from lein?
As opposed to tools.nrepl? Thanks, Stu -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: is there a way to use clojure.main/repl from lein?
I thought I wanted some of the affordances, but not the nrepl connection (e.g. get to reply's standalone eval mode). But it turns out that for my use case, I don't need any of that, so calling clojure.main directly is the right thing. Thanks, Stu On Mon, May 27, 2013 at 11:27 AM, Laurent PETIT laurent.pe...@gmail.comwrote: Hello, What about lein run -m clojure.main ? 2013/5/27 Stuart Halloway stuart.hallo...@gmail.com: As opposed to tools.nrepl? Thanks, Stu -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Clojure and Datomic workshops at NDC Oslo week of June 10
Hi all, I will be doing Clojure and Datomic workshops, as well as a few talks. at NDC Oslo in a few weeks, see http://ndcoslo.oktaset.com/Agenda for details. Hope to see some of you there! Stu -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [pre-ANN] test2, the last Clojure testing framework
Hi Steven, A few thoughts: 1. You may want to look at https://github.com/clojure/test.generative/blob/master/data-model.org. 2. I don't think you want a ref for *assertion-results* -- I am not aware of any use cases that would need transactions. In any case the choice of reference type probably belongs in the impl, not the spec. Good luck with this! Stu On Sat, Jun 8, 2013 at 4:14 PM, Steven Degutis sbdegu...@gmail.com wrote: Test2 is a new testing lib for Clojure, where the power is its simplicity, extensibility, and a SPEChttps://github.com/evanescence/test2/blob/master/SPEC.md much like Ring's. Github: https://github.com/evanescence/test2 Some background: It came out of discussionshttps://github.com/evanescence/test2/wiki/Communal-Brainstorming with the smart folks in #clojure, who were frustrated with the inflexibility of existing libs, and intended this to be the spiritual successor to clojure.test. We wanted something that was still simple like clojure.test, but could be extended externally much more easily in case you wanted features found in clojure.test, Midje, Speclj, or Expectations, or whatever else. This is a pre-ANN because it's more of a call for extensions. I've written one last night, test2-autorunnerhttps://github.com/evanescence/test2-autorunner, which took about an hour. This should give some idea of how easy it is and how well-designed the SPEC was by the smart folks of #clojure. There are some ideas at the bottom of the wiki, but of course any extensions are encouraged. -Steven -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: getMethods
I have found a function to get the methods of the classes in the book The Joy of Clojure, and I would like to use it in REPL. Instead of java.awt.Frame I would like to specify the library that I want writing something like (methods any.library). Which is the way to get it? (for [method (seq (.getMethods java.awt.Frame)) :let [method-name (.getName method)]] method-name) You can do the above like this: (map #(.getName %) (.getMethods java.awt.Frame)) And to turn it into a function, you just do this: (defn class-methods [class-name] (map #(.getName %) (.getMethods class-name))) You might also want to look at clojure.reflect. The API results are data, and can easily be mapped/filtered/etc. 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: Can the namespace portion of a symbol contain slashes?
My question probably should have been: is it intentional that the Clojure reader accepts symbol names containing more than one slash, producing a namespace portion of the symbol containing slashes in its name? The docs (http://clojure.org/reader) are specific: '/' has special meaning, it can be used once in the middle of a symbol to separate the namespace from the name, e.g. my-namespace/foo. '/' by itself names the division function. 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: Can the namespace portion of a symbol contain slashes?
On Thu, Jun 23, 2011 at 10:40 AM, Stuart Halloway stuart.hallo...@gmail.com wrote: The docs (http://clojure.org/reader) are specific: '/' has special meaning, it can be used once in the middle of a symbol to separate the namespace from the name, e.g. my-namespace/foo. '/' by itself names the division function. Specific perhaps, but incomplete. The docs don't provide enough information to determine the validity or meaning or 'a/b/c.d for example. The docs say what '/ means (by itself) and what 'a/b means (used once - we'll put aside the imprecision of in the middle of a symbol) but not what used more than once means. On Thu, Jun 23, 2011 at 20:20, Ken Wesson kwess...@gmail.com wrote: On Thu, Jun 23, 2011 at 1:48 PM, Sean Corfield seancorfi...@gmail.com wrote: The docs say what '/ means (by itself) and what 'a/b means (used once - we'll put aside the imprecision of in the middle of a symbol) I think that's fairly clear: that the portions of the symbol to each side of the / are non-empty. In the middle as opposed to at one end or the other. I disagree. It's not at all clear from the above description how the reader will interpret a/b/c: (1) namespace: a/b name: c (2) namespace: a name: b/c (3) throw an exception since the string violates it can be used once. The reader as implemented behaves as (1), though it's not clear from the documentation why this would be preferred above (2) or (3). // Ben The docs at clojure.org do not aspire to enumerate every possible scenario, especially regarding the things that Clojure does *not* do. If the docs don't say you can do this, then you should assume you can't (or at least shouldn't). 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: Clojure for large programs
On Jul 3, 2011, at 3:13 AM, Sean Corfield wrote: Since I mostly work with 50-100kloc projects, I think 5-10kloc projects are kinda small :) My point was that I'm running into interesting questions even with a small program. The answers are not obvious to me. There's evidence I'm not alone, so those to whom the answers *are* obvious would help the community by describing them. * An example: organizing code into namespaces (skippable) I was uncertain that Midje's sweet (syntactically sugared) interface would catch on, so I organized it by translation layers. I wrote the unprocessed layer first; it had functions that worked solely on maps. The semi-sweet layer provided macros that introduced some useful conventions but had only one syntactic innovation. It was easy to translate the `expect` and `fake` macros into unprocessed function calls on maps. Then I added the sweet layer that has a considerably more ambitious set of macros that translate `facts` into `expects` and `fakes`. As time went on, I pulled out utility functions into namespaces like [midje.util thread-safe-var-nesting laziness file-position]. But that organization failed. When I divide things up into files, I want the division such that I usually find things in the first place I look. That wasn't happening. So I started migrating to an organization based on verbs (this is a functional language, right?). So I have namespaces like [midje.midje-forms recognizing translating building]. Two problems: 1) New features require recognizing, translating, and building, so all the hopping around files was annoying. 2) The functions didn't fall into such clear-cut categories that I could reliably find things in the first place I look. (Unsurprising, since clear-cut categories are rare in nature: http://www.exampler.com/testing-com/writings/pnsqc-2005-communication.pdf) Now I'm moving toward an organization around nouns, which feels a bit too OO to me, but at least I'm far enough in the project that the key concepts/nouns are likely to stay stable. This progression feels a lot more wasteful than it would have been in Java (which has IDE support) or Ruby (which lets you mention a file once and have it be available throughout the program). So I'd have preferred to get it (more) right in the first place. * What would help It'd be useful for people happy with their multi-namespace codebases to volunteer them as exemplars. What's grouped together and why? What are the dependencies? How'd you arrive at this structure? A really interesting thing to do would be to implement a feature and narrate how you decide where to put things, where existing things must be, and so forth. [I spend a fair amount of time parachuting into projects and learning the code structure by pairing. Works pretty nicely.] On large projects I do the following: (1) Use require :as prefix everywhere. This felt ugly at first, but puts pressure on naming in way that is beneficial as the codebase grows. (2) Think of the consumer of the lib, not the author. As a user of Midje, I would want all the utility fns in a single namespace (if they were separated from the domain API at all). In general, I have found that namespaces should be larger than my OO intuition would have them be. 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: Please stand firm against Steve Yegge's yes language push
It may be that I am really talking about the website (clojure.org, not any of the auxiliary ones, which are a bit of a mess in themselves) more than the language itself. If people receive the \right instructions, setting up Emacs/Leiningen/Web servers etc. is actually not so hard. The trouble is that all of this information is currently scattered to the four winds (I include things like the Paredit cheat sheet, Slime commands, which Emacs to use, etc.), and I don't think we should rely on users to pull this information together themselves and at any rate, why should they? Getting Started documentation is bound to be a high churn area. Here are things you can do to help: (1) Edit and improve the official docs: http://dev.clojure.org/display/doc/Getting+Started (2) Link to the official docs, and help us do the same. clojure.org has a slower update process than the dev site (by design!) but if there is something wrong, or a place where it needs to link out, please let us know! (3) Encourage people who wrote a blog post 18 months ago that is now filled with misinformation (as things have moved on) to go back and add a link to the official docs. There are now almost 300 signatories to the contributor agreement, and any of them can update dev.clojure.org without any review process. This should be plenty of horizontal scaling to keep documentation (even high-churn documentation) accurate. Thanks to everyone who is helping out! 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: Please stand firm against Steve Yegge's yes language push
For instance, a little while ago I was corresponding with someone who had released a patch to Clojure. (This was Alyssa Kwan, in case you want to look up the thread.) Her patch made refs persistent to disksomething that seemed very much in the spirit of Clojure. Dealing with disk persistence in a production-ready way may be its own discipline, but in a language that wishes to reduce ceremony, there is no reason that you should have to worry about which database to use when you merely want to write a program that remembers data when you re-start it. The interface needed to do this is \almost there It seemed an eminently useful thing, but it got posted to this list and sank without a trace. Nobody from Core ever contacted her. (She admitted it was a hack, but isn't that how all patches start out?) Several points worth calling out in the this short paragraph: (1) It is certainly a shame is somebody got frustrated and left the community, esp. if all that was needed was recognition of their input. The core team is doing better with this over time, but there is always room for improvement. (2) Improvements to Clojure do not, in fact, begin as hacks. Or even as patches. In general, they begin with a statement of a problem and some possible approaches to a solution. This is then followed by months of contemplation on and off at different times. 90% of carefully considered ideas are eventually rejected, or simply wither from lack of attention/urgency. (You can see some of these at [1], [2], [3], [4], and [5], below). For random patches, the failure rate is probably more like 99.5%. (3) The specific patch [6] you are discussing fails a bunch of different sniff tests: * creator acknowledges it is a hack * IP and licensing issues have not been resolved * new dependency underneath Clojure? hard coded to one db? * open composability issues (what happens to e.g. closed-overs?) * the patch is compound. There are a number of separate subfeatures hiding in the proposal, each also incomplete (e.g. a generic serialization mechanism) * ACID most of the time is not, IMO, in the spirit of Clojure * how is this better/worse than using a database? (4) That's just the sniff tests. It has already taken me about an hour to follow the thread and write this response, and I would categorize this idea as being in the pre-design phase of its lifecycle. It could easily take several more hours just to document the rough edges of this idea, which is tantamount to starting the design process. Once started, how long do you think it would/should take to design and implement a generic solution bridging Clojure's in-memory reference semantics with disk? It is absolutely true that as Clojure grows, more attention needs be paid to ease-of-use and ease-of-getting-started. Suggestions here are welcome! I think there are a number of issues around user experience that are almost entirely orthogonal to deep challenges such as disk-persistent references. As such, they are amenable to suggestions and improvements that do not require language changes or the same level of vetting that language changes imply. Leiningen [7] is a great example of this. Most of the core team's time is, and will continue to be, focused on solving hard problems. Rich will be presenting a great example of this at the NYC Clojure group on July 20 [8]. Cheers, Stu Stuart Halloway Clojure/core http://clojure.com [1] http://dev.clojure.org/display/design/Error+Handling [2] http://dev.clojure.org/pages/viewpage.action?pageId=950382 [3] http://dev.clojure.org/display/design/Resource+Scopes [4] http://dev.clojure.org/display/design/Asynchronous+Events [5] http://dev.clojure.org/display/design/Improve+Binding [6] https://groups.google.com/group/clojure/browse_thread/thread/561230749be02f28/655507b9773aa8be?lnk=gstq=alyssa+kwan#655507b9773aa8be [7] https://github.com/technomancy/leiningen [8] http://www.meetup.com/Clojure-NYC/events/16166953/ -- 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: Please stand firm against Steve Yegge's yes language push
Read my blog post (written a year ago; updated several times to ensure it works with newer versions of Clojure and Leiningen): http://corfield.org/blog/post.cfm/getting-started-with-clojure Now replace clojure.org/getting_started with something like that and I think most of the complaints would go away. 1. That's really all there is to it. The starting path needs to be Lein and lein repl. If that one section on the Clojure.org website were changed (it's been there for whattwo years?) it would look so much better to newcomers. Lein can at least get people up and running, and give them time to play with Clojure while they figure out IDEs. Here's a possible plan: 1. Core will produce a smaller, up-to-date page for clojure.org/getting_started. This page will do less, and will link out prominently to the contributor wiki. Turnaround time on this: probably not before the announcement [1] on July 20. We're quite busy atm. 2. Between now and then, please help make the contributor wiki (http://dev.clojure.org/display/doc/Getting+Started) better! Some obvious things: 2a. Create a no decisions needed path for beginners. I share the opinion that this should not be IDE-based. 2b. Link out to the various other resources that are particularly useful for beginners. Stu Stuart Halloway Clojure/core http://clojure.com [1] http://www.meetup.com/Clojure-NYC/events/16166953/ -- 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: Mutable Clojure Data Structures
I love Clojure ,but Clojure sucks a lot of memory and that frustrates me ! I am looking forward to find a way to put mutability in my code the same way i put immutable data structures. For example imagine ~[ 1 2 3 4 ] to be mutable vector and every semicolon that have this ~ in front to be mutable. But I dont know from where to start , can you give me some tips ? Maybe i will create a fork of the compiler or a binding library based on java collection API I know that developers of the compiler will not like it . However if we succeed , then there is a future of clojure in androids and desktop aplication ! A big thing that will help Android is build profiles [1]. In particular, we need a lean-and-mean build profile that eliminates source code and metadata entirely. And then, inevitably, some way to whitelist in metadata that is required by the application. (Clojure's own use of metadata isn't required at runtime, but who knows what other consumers of metadata may need or expect.) This problem needs more design work before coding begins. (Maybe I should add the preceding statement to my sig...) Stu Stuart Halloway Clojure/core http://clojure.com [1] http://dev.clojure.org/display/design/Build+Profiles -- 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: Recommendation for Clojure Enterprise Development toolkit
On Jul 9, 2011, at 3:29 AM, MarkH wrote: As a tech lead or architect you should be fired for even suggesting to use Clojure as an enterprise greenfield. Industry and academia is moving towards advanced type systems. Nobody in industry seriously considers Clojure for enterprise systems. This is a good time for a reminder. If you are using Clojure professionally and are allowed to talk about it, please email clojure-advoc...@clojure.com and get your story added to http://dev.clojure.org/display/community/Clojure+Success+Stories. Sadly I cannot talk (yet) about the three most interesting Clojure projects I have been involved with. But nobody involved with any of them wants to fire me. :-) 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: Looking for examples of using Java iterators from Clojure...
I don't think I like the notion of a lazy-seq and an iterator, since reading the iterator also changes it. Consider the case where you create a lazy-seq from an iterator, and the iterator somehow escapes. Somewhere else the iterator is read from, and now the data that where supposed to be in the lazy-seq no longer exists. I guess you could clone the iterator, but that would sort of remove the purpose of using a lazy-seq in the first place. Jonathan The same argument could apply to every other kind of lazy seq: * resultset-seq better not let the ResultSet escape * seqs over arrays better not let the array escape * line-seq better not let the BufferedReader escape and so on. Implementers of seqs are responsible for encapsulating implementation details and not letting them escape. It's a fact of life. 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: (doc more-examples)
On Sat, Jul 16, 2011 at 2:23 AM, Tuba Lambanog tuba.lamba...@gmail.com wrote: More examples in how to use a form in the (doc ...) facility within REPL would be very useful to newbies. Thanks. That would mean the docstrings need to provide more detail in the source code. Not sure how practical that is since the docstrings would substantially outweigh the code - maybe Clojure/core could comment? I wouldn't use docstrings for this, as they increase runtime footprint. That said, an alternate doc macro could look other places besides docstrings. It shouldn't be difficult to write an examples macro that calls out to e.g. clojuredocs.org. 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
following Rich's talk at NYC Clojure this Wednesday
Several people have asked about access to Rich's upcoming talk this Wednesday night [1]. In order to make information available for those who are not present in NYC, we are planning to do the following: During the talk: * We will be live streaming the talk at [2]. This is our first time live streaming from the facility, so cross your fingers. * We will be covering the talk live in the Clojure IRC. After the talk: * Video will be posted online. Once the editing is complete, I will post a link here with details. * The slides will be posted online. Cheers, Stu [1] http://www.meetup.com/Clojure-NYC/events/16166953/ [2] http://www.ustream.tv/channel/clojurenyc -- 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: following Rich's talk at NYC Clojure this Wednesday
The website claims that the talk starts at 6:45 pm EDT, but I suspect that the technical content actually starts at 7:00. Stu awesome!! looking forward to the talk.. like everybody else, I think it will be great to have the time and time-zone info posted.. Sunil. On Mon, Jul 18, 2011 at 9:28 PM, Stuart Halloway stuart.hallo...@gmail.com wrote: Several people have asked about access to Rich's upcoming talk this Wednesday night [1]. In order to make information available for those who are not present in NYC, we are planning to do the following: During the talk: * We will be live streaming the talk at [2]. This is our first time live streaming from the facility, so cross your fingers. * We will be covering the talk live in the Clojure IRC. After the talk: * Video will be posted online. Once the editing is complete, I will post a link here with details. * The slides will be posted online. Cheers, Stu [1] http://www.meetup.com/Clojure-NYC/events/16166953/ [2] http://www.ustream.tv/channel/clojurenyc -- 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: [ANN] ClojureScript
Where is the bug tracker for ClojureScript? Just created: http://dev.clojure.org/jira/browse/CLJS 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: BUG REPORT: ClojureScript : Portable Path Support
If ClojureScript isn't mavenified, how else do you easily make it a dependency in a web application? Maven doesn't any problems that we have, and would add complexity to the development process and slow us down. Also, we don't want to unthinkingly drag Java presumptions into ClojureScript. Let's wait and collect feedback from the community before pouring any cement on deployment approaches. 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
better community docs: getting started
I am working through a few of the pages on clojure.org with two goals: (1) remove or fix anything that is outdated or incorrect (2) move to the community site (dev.clojure.org) things that should be maintained by the community. As a first pass, I have trimmed http://clojure.org/getting_started, and quite clearly linked out to http://dev.clojure.org/display/doc/Getting+Started for advice on tools, IDEs, etc. The community getting started page could be much better. In particular, people have opined that there should be a clear, no-choices-to-make path For Newbies section.Help welcome! 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
better community docs: contrib
The Contrib link in the top right corner of clojure.org now points to http://dev.clojure.org/display/doc/Clojure+Contrib. Currently, this landing page is just a list of links to the various contrib projects. Not great, but that is better than the old link, which simply dumped you into the old, monolithic contrib git repository. More important, http://dev.clojure.org/display/doc/Clojure+Contrib is a community-managed page, so Clojure/core isn't a bottleneck on improving it. Help requested to make http://dev.clojure.org/display/doc/Clojure+Contrib better. Cheers, 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: better community docs: getting started
I am working through a few of the pages on clojure.org with two goals: (1) remove or fix anything that is outdated or incorrect I really like how minimal that is now. A quick suggestion: shouldn't the Copyright date be updated too? Yuo. Fixed, thanks. 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: better community docs: getting started
I am working through a few of the pages on clojure.org with two goals: (1) remove or fix anything that is outdated or incorrect (2) move to the community site (dev.clojure.org) things that should be maintained by the community. As a first pass, I have trimmed http://clojure.org/getting_started, and quite clearly linked out to http://dev.clojure.org/display/doc/Getting+Started for advice on tools, IDEs, etc. Thank you! A question about the packaging of the Developer Releases on the downloads page: in the 1.2.1 ZIP, there's clojure.jar exactly as mentioned on the getting_started page; in the 1.3.0 Beta 1 ZIP, there's clojure-1.3.0-beta1.jar and clojure-1.3.0-beta1-slim.jar - is that just an artifact of the interim builds? (and is the assumption that folks reading getting_started aren't likely to try non-stable releases?) I think it is reasonable to expect that someone grabbing a non-stable build would recognize the trailing version goo as build artifact. I guess we'll find out. :-) 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: One syntax to rule them all
The fact that Read and Eval are separate steps is fundamental here. The ClojureScript reader does not eval, and the Clojure reader gives you the knobs you need to do what you want. Stu ...and immediately a new attack vector is born with Clojure structure injection attacks... I so hope people don't start passing executable clojure back and forth. On 23/07/2011, at 7:54 PM, Jozef Wagner wrote: Clojure can run on top of JVM, CLR and Javascript VM. Clojure data structures can replace syntax of SQL result sets, JSON, XML, HTML, CSS and other languages (e.g. .properties syntax). Clojure data structures are even used for application configuration (lein, cake). 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: Alright, fess up, who's unhappy with clojurescript?
Hi James, The Clojure/dev folks who built ClojureScript disagree with all of the key points of your analysis: Google Closure is too Java. It's not idiomatic JavaScript. If you target idiomatic JavaScript you will find yourself living in the world of JavaScript semantics. It is evident that many people want that. We don't. Then, there's the elephant in the room, and that elephant is Jquery. JQuery is a powerful library. So is Google Closure. I don't share your certainty that JQuery is the elephant. (I don't use any JQuery apps that have the sophistication of GMail.) But in any case, we are targeting a future community, not any currently-existing one. Then, the Google Closure compiler is a moot point. Everyone by now already has a copy of jquery from the Google CDN and linking to it in your code will not download it any further after your first visit to a website that does so. In any case, it's already small and fast. This is a good argument for modest applications, and a poor argument for substantial ones. We are interested in the latter. Then there's rhino/jvm. I would much rather an in-browser focus. Rhino is an implementation detail of the development platform. That implementation detail could and probably should change. I'm tempted to fork clojurescript and redo it in javascript perhaps so that seamless interop with jquery would be the main priority. If that is your objective, the ClojureScript codebase won't be a useful starting point. You would be better off to start from scratch. Cheers, 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: ClojureScript - why is javascript object array and not a map?
Note the following code that works: (defn ^:export displayPlain [id] (let [h (.getElementById window/document id) txt (aget h innerText)] (window/alert (str plain txt)) (aset h innerText here I am!))) Here, javascript object h is treated as array, and I was able to get and set its value (since it is mutable). Note that the following code doesn't work, since h is not a map, and thus we can't access its properties neither as keywords nor as names. (defn ^:export displayPlain2 [id] (let [h (.getElementById window/document id) ;; txt (get h innerText) txt (:innerText h)] (window/alert (str plain txt This makes dealing with js objects a bit mor verbose than clojure maps. It would be good if Clojure maps and JS object would be interchangeable from ClojureScript code. Would it make sense to open a bug/feature for this? I know that this is doable using closure library, but it would be nice if it could be easily doable using plain objects. (defn ^:export display [id] (let [h (dom/getElement id) txt (dom/getTextContent h)] (window/alert (str gdom txt Regards, Marko Design is underway on this. Stay tuned. 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: format and printf can't be used with BigInt
What the devil? Why was this done? Seems like wheel reinvention to me. Understanding the motivation for such a decision requires taking the time to understand the limitations of what Java provides. Java provides no wheel here -- BigInteger's hash is broken. The draft docs are here: http://dev.clojure.org/display/doc/Documentation+for+1.3+Numerics. These should be made better and placed in a more prominent place before 1.3 goes final. 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: format and printf can't be used with BigInt
I can't think of a single good reason why any of these pages should not be world-readable. We're an open source project. It's not as if we have trade secrets or something. I have no problem, of course, with restricting *edit* privileges to those with accounts that have proven to be responsible adults. This should be fixed now. Please verify: http://dev.clojure.org/display/doc/Documentation+for+1.3+Numerics Thanks, 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
novel feedback is always welcome
(I have take the liberty of changing the subject line, which may be less than ideal for some people's reading style.) Responses inline. There is something of an issue here, though: where, exactly, should the line be drawn between thou shalt not question this on the mailing list! and fair game for discussion In principle the line is clear. Everything is fair game. Novel feedback is always welcome. Question small decisions, question big ones. Press hard for quality. The opposite of providing novel feedback is recovering old ground. This takes two (often overlapping) forms: (1) Pushing an agenda when you aren't up to speed enough to be in the conversation. (2) Pushing an agenda when project leadership has said, I understand your feedback and disagree. This is not the direction we plan to pursue. Here are some specific examples: (A) The OP on the fess up thread drifted further and further into category (1) as the thread continued. He did not understand the difference between language and platform, and from there was at a loss to understand our decision-making. The very first reply on-thread covered the issue (http://groups.google.com/group/clojure/msg/448a2fec7636e5ad). If only the thread could have died there... (B) A minority of people have pushed back on the numeric changes in 1.3. This is category (2) feedback. There are real tradeoffs here, and Rich has made decisions that not everyone will agree with. You seem to feel that major, already-made design decisions that would require a fork and massive effort to do differently lie on the shalt not question side. What about more minor choices -- for example, which of the three kinds of primitive math overflow behaviors, throwing, auto-promoting, or wrap-around, should be the default? Ken, you are beating a dead horse on 1.3 numerics. You haven't told me anything I don't know already, and you have said several things that suggest that you haven't put in the time that we have to think through the issues. In particular: (1) You think that the overflow defaulting choice is minor, and I think it is fundamental. (2) You were unaware of the platform issues in Java that drove us to implement our own BigInt. That said, Ken's questions on numerics are not unwelcome. It is not realistic for every comer to the mailing list to have encyclopedic knowledge about what has gone before. So nobody should bite anyone's head off for asking a question that has been answered before (particularly if e.g. it is hiding in a deep, convoluted thread and isn't search friendly). Keep the feedback coming! Preferably in atomic chunks with good subject lines. :-) Cheers, 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: Clojure Dev: How you can help! (Hint: Alioth Benchmarks)
Hi Isaac, 1) When I saw this posting on Clojure Dev a month ago http://groups.google.com/group/clojure-dev/browse_thread/thread/2abe6d79087af4fc/9030a0b0c15f26a2?hl=enie=UTF-8q=alioth+shootout+clojurepli=1 I recognised the desire to have some quick and dirty performance regression testing, the Scala developers have been using benchmarks game programs for exactly that purpose - http://www.scala-lang.org/node/360 What puzzled me then, and still puzzles me, is why all the work done by Andy Fingerhut and others is being ignored? Andy spent all his time targeting 1.2. I spend all my time working in 1.3, and have no personal interest in writing benchmarks for 1.2 or older. It is in code such as the Alioth benchmarks where 1.3 is most different from 1.2. That said, in many cases Andy's code would be a good place to start. 2) Also I don't see why this approach - Our approach was to start with the Java solution and do a direct port. Then, examine where we might have bottle-necks and improve. Repeat until we are on par with Java performance. - would create programs that show anything that interesting about Clojure? Fair enough! I certainly was not trying to dictate approach. The suggestion was more about providing a way for people to ease into contributing. 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: sorted-set
Trying to migrate some of my code from clojure and javascript to ClojureScript and I'm missing 'sorted-set' Does anyone know if is is one of those parts of the library that has just not yet been migrated? Or will not at all be migrated? Or maybe I'm getting something wrong and its usage is not recommended in Clojure? In that case is there a recommended alternative? It might affect my ability to migrate to ClojureScript. Today I'm using javascript arrays that I keep sorted on the client side and clojure sorted-sets on the server. It would be really cool to have sorted-set's on both sides thanks Oded Hi Oded, sorted-set is on the todo list. Also, the which libraries are todo list is available in the repos at devnotes/corelib.org. Just look for anything marked todo. 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: Creating a Clojure Record from a string
Given:
test=(defrecord Foo [A B])
test=(class (Foo. 1 2))
test.Foo
How do I:
test=(new test.Foo 1 2)
#:test.Foo{:A 1, :B 2}
Currently I get Unable to resolve classname: test/Foo.
Thanks,
Timothy
(Class/forName java.lang.String)
Be mindful of the performance...
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: mini-version of clojure.jar?
My company (read: I) develop an web-based educational application (a language lab) implemented as a Java applet. I have spendt the summer porting it to Clojure. I am very happy with the results. Except: The download (and therefore the download-time) has increased dramatically, as I now include the clojure.jar as part of the download. (Actually, I repackage the content together with my application.) This, I fear is going to hit alot of the pupils hard, when 20 pupils at a time attempt to access the applet for the first time over the mediocre (at best) web-connections at their schools. Yes, I do manipulate the java applet cache-params. But There will always be a need for full downloads - both for first- time-users, and when I update the applet (frequently). My question: Is there anyway to reduce the size of the jar - drastically? Can I somehow remove most of the class-files generated from core.clj etc, and still have everything working properly? Tips/hints/suggestions? Great question. Post 1.3 we hope to look at a super-slim jar. The design notes are minimal at this point, but FWIW: http://dev.clojure.org/display/design/Build+Profiles 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: Making clojure.lang.IDeref a protocol
Hey, Has there been discussion about making clojure.lang.IDeref a protocol? I'd like to extend some java types to this the IDeref interface but currently this is not possible. I feel like this is such a common idiom, to get values, and doing so will allow me to leverage the @ reader macro for many data types. Best, Brent Someday. The challenge is load order. A lot would have to change to make protocols available early enough in Clojure's bootstrap to allow this. That said, I don't know many Java classes that have value-yielding semantics. And if you are writing your own class, you can implement the IDeref interface. 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: Contagious BigInts in 1.3? Why is (type (- 2 1N)) java.lang.Long?
In Clojure 1.3, BigInts are said to be contagious across operations. When different types of numbers are used in a math operation, the result will be the larger or more general of the two types. For example, any integer operation involving a BigInt will result in a BigInt, [...]. http://dev.clojure.org/display/doc/Documentation+for+1.3+Numerics However (type (- 2 1N)) results in java.lang.Long and does not seem to work accordingly. What's going on here? Cheers, Dominikus This is already fixed on master. 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: Migration to 1.3 for mortals
My worry is that the decoupling of core Clojure from contrib will result in contrib authors not caring too much about sorting out the current situation. Also, I think much of the fanfare of the 1.3 release will be shadowed by the contrib situation. And perhaps most importantly, I worry that I won't be able to take advantage of Clojure 1.3 in any of my applications anytime soon. Helping people migrate contribs is a significant issue and we will continue to work on it. Among other things, I like the idea of a bringing back a single download for people who don't care about modularity. This is easy enough to do on top of a modular system, it just hasn't bubbled to the top of anybody's priority list. That said, there are businesses who could use Clojure 1.3 tomorrow if it had an official release. They shouldn't have to wait. Also, the single best way to flush out the contrib issues is to have people trying a release. 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: puzzlement over lazy sequences
Hi George,
Once again, I make a globally referenced, infinitely long stream. But
now I use lazy-seq
instead of cycle:
user= (def ev-stream (lazy-seq (cons true (cons false ev-
stream
#'user/ev-stream
user= (defn ev? [n] (nth ev-stream n))
#'user/ev?
user= (time (ev? 9876543210))
Elapsed time: 47244.061 msecs
true
OMG! Not only did it NOT hose the heap and crash, it actually ran much
faster than the version
with the unreferenced (cycle [true false]).
The consing version of ev-stream is self-referential, because you explicitly
made it so by consing it back onto itself. So it only has two items in it,
though it bounces back and forth between them forever. The cycling version is
not self-referential.
The only reason I can think of, for this to NOT exhaust memory, is
that the lazy-seq macro knows
when to construct a circular list. Is that what happens? If so, why
DOESN'T it happen with cycle,
where it's obviously the behavior one would want?
cycle actually calls lazy-seq. A quick way to check such things at the REPL is
with source:
user= (source cycle)
(defn cycle
Returns a lazy (infinite!) sequence of repetitions of the items in coll.
{:added 1.0
:static true}
[coll] (lazy-seq
(when-let [s (seq coll)]
(concat s (cycle s)
snip
Now I'll test it with 9876543210, a number which ev? was able to
handle:
user= (time (mod3 9876543210))
Elapsed time: 37759.615 msecs
1
user= (mod 987654321 3)
0
Whoa! The computation finished in reasonable time, but with the WRONG
answer! How did that happen?
Did I find a bug?
No, there is simply a typo in your input arg.
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: N00b alert! - A question on immutable/mutable data structures...
For example, what if I have a hash-map that needs to handle concurrent changes to the data structure, but never needs to have concurrent changes to a given piece of data (i.e a key/value pair). Wouldn't there be value in being able to modify the data in-place without making a copy, or needing to endure the overhead associated with STM? Hi Trevor, You should endure the overhead of the STM if you need what the STM provides: coordination of activity across identities. But there are several things in Clojure that provide identities without STM. In your example, you could place a map inside an atom, which provides atomic transitions between values, but no coordination. Abandoning values entirely should be highly motivated by a specific need. If you're there, then Java's concurrent maps are good and appropriate. 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: Is there a reason that def- isn't part of the core lib?
We will see this subject line in this mailing list every few months until the end of time, or until def- is added to core. So be it. The burden, no matter how distributed, of answering that question forevermore greatly outweighs the burden of moving a def- macro from a contrib file to a core file. It even outweighs the aesthetic concerns (which I confess I don't understand). Alan covered the biggest problem succinctly: it pollutes the language core to provide convenience APIs that are combinatorial in nature. I don't really think the people that want def- need it in the language core. They just want to know where to get it, and maybe automatically include it in their own projects. So make a community-centralized, maven-ready, CI-friendly place to put such things. In fact: such a place already exists: https://github.com/clojure/core.incubator. Add a slew of custom def forms to incubator.clj and party on. Stu -- 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 there a reason that def- isn't part of the core lib?
The API already contains `find` and `contains?`, which are woefully misleading names. That's not a big deal: I'm *terrible* at naming. I tell people that all the time. I've learned to accept it. It doesn't detract from my wonderfulness. It doesn't detract from the underlying wonderfulness of the software I produce. It just means I have to rethink and revise names, especially after other people use them and say WTF??. It's a shame it's too late to do that for `find` and `contains?`. Fortunately, additions are easier than changes. This argument supports my position, not yours. It is much easier to revise names in an incubator library, rather than experimenting in core. I really think `def-` would be a good gesture, a minor but emblematic step on the way to widespread acceptance of Clojure, which (for my sake) I really, really, really hope for. I don't understand how a casual approach to adding things to core would be a good gesture to anybody. Can you send me a list of languages that add features to core after this level of discussion (and without clear agreement) because some people find them useful? I am not aware of any. To restate my earlier point: Why isn't this in core? and Why isn't this conveniently available to me? are very different questions. If you have a problem that can be trivially solved outside of core, why are you in such a hurry to change core? Making unnecessary changes at the bottom strikes me as bad design and bad stewardship. Here's a thought experiment: There is a ton of useful stuff in my .emacs file. I can think of a few dozen things in my .emacs file that are in the def- category for me, e.g. I like them, and I want them around always, and immediately when I launch. So those things are core to me. What do you think would happen if I joined the emacs dev list, picked my very favorite convenience, and said please add this to emacs core? Emacs doesn't work that way. It is modular, and people solve problems in *libraries*. Sometimes large groups of people agree about certain things. Even then you often get awesome tools like the emacs starter kit *without* changes to emacs core. The clojure.core namespace evolves at the speed of design, not at the speed of itch-scratching. I think this is a fundamental value. Stu -- 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 there a reason that def- isn't part of the core lib?
I don't understand your comment about polluting the language core. Do you really think people are going to use def- for some other purpose? If you don't, then it is not pollution. Fair enough. Maybe pollution wasn't the best word. Introducing a combinatorial set of names is a [some other word for bad thing] for core, even if we agree what the names mean. I think the big issue here is I think that the big issue here is that we do not agree on how careful the dev team should be about adding things to core. I think we should be quite careful. The name is core not kitchen-sink. If anything, core is already too big. that certain functions in Clojure core *imply* the existence of other certain functions in the core. When they don't exist, it comes as a surprise. Surprise is bad. Agreed, but this is how you argue for a complete set, not for a convenient subset. No one seems to be asking for defmacro-, even though core itself defines a private macro. defn- implies the existence of def- Then let us deprecate defn-. The other example that immediately leaps to mind is that the family of get-in, get, and update-in implies the existence of update. It is rather startling to me that update does not exist in the core. This is a good question. I don't know why I never noticed its absence. Have other people missed this? Stu -- 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 there a reason that def- isn't part of the core lib?
What really puzzles me is that it doesn't seem to be generally regarded as idiomatic Clojure style to just use top-level (let)s for your private globals. This has lots of benefits: - If you do this you can make them actually, genuinely private, rather than just marked as please don't use this - You get more self-documenting source code: (let [x 1] (defn foo [] (...use x...))) is clear about how and where x will be used, while (def- x 1) (defn foo [] (...use x...)) leaves open the possibility that x is important all over the namespace. - You avoid runtime var-deref costs for constants that will never change. I find this style so useful and readable that I'm curious why it isn't more popular in the community at large. Top-level lets make it more difficult for tools to statically analyze code. Of course said tools are largely hypothetical at present. :-) 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: Is there a reason that def- isn't part of the core lib?
I also think it is worth remembering the difficulty people have with getting started with Clojure (wrt to IDEs). There are *so* many third party libraries out there at the moment that a beginner could easily be overwhelmed. The more self contained and feature complete the core is the better. A self contained complete starter env (e.g. including all the modular contribs) is a good idea. It should not be core. Stu -- 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: issues to build clojure-1.3.0-RC0 with JDK-1.7
Hi Jochen, thanks for this report. It looks like the annotations tests are failing due to changes from JDK 1.6 to 1.7. They were brittle tests to begin with and should probably be removed or replaced. This also revealed to me that our JDK test builds on Hudson were not actually building properly. That is now fixed, so we can confirm this issue on Hudson: http://build.clojure.org/view/Clojure/job/clojure-test-matrix/ -Stuart Sierra clojure.com Now fixed on master. Thanks for the report! 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: Why visible in-transaction changes?
I would have hoped that changes to refs during an transaction wouldn't affect the in-transaction value of the ref (that is, I would have liked the code to print 1, then 2). This way, the view of the program's state would always be guaranteed to be consistent, even during a transaction, and there would be no fear of non-consistent in- transaction states breaking anything. The way it is currently work in Clojure, though, still requires one to take all such inconsistent states into account, rendering them effectively useless for the kind of state management I imagined. (Note that I am not talking about multi-threading here; my objective is to reduce the number of possible states in the single-threaded case, and make sure that every computation is based upon a consistent state.) Why was this behavior chosen, instead of only making changes to refs invisible until commited (even to the transaction commiting them)? I believe that the latter approach would actually fit better to Clojure in general. Maybe there could at least be an alternative dosync form that acts like this? Regards, Denis There are a lot of scenarios that would become difficult or impossible with the semantics you propose. On the other hand, what you want is quite simple to achieve: If you want consistent view of the the values of refs, deref them all at the start of the transaction. 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: issues to build clojure-1.3.0-RC0 with JDK-1.7
Hi Jochen, thanks for this report. It looks like the annotations tests are failing due to changes from JDK 1.6 to 1.7. They were brittle tests to begin with and should probably be removed or replaced. This also revealed to me that our JDK test builds on Hudson were not actually building properly. That is now fixed, so we can confirm this issue on Hudson: http://build.clojure.org/view/Clojure/job/clojure-test-matrix/ -Stuart Sierra clojure.com Now fixed on master. Thanks for the report! Can you tell me the exact commit number, so I can apply the patch to the Fedora package. Best Regards: Jochen Schmitt The SHA for that commit is fcc3d799cc33c920720fa512b18901e2f2a81dda . But you might want to leapfrog that and just grab the clojure-1.3.0 tag. :-) 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: beginner question
the website says: deftype supports mutable fields, defrecord does not so deftype seems to be what would be a java bean with simple properties in java Nope. :-) Domain information should use defrecord, and should never be mutable. This is the closest thing to a Java bean, but is radically different in being (1) immutable, (2) persistent, and (3) accessible generically as a map. Game state would modeled with defrecord. deftype is for things like custom data structures. In a Clojure-in-Clojure implementation, deftype would be used to implement maps, vectors, and lists. deftype's mutation ability would be used to implement transients. Stu -- 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: :use :only support in ClojureScript now available
Nice! This is great. Will the :only directive always be required, or will we eventually be able to pull in entire namespaces? - Jason Probably the former. Pulling in entire namespaces is generally considered bad practice. Stu -- 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: beginner question
what's the difference between persistent and immutable? See http://en.wikipedia.org/wiki/Persistent_data_structure, which now has a nice shout out to Clojure. Stu -- 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: suggestion for clojure development
I hope so, too, but very often this doesn't happen in practice. Much useful code is not maintained. If I add a dependency from Clojars or maven central to my project.clj file, I don't want to pay the tax of deciding what Clojure version it is and whether it is actively maintained, Clojars has a super-low barrier to entry. This is great for getting a lot of code published, but I don't see how you can use Clojars (or anything like it) without having to verify some basic facts about the code you are using. Better metadata would be great, but you would still want to check it. FWIW, on my commercial work we ban clojars and review the source code of every dependency. Of course this can be necessary when there are bugs, but now almost all the 1400+ libraries in Clojars are suspect because of the 1.2 to 1.3 transition. Let's start by fixing the most important ones. Sean Corfield and others are leading the way with contribs. Any candidates for a short list of libs that need updates ASAP? I consider this to be incidental complexity and I am tired/old/lazy/ stupid. I want to simply use the library. Clojure indeed is brilliantly designed exactly to make libraries easy to use (by using immutable data and avoiding the OOP pitfall of excessively complex types) and this breaking transition from 1.2 to 1.3 tends to undermine that achievement. I do like Phil's classloader suggestion, but I wonder if there might be a way for leiningen to automatically provide a transparent wrapper around 1.2 jars so that they can be called by 1.3 code without local (eval-in-1.3 ...) macros. This sounds big and hairy compared to simple detect-and-warn or detect-and-fail approaches. 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: suggestion for clojure development
So what's the plan for the future? Are there plans to make clojure stable at some point so that backward compatibility can be expected? Otherwise I am going to have difficulty continuing to advocate clojure to my colleagues. In other words, when will the library ecosystem be considered important enough not to break? A key benefit of the move to modular contrib libraries is to prevent having library ecosystem == monolithic hairball. I think a statement of the policies of the Clojure/Core team (perhaps spelled out on the website) concerning stability and backward compatibility would really help those of us who want to be able to rely on Clojure. The objective is the kind of stability seen across 1.0, 1.1, and 1.2. I am aware of nothing on the horizon like the numerics change, but if something important enough comes along, a decision will be made. 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: suggestion for clojure development
Staying with 1.2 meant not only staying with the Clojure core, which worked fine, but also losing any progress on any of the contribs, which was frankly more important to me than core language changes. Perhaps part of the really big issue here is not Clojure per se, but the contribs. In one fell swoop, the entire contrib universe for 1.2 was being deprecated. I saw no commitment anywhere that bug fixes would be backported to the 1.2 contrib library. (I'm not making a principled stand here: the clojure contrib library as of 1.2 was very spotty in quality, and required many workarounds for bugs in my code. I very much look forward to fixes there.) Agreed, this is really all about the contribs. And now that they are independently versioned, there should never be a big bump like the move to 1.3 again. Stu -- 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: Equality comparison in 1.3
user= (= 23.0 23) false user= (= 23 23) true This is the correct behavior. If the doc string is confusing, please propose alternate language. 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: suggestion for clojure development
Stu's comment actually worries me in this respect: the fact that each contrib has its own version may make it easier to evaluate them separately, but it would appear to me as a defeatist goal for Clojure moving forward. Things that are simple can be composited. Things that are compounds typically cannot be simplified. Separate versions make it easier for the dev team to release a batteries-included build (or a beginner build, or an Android build, etc. etc.) Also: With modular contribs it is easy for people shipping software to vet and groom their own team-specific standard library. What I would want to see is a coherent standard library that is centrally maintained. Modularity helps, not hurts, in achieving this. Contrarily, it seems that effort is being put into cleaning up the core and jettisoning anything merely suspected of being superfluous. That certainly isn't an objective. Can you list some examples of things that in your opinion were casually jettisoned? So, what's going to happen to all that stuff outside? Will it be maintained by the community? The same community that made the 1.2 contrib? Or maybe Clojure 1.5 will bring some of them into the fold? (I'm not being sarcastic; these are honest questions about the possibilities and vision.) Can you list the specific libraries that you think are causing the most trouble? Someone on this thread mentioned that it's all as expected, and that Clojure is just for a bunch of geeks, anyway, so breakage is no big deal (I'm paraphrasing). I hope for a strong official position against that. Clojure is for production software. Breakage is a huge deal. Clojure has an amazing track record of stability, even including the changes in 1.3. Libraries are a different story. Contrib in particular has a mixed record. We are changing that now. Help welcomed. Stu -- 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: suggestion for clojure development
Contrarily, it seems that effort is being put into cleaning up the core and jettisoning anything merely suspected of being superfluous. That certainly isn't an objective. Can you list some examples of things that in your opinion were casually jettisoned? I didn't use the word casually. But, to the point, see the discussion here, re defn-: https://groups.google.com/d/topic/clojure/r_ym-h53f1E/discussion Thanks for picking an example I am already familiar with. :-) The defn- thread wasn't about casually jettisoning something, but almost the opposite. In that thread you see me and several other people standing *against* making a casual breaking change to core, to meet an entirely superficial need that is easily solved by libraries. I would point to this thread as an example of responsible stewardship, of How It Ought To Work. A question was raised in the right forum (on the public mailing list), a respectful conversation followed, a variety of opinions where expressed, and best of all no breaking changes were made. Libraries are a different story. Contrib in particular has a mixed record. We are changing that now. Help welcomed. I'll repeat that I'd prefer not to think of it is as contrib, as if it's something provided by the community (help welcomed/wanted), but as a standard library very close to the language itself. In my opinion, this would strengthen Clojure and its acceptance. The language core might be mature, but any language needs a mature standard library. I can think of a few non-exciting languages (Java!) that were broadly adopted because the standard library -- together with the rest of the platform -- was strong, mature, and proven. I was referring to the aggregate contrib, not a curated subset (which I agree is a good idea). Maybe we should call the aggregated thing the Libraries Formerly Known as Contrib (LFKAC). Stu -- 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: suggestion for clojure development
On 10/02/2011 05:20 PM, Stuart Halloway wrote: I was referring to the aggregate contrib, not a curated subset (which I agree is a good idea). Maybe we should call the aggregated thing the Libraries Formerly Known as Contrib (LFKAC). Here's how I envision the distribution structure: Clojure Core: the language engine itself, at its bare minimum Clojure Base: a collection of crucial libraries that is released *in tandem* with Clojure Core, meaning that they have the same base version which they are tested against. So, Clojure 1.5 would be released at the same time as Clojure Base 1.5. Critical fixes could then be minor releases, such as Clojure Base 1.5.1. But, it would be obvious that it is tested against Clojure 1.5.X and that is *for* Clojure 1.5.X. The Clojure Base libraries would also exist on their own with their own versions, and can be upgraded or used separately. The Clojure Base versioned distribution establishes a integrally tested baseline: the idea is that if you stick to Clojure Base, you cannot go wrong, and a clear upgrade path would appear in the future if necessary, say, for 1.6. Clojure Extras: community-maintained libraries outside of Clojure Base, but that are -- for convenience's sake -- listed on Clojure's main web sites and repositories next to the Clojure Base libraries. What marks these libraries as different from just any other library in the larger Clojure ecosystem is that Clojure Extras get approved clojure.* namespaces, such as clojure.java.jdbc. Some of these might be candidates for eventual inclusion in Clojure Base (marked as incubating) but they do not have to be; Clojure Extras might be their natural home. For inclusion in Clojure Extras, a library would have to prove some kind of essential generic functionality warranting a clojure.* namespace, such as support for a standard or technology or an implementation of a well-known algorithm. So: no frameworks, products, etc. The idea is that users would go to Clojure Extras first to find an API, knowing that it has received some minimal review, before rummaging through the wild, wild Internets. The batteries included build at http://dev.clojure.org/display/design/Release.Next+Planning is probably the same as your Clojure Base. 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: Can't eval locals problem
Ok, so I'm stuck. If any of you more seasoned clojurians have a hint that could get me out, I will be forever gratefull to him/her: I'm trying execute a query against google app engine datastore, using appengine-magic, with the filter dynamically generated from a map. Here's the closest code I have been able to come up with: (defmacro order-query [params] `(ds/query :kind Order :filter ~(map #(list (key %) (val %)) (eval params This macro fails with a Can't eval locals error. I recognize that the main issue here is that i'm forcing evaluation of something at macro expansion time. Apparently clojure does not (fully) support this, so I'm looking then for alternatives. Cheers, Razvan Hi Razvan, Can you tell us a bit more: (1) the stack trace of the error you are seeing (2) the form you are using to call order-query (3) what you expect evaling something at macroexpansion time should be doing Thanks, Stu -- 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 handling changes in Clojure 1.3.0
The Google App Engine SDK uses checked exceptions on many of its API methods. In many cases, I want to catch these exceptions and do something Clojure-friendly with them. With Clojure 1.2.x, I had no trouble catching checked exceptions by type, e.g.: (try (some-app-engine-api-methods-called-here ...) (catch EntityNotFoundException ex ...)) This stopped working in 1.3.0. The caught exception does not match EntityNotFoundException; it is now a RuntimeException with the original typed exception chained to it. I don't fully understand the implications of the exception handling changes in 1.3 (https://github.com/clojure/clojure/commit/ 8fda34e4c77cac079b711da59d5fe49b74605553). Does it mean that all exceptions coming in from Java code into Clojure will now be wrapped in an extra RuntimeException? Catching checked exceptions seems to work fine. Try e.g. (try (throw (java.io.IOException.)) (catch java.io.IOException _ caught!)) I suspect something else is going wrong in the GAE example. Can you narrow the code down to a block you can quote in full here? 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: defprotocol problem in 1.3?
I finally got around to trying out the 1.3 release yesterday with a batch of code that was constructed using 1.2, and promptly ran into a problem. In 1.2, it's possible to define a protocol with zero methods, so, for example, (defprotocol xxx) works just fine. In 1.3, this generates the rather peculiar error java.lang.UnsupportedOperationException: Unknown Collection type. Is this an intentional change from 1.2, or a problem? Hi Howard, Not intentional, maybe a problem. :-) What are you using empty protocols for? Stu -- 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.contrib.base64
I use Base64 encoding a lot and the slow implementation is hurting a lot. It's slower than Sun misc encoder/decoder and that one is very very slow. I was using Sun's implementation a bit and it took 80 seconds to encode a 56 MB file. Then I found this: http://migbase64.sourceforge.net/ It loaded from a disk drive and encoded the same file in 0.3 seconds! Would it be possible to have Clojure contrib use an implementation like this and thus enable all Clojure developers to have lightning fast Base64 encoding/decoding? I know having everything implemented in clojure is a big thing around here but in case of Base64 encoding and regular expressions I think the language would benefit greatly by having implementations which are orders of magnitude faster than default implementations in java. Did I say regular expressions? http://www.tusker.org/regex/regex_benchmark.html Like Rich Hickey said: why should we reinvent file streams and sockets in each language? I think the same principle applies to Base64 and regular expressions, especially when in Clojure we have an opportunity to replace standard java implementations with ones that are orders of magnitude faster. What are your views on this? I too would like a fast base64. There are a few different things we could do: 1. Vet the best Java one and link it from contrib.base64 (and possibly deprecate the contrib as well). 2. Approve a base64 lib for inclusion by reference in contribs. 3. Write a fast clojure one (possibly a direct port of the project you link, if it is the best). I have several Clojure projects that ship with no binary dependencies. This is a maintenance virtue, which is why I think #3 is important. If somebody writes a good one I will fast track getting it into contrib. Stu -- 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.contrib.base64
I threw a base64 encoder together a while ago when playing with the new primitive stuff. Interesting to note that it is faster than the one in Apache commons-codec. https://github.com/ataggart/codec/blob/master/src/codec/base64.clj Do you want to make this the basis for an improved contrib? One thing I would like to see is a call that takes bytes,offset,length. When I care about fast I also care about not being forced to do an arraycopy. 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: clojure.contrib.base64
Sure, I'll start working on it. Do you want it to be worked on in a contrib project or just submit it once it's functional? Whatever works best for you. Also, I assume you'd want this to work with 1.2, right? I won't personally need that. Plus, this is the kind of lib where the code would differ substantially. Your call, though. Thanks, Stu -- 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: Faster JSON library
Trying to be a little bit constructive here, in case I come across as complaining, I took the source for c.d.json and put it into a leiningen project, enabled warn on reflection, and found that several cases of (... (let [c (char i] ... (= c \x) ...) results in Clojure deciding it needs to perform reflection in order to call equals in the comparison with a fixed character. I'm not really sure what the proper solution for this is, but I changed the let to (let [c (Character/valueOf (char i)] ...) and the time for my 217KB JSON file dropped from 107 seconds to 2 seconds, or only a little more than twice as slow as clj-json (which clocked in a little under one second for my file). Lars Nilsson Thanks. I am going to take a look at this now. 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: Faster JSON library
Trying to be a little bit constructive here, in case I come across as complaining, I took the source for c.d.json and put it into a leiningen project, enabled warn on reflection, and found that several cases of (... (let [c (char i] ... (= c \x) ...) results in Clojure deciding it needs to perform reflection in order to call equals in the comparison with a fixed character. I'm not really sure what the proper solution for this is, but I changed the let to (let [c (Character/valueOf (char i)] ...) and the time for my 217KB JSON file dropped from 107 seconds to 2 seconds, or only a little more than twice as slow as clj-json (which clocked in a little under one second for my file). Lars Nilsson This reflection warning can be fixed with an enhancement on the Clojure side, which I have just pushed to master [1]. I would like to create 1.4 alpha 1 with the code changes that have gone in today. It would be super-great if anybody has time to build your own project against master and let us know if you see any issues. Thanks, Stu [1] https://github.com/clojure/clojure/commit/405d24dd49d649c01b7881f1394fc90924c54ef0 -- 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.contrib.base64
On Sunday, 9 October 2011 19:49:17 UTC-7, Stuart Sierra wrote: Clojure unless somebody clever can make one that's actually *faster* than the best Java lib. Here ya go: https://github.com/ataggart/clojure.data.codec I owe you a beer for the offset and length args. Thanks! 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: Type hints and records
I am using a record to wrap a number of java classes, which I then access various properties on. I am trying to avoid reflection so I type have type hinted, however when accessing the values in the record the type hints are lost. It might look something like this (defrecord Rec [^Integer i]) (defn to-string [^Rec record] (.toString (:i record))) However the to-string function gives a reflection warning, even with the input the to function type hinted. Now I know that type hints don't survive across function boundaries, but is there no way to get a type hinted value from the record? Treat the record as a typed thing instead of as a map (note the dot instead of the colon). (defn to-string [^Rec record] (.toString (.i record))) That said, and not knowing exactly what you are doing, the following looks better to me: (defrecord Rec [^int i]) (defn to-string [^Rec record] (str (:i record))) 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: Please help me on submitting the Contributor Agreement
I want to submit the Contributor Agreement. One question is whether the following mail address on http://clojure.org/contributing is still valid: Rich Hickey 514 South Duke Street Durham, NC 27701 The other question is whether the above address is in USA. I live in Beijing. I need to fill the country name in mail address. Yes, that is a valid address, and it is in the USA. Cheers, Stu -- 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 1.3 treatment of integers and longs
Thanks. I read through that and it didn't quite answer my question. To
me it seems more logical that:
1. Clojure defaults to longs when you create a new number (with a
literal 0, 1, etc)
2. You can create ints by doing (int 0)
3. Clojure never changes the types of things you're using
I find Clojure's behavior of changing the types of primitive ints to
longs highly unusual, and it is causing a lot of pain in upgrading
Storm to 1.3.
Integers and longs are going to be painful no matter what because they are
broken in Java, e.g.
Object[] objects = new Object[] {-1, -1L};
System.out.println(objects[0].hashCode());
System.out.println(objects[1].hashCode());
Clojure avoids this pit by standardizing on longs, which leaves you with the
need to specifically request ints when you need them for interop. You can use
(int n) hints to select the correct interop method invocation, or box an int if
you want to hold on to a value guaranteed to be int.
Can you post a code example that shows a problem you are having?
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: Newbie help in pitching in
Hi all, Now that I have my shiny new, clojure-dev membership, I'd like to pitch in. I took a look at the pages describing how to contribute. http://clojure.org/contributing http://clojure.org/patches The process for contributing is pretty clear, but I'm finding it hard to find anything appropriate to my skill level and familiarity with the Clojure / clojure-contrib source to work on. Even finding an appropriate issue from a 'process' perspective is difficult, e.g. I ran a JIRA search on open, unassigned, issues and found that many of them already had patches associated with them, were waiting for someone do something or had comments that seemed to imply that someone was already working on the issue or perhaps was no longer even an issue. To say nothing of the difference between an issue being assigned to backlog, approved backlog, and the various releases. I'm wondering if anyone has some suggestions on tasks that might be useful for a newbie to work on -- documentation or grunt programming tasks would be fine. Maybe updating or expanding test cases? Hi Rett, Contributing a 1.3-ready Alioth benchmark to https://github.com/clojure/test.benchmark would be terrific. These act as test cases for both functionality and performance. Improving the docs at http://dev.clojure.org/ is also a great help (although the site seems down atm). Cheers, 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: Clojure 1.3 treatment of integers and longs
Yes, I understand the behavior perfectly well. The primitive int gets converted to a Long immediately, as this code demonstrates: user= (class (Integer/parseInt 5)) java.lang.Long The int isn't being boxed into a Long -- the type is being changed. I'm aware that I can fix things by converting the type back to an Integer manually, but that's not the point. Changing the types is unusual behavior that leads to hard to track down bugs like I ran into with the ClassCastException. My proposal still stands. -Nathan Somebody has to work hard: either users of collections, or interop callers. The current behavior makes things just work for collections, at the cost of having to be explicit for some interop scenarios. There are two reasons to favor collection users over interop users: (1) Interop problems are local, and can be resolved by checking the type signature at the point of the problem. Collection key problems are global and break the composability of collections. It is a *huge* benefit of Clojure that collections are sane. (2) There are a lot more lines of code working with collections than doing interop. Stu -- 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 there a reader setting support BigDecimal by default?
It appears that the answer to the original question is no, there is no way to configure the reader to default numbers with a decimal point to be BigDecimal instead of Double. Scott Hickey Reading a double implies that somebody upstream of you was using doubles, which violates the guarantees you want from BigDecimals. Why is the upstream provider using doubles? Stu -- 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 there a reader setting support BigDecimal by default?
It appears that the answer to the original question is no, there is no way to configure the reader to default numbers with a decimal point to be BigDecimal instead of Double. Scott Hickey Reading a double implies that somebody upstream of you was using doubles, which violates the guarantees you want from BigDecimals. Why is the upstream provider using doubles? I don't follow. The OP has text, which Clojure is reading as doubles. This only implies that upstream (which need not have been written in Clojure) is producing numbers matching #[-]?[1-9][0-9]*[.][0-9]*|0, because LispReader interprets that as Double. Whatever internal representation this text was produced form may or may not have been (binary) floating point initially. It doesn't seem reasonable to assume that the OP's 'business' applications I've built over the last 25 years could have known that Clojure would come along later and expect to find M on the end of every decimal number. // Ben Hmm, highly apropos discussion since Rich's talk on simplicity posted today. The reader does one thing: read Clojure data. Sometimes you need something else: read data written in another format. You might accomplish that by (1) making the reader able to do two things, adding a flag to deal with a specific format, or (2) by using a different reader for that job. (2) is hands-down the right answer. Stu -- 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 1.3 treatment of integers and longs
Luc, what you're saying sounds to me like this is the way it is so deal with it. Can you give me some concrete code snippets showing why it's better to box ints as Longs? Do you really think the following is at all intuitive? user= (class (Integer/parseInt 1)) java.lang.Long user= (class (Integer/valueOf 1)) java.lang.Integer -Nathan If you box Ints and Longs separately then collection keys stop working, as I said at the start of this thread. There is no such thing as intuitive. The behavior above follows from a clear rule that can be followed locally in all cases. What you propose, in addition to breaking collections, requires more contextual reasoning to understand code in a bunch of scenarios. Could we meet on IRC and discuss this later today? Feel like we are going in circles. Stu -- 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
