Re: When should I use non-blocking >! / threads and blocking >!! / goroutines with clojure core.async

2014-01-30 Thread Caspar Hasenclever
I think your case is exactly where not to use go blocks. Stuff in go blocks is executed on a limited size thread pool so with enough blocking I/O in there you could in theory slow down async processing. The win in using ! in go blocks is that they don't block async threads _while they are waiting

Re: Problems with &form (in an effort to make serializable functions)

2012-04-17 Thread Caspar Hasenclever
The # appears when *print-level* is exceeded in pr/pr-str, just as you get "..." when *print-lengtht* is exceeded: (pr-str {:foo {:bar {:baz 3}}}) => "{:foo {:bar {:baz 3}}}" (set! *print-level* 2) => 2 (pr-str {:foo {:bar {:baz 3}}}) => "{:foo {:bar #}}" Could it be that a preceding test sets

Re: How to represent trees for use with zippers

2012-10-16 Thread Caspar Hasenclever
Hi Dave, I don't know if there is the one true way of representing a tree as a vector, but clojure.zip allows you to zip over pretty much any structure you like, as long as you provide the right functions. The zipper function is a bit like an informal protocol in that way. The built-in vector-zip

Re: Attn: clj-time users - possible breaking change being considered!

2012-02-06 Thread Caspar Hasenclever
As Avi points out on the github issue discussion, this change would best be done throughout, i.e. wherever a DateTime instance is created, otherwise one would end up with surprising behaviour (default of UTC in date-time, default of JVM default time zone in formatter). That being said, I would arg

Re: lazy-sequences and memory leaks

2012-02-29 Thread Caspar Hasenclever
Hi Sunil, Might the problem lie within the function that consumes the seq-of-maps? There is a reduce in there that accumulates some data. I can't tell from the code whether that would amount to much, though. Regards, Caspar -- You received this message because you are subscribed to the Google