Re: Is ^{:once true} still necessary for lazy-seqs?

:once mechanism isn't (if I'm not mistaken) thread-safe. That's why LazySeq and Delay had to use synchronized blocks even when they relied on :once (again, if I'm correct in the assessment that they no longer do). On Tuesday, February 18, 2014 7:39:06 PM UTC+2, pron wrote

Is ^{:once true} still necessary for lazy-seqs?

lazy-seq marks it's supplied lambdata with ^{:once true} to prevent the memory leak described at the bottom of this page . However, while going over the code for clojure.lang.LazySeq, I noticed that ever since this commit by Rich

Re: Improving the bean function with caching

; > Is there any way to invalidate this cache? > > Thanks, > Ambrose > > > On Thu, Jan 30, 2014 at 9:35 PM, pron >wrote: > >> The bean function is a very useful Java interop feature that provides a >> read-only view of a Java Bean as a Clojure map. >> As

Re: Improving the bean function with caching

Sorry, you're right. No WeakReferences on the class keys, rather a map is stored in a field of Class (similarly to ThreadLocal). BTW, this ClassValue was written by John Rose as part of JSR 292, and a very interesting implementation vis-a-vis concurrency On Thursday, January 30, 2014 4:59:40 PM

Re: Improving the bean function with caching

.Date.))) > #'user/b > user=> (def hm (into {} (select-keys b [:year :month :date]))) > #'user/hm > user=> hm > {:date 30, :month 0, :year 114} > user=> (def mb (memoize b)) > #'user/mb > user=> (mb :day) > 4 > > JW > > > > On

Improving the bean function with caching

The bean function is a very useful Java interop feature that provides a read-only view of a Java Bean as a Clojure map. As it stands, the function performs introspection on the bean's class whenever the function is called: (defn bean "Takes a Java object and returns a read-only implementation

ANN: Pulsar 0.2.0 Released

Featuring: distributed actors, supervisors, fiber-blocking IO, and an implementation of core.async. Read the announcement here . Imagine running an entire Ring handler inside a go-block... -- -

Re: core.async implemented on top of Pulsar

I had some time to play with core.async further today, and I learned some more about it. First let me say that I've completed the implementation of core.async on top of Pulsar (I've copied the alt! macro from the core.async repository and placed a copyright notice around it). I ran some of core.

Re: core.async implemented on top of Pulsar

Oh, yeah. It's 0.2-SNAPSHOT. On Monday, July 1, 2013 11:24:40 AM UTC+3, puzzler wrote: > > I'd love to try this out, but when I follow the getting started directions > and add [co.paralleluniverse/pulsar "0.1.1"] to my dependencies, I seem to > get a completely different API and namespace layout

core.async implemented on top of Pulsar

Hi. So I wanted to see how easy it would be to implement core.async on top of Pulsar. It turned out to be quite trivial, but the exercise shows the different approaches of the two projects. First, Pulsar is the Clojure API to Quasar

Julia - A new homoiconic language

Found this announcement and discussion on HN today. Julia is a new Matlab-like technical computing language that has a very interesting design: Dynamic typing

Re: ForkJoin updates

Here's a new blog post describing the effect the improved fork-join pool has had on Akka actors: http://letitcrash.com/post/17607272336/scalability-of-fork-join-pool -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email

Re: Persistent collections and garbage collection

I watched Phil Bagwell's talk and found it very interesting, but I as far as I remember he doesn't discuss GC. Anyway, let's leave this as an "open question", and I'd be interested in hearing from people who've memory-profiled their persistent collections. But I can understand from your answer t

Re: Persistent collections and garbage collection

Alright, let me explain. I'm not talking about memory leaks or whether or not objects become eligible for collection when they should. The JVM garbage collector is a generational collector, which means there's a * humongous* difference in GC work between objects that become unreachable (eligible

Re: Persistent collections and garbage collection

And have you profiled the objects making it to the old generation (requiring/causing the full GC)? Are persistent collection nodes a significant part of those? -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to cloj

Re: Persistent collections and garbage collection

Yes, that's what I thought. Does anyone have any experience with Clojure's garbage production pattern (esp. due to the persistent collection) and it's behavior with the older GCs as well as with G1? -- You received this message because you are subscribed to the Google Groups "Clojure" group. T

Persistent collections and garbage collection

Hi. I have a question: I love Clojure's persistent collections, but don't they generate many long-lived objects (that go to the surving generations) that are hard to garbage-collect? After all, the discarded nodes after "modification" are not necessarily short lived. It seems like they would beh

Re: ForkJoin updates

This is exactly what I meant. :) -- You 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 fro

ForkJoin updates

This has been posted to the concurrency-interest mailing list. Apparently there have been some nice improvements to ForkJoin: ...This also greatly improves throughput when all tasks are async and submitted to the pool

Re: Another newbie question

On Tuesday, November 8, 2011 8:42:13 PM UTC+2, Sean Corfield wrote: > > Have you looked at autodoc? > Yes, but it lacks cross-referencing and linking from within the docstrings themselves (like Javadoc's @See). I would like to suggest tagging in order to compensate for the lack of Javadoc's

Re: Another newbie question

On Tuesday, November 8, 2011 8:04:19 AM UTC+2, Sean Corfield wrote: > > docstrings? > Yeah, sure, but docstrings aren't linkable. It's interesting that Java, with all its faults, has an incredible documentation system. Scala has a problem in this field, too, since the complex typing and tricks

Re: Another newbie question

I see. So namespaces are helpful here. What other team practices do you use? E.g. what do you use for effective documentation? With Java you can easily find all helpful operations that can be used to manipulate a type. How do you make sure developers find all relevant functions in Clojure and d

Another newbie question

Hi. I'm new to Clojure, and enjoy using it very much. It's been years since I learned Scheme back in college, and it's a pleasure going back to lisp. I do, however, have a question regarding real-world Clojure use in large teams. While I clearly understand the pros of common data access/manipul