Re: Mysterious performance anomalies
On Jan 20, 3:14 am, e evier...@gmail.com wrote: That's a solid arg, too . . . but it would be stronger if we weren't importing things from java all the time. If we said like, (gui-frame hello), which happened to be implemented as a JFrame . . . then that'd be even stronger. Drop in a different REPL and you'd still get a JFrame-like thing even if it weren't from a java lib via a JVM. For me it doesn't make sense to invest in writing a GUI wrapper for Swing (and for SWT, Qt-whatever-was-it's-name) and make it work on a VVM (Virtual Virtual Machine). People who do and know GUI programming now, will find it easier to work with their GUI lib directly, instead of learning one more wrapper. Also there are quite a few differences with GUI libraries, and you'll have to think of a way to wrap these. And in the end you'll end up with imperfect wrapper which will miss specific features from each library it supports. The GUIs done with this wrapper will be most probably uglier or less functional than the ones done with the underlying library directly, so who would want to port them to VVM then? Besides, GUIs aren't the only thing. You can say the same for database access, persistence, sockets, and everything which is not (re) implemented in Clojure. For me, JVM is a good choice. JVM is multiplatform, with very good garbage collector and with tons of libraries. And it's getting better. IIRC, the only major complain Rich has about JVM is the lack of tail-call optimization. -- Ivan --~--~-~--~~~---~--~~ 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 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: Yet another html templating library
Daniel Jomphe a écrit : Stuart Sierra wrote: Very interesting, Christophe. I've been playing with StringTemplate http://www.stringtemplate.org/ lately, but this separates design from code even further. Can it do conditionals, as in if this variable is true, includes this HTML element? Therefore, this feels a bit misleading to me: this separates design from code even further. I just want to point out StringTemplate helps separating design from code, but its main goal is separating the View from Controller and Model in a formally strict way. In the case of enlive, this main goal is not achieved, so it couldn't be done even further. I think you both aren't talking about the same separation: - (To put it in MVC terms) Enlive separates the View into design (plain html, no extra tags, no $..$) and code (clj) - StringTemplate enforces a strict separation of the View from Model and Controller. Christophe --~--~-~--~~~---~--~~ 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 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: Unexpected binding behavior
Doh. Disregard my code example. :-) The reasoning is correct however. Stuart Hi On Tue, Jan 20, 2009 at 7:01 AM, Stuart Halloway stuart.hallo...@gmail.com wrote: Lazy evaluation is a harsh mistress. user= (def b1 (binding [*num* 1024] (f1))) #'user/b1 user= (def b2 (binding [*num* 1024] (f1))) #'user/b2 Did you mean b1 and b2 to have the same definition? If so, I don't understand what you are trying to demonstrate by doing that. user= b1 (16) user= b2 (16) The difference between the example above and your example is the interaction with the REPL. Your f1 is lazy, and is not realized until outside the binding, when the REPL needs it. Your f2, also lazy, is realized inside the binding because of the call to first. I thought this stuff was supposed to be easier to reason about! :) Would it perhaps make sense to save the environment that f1 was called in and use that during the realisation of its result? That would seem to be far more sensible, but maybe there's a reason it would not work. How would one go about fixing f1 (or b1)? -- Michael Wood esiot...@gmail.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com 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: per-defmulti hierarchies
On Jan 20, 12:13 am, Mark Fredrickson mark.m.fredrick...@gmail.com wrote: On the subject of per defmulti hierarchies: The recent CLJOS thread got me thinking about this problem again. While allowing per-multimethod hierarchies solves a large number problems, I think it might be lacking for a class of needs. I think I have solution that can provide for multiple hierarchies and meet this larger class to which I allude. Allow me to provide an illustration. Say I have a step-wise mathematical function. From less than or equal to zero, return zero. From more than zero to less than equal to five, return the value. Above 5, square the value. I could implement that as multimethod: (defmulti stepwise (fn [n] (cond (= 0 n) :zero (and ( n 0) ( n 5)) :zero-five :else :above-five))) (defmethod stepwise :zero [_] 0) (defmethod stepwise :zero-five [x] x) (defmethod stepwise :above-five [x] (* x x)) I've left an intentional programming error in to show how easy it is to make an error with such (cond ...) based dispatch. Yuck. But there is a better way. What if I could supply my own function to decide which key matched the multimethod (not what the key is for the value, but how the key maps to a multimethod). Currently all we have is isa?, but if this were only the default? My example might look something like: (defmulti stepwise identity =) (defmethod stepwise 0 [_] 0) (defmethod stepwise 5 [n] n) (defmethod stepwise :default [n] (* n n)) (prefer-method stepwise 0 5) ; since -1 0 and -1 5 I find this much cleaner, and the subtle error above was been eliminated. And if I want to add another case, its not too hard (though the number of prefer-methods might increase exponentially). This is a rather trivial case, but I think it makes the need clear: per-multi comparison functions. For multiple hierarchies, this would be a common idiom: (defmulti mymulti dispatch-function (fn [object-key method-key] (isa? *my-hiearchy* object-key method-key)) A user could use a ref or atom as needed, no special casing in the Clojure code. What do people think? This seems to me to be a half step towards predicate dispatch. With the a la carte hierarchies freeing us from type-based inheritance, it might be worth someone revisiting Chambers/Chen style predicate dispatch. Rich --~--~-~--~~~---~--~~ 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 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: Patch: Arbitrary Symbols between ||
On Jan 14, 8:47 am, Christian Vest Hansen karmazi...@gmail.com wrote: On Wed, Jan 14, 2009 at 1:59 PM, Rich Hickey richhic...@gmail.com wrote: I am interested insymbolswith arbitrary names, Why is this interesting? It supports working with names from some arbitrary external namespace symbolically. Rich --~--~-~--~~~---~--~~ 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 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: Patch: Arbitrary Symbols between ||
On Jan 14, 10:53 am, Robert Pfeiffer pfeiffer.rob...@googlemail.com wrote: On 14 Jan., 13:59, Rich Hickey richhic...@gmail.com wrote: [...] the toString in the patch is quite inefficient. Becausesymbolsare immutable, they could cache the printable representation in an extra field, but this would double the space occupied by them. Second, it would be better not to replicate the logic for macro characters etc that already exists in the reader. That's not to say the reader stuff is ready for reuse as is, but making it so is the right thing. Issue 13 is related to this. Syntactic validation ofsymbolsin clojure.core/symbol depends on the reader syntax of clojure also. Would this patch eliminate the need to validatesymbols? Are there other constraints than that the printed representation read again should result in the same symbol? Again, I haven't thought this through, but the general idea is to put this logic in a single place. Rich --~--~-~--~~~---~--~~ 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 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 in (try (dosync ...) (finally (dosync ...)))?
On Jan 19, 1:59 pm, John D. Hume duelin.mark...@gmail.com wrote: With the latest from svn, I'm seeing the following weird behavior. (def r (ref :old)) (let [old-value @r] (try (dosync (ref-set r :new)) (finally (dosync (ref-set r old-value)) ))) (println @r is @r) This prints @r is nil whereas I'd expect it to print @r is :old. But the following prints @r is :old as expected: (def r (ref :old)) (let [old-value @r] (try (dosync (ref-set r :new)) (finally old-value ; This line is the only difference (dosync (ref-set r old-value)) ))) (println @r is @r) The only difference is the do-nothing expression old-value that immediately follows the finally. Am I missing something or is this a bug? I realize this is a very weird thing to be doing. In the real world you'd want to have one (dosync ...) block, but this is for a macro for unit tests where I want to be able to restore the proper value of a ref after a test has had a chance to mess it up. Fixed - SVN 1217 - thanks for the report! Rich --~--~-~--~~~---~--~~ 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 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: Mysterious performance anomalies
fyi... non of the bytecode machines made much headway; once you get above a certain (actually fairly small) size device you can afford a tiny JIT - and even a trivial JIT instantly blows away pure bytecode interpreters; to the point that the energy consumed is actually less even counting the JIT cost against you because the resulting code is so much better. Other things a JVM gives you: - Code gen Register allocation - A reliable multi-threaded Memory Model, which otherwise varies from platform to platform, and even within just X86 systems - *fairly* reliable performance; obviously Clojure is walking the edge here - Already mentioned: OS interface, GC/memory allocation, Security, Vast pre-existing libs - Steady engineering providing continuous incremental gains Cliff On Jan 18, 9:31 am, e evier...@gmail.com wrote: I see. From wikipedia: A Jazelle-aware Java Virtual Machinehttp://en.wikipedia.org/wiki/Java_Virtual_Machine(JVM) will attempt to run Java bytecodes in hardware, while returning to the software for more complicated, or lesser-used bytecode operations. ARM claim that approximately 95% of bytecode in typical program usage ends up being directly processed in the hardware. That's awesome. Also, I've only read the title and skimmed here, so far, but it seems relevant:http://blogs.vmware.com/performance/2008/08/esx-runs-java-v.html On Sun, Jan 18, 2009 at 11:48 AM, e evier...@gmail.com wrote: That's a great argument. I need arguments like these. I work with people who dismiss JVM. Even though there are many non-Sun JVM's, folks say, Sun is dead - java is dead - jvm is dead. . even though Java is the most popular language right now. http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html I wonder if there will ever be a JM ... that is a chip that natively executes byte code. I wonder what they'd have to say, then. I think I'll do a Google search. I also wonder if it was a tough decision for Rich to cut the CLI support. I know he feels fine looking back. On Sun, Jan 18, 2009 at 12:23 AM, Mark H. mark.hoem...@gmail.com wrote: On Jan 16, 6:47 am, e evier...@gmail.com wrote: Is it much much easier to make byte code than assembly code? I'll chime in too to say that x86 is only king of the desktop / laptop world -- many portable devices are ARM-based (and a lot of Windows apps run on ARM), and there are other architectures used for enterprise and HPC servers. Plus it's not clear to me that x86 will win, esp. in power-constrained arenas. (All those legacy instructions and the translation from x86 ops into reasonable microops eat power and area.) I've dealt with at least six different instruction sets in my HPC work and the JVM runs on at least five of them: instant portability! mfh --~--~-~--~~~---~--~~ 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 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 -~--~~~~--~~--~--~---
Patch: Make clojure.set/union accept any number of arguments
I have submitted an issue (with patch) today for making clojure.set/ union accept more than two sets. The operation is well defined, and other similar operations in Clojure (+ * concat ...) take multiple arguments as well, so this looks coherent to me. Moreover, I needed the multi-argument version in my code :-) Here is the issue/patch: http://code.google.com/p/clojure/issues/detail?id=52 Konrad. --~--~-~--~~~---~--~~ 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 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: Mysterious performance anomalies
On Jan 20, 12:01 am, ivant itosh...@gmail.com wrote: On Jan 20, 3:14 am, e evier...@gmail.com wrote: That's a solid arg, too . . . but it would be stronger if we weren't importing things from java all the time. If we said like, (gui-frame hello), which happened to be implemented as a JFrame . . . then that'd be even stronger. Drop in a different REPL and you'd still get a JFrame-like thing even if it weren't from a java lib via a JVM. For me it doesn't make sense to invest in writing a GUI wrapper for Swing... Plus other folks have invested the time already in writing cross- platform GUI libs -- the only thing to do is establish cross-language bindings. mfh --~--~-~--~~~---~--~~ 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 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: Unexpected binding behavior
On Mon, Jan 19, 2009 at 11:01 PM, Stuart Halloway stuart.hallo...@gmail.com wrote: Lazy evaluation is a harsh mistress. user= (def b1 (binding [*num* 1024] (f1))) #'user/b1 user= (def b2 (binding [*num* 1024] (f1))) #'user/b2 user= b1 (16) user= b2 (16) The difference between the example above and your example is the interaction with the REPL. Your f1 is lazy, and is not realized until outside the binding, when the REPL needs it. Your f2, also lazy, is realized inside the binding because of the call to first. OK, good, thanks for the explanation. Is it desirable behavior? Is there some case where a programmer wants this behavior? It's pretty scary to have to consider these hidden effects. Sort of the opposite of FP. My gut tells me I want to get the same results evaluating lazily or eagerly, is that reasonable? Doesn't seem practical to use bindings if it can bite you like this. BTW in the actual case that bit me, a function inside another anonymous function, all inside a macro, used the stale value of the Var. IOW it wasn't a case of evaluating at the repl. The f1 I posted here was an attempt to simplify that case, but it's maybe too simple to demonstrate the full problem. Hugh Cheers, Stuart Hi all. Is this a bug or a feature? When I bind the var *num* to a new value, in one case it appears the lambda uses the original value, not the newly bound one. (def *num* 16) (defn f1 [] ( map (fn [x] *num* ) [1])) (defn f2 [] ;; same as f1 but calls first on the map (first ( map (fn [x] *num* ) [1]))) user (f1) (16) --ok user (f2) 16 --ok user (binding [*num* 1024] (f1)) (16) -- expected 1024 user (binding [*num* 1024] (f2)) 1024 --ok after all, in spite of the fact the above gave list (16) Thanks, Hugh --~--~-~--~~~---~--~~ 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 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 -~--~~~~--~~--~--~---
pmap memory hogging
Hi All, Yesterday I had a strange case of pmap (parallel map) eating up all of the heap space I'd make available -- from 256M up to a Gig. I track SVN, I know for sure this wasn't happening last Wednesday (the 14th). Calling map in place of pmap caused the code to run fine inside of a 256M heap. I don't see anything in the SVN logs that looks like the culprit, but the behavior is easy enough to reproduce: user= (def result (map inc (range 100))) #'user/result user= (count result) 100 user= (def result-p (pmap inc (range 100))) java.lang.OutOfMemoryError: Java heap space (NO_SOURCE_FILE:8) Stack trace below. Best to open an issue? Perry user= (.printStackTrace *e) java.lang.OutOfMemoryError: Java heap space (NO_SOURCE_FILE:8) at clojure.lang.Compiler$InvokeExpr.eval(Compiler.java:2700) at clojure.lang.Compiler$DefExpr.eval(Compiler.java:297) at clojure.lang.Compiler.eval(Compiler.java:4180) at clojure.core$eval__3745.invoke(core.clj:1588) at clojure.main$repl__5474$fn__5492.invoke(main.clj:148) at clojure.main$repl__5474.doInvoke(main.clj:145) at clojure.lang.RestFn.invoke(RestFn.java:426) at clojure.main$repl_opt__5516.invoke(main.clj:208) at clojure.main$main__5551$fn__5553.invoke(main.clj:295) at clojure.main$main__5551.doInvoke(main.clj:289) at clojure.lang.RestFn.invoke(RestFn.java:402) at clojure.lang.Var.invoke(Var.java:332) at clojure.lang.AFn.applyToHelper(AFn.java:172) at clojure.lang.Var.applyTo(Var.java:453) at clojure.main.main(main.java:39) Caused by: java.lang.OutOfMemoryError: Java heap space at clojure.core$cycle__3644$thisfn__3646.invoke(core.clj:1457) at clojure.core$cycle__3644$thisfn__3646$fn__3648.invoke (core.clj:1458) at clojure.lang.LazyCons.rest(LazyCons.java:60) at clojure.lang.ASeq.count(ASeq.java:100) at clojure.lang.ASeq.size(ASeq.java:169) at clojure.lang.RT.nth(RT.java:766) at clojure.core$nth__3358.invoke(core.clj:871) at clojure.core$pmap__4904$step__4914.invoke(core.clj:3646) at clojure.core$pmap__4904.invoke(core.clj:3653) at clojure.lang.AFn.applyToHelper(AFn.java:176) at clojure.lang.RestFn.applyTo(RestFn.java:137) at clojure.lang.Compiler$InvokeExpr.eval(Compiler.java:2695) ... 14 more nil user= --~--~-~--~~~---~--~~ 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 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.contrib/repl-utils
I think that the get-source function should be changed slightly so that hyphens in the path (at the first let form) are replaced by underscores. This would update the function to be consistent with the documentation for lib. More generally, are hyphens replaced by underscores in the file and path names for lib purposes? Are there operating systems where xxx-xxx/ yyy-yyy.clj is a problem? Is there any way to report suggestions or little items like this one directly to the author? Such items seem a little out of place when compared to the discussions on language design and other esoteric topics that are covered. Personally, I feel a little uncomfortable suggesting any sort of change or error when it comes to code written by Chris Houser and the other contributors to clojure.contrib. IMHO they are doing an incredible job. I am learning so much reading their code. Thanks again to everyone working on Clojure. --~--~-~--~~~---~--~~ 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 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: Multimethod question
Hi Konrad!
Konrad Hinsen a écrit :
Given the definitions:
(defmulti foo class)
(defmethod foo clojure.lang.IPersistentCollection [_] :a-collection)
(defmethod foo clojure.lang.IPersistentVector [_] :a-vector)
one obtains the following results:
(foo [1 2 3]) - :a-vector
(foo #{1 2 3}) - :a-collection
This looks perfectly logical from an OO point of view, but I cannot
find anything in the documentation (http://clojure.org/multimethods)
that actually promises that the vector implementation of foo takes
precedence over the generic collection version if the argument is a
vector. Can I rely on that or should I add
(prefer-method foo clojure.lang.IPersistentVector
clojure.lang.IPersistentCollection)
explicitly?
user= (ancestors clojure.lang.IPersistentVector)
#{clojure.lang.Sequential clojure.lang.Associative
clojure.lang.IPersistentCollection clojure.lang.Reversible
clojure.lang.IPersistentStack}
Hence clojure.lang.IPersistentVector clearly dominates
clojure.lang.IPersistentCollection: there's no need for prefer-method.
prefer-method http://clojure.org/api#prefer-method is used for
disambiguating in case of multiple matches where neither dominates the
other.
Christophe
--~--~-~--~~~---~--~~
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
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: Yet another html templating library
Christophe Grand wrote: Therefore, this feels a bit misleading to me: this separates design from code even further. I just want to point out StringTemplate helps separating design from code, but its main goal is separating the View from Controller and Model in a formally strict way. In the case of enlive, this main goal is not achieved, so it couldn't be done even further. I think you both aren't talking about the same separation: - (To put it in MVC terms) Enlive separates the View into design (plain html, no extra tags, no $..$) and code (clj) - StringTemplate enforces a strict separation of the View from Model and Controller. Not really. What you perceived as such is because of my bad attempt at saying the following. The html-clj separation is completely distinct from StringTemplate's v- mc separation. Therefore, it feels a bit misleading to compare them using such relation as even further; it diverges one's thinking from either real goal of Enlive or S.T.: Enlive's real goal is, in the View, to separate design and code. In fact, Enlive looks really great here. And ST fares better on this aspect than most other templating libraries, but it's only one of the consequences of enforcing ST's real goal. If one thinks in terms of Enlive goes even further than ST at separating design from code, one might completely overlook the real goal of ST. ST's real goal is to separate the View from Model and Controller (VMC/ MVC). In my understanding, Enlive doesn't try to enforce this at all. Consequently, most projects using Enlive will feature intertwined VMC aspects in the code of their V, because it's really hard not to cross the line. Therefore, if one thinks in terms of Enlive goes even further than ST at separating design from code and thinks of design as V and code as MC, one will end up with a false conclusion. Now, I must confess that I kind of jumped on the issue because I had just read the paper and felt the phrase misleading. I might as well have let it like it is and nobody would have suffered much about it. :) This being said, I didn't doubt that Stuart's intention was to mean literally html-(code-in-the-view) separation. Sorry that it looked like that. --~--~-~--~~~---~--~~ 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 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: Multimethod question
On Jan 20, 2009, at 17:49, Christophe Grand wrote:
user= (ancestors clojure.lang.IPersistentVector)
#{clojure.lang.Sequential clojure.lang.Associative
clojure.lang.IPersistentCollection clojure.lang.Reversible
clojure.lang.IPersistentStack}
Hence clojure.lang.IPersistentVector clearly dominates
clojure.lang.IPersistentCollection: there's no need for prefer-method.
prefer-method http://clojure.org/api#prefer-method is used for
disambiguating in case of multiple matches where neither dominates the
other.
The problem I see is that this domination is nowhere defined or
explained, nor mentioned anywhere except in the documentation of
prefer-method. When reading source code or documentation, I can be
worse than a lawyer ;-)
Konrad.
--~--~-~--~~~---~--~~
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
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: Unexpected binding behavior
OK, good, thanks for the explanation. Is it desirable behavior? Is there some case where a programmer wants this behavior? It's pretty scary to have to consider these hidden effects. Sort of the opposite of FP. If you write functions that work differently depending on a binding, then you are outside FP anyway. And at that point laziness may no longer be your friend. You will need to make sure things happen eagerly. There are probably some opportunities to generalize this with a macro. Stuart --~--~-~--~~~---~--~~ 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 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: Unexpected binding behavior
On Tue, Jan 20, 2009 at 11:45 AM, Stuart Halloway stuart.hallo...@gmail.com wrote: OK, good, thanks for the explanation. Is it desirable behavior? Is there some case where a programmer wants this behavior? It's pretty scary to have to consider these hidden effects. Sort of the opposite of FP. If you write functions that work differently depending on a binding, then you are outside FP anyway. It only works differently depending on a binding under lazy evaluation. Inside FP, outside FP, all I want is no surprises. Hugh --~--~-~--~~~---~--~~ 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 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: Mysterious performance anomalies
On Tuesday 20 January 2009 08:01:19 ivant wrote: IIRC, the only major complain Rich has about JVM is the lack of tail-call optimization. That's a pretty major problem. :-) -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e --~--~-~--~~~---~--~~ 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 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: pmap memory hogging
On Jan 20, 8:36 am, Perry Trolard trol...@gmail.com wrote: Yesterday I had a strange case of pmap (parallel map) eating up all of the heap space I'd make available -- from 256M up to a Gig. I track SVN, I know for sure this wasn't happening last Wednesday (the 14th). Calling map in place of pmap caused the code to run fine inside of a 256M heap. I don't see anything in the SVN logs that looks like the culprit, but the behavior is easy enough to reproduce: user= (def result (map inc (range 100))) #'user/result user= (count result) 100 user= (def result-p (pmap inc (range 100))) java.lang.OutOfMemoryError: Java heap space (NO_SOURCE_FILE:8) Stack trace below. Best to open an issue? Doesn't pmap have to construct the whole sequence explicitly in order to map its execution across more than one processor? or does it take in a lazy fashion? mfh --~--~-~--~~~---~--~~ 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 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: pmap memory hogging
Doesn't pmap have to construct the whole sequence explicitly in order to map its execution across more than one processor? or does it take in a lazy fashion? Semi-lazy, according to the doc: Like map, except f is applied in parallel. Semi-lazy in that the parallel computation stays ahead of the consumption, but doesn't realize the entire result unless required. But I don't think lazyness is the problem: user= (def r (doall (map inc (range 100 #'user/r user= (count r) 100 user= (pmap inc [0]) java.lang.OutOfMemoryError: Java heap space (NO_SOURCE_FILE:0) That is, map's fine with fully realizing a sequence of a million items; pmap consumes all of the heap with a sequence of one item. Perry --~--~-~--~~~---~--~~ 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 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 -~--~~~~--~~--~--~---
Newbie: What is the function of refer-clojure?
I'm trying to get into more of how namespaces work. The refer function refers to all the public variables of a library. What is the point of refer-clojure, though? When would you use it? What variables of clojure.core are not normally present in a new 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 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: What is the function of refer-clojure?
All of them, if you use in-ns: (in-ns 'foo) #Namespace foo str java.lang.Exception: Unable to resolve symbol: str in this context (clojure.core/refer-clojure) - nil str - #core$str__2981 clojure.core$str__2...@bf8aa92 I'm trying to get into more of how namespaces work. The refer function refers to all the public variables of a library. What is the point of refer-clojure, though? When would you use it? What variables of clojure.core are not normally present in a new 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 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: Utilities for clojure.contrib?
A couple more updates to these: (defn random-permutation [s] Return a random permutation of this seq. (let [arr (to-array s) len (alength arr)] (dotimes [i (dec len)] (let [r (+ i (rand-int (- len i))), prev (aget arr i)] (aset arr i (aget arr r)) (aset arr r prev))) (seq arr))) Per [1] this thread, (defn shuffle-java Shuffles coll using a Java ArrayList. Blows shuffle out of the water on speed and space. [coll] (let [l (ArrayList. coll)] (Collections/shuffle l) (seq l))) is both much simpler and much much much faster than my implementation. [1] http://groups.google.com/group/clojure/browse_thread/thread/180842eb58c58370 (defmacro lazy-get Like get but lazy about evaluating the default value [m k d] `(if-let [pair# (find ~m ~k)] (second pair#) ~d)) This should be (defmacro lazy-get Like get but lazy about evaluating the default value [m k d] `(if-let [pair# (find ~m ~k)] (val pair#) ~d)) Changing the second to a val speeds both this and safe-get up by more than a factor of 4! [2] [2] http://w01fe.com/blog/2009/01/more-on-clojure-map-accessor-speeds/ Also, once again (Chouser?), is there anything I can do to help implement the changes we've talked about? I can try to make patches for the changes in core, and/or improve and document other utilities for clojure.contrib, if that would be helpful. Cheers, Jason --~--~-~--~~~---~--~~ 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 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: Unexpected binding behavior
On Jan 20, 10:06 am, Hugh Winkler hwink...@gmail.com wrote: Inside FP, outside FP, all I want is no surprises. I agree, this is confusing for new users. Especially given the counter-intuitive (for a new person) way the REPL forces evaluation of everything, making everything seem to be eager when it's not. This aspect of Clojure is very different from most languages, including other Lisps, and the kinds of errors it can produce are often silent and hard to figure out. Some documentation loudly proclaiming the laziness of map and friends, the importance of dorun/doall/doseq, and the potential pitfalls of laziness would be helpful. Perhaps as an FAQ entry if nothing else? --~--~-~--~~~---~--~~ 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 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: What is the function of refer-clojure?
On Tue, Jan 20, 2009 at 2:59 PM, Stuart Halloway stuart.hallo...@gmail.com wrote: I'm trying to get into more of how namespaces work. The refer function refers to all the public variables of a library. What is the point of refer-clojure, though? When would you use it? What variables of clojure.core are not normally present in a new namespace? All of them, if you use in-ns: (in-ns 'foo) #Namespace foo str java.lang.Exception: Unable to resolve symbol: str in this context (clojure.core/refer-clojure) - nil str - #core$str__2981 clojure.core$str__2...@bf8aa92 While this is true, it's not the primary purpose of 'refer-clojure', since you could instead simply do: (clojure.core/refer 'clojure.core) The reason 'refer-clojure' exists is for use with the 'ns' macro. By default, 'ns' refers all of clojure.core, which is usually what you want. However, if you want to restrict or change any of the clojure.core symbols on their way into your new namespace, you can use :refer-clojure and 'ns' will let you do what you want. Let's say I want a new normal namespace, except without the builtin 'slurp' function: (ns bar (:refer-clojure :exclude (slurp))) bar= slurp java.lang.Exception: Unable to resolve symbol: slurp in this context (NO_SOURCE_FILE:0) Why would I want to do something like this? Perhaps because I want to use a different version of 'slurp': (ns bar (:refer-clojure :exclude (slurp)) (:use [clojure.contrib.mmap :only (slurp)])) bar= str #core$str__2987 clojure.core$str__2...@1ee148b bar= slurp #mmap$slurp__205 clojure.contrib.mmap$slurp__...@7ecd78 Note that 'ns' is meant to be used in .clj files, not at the REPL. --Chouser --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com 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: Utilities for clojure.contrib?
On Tue, Jan 20, 2009 at 3:06 PM, Jason Wolfe jawo...@berkeley.edu wrote: Also, once again (Chouser?), is there anything I can do to help implement the changes we've talked about? I'm sorry, Jason, I really thought I answered this the first time you asked. But I can't find any such answer in the archives, so I must have been mistaken. I can try to make patches for the changes in core, and/or improve and document other utilities for clojure.contrib, if that would be helpful. I think it might be most useful to split up the changes into smaller chunks, perhaps as small as a single function each, or maybe a couple of related functions together. Each of these chunks can be posted as a feature-request on the issues page. This would allow any further discussion of implementation details and any patches to be collected, and would allow Rich to accept or reject each chunk independently. --Chouser --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com 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 -~--~~~~--~~--~--~---
doall vs. dorun
Can someone describe a situation where it is preferable to use doall instead of dorun? I see in the documentation that it retains the head and returns it, thus causing the entire seq to reside in memory at one time, but I'm not sure why I'd want that. -- R. Mark Volkmann Object Computing, Inc. --~--~-~--~~~---~--~~ 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 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: Utilities for clojure.contrib?
I'm sorry, Jason, I really thought I answered this the first time you asked. But I can't find any such answer in the archives, so I must have been mistaken. No worries, thanks for all your help with this. I can try to make patches for the changes in core, and/or improve and document other utilities for clojure.contrib, if that would be helpful. I think it might be most useful to split up the changes into smaller chunks, perhaps as small as a single function each, or maybe a couple of related functions together. Each of these chunks can be posted as a feature-request on the issues page. This would allow any further discussion of implementation details and any patches to be collected, and would allow Rich to accept or reject each chunk independently. OK, I'll get on this then. It this just for changes to core, or should I post proposed functions for contrib there/ on the contrib issues page too? If not, what should I do with them? Thanks! Jason --~--~-~--~~~---~--~~ 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 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 Library Documentation
On Tue, Jan 20, 2009 at 10:09 AM, Mark Addleman mark_addle...@bigfoot.com wrote: I'm a long time Java programmer and, before that, a Smalltalker. One of the major biggest challenges I face when picking up a new language is getting a working understanding of its libraries. I believe that standardizing on a doc format was a pretty important driver for Java's success. As I see it, Java has three natural forms that aid a newbie learning its libraries: Packages, hierarchies and type declarations. Packages and hierarchies give newbies a few good ways of browsing the libraries to gain familiarity and, much more importantly, a way of organizing all those bits of information in our heads. Type declarations serve as a good way of documenting the parameters for methods (e.g. parameter one must respond to well-defined set of messages). I'm willing to forgo the documentation benefits of type declarations to get back to dynamic typing that I enjoyed with Smalltalk but I'm too old to try to read through, memorize and create memes for a new library as rich as Clojure's. At the same time, I think there are enough limitations to JavaDoc to warrant spending a little time trying to come up with a better alternative. I haven't thought my proposal through very well, but here's the idea: a multidimensional relational, categorization system similar to the tagging system seen on blogs or the WikiBadge (http://c2.com/cgi/wiki? WikiBadge) system. The idea goes something like this: Clojure functions could be tagged with any user created tag. Tags can be related to one another through named relations to provide context. For example: Tags: java interop primitive array function Relations: is a A little prolog-ese: is_a(primitive, java_interop) is_a(array_function, primitive) array_function(areduce) With the appropriate logic, a search for is_a(?, java_interop) would yield areduce I suspect that by applying tags to function arguments and with careful definition of relations, a Clojure IDE could perform similarly fancy suggestions and refactorings as modern Java IDEs. I'm throwing this out to the group in an effort to jump start some real documentation efforts. It would be a tremendous boon to Clojure's up-take, I think. I completely agree that some form of categorization of core Clojure functions would be very helpful. For example, which of the hundreds of core functions perform some operation on a string? I started trying to categorize them for my own benefit. See the first table at http://www.ociweb.com/mark/programming/Clojure.html. This isn't yet complete. Stuart H., I think something like this would make a great appendix in your book! -- R. Mark Volkmann Object Computing, Inc. --~--~-~--~~~---~--~~ 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 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: Utilities for clojure.contrib?
On Jan 20, 2009, at 3:36 PM, Jason Wolfe wrote: OK, I'll get on this then. It this just for changes to core, or should I post proposed functions for contrib there/ on the contrib issues page too? If not, what should I do with them? I recommend that proposed changes for clojure-contrib be tracked as clojure-contrib issues. My understanding of the issue policy for Clojure is that Rich would still like to approve them either here or on #clojure (irc) before they're entered. (ref: his recent posting on the topic.) I'm not aware of whether or not he has approved entering issue(s) in this case. By extension, it may make sense to get approval from a member of clojure-contrib before posting an issue there. I think that would work fine for now, but I don't speak for the group. In this case, you appear to have (at least) Chouser's approval for entering clojure-contrib issues related to your post. --Steve smime.p7s Description: S/MIME cryptographic signature
Re: Unexpected binding behavior
On Tue, Jan 20, 2009 at 12:53 AM, Timothy Pratley timothyprat...@gmail.com wrote: How would one go about fixing f1 (or b1)? Depends what you want to achieve... here are two possible 'fixes': ; don't use lazy evaluation (defn f1 [] (doall (map (fn [x] *num* ) [1]))) ; use lazy evaluation, but preserve the binding when the lazy sequence is created (defn f1 [] (let [mynum *num*] (map (fn [x] mynum) [1]))) Yes, these work. They presume the author of f1 knows that the caller is liable to rebind *num*. Is it always going to be unsafe to use Vars in a lazily evaluated function? If so, could the compiler or runtime automate forcing doall or let? I'm understanding better. The caller can also do (binding [*num* 1024] (doall (f1))) The caller doesn't necessarily know he's getting a lazy sequence back, but this would be a boilerplate pattern you use anytime you use binding. Again, could/should Clojure automate doing that? Thanks all for the insights. Hugh --~--~-~--~~~---~--~~ 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 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: Unexpected binding behavior
Hi Hugh, I don't see how this would work in general, which is why a I suggested a special-purpose macro before. Surely you would not want a binding to force all sequences while that binding is in effect. And if not that, what would the general strategy be for deciding which sequences to force, and which not? Stuart On Tue, Jan 20, 2009 at 12:53 AM, Timothy Pratley timothyprat...@gmail.com wrote: How would one go about fixing f1 (or b1)? Depends what you want to achieve... here are two possible 'fixes': ; don't use lazy evaluation (defn f1 [] (doall (map (fn [x] *num* ) [1]))) ; use lazy evaluation, but preserve the binding when the lazy sequence is created (defn f1 [] (let [mynum *num*] (map (fn [x] mynum) [1]))) Yes, these work. They presume the author of f1 knows that the caller is liable to rebind *num*. Is it always going to be unsafe to use Vars in a lazily evaluated function? If so, could the compiler or runtime automate forcing doall or let? I'm understanding better. The caller can also do (binding [*num* 1024] (doall (f1))) The caller doesn't necessarily know he's getting a lazy sequence back, but this would be a boilerplate pattern you use anytime you use binding. Again, could/should Clojure automate doing that? Thanks all for the insights. Hugh --~--~-~--~~~---~--~~ 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 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: doall vs. dorun
Pretty much any lazy-seq thats reading data from somewhere that might give up on you if you take to long. For example: Your using line-seq to read from a socket, but the sequence wont be read through until the user does something. On Tue, Jan 20, 2009 at 3:32 PM, Mark Volkmann r.mark.volkm...@gmail.comwrote: Can someone describe a situation where it is preferable to use doall instead of dorun? I see in the documentation that it retains the head and returns it, thus causing the entire seq to reside in memory at one time, but I'm not sure why I'd want that. -- R. Mark Volkmann Object Computing, Inc. -- -Nate --~--~-~--~~~---~--~~ 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 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: doall vs. dorun
On Jan 20, 3:32 pm, Mark Volkmann r.mark.volkm...@gmail.com wrote: Can someone describe a situation where it is preferable to use doall instead of dorun? Here's one: (defn read-my-file [] (with-open [reader (BufferedReader. (FileReader. my-file.txt))] (doall (line-seq reader line-seq returns a lazy sequence, but you have to consume that sequence before with-open closes the file. -Stuart Sierra --~--~-~--~~~---~--~~ 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 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 Library Documentation
Hello, As modest as this could be in the quest of a formal categorization, I find the integrated string pattern search integrated into clojuredev really useful, so I can't resist to do this shameless plug. You can see it in action, with a search on the word string, either by searching the word in symbol names or also in symbols functions, at this link : http://code.google.com/p/clojure-dev/wiki/ScreenShots#Namespace_Browser_examples What I think makes it really usefull is that it's fast, compared to going to your browser, launching the API page of the clojure website, and searching for the word string through the entire page. And you have the args and doc string as a tooltip when hovering over a symbol. Of course, if some sort of categorization is done on symbols, maybe via a project that could make a pass on existing symbols and enhance their metadata with lists of Strings, this would be an enhancement interesting to incorporate into an IDE (or even a command-line REPL), for sure ! See you, -- Laurent On 20 jan, 21:42, Mark Volkmann r.mark.volkm...@gmail.com wrote: On Tue, Jan 20, 2009 at 10:09 AM, Mark Addleman mark_addle...@bigfoot.com wrote: I'm a long time Java programmer and, before that, a Smalltalker. One of the major biggest challenges I face when picking up a new language is getting a working understanding of its libraries. I believe that standardizing on a doc format was a pretty important driver for Java's success. As I see it, Java has three natural forms that aid a newbie learning its libraries: Packages, hierarchies and type declarations. Packages and hierarchies give newbies a few good ways of browsing the libraries to gain familiarity and, much more importantly, a way of organizing all those bits of information in our heads. Type declarations serve as a good way of documenting the parameters for methods (e.g. parameter one must respond to well-defined set of messages). I'm willing to forgo the documentation benefits of type declarations to get back to dynamic typing that I enjoyed with Smalltalk but I'm too old to try to read through, memorize and create memes for a new library as rich as Clojure's. At the same time, I think there are enough limitations to JavaDoc to warrant spending a little time trying to come up with a better alternative. I haven't thought my proposal through very well, but here's the idea: a multidimensional relational, categorization system similar to the tagging system seen on blogs or the WikiBadge (http://c2.com/cgi/wiki? WikiBadge) system. The idea goes something like this: Clojure functions could be tagged with any user created tag. Tags can be related to one another through named relations to provide context. For example: Tags: java interop primitive array function Relations: is a A little prolog-ese: is_a(primitive, java_interop) is_a(array_function, primitive) array_function(areduce) With the appropriate logic, a search for is_a(?, java_interop) would yield areduce I suspect that by applying tags to function arguments and with careful definition of relations, a Clojure IDE could perform similarly fancy suggestions and refactorings as modern Java IDEs. I'm throwing this out to the group in an effort to jump start some real documentation efforts. It would be a tremendous boon to Clojure's up-take, I think. I completely agree that some form of categorization of core Clojure functions would be very helpful. For example, which of the hundreds of core functions perform some operation on a string? I started trying to categorize them for my own benefit. See the first table athttp://www.ociweb.com/mark/programming/Clojure.html. This isn't yet complete. Stuart H., I think something like this would make a great appendix in your book! -- R. Mark Volkmann Object Computing, Inc. --~--~-~--~~~---~--~~ 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 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: doall vs. dorun
In addition to what others have said, I also tend to use doall when working with agent actions that return sequences (i.e. to force any computation to happen in the agent's thread and not in the caller's) Cheers, Mark On Wed, Jan 21, 2009 at 7:32 AM, Mark Volkmann r.mark.volkm...@gmail.com wrote: Can someone describe a situation where it is preferable to use doall instead of dorun? I see in the documentation that it retains the head and returns it, thus causing the entire seq to reside in memory at one time, but I'm not sure why I'd want that. -- R. Mark Volkmann Object Computing, Inc. --~--~-~--~~~---~--~~ 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 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: Utilities for clojure.contrib?
On Tue, Jan 20, 2009 at 3:55 PM, Stephen C. Gilardi squee...@mac.com wrote: I recommend that proposed changes for clojure-contrib be tracked as clojure-contrib issues. I agree. My understanding of the issue policy for Clojure is that Rich would still like to approve them either here or on #clojure (irc) before they're entered. (ref: his recent posting on the topic.) I'm not aware of whether or not he has approved entering issue(s) in this case. That's a very interesting point. My impression has been that lack of objection from him here (or on IRC) is sufficient approval to post something on the issues page. If he was completely opposed to these proposals, he's had several days to make his opinion known. Of course that's no guarantee that the issue or any particular patch will be approved, but it makes sure that issues and proposed patches aren't lost in archives. Hopefully Rich will clarify his wishes on this. --Chouser --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com 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: Mysterious performance anomalies
On Jan 20, 4:21 pm, Mark H. mark.hoem...@gmail.com wrote: On Jan 20, 9:31 am, Jon Harrop j...@ffconsultancy.com wrote: On Tuesday 20 January 2009 08:01:19 ivant wrote: IIRC, the only major complain Rich has about JVM is the lack of tail-call optimization. That's a pretty major problem. :-) btw, did you ever stop trolling comp.lang.lisp? You were the main reason I figured out how to filter individual names out of a Google Groups feed ;-P Let's keep from making the same mistakes as c.l.l, including calling people trolls. This issue (TCO) is resolved - it's a limitation of the JVM that Clojure accepts. If that is a significant problem for anyone they should either not use Clojure or work on adding TCO to the JVM via the MLVM effort: http://openjdk.java.net/projects/mlvm/ Rich --~--~-~--~~~---~--~~ 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 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: Multiple hashing functions? (+ (update: not a) bug in PersistentHashMap.java?)
And, lest you think that confusing = and .equals is just a noobie mistake, let me point out what seems to be a bug in PersistentHashMap.java I just found based on this same confusion. In particular, Objects are located in the map using Clojure's hash function, which is equivalent to .hashCode (and 0 for nil). But, the equality check done on line 561 is done using Util.equal, which is equivalent to Clojure = ... My apologies, this is not a bug. Util.equals is not the same as Clojure =, I was looking at Util.equiv. Sorry to drag this up again, but just in case anyone was following this I figured I should follow up. Actually, I'd be happy with a single type of hashing compatible with = rather than .equals if the idea of multiple flavors is not popular (as I imagine it probably won't be). Also, I back down on this. Clojure maps implement Java.util.Map, and thus should be using .equals for equality (as they are now). I still might like variants of maps that use identical? or =, but not as the default. -Jason --~--~-~--~~~---~--~~ 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 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: Unexpected binding behavior
That's simpler than the example I was typing up, so I will stop now. :-) Another problem is that you might want the binding to be in effect while defining a sequence, but not while realizing it. Haven't come up with any realistic examples of that, though. Cheers, Stuart Uh oh, I see what you mean Stuart. I made f1 return a list of lists: (defn f1 [] ( map (fn [x] (map (fn [y] *num*) [x])) [1])) user (safe-binding [*num* 1024] (f1)) ((16)) OK, so much for the magic bullet. Hugh --~--~-~--~~~---~--~~ 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 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: Unexpected binding behavior
On Tue, Jan 20, 2009 at 10:54 PM, Hugh Winkler hwink...@gmail.com wrote: but why not make safe the default? i.e. use unsafe-binding if you know it's OK. Not all seqs are finite. Also, Clojure skews toward lazy-by-default. Once a function has run inside a `binding, I would assume that the result it delivers is exactly what it means to deliver. And `map means to deliver a lazy seq. If `binding, however, decided to do something with that result before returning, then I would consider that a side-effect of binding. It would mean that I cannot use `binding that produce a lazy-seq sources from some IO resource or any infinite seq. This safe would probably either do too much work in the wrong thread or blow my heap. From the interaction bellow, I'd probably prefer the style of the 'h function for this kind of situation: user= (def *num* 16) #'user/*num* user= (defn f [] (map (fn [_] *num*) [1])) #'user/f user= (defn g [] (map (constantly *num*) [1])) #'user/g user= (defn h [n] (map (constantly n) [1])) #'user/h user= (binding [*num* 1024] (f)) (16) user= (binding [*num* 1024] (g)) (1024) user= (binding [*num* 1024] (h *num*)) (1024) -- Venlig hilsen / Kind regards, Christian Vest Hansen. --~--~-~--~~~---~--~~ 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 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: doall vs. dorun
On Tue, Jan 20, 2009 at 3:14 PM, Stuart Sierra the.stuart.sie...@gmail.com wrote: On Jan 20, 3:32 pm, Mark Volkmann r.mark.volkm...@gmail.com wrote: Can someone describe a situation where it is preferable to use doall instead of dorun? Here's one: (defn read-my-file [] (with-open [reader (BufferedReader. (FileReader. my-file.txt))] (doall (line-seq reader line-seq returns a lazy sequence, but you have to consume that sequence before with-open closes the file. How is it different if you change doall to dorun? According to their doc strings, they both can be used to force any effects. Walks through the successive rests of the seq -- R. Mark Volkmann Object Computing, Inc. --~--~-~--~~~---~--~~ 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 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: doall vs. dorun
On Jan 20, 2009, at 5:32 PM, Mark Volkmann wrote: Here's one: (defn read-my-file [] (with-open [reader (BufferedReader. (FileReader. my-file.txt))] (doall (line-seq reader line-seq returns a lazy sequence, but you have to consume that sequence before with-open closes the file. How is it different if you change doall to dorun? According to their doc strings, they both can be used to force any effects. Walks through the successive rests of the seq Using doall will cause read-my-file to return a seq of all the lines. dorun will return nil. Here's a simpler example: user= (doall (map #(do (prn %) %) [1 2 3])) 1 2 3 (1 2 3) user= (dorun (map #(do (prn %) %) [1 2 3])) 1 2 3 nil user= (Note the difference in return value.) --Steve smime.p7s Description: S/MIME cryptographic signature
2nd European Lisp Symposium 2009
2nd European Lisp Symposium (ELS 2009) Milan, Italy, May 27-29, 2009 Università degli Studi di Milano-Bicocca New Submission Deadline: * Submission deadline:February 4, 2009 Journal Publication: A selection of accepted research papers will be invited for a special issue of the Journal of Universal Computer Science (J.UCS). Registration Fees: ** * Early registration before April 25, 2008: Students €60, regular €120. * Late registration before May 16, 2008: Students €80, regular €160. * Onsite registration: Students €100, regular €220. Registration will include the proceedings, coffee breaks, lunches, and the symposium dinner. Accommodation is not included. Scope: ** The purpose of the European Lisp Symposium is to provide a forum for the discussion of all aspects of the design, implementation and application of any of the Lisp dialects. We encourage everyone interested in Lisp to participate. The European Lisp Symposium 2009 invites high quality papers about novel research results, insights and lessons learned from practical applications, and educational perspectives, all involving Lisp dialects, including Common Lisp, Scheme, Emacs Lisp, AutoLisp, ISLISP, Dylan, Clojure, and so on. Topics include, but are not limited to: * Language design and implementation techniques * Language integration, interoperation and deployment * Language critique and future directions * Reflection and meta-level architectures * Educational approaches * Software adaptation and evolution * Configuration management * Artificial intelligence * Large and ultra-large-scale systems * Development methodologies * Development support and environments * Persistent systems * Scientific computing * Parallel and distributed computing * Data mining * Semantic web * Dynamic optimization * Innovative applications * Hardware and virtual machine support * Domain-oriented programming * Lisp pearls * Experience reports and case studies We also encourage submissions about past approaches that have been largely forgotten about, as long as they are presented in a new setting. We invite submissions in two categories: original contributions and work-in-progress papers. * Original contributions have neither been published previously nor are under review by other refereed events or publications. Research papers should describe work that advances the current state of the art, or presents old results from a new perspective. Experience papers should be of broad interest and should describe insights gained from substantive practical applications. The program committee will evaluate each contributed paper based on its relevance, significance, clarity, and originality. * Work in progress describes ongoing work that is not ready for publication yet, but would benefit strongly from feedback by other researchers, practitioners and educators. Such contributions will not be published in the symposium proceedings, but will be made available at the symposium website. The work-in-progress track will be organized as a series of writers' workshops where authors work together to improve their papers. Some authors who submit papers for the main track will be suggested to contribute their work in this track instead, if the program committee decides that their submission is not yet ready for a publication. The writers' workshops will take place at the symposium in Milan on May 27, 2008. Program Chair: ** * António Leitão, Technical University of Lisbon, Portugal Local Chair: * Marco Antoniotti, Università Milano Bicocca, Italy Program committee: ** * Giuseppe Attardi, Università di Pisa , Italy * Pascal Costanza, Vrije Universiteit Brussel, Belgium * Irene Durand, Université Bordeaux 1, France * Marc Feeley, Université de Montréal, Canada * Ron Garret, Amalgamated Widgets Unlimited, USA * Gregor Kiczales, University of British Columbia, Canada * Scott McKay, ITA Software, Inc., USA * Peter Norvig, Google Inc., USA * Julian Padget, University of Bath, UK * Kent Pitman, PTC, USA * Christian Queinnec, Université Pierre et Marie Curie, France * Christophe Rhodes, Goldsmiths College, University of London, UK * Robert Strandh, Université Bordeaux 1, France * Mark Tarver, Lambda Associates, UK * Didier Verna, EPITA Research and Development Laboratory, France * JonL White, TheGingerIceCreamFactory of Palo Alto, USA * Taiichi Yuasa, Kyoto University, Japan For more information, see http://european-lisp-symposium.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to
Re: doall vs. dorun
On Tue, Jan 20, 2009 at 4:32 PM, Mark Volkmann r.mark.volkm...@gmail.comwrote: On Tue, Jan 20, 2009 at 3:14 PM, Stuart Sierra the.stuart.sie...@gmail.com wrote: On Jan 20, 3:32 pm, Mark Volkmann r.mark.volkm...@gmail.com wrote: Can someone describe a situation where it is preferable to use doall instead of dorun? Here's one: (defn read-my-file [] (with-open [reader (BufferedReader. (FileReader. my-file.txt))] (doall (line-seq reader line-seq returns a lazy sequence, but you have to consume that sequence before with-open closes the file. How is it different if you change doall to dorun? According to their doc strings, they both can be used to force any effects. Walks through the successive rests of the seq Use dorun when you want to do something purely for the side effects. If you don't need what doall would return then you can use dorun instead to clearly indicate your intent. -- Cosmin Stejerean http://offbytwo.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 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.contrib.sql - Support DataSource in with-connection
I've been using clojure for prototyping in JBoss and I found that
clojure.contrib.sql does not currently support opening JDBC
connections
via a javax.sql.DataSource.
So I propose the patch below.
Cheers,
Juergen
diff --git a/src/clojure/contrib/sql.clj b/src/clojure/contrib/sql.clj
index 75242b5..0141398 100644
--- a/src/clojure/contrib/sql.clj
+++ b/src/clojure/contrib/sql.clj
@@ -24,8 +24,8 @@
(defmacro with-connection
Evaluates body in the context of a new connection to a database
then
- closes the connection. db-spec is a map containing string values
for
- these required keys:
+ closes the connection. db-spec is either a javax.sql.DataSource
+ or a map containing string values for these required keys:
:classname the jdbc driver class name
:subprotocol the jdbc subprotocol
:subname the jdbc subname
diff --git a/src/clojure/contrib/sql/internal.clj b/src/clojure/
contrib/sql/internal.clj
index 9f1aca7..29c7791 100644
--- a/src/clojure/contrib/sql/internal.clj
+++ b/src/clojure/contrib/sql/internal.clj
@@ -50,26 +50,37 @@
([val]
(swap! (:rollback-only *db*) (fn [_] val
-(defn with-connection*
- Evaluates func in the context of a new connection to a database
then
- closes the connection. db-spec is a map containing string values
for
- these required keys:
-:classname the jdbc driver class name
-:subprotocol the jdbc subprotocol
-:subname the jdbc subname
- If db-spec contains additional keys (such as :user, :password,
etc.) and
- associated values, they will be passed along to the driver as
properties.
- [{:keys [classname subprotocol subname] :as db-spec} func]
- (clojure.lang.RT/loadClassForName classname)
- (with-open
- [con
- (java.sql.DriverManager/getConnection
-(format jdbc:%s:%s subprotocol subname)
-(properties (dissoc db-
spec :classname :subprotocol :subname)))]
+(defn- with-open-connection [con func]
+ (with-open [con con]
(binding [*db* (assoc *db* :connection con :level 0
:rollback-only (atom false))]
(func
+(defmulti
+ #^{:doc
+ Evaluates body in the context of a new connection to a database
then
+ closes the connection. db-spec is either a javax.sql.DataSource
+ or a map containing string values for these required keys:
+ :classname the jdbc driver class name
+ :subprotocol the jdbc subprotocol
+ :subname the jdbc subname
+ If db-spec contains additional keys (such as :user, :password,
etc.) and
+ associated values, they will be passed along to the driver as
properties.}
+ with-connection* (fn [spec func] (class spec)))
+
+(defmethod with-connection* javax.sql.DataSource
+ [ds func]
+ (with-open-connection (.getConnection ds) func))
+
+(defmethod with-connection* :default
+ [{:keys [classname subprotocol subname] :as db-spec} func]
+(clojure.lang.RT/loadClassForName classname)
+(with-open-connection
+ (java.sql.DriverManager/getConnection
+(format jdbc:%s:%s subprotocol subname)
+(properties (dissoc db-
spec :classname :subprotocol :subname)))
+ func))
+
(defn transaction*
Evaluates func as a transaction on the open database connection.
Any
nested transactions are absorbed into the outermost transaction. All
--~--~-~--~~~---~--~~
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
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: doall vs. dorun
Thanks Steve and Cosmin! I understand it now. On Tue, Jan 20, 2009 at 4:53 PM, Stephen C. Gilardi squee...@mac.com wrote: On Jan 20, 2009, at 5:32 PM, Mark Volkmann wrote: Here's one: (defn read-my-file [] (with-open [reader (BufferedReader. (FileReader. my-file.txt))] (doall (line-seq reader line-seq returns a lazy sequence, but you have to consume that sequence before with-open closes the file. How is it different if you change doall to dorun? According to their doc strings, they both can be used to force any effects. Walks through the successive rests of the seq Using doall will cause read-my-file to return a seq of all the lines. dorun will return nil. Here's a simpler example: user= (doall (map #(do (prn %) %) [1 2 3])) 1 2 3 (1 2 3) user= (dorun (map #(do (prn %) %) [1 2 3])) 1 2 3 nil user= (Note the difference in return value.) --Steve -- R. Mark Volkmann Object Computing, Inc. --~--~-~--~~~---~--~~ 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 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] Dejcartes
Mark,
Thanks for doing this, I haven't had a chance to look at it yet but its been
on the wish list for a while.
Cheers
Tom
2009/1/20 Mark Fredrickson mark.m.fredrick...@gmail.com
Hello friends,
I would like to announce a super-pre-alpha release of Dejcartes, a
Clojure wrapper around the JFreeChart charting library. From the readme:
Dejcartes is a Clojure interface to the JFreeChart charting and graphing
library. A simple interface to be sure, but practical for graphing
many data
sources. Dejcartes is mostly a wrapper around the ChartFactory static
methods.
This interface suits Clojure's functional paradigm very well.
Chart supports using native Clojure collections for data sources. This
makes
graphing from Clojure applications very intuitive. Lists, vectors, and
hash-maps are translated into JFreeChart's native data types behind
the scenes
as needed. A demo showing many of the supported functions and Clojure
native data
structures is included and can be run from the command line with ant
demo. Here
is a brief excerpt:
(require '[com.markmfredrickson.dejcartes :as chart])
;; a simple function for making windows -- wrapper coming soon
(import '(org.jfree.chart chartframe))
(defn make-window [title chart]
(doto (new chartframe title chart)
(.pack)
(.setvisible true)))
; first, some categorical data
(def editor-survey
{2009
{emacs 312 vim 234 eclipse 193 netbeans 82 other 26}
2008
{vim 192 emacs 267 eclipse 297 other 75}})
;; a pie chart of the 2009 data
(make-window Editor Survey
(chart/pie 2009 Results (editor-survey 2009)))
Dejcartes is a young project and is lacking in comprehensive
documentation. The
best reference right now is the demo.clj example code and the
JFreeChart API
documentation. Future improvements will include more documentation, an
Agent
based interface for interacting with chart windows, and a persistent
(read:
non-mutating) interface for annotations and other more powerful chart
features.
Dejcartes is licensed under the GNU Lesser GPL, which is consistent with
JFreeChart's license.
The code can be found at: http://www.markmfredrickson.com/code/
Best wishes,
- Mark Fredrickson
mark.m.fredrick...@gmail.com
http://www.markmfredrickson.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
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: Mysterious performance anomalies
On Jan 20, 1:41 pm, Rich Hickey richhic...@gmail.com wrote: Let's keep from making the same mistakes as c.l.l, including calling people trolls. Sorry, yes Rich, I will refrain from using such titles in the future. mfh --~--~-~--~~~---~--~~ 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 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 -~--~~~~--~~--~--~---
Multimethod Reflection?
Looking at the multimethod implementation (MultiFn.java) I noticed that multimethod keeps an internal persistent map of dispatch values in a field call methodTable. It seems to me it would pretty simple to expose this field (or a copy of it anyway) so that multimethod reflection can take place. (responds? astruct amultifn) It's seems to me to be a minor change that would add a considerable amount of reflective power to multimethods, as well providing support for something like who-specializes in SLIME or any other IDE. Thoughts? --~--~-~--~~~---~--~~ 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 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: pmap memory hogging
On Jan 20, 1:38 pm, Perry Trolard trol...@gmail.com wrote: Doesn't pmap have to construct the whole sequence explicitly in order to map its execution across more than one processor? or does it take in a lazy fashion? Semi-lazy, according to the doc: Like map, except f is applied in parallel. Semi-lazy in that the parallel computation stays ahead of the consumption, but doesn't realize the entire result unless required. But I don't think lazyness is the problem: user= (def r (doall (map inc (range 100 #'user/r user= (count r) 100 user= (pmap inc [0]) java.lang.OutOfMemoryError: Java heap space (NO_SOURCE_FILE:0) Regression in SVN 1215 - fixed in SVN 1218 - thanks for the report! Rich --~--~-~--~~~---~--~~ 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 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 -~--~~~~--~~--~--~---
Proposal: smarter set operations that take size into account for speed
I ran into a situation in my application where I wanted to take a set- difference between a small set and a large set. In this circumstance, clojure.set/difference is needlessly slow. Because of this, in general, a sequence of n clojure.set operations may run in O(n^2) time when O(n) is easily achievable. Here's the basic idea: (defn difference2 Like difference, but fast for big s2 and small s1 [s1 s2] (reduce (fn [result item] (if (contains? s2 item) (disj result item) result)) s1 s1)) (defn fast-difference Like difference, but faster. [s1 s2] (let [c1 (int (count s1)) c2 (int (count s2))] (if ( c1 c2) (difference2 s1 s2) (clojure.set/difference s1 s2 user (let [small-set (hash-set 1), big-set (set (range 1))] (doseq [fn [clojure.set/difference difference2 fast-difference] [s1 s2] [[small-set big-set] [big-set small-set]]] (time (dotimes [_ 1000] (fn s1 s2) Elapsed time: 3995.249 msecs ; (set/difference small big) Elapsed time: 3.358 msecs ; (set/difference big small) Elapsed time: 1.91 msecs ; (difference2 small big) Elapsed time: 4935.183 msecs ; (difference2 big small) Elapsed time: 3.088 msecs ; (fast-difference small big) Elapsed time: 3.401 msecs ; (fast-difference big small) For the commutative operations (union and intersection), I suppose you could argue that the user should know how the operations work and put the arguments in the right (fast) order -- but sometimes, that information will only be known at runtime. Overall, the possibility of a big O improvement for a small constant penalty seems worth it to me. Questions or comments? Any objections/support for me adding this as an issue? Thanks, Jason --~--~-~--~~~---~--~~ 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 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.sql - Support DataSource in with-connection
On Jan 20, 2009, at 6:16 PM, Juergen Gmeiner wrote: I've been using clojure for prototyping in JBoss and I found that clojure.contrib.sql does not currently support opening JDBC connections via a javax.sql.DataSource. So I propose the patch below. Hi Juergen, I'd like for clojure.contrib.sql to support DataSource. As an alternative implementation, what do you think of db-spec allowing a :datasource key. If :datasource is specified, with-connection could use its value to acquire the connection, possibly along with :username and :password if they are specified. If not, it would connect using the jdbc URL parts as it does now. I think it makes sense to prefer :datasource if it's present because according to recent jdbc docs, DataSource is preferred over DriverManager as a way of acquiring a connection. --Steve smime.p7s Description: S/MIME cryptographic signature
Re: Utilities for clojure.contrib?
On Jan 20, 4:15 pm, Chouser chou...@gmail.com wrote: On Tue, Jan 20, 2009 at 3:55 PM, Stephen C. Gilardi squee...@mac.com wrote: I recommend that proposed changes for clojure-contrib be tracked as clojure-contrib issues. I agree. My understanding of the issue policy for Clojure is that Rich would still like to approve them either here or on #clojure (irc) before they're entered. (ref: his recent posting on the topic.) I'm not aware of whether or not he has approved entering issue(s) in this case. That's a very interesting point. My impression has been that lack of objection from him here (or on IRC) is sufficient approval to post something on the issues page. If he was completely opposed to these proposals, he's had several days to make his opinion known. Of course that's no guarantee that the issue or any particular patch will be approved, but it makes sure that issues and proposed patches aren't lost in archives. Hopefully Rich will clarify his wishes on this. Yes, proposed changes to clojure-contrib should be discussed here first. If a member of clojure-contrib approves, they should become clojure-contrib issues, and any related patches attached to such issues. clojure-contrib members can incorporate (or not!) those patches (when coming from registered contributors), check them in, and resolve the issues. I.e., I am trusting the members of clojure-contrib to be its stewards. If I think something is off track I'll chime in. Thanks all for your help and effort! Rich --~--~-~--~~~---~--~~ 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 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: Proposal: smarter set operations that take size into account for speed
One caveat: I do like the fact that the set operations currently don't require the second argument to be a set. In the case that it's not, I believe the current implementations (at least for difference) are as good as it gets. So, I guess fast-difference should read: (defn fast-difference Like difference, but faster. [s1 s2] (if (or (not (set? s2)) ( (int (count s1)) (int (count s2 (clojure.set/difference s1 s2) (difference2 s1 s2))) -Jason --~--~-~--~~~---~--~~ 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 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: Utilities for clojure.contrib?
On Jan 20, 4:15 pm, Chouser chou...@gmail.com wrote: On Tue, Jan 20, 2009 at 3:55 PM, Stephen C. Gilardi squee...@mac.com wrote: I recommend that proposed changes for clojure-contrib be tracked as clojure-contrib issues. I agree. My understanding of the issue policy for Clojure is that Rich would still like to approve them either here or on #clojure (irc) before they're entered. (ref: his recent posting on the topic.) I'm not aware of whether or not he has approved entering issue(s) in this case. That's a very interesting point. My impression has been that lack of objection from him here (or on IRC) is sufficient approval to post something on the issues page. If he was completely opposed to these proposals, he's had several days to make his opinion known. Of course that's no guarantee that the issue or any particular patch will be approved, but it makes sure that issues and proposed patches aren't lost in archives. Hopefully Rich will clarify his wishes on this. Yes, proposed changes to clojure-contrib should be discussed here first. If a member of clojure-contrib approves, they should become clojure-contrib issues, and any related patches attached to such issues. clojure-contrib members can incorporate (or not!) those patches (when coming from registered contributors), check them in, and resolve the issues. Thanks Rich. But, I think this answers only one of the questions at hand (about clojure.contrib issues). The other question (to which I think Chouser was referring above) was about issues for Clojure core, and whether or not an explicit sign-off from you was desired before they are posted there. This came up in this thread since after discussing with Chouser, several of my utilities seemed better-suited as changes/additions to Clojure core rather than contrib. -Jason --~--~-~--~~~---~--~~ 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 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: pmap memory hogging
On Jan 20, 10:38 am, Perry Trolard trol...@gmail.com wrote: But I don't think lazyness is the problem: user= (def r (doall (map inc (range 100 #'user/r user= (count r) 100 user= (pmap inc [0]) java.lang.OutOfMemoryError: Java heap space (NO_SOURCE_FILE:0) Hm, that's funny, the latter works just fine for me: it returns (1). With what options are you starting java? and what JVM is it? java - version on my machine (Linux x86_64) returns java version 1.6.0_10 Java(TM) SE Runtime Environment (build 1.6.0_10-b33) Java HotSpot(TM) 64-Bit Server VM (build 11.0-b15, mixed mode) and I start java with the following options (not counting the classpath): java -server -Xdebug - Xrunjdwp:transport=dt_socket,server=y,suspend=n,address= mfh --~--~-~--~~~---~--~~ 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 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: Another socket repl
Craig McDaniel craig...@gmail.com writes: On Jan 19, 11:45 am, Phil Hagelberg p...@hagelb.org wrote: I noticed that very little of this code is specific to the REPL; the bulk of it is just dealing with creating and doing things with server sockets. Perhaps it could be included in clojure-contrib as a generalized server-sockets library if instead of calling (repl) it could take an optional argument for a different function to use? Thanks, that's a good point. I'm posting a new file server-socket.clj that is more generic and includes the REPL as an example case. I just rewrote part of my app to take advantage of this new library; it's been very useful for moving the dirty details out of my code. I wonder if it wouldn't be a good idea to move the call to binding from socket-repl into accept-fn. It seems like a reasonable default to rebind *in* and *out* for the duration of the accepting function; the example uses this as does my application. If this is desired, I can put together a patch and create an issue for it. -Phil --~--~-~--~~~---~--~~ 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 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: Multimethod Reflection?
On Jan 20, 6:48 pm, David Nolen dnolen.li...@gmail.com wrote: Looking at the multimethod implementation (MultiFn.java) I noticed that multimethod keeps an internal persistent map of dispatch values in a field call methodTable. It seems to me it would pretty simple to expose this field (or a copy of it anyway) so that multimethod reflection can take place. (responds? astruct amultifn) It's seems to me to be a minor change that would add a considerable amount of reflective power to multimethods, as well providing support for something like who-specializes in SLIME or any other IDE. Thoughts? Fine idea - try SVN 1219 ;) Rich --~--~-~--~~~---~--~~ 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 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: Multimethod Reflection?
Thanks! On Tue, Jan 20, 2009 at 7:28 PM, Rich Hickey richhic...@gmail.com wrote: On Jan 20, 6:48 pm, David Nolen dnolen.li...@gmail.com wrote: Looking at the multimethod implementation (MultiFn.java) I noticed that multimethod keeps an internal persistent map of dispatch values in a field call methodTable. It seems to me it would pretty simple to expose this field (or a copy of it anyway) so that multimethod reflection can take place. (responds? astruct amultifn) It's seems to me to be a minor change that would add a considerable amount of reflective power to multimethods, as well providing support for something like who-specializes in SLIME or any other IDE. Thoughts? Fine idea - try SVN 1219 ;) Rich --~--~-~--~~~---~--~~ 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 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: pmap memory hogging
On Jan 20, 8:36 am, Perry Trolard trol...@gmail.com wrote: Yesterday I had a strange case of pmap (parallel map) eating up all of the heap space I'd make available -- from 256M up to a Gig. I track SVN, I know for sure this wasn't happening last Wednesday (the 14th). Calling map in place of pmap caused the code to run fine inside of a 256M heap. I just fetched Clojure from SVN and restricted the heap size (both initial and max) to 256 MB, and your examples work for me: user (count (pmap inc (range 100))) 100 user (def result (map inc (range 100))) #'user/ result user (count result) 100 user (def result-p (pmap inc (range 100))) #'user/result- p user (count result- p) 100 The last (count result-p) call takes a few seconds (probably because there's a one-to-one mapping of tasks to sequence elements) but it finishes. Strange! mfh --~--~-~--~~~---~--~~ 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 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: Utilities for clojure.contrib?
On Jan 20, 2009, at 7:16 PM, Jason Wolfe wrote: On Jan 20, 4:15 pm, Chouser chou...@gmail.com wrote: On Tue, Jan 20, 2009 at 3:55 PM, Stephen C. Gilardi squee...@mac.com wrote: I recommend that proposed changes for clojure-contrib be tracked as clojure-contrib issues. I agree. My understanding of the issue policy for Clojure is that Rich would still like to approve them either here or on #clojure (irc) before they're entered. (ref: his recent posting on the topic.) I'm not aware of whether or not he has approved entering issue(s) in this case. That's a very interesting point. My impression has been that lack of objection from him here (or on IRC) is sufficient approval to post something on the issues page. If he was completely opposed to these proposals, he's had several days to make his opinion known. Of course that's no guarantee that the issue or any particular patch will be approved, but it makes sure that issues and proposed patches aren't lost in archives. Hopefully Rich will clarify his wishes on this. Yes, proposed changes to clojure-contrib should be discussed here first. If a member of clojure-contrib approves, they should become clojure-contrib issues, and any related patches attached to such issues. clojure-contrib members can incorporate (or not!) those patches (when coming from registered contributors), check them in, and resolve the issues. Thanks Rich. But, I think this answers only one of the questions at hand (about clojure.contrib issues). The other question (to which I think Chouser was referring above) was about issues for Clojure core, and whether or not an explicit sign-off from you was desired before they are posted there. This came up in this thread since after discussing with Chouser, several of my utilities seemed better-suited as changes/additions to Clojure core rather than contrib. I didn't find any of them compelling enough for core just yet. Putting them in contrib first lets people try them out and refine them, point out redundancies and conflicts etc. As a general rule I haven't pulled many simple combining functions from contrib, as they just pollute the namespaces. Plus, I don't think things are as cut and dried as you make out, for instance I'd expect map-when and iterate-while to take predicates. Rich --~--~-~--~~~---~--~~ 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 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: Proposal: smarter set operations that take size into account for speed
Apologies for multiple posts; I will try to thoroughly investigate things before starting posting next time. Anyway, to round out the thread, here are corresponding results for intersection and union: (defn- fast-intersection- Expects s1 and s2 sets, s1 bigger than s2. [s1 s2] (reduce (fn [result item] (if (contains? s1 item) result (disj result item))) s2 s2)) (defn fast-intersection Like intersection, but faster. [s1 s2] (if (or (not (set? s2)) ( (int (count s1)) (int (count s2 (fast-intersection- s1 s2) (fast-intersection- s2 s1))) user (let [small-set (hash-set 1), big-set (set (range 1))] (doseq [fn [clojure.set/intersection fast-intersection] [s1 s2] [[small-set big-set] [big-set small-set]]] (time (dotimes [_ 1000] (fn s1 s2) Elapsed time: 3976.334 msecs ; (clojure.set/intersection small big) Elapsed time: 18059.634 msecs ; (clojure.set/intersection big small) Elapsed time: 9.68 msecs ; (fast-intersection small big) Elapsed time: 7.598 msecs ; (fast-intersection big small) As you can see, it looks like clojure.set/intersection is fast for *neither* ordering of sets if they are of disparate size. (defn fast-union Like union, but faster. [s1 s2] (if (or (not (set? s2)) ( (int (count s1)) (int (count s2 (reduce conj s1 s2) (reduce conj s2 s1))) user (let [small-set (hash-set 1), big-set (set (range 1))] (doseq [fn [clojure.set/union fast-union] [s1 s2] [[small-set big-set] [big-set small-set]]] (time (dotimes [_ 1000] (fn s1 s2) Elapsed time: 20444.035 msecs ; (clojure.set/union small big) Elapsed time: 0.956 msecs ; (clojure.set/union big small) Elapsed time: 2.906 msecs ; (fast-union small big) Elapsed time: 2.826 msecs ; (fast-union big small) And, finally, clojure.set/union is fast for one order of arguments but (especially) slow for the other. -Jason --~--~-~--~~~---~--~~ 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 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: Utilities for clojure.contrib?
I didn't find any of them compelling enough for core just yet. Putting them in contrib first lets people try them out and refine them, point out redundancies and conflicts etc. As a general rule I haven't pulled many simple combining functions from contrib, as they just pollute the namespaces. Plus, I don't think things are as cut and dried as you make out, for instance I'd expect map-when and iterate-while to take predicates. Fair enough, I would be happy with those in contrib. The main things I'd like to see in core are: - 0-arg distinct? returns true, not an exception (so (apply distinct? nil) = true) - rewrite concat so that (apply concat seq) doesn't evaluate the first three elements of seq - make every?, not-every?, some, not-any? take multiple seq args like map, i.e., (every? not= [1 2 3] [2 3 4]) - allow arguments to merge-with after the first to be lists of pairs. More details on each of these are above. None of these affect the existing functionality of these core functions, and it doesn't seem to make sense to create new versions in clojure.contrib just to add the new functionality. Will you accept issues for any of these? Thanks, Jason --~--~-~--~~~---~--~~ 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 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 -~--~~~~--~~--~--~---
What's best way to get rid of #File?
Hi I would just print the files, excluding #File and . what's the best way? user= (filter recently-modified? (file-seq (File. .))) (#File . #File ./.my-hints.clj.swn #File ./my-hints.clj) Thanks -Sun --~--~-~--~~~---~--~~ 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 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: Proposal: smarter set operations that take size into account for speed
On Jan 20, 4:44 pm, Jason Wolfe jawo...@berkeley.edu wrote:
Apologies for multiple posts; I will try to thoroughly investigate
things before starting posting next time. Anyway, to round out the
thread, here are corresponding results for intersection and union:
Well, that didn't last too long ... from now on ... :) Anyway, there
was a bug in fast-intersection when s2 was not a set. Fixed version:
(defn fast-intersection Like intersection, but faster. [s1 s2]
(cond (not (set? s2))
(reduce (fn [result item]
(if (contains? s1 item)
(conj result item)
result))
#{} s2)
( (int (count s1)) (int (count s2)))
(fast-intersection- s1 s2)
:else
(fast-intersection- s2 s1)))
-Jason
--~--~-~--~~~---~--~~
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
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---
Re: What's best way to get rid of #File?
On Jan 20, 2009, at 8:42 PM, wubbie wrote: Hi I would just print the files, excluding #File and . what's the best way? user= (filter recently-modified? (file-seq (File. .))) (#File . #File ./.my-hints.clj.swn #File ./my-hints.clj) http://java.sun.com/j2se/1.5.0/docs/api/java/io/File.html#getName() Thanks -Sun --~--~-~--~~~---~--~~ 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 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.sql - Support DataSource in with-connection
On Jan 20, 2009, at 7:01 PM, Stephen C. Gilardi wrote: I'd like for clojure.contrib.sql to support DataSource. As an alternative implementation, what do you think of db-spec allowing a :datasource key. If :datasource is specified, with-connection could use its value to acquire the connection, possibly along with :username and :password if they are specified. If not, it would connect using the jdbc URL parts as it does now. I've checked in an implementation for this. I confirmed that it doesn't harm the jdbc url method of connecting, but I don't have a DataSource setup to test the DataSource method. Juergen, I'd appreciate hearing whether or not this works for you. Thanks, --Steve smime.p7s Description: S/MIME cryptographic signature
Re: Proposal: smarter set operations that take size into account for speed
I say thumbs up to this proposal. Sets really should test for the size of the two inputs, and adjust the algorithm accordingly. --~--~-~--~~~---~--~~ 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 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: repl-utils show
On Mon, Jan 19, 2009 at 1:09 PM, Stuart Sierra
the.stuart.sie...@gmail.com wrote:
On Jan 19, 11:59 am, Chouser chou...@gmail.com wrote:
But my version also only allows matches on the method name (not on
return value or argument class names). At first I thought this was
also good, but now I'm less sure. How often do you think you'd want
to be able to search on a method's argument names, vs. how many
unhelpful matches you'd get doing (show String string) ? Opintions?
Would it be possible to separate show into two functions, one of
which returns a sequence of method signatures and another which prints
them? Then you could filter the sequence however you like.
As of SVN 397, show accepts a string, regex, or predicate in addition
to still accepting a number for its second arg. The number works as
before, returning the member object itself.
A string or regex will act as a case-insensitive filter on the name of
the member:
user= (show Thread stop) ; all members named stop
=== public java.lang.Thread ===
[54] stop : void ()
[55] stop : void (Throwable)
nil
user= (show Thread #^\w{5}$) ; all members with 5-letter names
=== public java.lang.Thread ===
[12] static sleep : void (long)
[13] static sleep : void (long,int)
[14] static yield : void ()
[29] getId : long ()
[53] start : void ()
nil
I find it very unlikely that anyone would bother being any more
specific than this. But just in case, you can also provide a
predicate function:
; all methods that take exactly two ints
user= (show Integer #(re-seq #\(int,int\) (:text %)))
=== public final java.lang.Integer ===
[17] static rotateLeft : int (int,int)
[18] static rotateRight : int (int,int)
[24] static toString : String (int,int)
nil
The predicate takes a map based on the 'bean' of the member object,
but with :text and :member keys added. The :text is what will be
printed, the :member is the original member object itself. It ends up
looking like this:
{:name intValue,
:text intValue : int (),
:class java.lang.reflect.Method,
:member #Method public int java.lang.Integer.intValue(),
:returnType int,
:accessible false,
:annotations #Annotation[] [Ljava.lang.annotation.Annotation;@46d228,
:bridge false,
:declaredAnnotations #Annotation[] [Ljava.lang.annotation.Annotation;@46d228,
:declaringClass java.lang.Integer,
:defaultValue nil,
:exceptionTypes #Class[] [Ljava.lang.Class;@182ef6b,
:genericExceptionTypes #Class[] [Ljava.lang.Class;@1980630,
:genericParameterTypes #Class[] [Ljava.lang.Class;@e34726,
:genericReturnType int,
:modifiers 1,
:parameterAnnotations #Annotation[][]
[[Ljava.lang.annotation.Annotation;@e99681,
:parameterTypes #Class[] [Ljava.lang.Class;@1d32e45,
:sort-val [true true intValue : int ()],
:synthetic false,
:typeParameters #TypeVariable[] [Ljava.lang.reflect.TypeVariable;@1e12f6d,
:varArgs false}
Thank you all for you input.
--Chouser
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Clojure group.
To post to this group, send email to clojure@googlegroups.com
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/repl-utils
On Tue, Jan 20, 2009 at 11:42 AM, pc peng2che...@yahoo.com wrote: I think that the get-source function should be changed slightly so that hyphens in the path (at the first let form) are replaced by underscores. This would update the function to be consistent with the documentation for lib. You're right. More generally, are hyphens replaced by underscores in the file and path names for lib purposes? Are there operating systems where xxx-xxx/ yyy-yyy.clj is a problem? My understanding is that it's not the file or directory name that's a problem, but rather that these map to Java package and class names. Java does not allow deashes in either, presumably because they aren't legal in Java identifiers; they'd look like subtraction operators. Is there any way to report suggestions or little items like this one directly to the author? Such items seem a little out of place when compared to the discussions on language design and other esoteric topics that are covered. Personally, I feel a little uncomfortable suggesting any sort of change or error when it comes to code written by Chris Houser and the other contributors to clojure.contrib. This is the best place to report any size bug or issue. Thanks for catching this one! It's fixed in clojure-contrib svn rev 399. --Chouser --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com 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 -~--~~~~--~~--~--~---
