Re: Trying to use lazy-seq for the first time, failing.
Harold, Do you have any material on Factor? I won't going through it. Regards, Emeka On Sat, Jun 27, 2009 at 12:23 AM, _hrrld wrote: > > Hi, > > I'm trying to use lazy-seq to implement a cool piece of functionality > I saw in the Factor programming language. Here is the documentation > for that functionality: > http://docs.factorcode.org/content/word-produce,sequences.html > > I think a lazy version of Factor's "produce" word would be super- > powerful for some of the things I'm working on. > > This is the first time I've tried to create my own lazy sequence, so > don't laugh. > > Here is my attempt: > http://gist.github.com/136825 > > For some reason, the lazy sequence that is returned is always empty > (?) or at least seems that way. > > Am I doing something silly? Or perhaps I've misunderstood lazy-seq's > operation. > > Thanks in advance for any advice, > -Harold > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Hash Consing
Dear all, I am coding a (very) small hash consing library for clojure. For those we don't happen to know what hash consing is, it is a way of allowing equal data structures to be shared in memory. This leverages the purity (as in "immutability") of data structures to reduce memory footprint (no duplication of data for just a constant overhead per allocation) and makes hashing and equality tests faster. (You can use java non overloaded hashCode, and == to test equality, because of the sharing. So both operations are O(1), with a very small constant, whatever is the complexity of the hash consed data structures.) This can then be used, in combination with referential transparency to make memoized function faster. I have a java file and a clojure interface that seem to work, at least on my example. I plan to put something somewhere someday, but before spending too much time in making this releasable, i Have a few questions: - does something already exists in contrib that I have missed? - is someone else working on that? - are there any "features that I need and that you must implement" that you think of? My current plans are: - using a java concurrent hash map to soft referenced objects for the hash consing table. - only two fields in an hash consed object: the value it represents, and a generic field called "cached_data" used to store anything you want to memoize about this data structure. (Keeping this cached data a bit longer is the reason I plan to use soft references and not weak references) I am not a clojure expert and I am not a java coder at all, so don't hesitate to tell me if my plans are somehow wrong. Bets regards, Nicolas. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Hash Consing
On Jun 29, 3:09 pm, Nicolas Oury wrote: > Dear all, > > I am coding a (very) small hash consing library for clojure. > > For those we don't happen to know what hash consing is, it is a way of > allowing equal data structures to be shared in memory. > This leverages the purity (as in "immutability") of data structures to > reduce memory footprint (no duplication of data for just a constant > overhead per allocation) and makes hashing and equality tests faster. > (You can use java non overloaded hashCode, and == to test equality, > because of the sharing. So both operations are O(1), with a very small > constant, whatever is the complexity of the hash consed data > structures.) I don't know anything about hash consing. Based on my limited understanding of the description I am just wondering if this is different from structural sharing that Clojure collections have. Quoting the docs[1]: " In particular, the Clojure collections support efficient creation of 'modified' versions, by utilizing structural sharing, and make all of their performance bound guarantees for persistent use. " Do you have something different in mind with hash consing? Regards, Parth [1] http://clojure.org/data_structures#toc12 > This can then be used, in combination with referential transparency to > make memoized function faster. > > I have a java file and a clojure interface that seem to work, at least > on my example. I plan to put something somewhere someday, but before > spending too much time in making this releasable, i Have a few > questions: > > - does something already exists in contrib that I have missed? > - is someone else working on that? > - are there any "features that I need and that you must implement" that > you think of? > > My current plans are: > - using a java concurrent hash map to soft referenced objects for the > hash consing table. > - only two fields in an hash consed object: the value it represents, > and a generic field called "cached_data" used to store anything you > want to memoize about this data structure. (Keeping this cached data a > bit longer is the reason I plan to use soft references and not weak > references) > > I am not a clojure expert and I am not a java coder at all, so don't > hesitate to tell me if my plans are somehow wrong. > > Bets regards, > > Nicolas. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Would *default-precision* make sense?
At least I believe so: it would allow client code to set the desired precision once and then be able to invoke functions that take an optional precision parameter (or none at all) without having to specify precision every time. For example: (set! *default-precision* (. java.math.MathContext/DECIMAL128 getPrecision)) (defn harmonic-number ([] ((fn more [sum n] (let [new-sum (+ sum (with-precision *default- precision* :rounding HALF_EVEN (/ 1 (bigdec n] (lazy-seq (cons (bigdec new-sum) (more new-sum (inc n)) 0 1)) ([n] (harmonic-number n *default-precision*)) ([n #^Integer precision] (reduce + (map #(with-precision precision :rounding HALF_EVEN (/ 1 (bigdec %))) (range 1 (inc n) ) user=> (harmonic-number 5) 2.28M user=> (take 10 (harmonic-number)) (1M 1.5M 1.83M 2.08M 2.28M 2.45M 2.5928571428571428571428571428571429M 2.7178571428571428571428571428571429M 2.8289682539682539682539682539682540M 2.9289682539682539682539682539682540M) Any thoughts? Is there another way to accomplish this that I have overlooked? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Hash Consing
I'm pretty sure Clojure already does this, because of the built in equality by value. I'm pretty sure the hash keys work of off the value, too. Do you have any code you could post to github or something? That would help us determine if such a thing already exisits. I know this doesn't save you the pain of writing the library, but it could save you the trouble of maintaining it in the future. However, writing this library could be a very cool educational exercise. That, and I could have missed your intent entirely. Good luck Sean On Jun 29, 6:09 am, Nicolas Oury wrote: > Dear all, > > I am coding a (very) small hash consing library for clojure. > > For those we don't happen to know what hash consing is, it is a way of > allowing equal data structures to be shared in memory. > This leverages the purity (as in "immutability") of data structures to > reduce memory footprint (no duplication of data for just a constant > overhead per allocation) and makes hashing and equality tests faster. > (You can use java non overloaded hashCode, and == to test equality, > because of the sharing. So both operations are O(1), with a very small > constant, whatever is the complexity of the hash consed data > structures.) > This can then be used, in combination with referential transparency to > make memoized function faster. > > I have a java file and a clojure interface that seem to work, at least > on my example. I plan to put something somewhere someday, but before > spending too much time in making this releasable, i Have a few > questions: > > - does something already exists in contrib that I have missed? > - is someone else working on that? > - are there any "features that I need and that you must implement" that > you think of? > > My current plans are: > - using a java concurrent hash map to soft referenced objects for the > hash consing table. > - only two fields in an hash consed object: the value it represents, > and a generic field called "cached_data" used to store anything you > want to memoize about this data structure. (Keeping this cached data a > bit longer is the reason I plan to use soft references and not weak > references) > > I am not a clojure expert and I am not a java coder at all, so don't > hesitate to tell me if my plans are somehow wrong. > > Bets regards, > > Nicolas. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Hash Consing
Hi, I'm interested in knowing how you solve garbage collection issues ? 2009/6/29 Nicolas Oury : > > Dear all, > > I am coding a (very) small hash consing library for clojure. > > For those we don't happen to know what hash consing is, it is a way of > allowing equal data structures to be shared in memory. > This leverages the purity (as in "immutability") of data structures to > reduce memory footprint (no duplication of data for just a constant > overhead per allocation) and makes hashing and equality tests faster. > (You can use java non overloaded hashCode, and == to test equality, > because of the sharing. So both operations are O(1), with a very small > constant, whatever is the complexity of the hash consed data > structures.) > This can then be used, in combination with referential transparency to > make memoized function faster. > > I have a java file and a clojure interface that seem to work, at least > on my example. I plan to put something somewhere someday, but before > spending too much time in making this releasable, i Have a few > questions: > > - does something already exists in contrib that I have missed? > - is someone else working on that? > - are there any "features that I need and that you must implement" that > you think of? > > My current plans are: > - using a java concurrent hash map to soft referenced objects for the > hash consing table. > - only two fields in an hash consed object: the value it represents, > and a generic field called "cached_data" used to store anything you > want to memoize about this data structure. (Keeping this cached data a > bit longer is the reason I plan to use soft references and not weak > references) > > I am not a clojure expert and I am not a java coder at all, so don't > hesitate to tell me if my plans are somehow wrong. > > Bets regards, > > Nicolas. > > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Hash Consing
Hi! I think it’s basically a generalized version of this: user> (def hcons (memoize cons)) #'user/hcons user> (identical? (cons 1 nil) (cons 1 nil)) false user> (identical? (hcons 1 nil) (hcons 1 nil)) true In the case of cons, every two equal (value-wise) data structes have the same "construction history", thus memoizing cons would make them object-identical. I wonder how this can be leveraged for the remaining data structures though. Vectors, sets and maps don't have construction histories unique to their values ... Kind regards, Achim Am 29.06.2009 um 13:11 schrieb Parth: > On Jun 29, 3:09 pm, Nicolas Oury wrote: >> Dear all, >> >> I am coding a (very) small hash consing library for clojure. >> >> For those we don't happen to know what hash consing is, it is a way >> of >> allowing equal data structures to be shared in memory. >> This leverages the purity (as in "immutability") of data structures >> to >> reduce memory footprint (no duplication of data for just a constant >> overhead per allocation) and makes hashing and equality tests faster. >> (You can use java non overloaded hashCode, and == to test equality, >> because of the sharing. So both operations are O(1), with a very >> small >> constant, whatever is the complexity of the hash consed data >> structures.) > > I don't know anything about hash consing. Based on my > limited understanding of the description I am just wondering > if this is different from structural sharing that Clojure collections > have. > > Quoting the docs[1]: > " > In particular, the Clojure collections support efficient creation of > 'modified' > versions, by utilizing structural sharing, and make all of their > performance > bound guarantees for persistent use. > " > > Do you have something different in mind with hash consing? > > Regards, > Parth > > [1] http://clojure.org/data_structures#toc12 > >> This can then be used, in combination with referential transparency >> to >> make memoized function faster. >> >> I have a java file and a clojure interface that seem to work, at >> least >> on my example. I plan to put something somewhere someday, but before >> spending too much time in making this releasable, i Have a few >> questions: >> >> - does something already exists in contrib that I have missed? >> - is someone else working on that? >> - are there any "features that I need and that you must implement" >> that >> you think of? >> >> My current plans are: >> - using a java concurrent hash map to soft referenced objects for the >> hash consing table. >> - only two fields in an hash consed object: the value it represents, >> and a generic field called "cached_data" used to store anything you >> want to memoize about this data structure. (Keeping this cached >> data a >> bit longer is the reason I plan to use soft references and not weak >> references) >> >> I am not a clojure expert and I am not a java coder at all, so don't >> hesitate to tell me if my plans are somehow wrong. >> >> Bets regards, >> >> Nicolas. > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Would *default-precision* make sense?
On Mon, Jun 29, 2009 at 1:23 PM, arasoft wrote: > > At least I believe so: it would allow client code to set the desired > precision once and then be able to invoke functions that take an > optional precision parameter (or none at all) without having to > specify precision every time. If your code allow precision to be tuned in specific area, I think you should expose your own specific *default-precision* and bind or set! it once for all (and not at each call). If you really want to set! application-wide precision, you should directly set (or redef) *math-context* or wrap the whole computation in a single with-precision: (defn harmonic-number ([] ((fn more [sum n] (let [new-sum (+ sum (/ 1 (bigdec n)))] (lazy-seq (cons (bigdec new-sum) (more new-sum (inc n)) 0 1)) ([n] (reduce + (map #(/ 1 (bigdec %)) (range 1 (inc n)) (with-precision (inc (.getPrecision java.math.MathContext/DECIMAL128)) :rounding HALF_EVEN (doall (take 10 (harmonic-number This code doesn't yield numbers with the same precision as yours because, in your code, + wasn't "precisioned". hth, Christophe -- Professional: http://cgrand.net/ (fr) On Clojure: http://clj-me.blogspot.com/ (en) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Troll in our midst - please ignore them
It's unfortunate when a troll has a brain and uses it for evildoing. Thank you Rich for the language, and your efforts at moderation. On Jun 29, 12:56 am, Alex Combas wrote: > On Sun, Jun 28, 2009 at 10:21 PM, CuppoJava wrote: > > > > > Thank you Denfer, > > That's a very interesting trick. I'm sure it'll be handy to me in the > > future. I really never considered trolls a possibility on this forum. > > It seems if that sort of thing interests you, there's much easier and > > satisfying prey elsewhere. > > heh, well if trolls had brains they wouldn't be trolls now would they? > > Best regards, > agc --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Hash Consing
>
> I don't know anything about hash consing. Based on my
> limited understanding of the description I am just wondering
> if this is different from structural sharing that Clojure collections
> have.
The sharing only concerns data structure having the same creation
point.
As Achim explained, better than me:
user> (identical? (cons 1 nil) (cons 1 nil)) false
In some sense, it corresponds to:
user> (def hcons (memoize cons))
#'user/hcons
but is not limited to consing.
In this sense, it acts more as:
user> (def hidentity (memoize identity))
Which is a bit more generic but less good for GC (it builds a structure
and release it just after the call to hidentity).
Creating specialized functions like hcons might be interesting too.
> I'm interested in knowing how you solve garbage collection issues ?
The main difference with that is how it hanldes GC. The table is a
concurrent hash table whose keys are references to the objects and
values are Soft/Weak references to a HashConsed object.
This HashConsed has a reference to the initial object and is the thing
you want to hold too if you want sharing to work.
When it is finalized, it removes its entries from the hash table, after
some checks (to see it still owns this entry).
> I wonder how this can be leveraged for the remaining data structures
> though. Vectors, sets and maps don't have construction histories
> unique to their values ...
I was thinking of doing something more coarse-grained, for list or
trees. Where these complexed structures (vectors, set, map) are thought
atomic and not hashed incrementally.
(I would be happy to do otherwise, but it seems quite complicated.)
Example of use to create, for example, a tree:
(hash-cons {:head :a :children {set of hash consed nodes}})
This hashing is done in O(num of children), and then you get back a
HashConsed structure, that is shared for all hash consed instances
of the same tree. It can be used to test equality O(1), with identical?,
and not O(size of the tree).
Hashing is done in O(1) too.
Of course, incremental hash consing of sets/map/vectors could give us
adding/removing a children in a better time than O(num of children) but
I don't have much clue on how to do that. Any ideas?
Best,
Nicolas.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---
Re: Would *default-precision* make sense?
I very much like your idea of setting *math-context* (I was looking for something like that, but could not find it in the documentation), but how do I do it globally? user=> (set! *math-context* java.math.MathContext/DECIMAL128) # whereas (set! *warn-on-reflection* true) works fine? What is the difference? How is it done right? On Jun 29, 2:24 pm, Christophe Grand wrote: > On Mon, Jun 29, 2009 at 1:23 PM, arasoft wrote: > > > At least I believe so: it would allow client code to set the desired > > precision once and then be able to invoke functions that take an > > optional precision parameter (or none at all) without having to > > specify precision every time. > > If your code allow precision to be tuned in specific area, I think you > should expose your own specific *default-precision* and bind or set! it once > for all (and not at each call). > If you really want to set! application-wide precision, you should directly > set (or redef) *math-context* or wrap the whole computation in a single > with-precision: > > (defn harmonic-number > ([] > ((fn more [sum n] (let [new-sum (+ sum (/ 1 (bigdec n)))] > (lazy-seq (cons (bigdec new-sum) (more new-sum (inc n)) > 0 1)) > ([n] > (reduce + (map #(/ > 1 (bigdec %)) (range 1 (inc n)) > > (with-precision (inc (.getPrecision java.math.MathContext/DECIMAL128)) > :rounding HALF_EVEN > (doall (take 10 (harmonic-number > > This code doesn't yield numbers with the same precision as yours because, in > your code, + wasn't "precisioned". > > hth, > > Christophe > > -- > Professional:http://cgrand.net/(fr) > On Clojure:http://clj-me.blogspot.com/(en) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Would *default-precision* make sense?
On Mon, 2009-06-29 at 07:04 -0700, arasoft wrote: > I very much like your idea of setting *math-context* (I was looking > for something like that, but could not find it in the documentation), > but how do I do it globally? > > user=> (set! *math-context* java.math.MathContext/DECIMAL128) > # establish root binding of: *math-context* with set (NO_SOURCE_FILE:0)> > > whereas > > (set! *warn-on-reflection* true) > > works fine? > > What is the difference? How is it done right? I am not sure, but I believe it's due to *warn-on-reflection* being bound by the compiler/REPL before evaluating (set! *warn-on-reflection* true). When I looked, the REPL was called within a macro 'with-bindings repl' that expands to (binding [ *warn-on-reflection* ] repl) allowing the execution of REPL to set! *war-on-reflection* and some other similar vars. (*ns*, *compile-files*, *compile-path*, etc...) I suppose the compiler does a similar thing, but I have never looked. Best, Nicolas. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Trying to use lazy-seq for the first time, failing.
On Jun 29, 1:15 am, Emeka wrote: > Harold, > > Do you have any material on Factor? I won't going through it. Emeka, Many of these links are relevant: http://www.google.com/search?q=factor+language Regards, -Harold --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: executing tasks on a schedule
I wrote a basic quartz adapter for calling clojure functions by submitting a job to call a clojure function by namespace/name or submitting a closure. My write-up is here: http://asymmetrical-view.com/2009/05/19/quartz-and-clojure.html The example quartz code is in my github sandbox: http://github.com/kyleburton/sandbox/tree/master For me the advantage of using quartz and clojure is that it's in the same JVM as other parts of the application - I don't need to create a separate command line runner which can be invoked by cron. I'm also exploring creating a scheduling service using Quartz listening on an AMQP message queue - where you can send it a message with the scheduling details (one off or recurring) a return queue and an embedded message body. At the triggering time it sends the embedded message back. This is also more flexible than Cron - it's all handled within the application and I can register and unregister the triggers. Cron would be more difficult to use for cases where I want to defer some activity by sending it to the scheduler to be returned in say 10 minutes. The scheduler service isn't in my sandbox yet, but I do plan on publishing it when its complete and I have the time. HTH, Kyle On Sat, Jun 27, 2009 at 2:55 AM, ataggart wrote: > > What do you need that a cron job wouldn't provide? > > On Jun 26, 8:43 am, Stuart Halloway wrote: >> I am working on a Clojure project that is becoming more and more >> schedule-oriented. So far I have been using Clojure's native >> concurrency constructs, but I am becoming tempted to use Java's >> concurrency primitives to get interruptability, etc. -- or maybe even >> wrap a Java library like Quartz. >> >> Has anyone else been down this road? >> >> Stu > > > -- -- kyle.bur...@gmail.comhttp://asymmetrical-view.com/ -- --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Would *default-precision* make sense?
On Jun 29, 2009, at 10:11 AM, Nicolas Oury wrote: I am not sure, but I believe it's due to *warn-on-reflection* being bound by the compiler/REPL before evaluating (set! *warn-on- reflection* true). When I looked, the REPL was called within a macro 'with-bindings repl' that expands to (binding [ *warn-on-reflection* ] repl) allowing the execution of REPL to set! *war-on-reflection* and some other similar vars. (*ns*, *compile-files*, *compile-path*, etc...) I suppose the compiler does a similar thing, but I have never looked. That's correct. You can see the vars that are set!-ale in the REPL in: user=> (doc clojure.main/with-bindings) - clojure.main/with-bindings ([& body]) Macro Executes body in the context of thread-local bindings for several vars that often need to be set!: *ns* *warn-on-reflection* *print-meta* *print-length* *print-level* *compile-path* *command-line-args* *1 *2 *3 *e nil In your own REPL, you could make *math-context* set!-able by launching a new repl wrapped in code that binds *math-context*: user=> (binding [*math-context* *math-context*] (clojure.main/repl)) user=> (set! *math-context* (java.math.MathContext. 4)) # user=> (+ 3 1.M) 4.556M user=> (set! *math-context* (java.math.MathContext. 6)) # user=> (+ 3 1.M) 4.6M user=> It seems to me that clojure.main/with-bindings should be enhanced provide a root binding for *math-context* so it's set!-able at the repl. Does anyone have any objection to or support for that idea? --Steve smime.p7s Description: S/MIME cryptographic signature
Re: Troll in our midst - please ignore them
Rich, I'd also suggest that folks rate the posts that are exceptionally good or exceptionally bad. If a user account is noted predominately for bad posts, a moderator - whether in this group or another - will think twice about allowing the user to freely post. And vice versa, posts from a user with 5 star rating, like yourself, should be welcomed anywhere. Best regards, Andrew --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: ANN: libraries promoted from contrib to clojure
There may already have been a discussion about this in IRC, but I would have loved to see the 'are' macro continue to support the old syntax (maybe with deprecation warnings) as well as the new until after 1.1 is released. This change makes it relatively expensive for any library with a significant test suite that uses 'are' to keep testing with both the current release and the current snapshot of clojure and contrib. On Thu, Jun 25, 2009 at 10:40 PM, Stuart Halloway wrote: > ... Also, the signature and implementation > of test/are has changed, and is now more idiomatic. For example: > > (deftest test-count > (are [x y] (= x y) ; instead of (are (= _1 _2)) > (count nil) 0 > (count ()) 0 > (count '(1)) 1 > (count '(1 2 3)) 3 > ; etc. -- http://elhumidor.blogspot.com/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: ANN: libraries promoted from contrib to clojure
On Mon, Jun 29, 2009 at 11:14 AM, John D. Hume wrote: > > There may already have been a discussion about this in IRC The discussion took place here: http://groups.google.com/group/clojure-dev/msg/2df101865a378156?hl=en > This change makes it relatively expensive for > any library with a significant test suite that uses 'are' to keep > testing with both the current release and the current snapshot of > clojure and contrib. If you really want to maintain a single test suite for both 1.0.x and 'master', it shouldn't be difficult to write a macro that expands to either the old or new 'are' syntax, depending on the Clojure version runnin. --Chouser --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: ANN: libraries promoted from contrib to clojure
On Jun 29, 6:14 pm, "John D. Hume" wrote: > There may already have been a discussion about this in IRC, but I > would have loved to see the 'are' macro continue to support the old > syntax (maybe with deprecation warnings) as well as the new until > after 1.1 is released. This change makes it relatively expensive for > any library with a significant test suite that uses 'are' to keep > testing with both the current release and the current snapshot of > clojure and contrib. You can always checkout the contrib version prior to these breaking changes for your tests. (seems to be 3073f0dc0614cb8c95f2debd0b7e6a75c1736ece) There has been talk on IRC about creating a 1.0-compatible branch, but so far no-one has taken action. :/ You could also attempt to write a compatibility wrapper that has the old are syntax, but transforms it into the new are. If most of your tests are of the form (are (= _1 _2) ...) then it's only a matter of transforming that to (new-are [_1 _2] (= _1 _2) ...). -- Jarkko --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Would *default-precision* make sense?
On Mon, Jun 29, 2009 at 10:51 AM, Stephen C. Gilardi wrote: > > On Jun 29, 2009, at 10:11 AM, Nicolas Oury wrote: > >> I am not sure, but I believe it's due to *warn-on-reflection* being >> bound by the compiler/REPL before evaluating (set! *warn-on-reflection* >> true). >> >> When I looked, the REPL was called within a macro 'with-bindings repl' >> that expands to >> (binding [ >> *warn-on-reflection* >> ] >> repl) >> >> >> allowing the execution of REPL to set! *war-on-reflection* and some >> other similar vars. (*ns*, *compile-files*, *compile-path*, etc...) >> >> I suppose the compiler does a similar thing, but I have never looked. > > That's correct. You can see the vars that are set!-ale in the REPL in: > > user=> (doc clojure.main/with-bindings) > - > clojure.main/with-bindings > ([& body]) > Macro > Executes body in the context of thread-local bindings for several vars > that often need to be set!: *ns* *warn-on-reflection* *print-meta* > *print-length* *print-level* *compile-path* *command-line-args* *1 > *2 *3 *e > nil > > In your own REPL, you could make *math-context* set!-able by launching a new > repl wrapped in code that binds *math-context*: > > user=> (binding [*math-context* *math-context*] (clojure.main/repl)) > user=> (set! *math-context* (java.math.MathContext. 4)) > # > user=> (+ 3 1.M) > 4.556M > user=> (set! *math-context* (java.math.MathContext. 6)) > # > user=> (+ 3 1.M) > 4.6M > user=> > > It seems to me that clojure.main/with-bindings should be enhanced provide a > root binding for *math-context* so it's set!-able at the repl. > > Does anyone have any objection to or support for that idea? > Fine by me. 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 Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Would *default-precision* make sense?
I'm obviously all for it... On Jun 29, 5:53 pm, Rich Hickey wrote: > On Mon, Jun 29, 2009 at 10:51 AM, Stephen C. Gilardi wrote: > > > On Jun 29, 2009, at 10:11 AM, Nicolas Oury wrote: > > >> I am not sure, but I believe it's due to *warn-on-reflection* being > >> bound by the compiler/REPL before evaluating (set! *warn-on-reflection* > >> true). > > >> When I looked, the REPL was called within a macro 'with-bindings repl' > >> that expands to > >> (binding [ > >> *warn-on-reflection* > >> ] > >> repl) > > >> allowing the execution of REPL to set! *war-on-reflection* and some > >> other similar vars. (*ns*, *compile-files*, *compile-path*, etc...) > > >> I suppose the compiler does a similar thing, but I have never looked. > > > That's correct. You can see the vars that are set!-ale in the REPL in: > > > user=> (doc clojure.main/with-bindings) > > - > > clojure.main/with-bindings > > ([& body]) > > Macro > > Executes body in the context of thread-local bindings for several vars > > that often need to be set!: *ns* *warn-on-reflection* *print-meta* > > *print-length* *print-level* *compile-path* *command-line-args* *1 > > *2 *3 *e > > nil > > > In your own REPL, you could make *math-context* set!-able by launching a new > > repl wrapped in code that binds *math-context*: > > > user=> (binding [*math-context* *math-context*] (clojure.main/repl)) > > user=> (set! *math-context* (java.math.MathContext. 4)) > > # > > user=> (+ 3 1.M) > > 4.556M > > user=> (set! *math-context* (java.math.MathContext. 6)) > > # > > user=> (+ 3 1.M) > > 4.6M > > user=> > > > It seems to me that clojure.main/with-bindings should be enhanced provide a > > root binding for *math-context* so it's set!-able at the repl. > > > Does anyone have any objection to or support for that idea? > > Fine by me. > > 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 Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Hash Consing
> This hashing is done in O(num of children), and then you get back a > HashConsed structure, that is shared for all hash consed instances > of the same tree. It can be used to test equality O(1), with > identical?, > and not O(size of the tree). I've seen this referred to as interning -- indeed, that's what Java calls it for String: http://java.sun.com/j2se/1.4.2/docs/api/java/lang/String.html#intern() I used this technique to save heap in a CL app I wrote once -- there could be 2 million entries containing URLs submitted by a client, and most of those URLs were the same. Interning the strings before insertion (just as you do, by jamming them into a hash-table) was a big benefit, and made subsequent comparisons cheaper, too. -R --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Trying to use lazy-seq for the first time, failing.
Thanks, however I have that already :) Regards, Emeka On Mon, Jun 29, 2009 at 2:36 PM, _hrrld wrote: > > On Jun 29, 1:15 am, Emeka wrote: > > Harold, > > > > Do you have any material on Factor? I won't going through it. > > Emeka, > > Many of these links are relevant: > http://www.google.com/search?q=factor+language > > Regards, > -Harold > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Convincing others about Clojure
On Jun 25, 12:59 am, Baishampayan Ghose wrote: > Their concerns are thus: > > 1. How do you get Clojure programmers? Lisp is not for the faint hearted. You advertise for programmers and include Clojure, Lisp, Java, and functional programming on the roster of desirable skills. Lisp hackers want to hack Lisp. Over the past twenty years I;ve been on four teams that wrote the bulk of their code in Lisp, and finding people to do it has never been an issue. On the largest project we had somewhere in the neighborhood of 60 people; the non-Lispers that were hired had no trouble taking instruction from the Lispers. > 2. What about the performance of Clojure? Is it fast? It's usually about as fast as plain Java. Occasionally someone will write something that is slower. If it's slow enough to notice, it's generally easy to recode it to recover the speed. > 3. People who want to use this are more academically inclined and are > not practical. This will make the whole project fail. That one is just a prejudice.No one has that kind of knowledge, so whoever said it is just making it up, or revealing a personal bias. You'll have to figure out the best way to deal with it based on knowledge of the individual's personality. If it's a question of talking to investors, it's been my experience that, barring the quirks of particular individuals with prejudices, investors ask about platforms and technologies to (1) disqualify people who clearly have no clue and (2) find out how nimble you are about responding to inconvenient questions (because you're going to have to talk to a lot of people who will ask a lot of inconvenient questions, and the investors want to make sure before they give you money that you can talk confidently and convincingly under those circumstances). So in talking to investors about your platform I'd suggest focusing on advantages rather than trying too hard to defend against perceived disadvantages, and don't give out details that the questioners don't need to know. For example, why would they need to know what the source language is? The proposed product runs on the JVM, a proven platform. That should be enough, unless you want to build a sales pitch around specific competitive advantages Clojure gives you. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
ClojureQL - 0.9 approaching 1.0
Dear community,
Meikel and I have been driving an effort to get ClojureQL to version
1.0.
For those who do not yet know about ClojureQL, its a database adapter
which allows you to interface with MySql, Derby, Sqlite etc, without
ever leaving your lisp syntax. But more than being a syntax thing,
ClojureQL also is able to extend the functionality of databases, ie.
you can currently find an emulator in the backend which enables both
MySql and Derby to do FULL joins - Not something you normally get to
do.
In terms of functionality we almost cover every need that you'll have
when working with SQL, but there are still quirks to be ironed out
(ex. joins) and features to be added and extended (ex. alter table).
But this is where we'd like to appeal to the community to hit us with
some feedback! If you're interested in Clojure/SQL and you can find
the time to experiment a little, its as simple as this.
1) Put the src/ or the jar file on your class-path and get a REPL
going.
2) user> (use 'dk.bestinclass.clojureql) // Import the functions
3) Have fun, ala:
user> (def *connection* (make-connection-info "mysql" "//localhost/
cql" "cql" "cql"))
#'user/*connection*
user> (load-driver "com.mysql.jdbc.Driver")
com.mysql.jdbc.Driver
user> (run [*connection* results] (query * test)
(take 3 results))
({:id 1, :age 224} {:id 2, :age 23} {:id 3, :age 402})
If you run into trouble, because somethings is not currently
implemented, you can always resort to using (raw "SELECT * FROM foo
USING SPECIAL FUNC") or something similar - So you wont be stuck. If
you come across some features that are lacking, bugs that need
reporting or similar, please drop us a message at IRC or Github,
you'll find the project here: http://github.com/Lau-of-DK/clojureql/tree/master
Expect Join/Run syntax to change in the near future, and dont be
surprised if you come across something that needs a patch - We're not
1.0 yet, and we could use a little help in getting there :)
/Lau
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---
ants.clj and render thread starvation
After watching most of Rich's Clojure presentations over the weekend, I found myself playing with ants.clj again on my netbook. The ant simulation runs brilliantly on my quad-core machine at work. Not so much on my netbook. The problem seems to be that with only a single (hyperthreaded) core the render agent is almost constantly interrupted by some pesky ant while attempting to snapshot the world, forcing the render agent to automatically retry. And so, the ants run merrily around the world, only I can't see it. This raises a question. Clojure's refs and dosync sure are neat, but this experience would seem to indicate that there are potential scalability problems when combining long-running and short-running transactions. Under load (or on a slow machine) a long-running transaction may never get a chance to complete and may be stuck forever retrying, burning CPU but producing no useful output. This makes me uneasy. I was able to get ants.clj to work reliably on my netbook by playing around with the sleep times in such a way as to increase the probability of the renderer actually completing a snapshot, but this process felt hacky and ad-hoc. What works on my netbook might well be sub-optimal on another system. How could one change the design of ants.clj to work reliably (i.e. update the screen periodically) even on slower systems? // Ben --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: What are people using Clojure for?
I think we have some similar and overlapping concepts, including reducing a template to an executable function. I think there's a difference in composition, as Cascade has the concept of reusable fragments that take parameters. I also have a lot of ideas for control structures related to rendering and action request processing that haven't been realized in the existing code. Finally, I'm looking forward to (at least experimenting with) parallel rendering across fragments. The idea of hitting the database with N requests across N threads in parallel and assembling the result speedily is very promising. I'm not building Cascade to replace Tapestry, but to really learn the ins and outs of Clojure in a domain I really understand. 2009/6/28 Michael Böckling > > Hi Howard, > > I'd be interested to know what you think of Enlive (http:// > wiki.github.com/cgrand/enlive/). > On first sight it looks like pure genius, and the philosophy reminds > me of Tapestry5. T5 nicely decouples Java user code from the framework > by using IoC, callbacks, naming conventions and avoiding inheritance. > Enlive does the same for the view layer: it wraps around the HTML, > eliminating tight coupling. jQuery showed us that css-style selectors > work great in frontend javascript code, and I just asked myself: why > not use that on the server side, too? > > Regards, > Michael > > > On 19 Jun., 19:28, Howard Lewis Ship wrote: > > Cascade is coming along:http://wiki.github.com/hlship/cascade > > > > I don't have a lot of time to work on it. It's a way to use Clojure > > earnestly, and hit real world problems, and to learn to think more > > functionally, in a problem domain I know very, very well. > > > > It's an action framework, not a component framework like Tapestry. But > the > > view and fragment templates look a lot like Tapestry templates. > > > > So far, I just have a portion of the templating system working. > > > > On Thu, Jun 18, 2009 at 7:09 PM, Vagif Verdi > wrote: > > > > > On Jun 18, 8:39 am, Howard Lewis Ship wrote: > > > > I am having fun learning it by creating a simple web framework. > > > > > Howard, that's interesting to hear from a Tapestry creator. > > > > > I'm in a process of preparing to write a web application with clojure > > > web framework compojure. But if you have something usable, I'd love to > > > check it out before i made my decision. > > > > -- > > Howard M. Lewis Ship > > > > Creator of Apache Tapestry > > Director of Open Source Technology at Formos > > > > -- Howard M. Lewis Ship Creator of Apache Tapestry Director of Open Source Technology at Formos --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: What are people using Clojure for?
> Finally, I'm looking forward to (at least experimenting with) > parallel rendering across fragments. The idea of hitting the > database with N requests across N threads in parallel and assembling > the result speedily is very promising. This is how Amazon (and probably eBay et al) assemble pages. Each of the boxes you see -- recommendations, your browsing history, etc. -- are assembled in parallel. If an agent is taking too long to generate that part of the page, it's simply dropped to keep total page load time down. I'm sure they do it through some horrible chunk of procedural code, of course... --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Convincing others about Clojure
On Jun 26, 2:40 pm, Raoul Duke wrote: > > We are hiring; but do you live in Mumbai, India? :) > > no, but i do know some folks around there (although they are all happy > where they are, as far as i know). do you allow telecommuting from > usa? ;-) > > best of luck with the venture. I'm looking for part-time work as well. If your advisors/investors are ok with telecommuting, I don't think you'll have a problem finding programmers with Clojure experience. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Clojure for Scientific and other CPU-intensive Computing
Based on the recent survey "What are people using Clojure for?", people are mostly using it for non-CPU-intensive work, like parsing, report generation, GUIs, "glue" code. It's been argued by some that Clojure is as fast as Java, because at worst, you can implement your bottlenecks in Java. I have a problem with this argument, because the data structures that your Java has to work with are still (wasteful) Clojure ones. For example, a matrix data structure in Clojure could be based on Seqs (or Seqs of Seqs) of dynamically typed elements. There is overhead associated with this dynamic typing and mutation of the elements. When you discover that some procedure working on such data structure is slow, you can reimplement it in Java, but do you think it could compete with Java working on native statically typed arrays of floats? I would be curious to know if anyone is using Clojure for CPU- intensive work where performance really counts. I get the impression that Jon Harrop is gearing up to write Clojure for Scientists. Also I remember someone saying they are working on the Shootout entry for Clojure. Has this happened? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: ClassNotFoundException with def
On Sun, Jun 28, 2009 at 01:25:15PM -0700, hoeck wrote: [...] > Tried it, and had the same results. Somehow defining a class object as > a root value triggers some mechanism to load it with the root > classloader instead of the clojure one. > However, putting /home/me on the classpath using -cp works. Thank you, erik! Daniel --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Clojure for Scientific and other CPU-intensive Computing
> I would be curious to know if anyone is using Clojure for CPU- > intensive work where performance really counts. Respectfully, I wouldn't class telephony as "non-CPU-intensive". :) Speed directly translates to calls-per-second. I've been very happy with Clojure thus far. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Speedy accessors for the trees of clojure.xml
clojure.xml/parse returns a PersistentStructMap. Is there a way to refer to its struct template? I wish to create accessors for its keys, such as :tag, :attrs, and :content, with the accessor function for speed. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: What are people using Clojure for?
A friend of mine who worked for Sleepycat told me that the Amazon home page does up to 40 separate queries. Of course, this was at least five years ago, but still. That would be an option, a fragment that rendered its body in a new/worker thread, with a time limit, and replaced it with a placeholder if not ready in time. Still a ways to go; I have many other higher priority responsibilities. On Mon, Jun 29, 2009 at 12:00 PM, Richard Newman wrote: > > > Finally, I'm looking forward to (at least experimenting with) > > parallel rendering across fragments. The idea of hitting the > > database with N requests across N threads in parallel and assembling > > the result speedily is very promising. > > This is how Amazon (and probably eBay et al) assemble pages. Each of > the boxes you see -- recommendations, your browsing history, etc. -- > are assembled in parallel. If an agent is taking too long to generate > that part of the page, it's simply dropped to keep total page load > time down. I'm sure they do it through some horrible chunk of > procedural code, of course... > > > > -- Howard M. Lewis Ship Creator of Apache Tapestry Director of Open Source Technology at Formos --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Speedy accessors for the trees of clojure.xml
On Jun 29, 4:59 pm, samppi wrote: > clojure.xml/parse returns a PersistentStructMap. Is there a way to > refer to its struct template? I wish to create accessors for its keys, > such as :tag, :attrs, and :content, with the accessor function for > speed. If you look at the top of xml.clj you'll see they already exist. 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 Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: ANN: libraries promoted from contrib to clojure
On Jun 29, 11:14 am, "John D. Hume" wrote: > There may already have been a discussion about this in IRC, but I > would have loved to see the 'are' macro continue to support the old > syntax (maybe with deprecation warnings) as well as the new until > after 1.1 is released. There were some problems with the _1,_2 syntax, subtle edge cases that are inconsistent with the way %1,%2 work in #(). And the old c.c.test- is remains in older versions of contrib. Pretty soon now, Clojure will will likely introduce more breaking changes, so you'll have to pick one or the other. -SS --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Speedy accessors for the trees of clojure.xml
Wonderful. Thanks for the answer. On Jun 29, 2:47 pm, Rich Hickey wrote: > On Jun 29, 4:59 pm, samppi wrote: > > > clojure.xml/parse returns a PersistentStructMap. Is there a way to > > refer to its struct template? I wish to create accessors for its keys, > > such as :tag, :attrs, and :content, with the accessor function for > > speed. > > If you look at the top of xml.clj you'll see they already exist. > > 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 Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
debugging advice
Hi all, at the risk of sounding negative and (-; thus getting "moderated" ;-) ... I'm very interested in taking another stab at clojure after putting it down for a while, but I had real trouble debugging my programs. I'm looking for advice and/or an approach. as I recall, I simply got a general exception with no indication as to where or why. I also think this point of view could be seen as constructive ... because I've heard it from others who have tried (or heard about) clojure ... and I don't really know what to tell them -- having mostly experienced that myself. Thanks. - Eli --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: debugging advice
> at the risk of sounding negative and (-; thus getting > "moderated" ;-) ... I'm very interested in taking another stab at > clojure after putting it down for a while, but I had real trouble > debugging my programs. I'm looking for advice and/or an approach. Aside from two areas — JVM problems, such as with gen-class'ed classes, and exceptions occurring in Java code — I've found that the best general approach is to build small, functional programs. If every function is only a few lines long, and stands mostly alone, you can build from the bottom up and rely on your foundations. Test as you go, by hand or automatically — I find that automation is much less important with functional programming, because there are fewer knock- on effects of changes, but that's another kettle of fish — but if you keep most of your program free of side effects, composed of small functions, you should find that debugging in the large is greatly reduced. No side effects mean that the only time you can have a bug is if you get the wrong output from your function for the inputs you provided; debugging in that case means inspecting your function, and maybe navigating outwards the tree of calls it makes to other pure functions. Add tracing until you find the function that's returning the wrong thing, and fix it. If you're finding that you're managing a lot of state, and thus have trouble debugging, then you're probably not taking a sufficiently functional approach. (A big hint is if you find yourself wanting a stepping debugger to watch values change. It's the "change" part that's worrying!) If that's not your problem, could you elaborate so that we might all opine? :) -R --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: debugging advice
> If you're finding that you're managing a lot of state, and thus have > trouble debugging, then you're probably not taking a sufficiently > functional approach. (A big hint is if you find yourself wanting a > stepping debugger to watch values change. It's the "change" part > that's worrying!) personally, i find that approach to generally be sorta a less than ideal "blame the user" answer. while i /do/ very much appreciate that approach to building software, at the same time i don't believe that is the only way to go. not having good errors come out is a big negative in my mind. $0.02. sincerely. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: debugging advice
My negative experience with debugging touches on a number of things, but the biggest is the way that lazy evaluation makes it hard to determine cause and effect while debugging. This has been a problem, and I've had to do a lot of (prn) calls to try and identify what's going on. I eventually have figured out everything, but it's been a challenge I wouldn't recommend to a new coder without a lot of experience to draw upon! I'm not sure how to address it; but this is an issue that may ultimately have Clojure relegated as a "language for experts". I want it to be a language for everyone. On Mon, Jun 29, 2009 at 5:35 PM, Richard Newman wrote: > > > at the risk of sounding negative and (-; thus getting > > "moderated" ;-) ... I'm very interested in taking another stab at > > clojure after putting it down for a while, but I had real trouble > > debugging my programs. I'm looking for advice and/or an approach. > > Aside from two areas — JVM problems, such as with gen-class'ed > classes, and exceptions occurring in Java code — I've found that the > best general approach is to build small, functional programs. > > If every function is only a few lines long, and stands mostly alone, > you can build from the bottom up and rely on your foundations. Test as > you go, by hand or automatically — I find that automation is much less > important with functional programming, because there are fewer knock- > on effects of changes, but that's another kettle of fish — but if you > keep most of your program free of side effects, composed of small > functions, you should find that debugging in the large is greatly > reduced. > > No side effects mean that the only time you can have a bug is if you > get the wrong output from your function for the inputs you provided; > debugging in that case means inspecting your function, and maybe > navigating outwards the tree of calls it makes to other pure > functions. Add tracing until you find the function that's returning > the wrong thing, and fix it. > > If you're finding that you're managing a lot of state, and thus have > trouble debugging, then you're probably not taking a sufficiently > functional approach. (A big hint is if you find yourself wanting a > stepping debugger to watch values change. It's the "change" part > that's worrying!) > > If that's not your problem, could you elaborate so that we might all > opine? :) > > -R > > > -- Howard M. Lewis Ship Creator of Apache Tapestry Director of Open Source Technology at Formos --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: debugging advice
oh yeah . . . .been down the prn road for many many hours, myself. seems like a lot of nice people here ready to help so i'll get back into it soon and post specific problems. . . . there are a lot lot lot of them, so i am sure it will take some time. Thanks for the ideas. On Mon, Jun 29, 2009 at 8:39 PM, Howard Lewis Ship wrote: > My negative experience with debugging touches on a number of things, but > the biggest is the way that lazy evaluation makes it hard to determine cause > and effect while debugging. This has been a problem, and I've had to do a > lot of (prn) calls to try and identify what's going on. > > I eventually have figured out everything, but it's been a challenge I > wouldn't recommend to a new coder without a lot of experience to draw upon! > > I'm not sure how to address it; but this is an issue that may ultimately > have Clojure relegated as a "language for experts". I want it to be a > language for everyone. > > > On Mon, Jun 29, 2009 at 5:35 PM, Richard Newman wrote: > >> >> > at the risk of sounding negative and (-; thus getting >> > "moderated" ;-) ... I'm very interested in taking another stab at >> > clojure after putting it down for a while, but I had real trouble >> > debugging my programs. I'm looking for advice and/or an approach. >> >> Aside from two areas — JVM problems, such as with gen-class'ed >> classes, and exceptions occurring in Java code — I've found that the >> best general approach is to build small, functional programs. >> >> If every function is only a few lines long, and stands mostly alone, >> you can build from the bottom up and rely on your foundations. Test as >> you go, by hand or automatically — I find that automation is much less >> important with functional programming, because there are fewer knock- >> on effects of changes, but that's another kettle of fish — but if you >> keep most of your program free of side effects, composed of small >> functions, you should find that debugging in the large is greatly >> reduced. >> >> No side effects mean that the only time you can have a bug is if you >> get the wrong output from your function for the inputs you provided; >> debugging in that case means inspecting your function, and maybe >> navigating outwards the tree of calls it makes to other pure >> functions. Add tracing until you find the function that's returning >> the wrong thing, and fix it. >> >> If you're finding that you're managing a lot of state, and thus have >> trouble debugging, then you're probably not taking a sufficiently >> functional approach. (A big hint is if you find yourself wanting a >> stepping debugger to watch values change. It's the "change" part >> that's worrying!) >> >> If that's not your problem, could you elaborate so that we might all >> opine? :) >> >> -R >> >> > > > -- > Howard M. Lewis Ship > > Creator of Apache Tapestry > Director of Open Source Technology at Formos > > > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
clueless hash-map question
hi, is there an equivalent of java.util.Map.entrySet() or an iterator over that? i see things for getting the keys alone, or the vals alone. i guess off the cuff i find it odd that doseq on a map doesn't give me k-v pairs as the entries by default, but gives them interleaved. -Mr. Not Yet With The Programme. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Speedy accessors for the trees of clojure.xml
As a matter of interest, one can get the keys keys in an unknown struct by allocating an empty struct; (def st (create-struct :a :b :c)) (keys (struct st)) (:a :b :c) -Adrian. On Tue, Jun 30, 2009 at 12:14 AM, samppi wrote: > > Wonderful. Thanks for the answer. > > On Jun 29, 2:47 pm, Rich Hickey wrote: > > On Jun 29, 4:59 pm, samppi wrote: > > > > > clojure.xml/parse returns a PersistentStructMap. Is there a way to > > > refer to its struct template? I wish to create accessors for its keys, > > > such as :tag, :attrs, and :content, with the accessor function for > > > speed. > > > > If you look at the top of xml.clj you'll see they already exist. > > > > 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 Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: clueless hash-map question
> is there an equivalent of java.util.Map.entrySet() or an iterator over
> that? i see things for getting the keys alone, or the vals alone. i
> guess off the cuff i find it odd that doseq on a map doesn't give me
> k-v pairs as the entries by default, but gives them interleaved.
If you're talking about Clojure maps, I'm not sure I understand you:
you can destructure the values you receive in doseq (or anywhere else,
such as the map function) --
user=> (doseq [[k v] {:foo 5 :bar 6}] (println k v))
:foo 5
:bar 6
Is that what you want?
-R
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---
Re: clueless hash-map question
On Jun 29, 9:34 pm, Raoul Duke wrote:
> hi,
>
> is there an equivalent of java.util.Map.entrySet() or an iterator over
> that? i see things for getting the keys alone, or the vals alone. i
> guess off the cuff i find it odd that doseq on a map doesn't give me
> k-v pairs as the entries by default, but gives them interleaved.
>
user=> (instance? java.util.Map$Entry (first {:a 1 :b 2}))
true
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
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---
Re: Clojure for Scientific and other CPU-intensive Computing
On Jun 29, 1:39 pm, Richard Newman wrote: > > I would be curious to know if anyone is using Clojure for CPU- > > intensive work where performance really counts. > > Respectfully, I wouldn't class telephony as "non-CPU-intensive". :) I would have thought those kinds of things are bandwidth-limited. > Speed directly translates to calls-per-second. I've been very happy > with Clojure thus far. Because of its competitive speed or something 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 Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Clojure for Scientific and other CPU-intensive Computing
>> Respectfully, I wouldn't class telephony as "non-CPU-intensive". :) > > I would have thought those kinds of things are bandwidth-limited. Typically not. Some rough numbers: a complete call setup and teardown is usually no more than 5KB, spread over the course of the call -- the initial signaling typically being less than 2KB. A gigabit ethernet link, then, can carry at least 20,000 call setups per second at 1/3 utilization (which is the point at which Ethernet starts to exhibit collisions, IIRC -- more might well be possible). Even really good SIP systems start to buckle well below 2,000cps, often as low as 200. The order of magnitude discrepancy is the time spent parsing, validating, looking up sessions, running routing logic, doing logging, switching processes and threads, etc... oh, and running your application code :) It would take a *really* fast piece of software, or a specialized appliance, to saturate a gigabit link with calls... and those almost always have multiple NICs for other reasons. This is ignoring, of course, any limitations upstream. You're unlikely to have a true gigabit link to a backbone. Then again, experience has shown that doing anything useful at all takes enough processor time that individual boxes will certainly be processor-bound for ordinary call volumes long before even a 100Mb link is saturated. 100Mb could supply all the calls an entire datacenter can handle. The reason this is an interesting domain is that, apart from logging, the entire call processing flow is in-memory and CPU-intensive. More importantly, it has latency requirements -- call setup time translates to dead air -- and even occasional slowdowns can cause a devastating cascade of retransmissions. Keeping up with requests is important, so speed is second only to reliability. >> Speed directly translates to calls-per-second. I've been very happy >> with Clojure thus far. > > Because of its competitive speed or something else? Both speed and power. I haven't noticed any performance degradation compared to my pure Java applications. For comparison, the routing logic I implemented on top of Clojure runs in 1/4 the time it takes for the Java servlet container just to parse a message from the (warm) disk cache -- I seem to recall that my code finished in 0.5ms, and the parsing in 2ms. Parsing is a very optimized part of the container! I haven't even begun profiling or optimization -- this is still a prototype. That impressed and surprised me, so much so that I actually doubled checked that everything was actually executing! (Imagine some Ruby or Python functions running in microseconds...) The commented Clojure source for the application almost seems trivial, which -- while somewhat deflating to the ego -- is a testament to how expressive the language is. I certainly wouldn't want to do this kind of exploratory development in Java (or even in CL! I use a lot of literal maps), and as things stand now there doesn't seem to be any reason to rewrite the Clojure code for performance or any other reason. I've personally written and maintained SIP servlets in Java, and they rapidly become horrific tangled webs of state machines meshed with Java methods. Not nice. Clojure, even more so than other Lisps, enables far more suitable abstractions for this kind of thing. (Some day I'll be able to write about them.) Even better, the code I've written -- thanks to STM and persistent data structures -- is very amenable to concurrency, so on an 8-core machine it'll scale safely as well as the servlet container will allow. I don't see the number of cores on our servers shrinking any time soon... Anyway, enough rambling. That's why I think telephony can be CPU intensive, and why I like Clojure :) -R --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Speedy accessors for the trees of clojure.xml
Yes, but I'm not so sure that you can get usable accessors with those keys: Clojure 1.0.0- user=> (defstruct test-s :a :b :c) #'user/test-s user=> (defstruct test-2-s :a :b :c) #'user/test-2-s user=> (def accessor-a (accessor test-s :a)) #'user/accessor-a user=> (accessor-a (struct test-2-s 5 3 2)) java.lang.Exception: Accessor/struct mismatch (NO_SOURCE_FILE:0) But thanks for the tip anyway! On Jun 29, 6:47 pm, Adrian Cuthbertson wrote: > As a matter of interest, one can get the keys keys in an unknown struct by > allocating an empty struct; > > (def st (create-struct :a :b :c)) > (keys (struct st)) > (:a :b :c) > > -Adrian. > > > > On Tue, Jun 30, 2009 at 12:14 AM, samppi wrote: > > > Wonderful. Thanks for the answer. > > > On Jun 29, 2:47 pm, Rich Hickey wrote: > > > On Jun 29, 4:59 pm, samppi wrote: > > > > > clojure.xml/parse returns a PersistentStructMap. Is there a way to > > > > refer to its struct template? I wish to create accessors for its keys, > > > > such as :tag, :attrs, and :content, with the accessor function for > > > > speed. > > > > If you look at the top of xml.clj you'll see they already exist. > > > > 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 Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Speedy accessors for the trees of clojure.xml
How about;
(defn get-accessors
"Given a struct definition, return a map of its keys and generated
accessors for each key."
[the-struct]
(let [st-kys (keys (struct the-struct))]
(reduce (fn [accsrs ky] (assoc accsrs ky
(accessor the-struct ky))) {} st-kys)))
(defstruct test-s :a :b :c)
(def acc (get-accessors test-s))
((acc :a) (struct test-s 5 3 2))
5
Obviously looking up the accessor to look up the value defeats the
performance objective, but not if you get the accessors once, "let" the
needed ones and then use them in a loop processing lots of strucs say.
On Tue, Jun 30, 2009 at 6:14 AM, samppi wrote:
>
> Yes, but I'm not so sure that you can get usable accessors with those
> keys:
> Clojure 1.0.0-
> user=> (defstruct test-s :a :b :c)
> #'user/test-s
> user=> (defstruct test-2-s :a :b :c)
> #'user/test-2-s
> user=> (def accessor-a (accessor test-s :a))
> #'user/accessor-a
> user=> (accessor-a (struct test-2-s 5 3 2))
> java.lang.Exception: Accessor/struct mismatch (NO_SOURCE_FILE:0)
>
> But thanks for the tip anyway!
>
> On Jun 29, 6:47 pm, Adrian Cuthbertson
> wrote:
> > As a matter of interest, one can get the keys keys in an unknown struct
> by
> > allocating an empty struct;
> >
> > (def st (create-struct :a :b :c))
> > (keys (struct st))
> > (:a :b :c)
> >
> > -Adrian.
> >
> >
> >
> > On Tue, Jun 30, 2009 at 12:14 AM, samppi wrote:
> >
> > > Wonderful. Thanks for the answer.
> >
> > > On Jun 29, 2:47 pm, Rich Hickey wrote:
> > > > On Jun 29, 4:59 pm, samppi wrote:
> >
> > > > > clojure.xml/parse returns a PersistentStructMap. Is there a way to
> > > > > refer to its struct template? I wish to create accessors for its
> keys,
> > > > > such as :tag, :attrs, and :content, with the accessor function for
> > > > > speed.
> >
> > > > If you look at the top of xml.clj you'll see they already exist.
> >
> > > > 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
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---
Re: clueless hash-map question
Hi,
Here would be the function returning a lazy seq of the map entries :
(def #^{:docstring "Returns a lazy seq of java.util.Map.MapEntry for
the map given as an argument." } mapentries (partial map identity))
(mapentries {:a 1 :b 2}) => ([:a 1] [:b 2]) (lazy seq)
Regards,
--
Laurent
2009/6/30 Raoul Duke :
>
> hi,
>
> is there an equivalent of java.util.Map.entrySet() or an iterator over
> that? i see things for getting the keys alone, or the vals alone. i
> guess off the cuff i find it odd that doseq on a map doesn't give me
> k-v pairs as the entries by default, but gives them interleaved.
>
> -Mr. Not Yet With The Programme.
>
> >
>
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---
Re: Clojure for Scientific and other CPU-intensive Computing
On Jun 30, 2:41 am, fft1976 wrote: > I would be curious to know if anyone is using Clojure for CPU- > intensive work where performance really counts. I'm using clojure for various computational physics tasks: 1. I'm writing a dsl for substructure searching. 2. I'm doing classical molecular dynamics / structure optimization. Substructures can be included, for coarse grain md. 3. All the parameter fitting codes suck, so I wrote one that works for atoms and/or coarse grain points. 4. Soon, I will extend my substructure searching into a full-fledged structure database. I haven't ran into any performance problems yet. If I do, there are some places where I can replace dumb algorithms with better algorithms. I will gladly trade the minor low-level inefficiencies of clojure, for the ability to easily try out high-level, possibly domain and/or data specific optimizations. Clojure rocks! --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
