Re: Fully lazy sequences are here!
Thanks Rich! Do you think it's worthwhile to add `not-empty?' in the core? It just feels more natural to go: (when (not-empty? (filter even? [1 2])) ...) over (when (seq (filter ..)) ..) What do you think? - Mike On Feb 17, 11:43 am, Rich Hickey wrote: > I've merged the lazy branch into trunk, SVN rev 1287 > > Please do not rush to this version unless you are a library/tool > developer. Let them do their ports and chime in on their progress. > Move only when the libs/tools you depend upon have been ported. > > Thanks to all for your feedback and input! > > Rich --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Curiousity with dorun
In the definition of dorun: (defn dorun "When lazy sequences are produced via functions that have side effects, any effects other than those needed to produce the first element in the seq do not occur until the seq is consumed. dorun can be used to force any effects. Walks through the successive nexts of the seq, does not retain the head and returns nil." ([coll] (when (and (seq coll) (or (first coll) true)) (recur (next coll ([n coll] (when (and (seq coll) (pos? n) (or (first coll) true)) (recur (dec n) (next coll) Why do we evaluate (or (first coll) true) instead of just calling it after the when? ie. (when (seq coll) (first coll) (recur (next coll)) I only bring this up because compiling with assert-if-lazy-seq=true and running something like: (doall (map range (repeat 0) (range 10))) brings up a lazy seq exception. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: The Path to 1.0
Rich says "Git is not going to happen any time soon, great as it may be, given the current lack of infrastructure (google code) and tools support." I'm curious as to why github isn't a viable alternative to google code? Now that it has issue tracking, I don't see the advantages of choosing google code over it (aside from the learning curve). Mike On Apr 17, 6:21 am, Rich Hickey wrote: > Thanks all for the feedback. One impression I get is that it seems the > existing community is getting along ok on trunk, so perhaps we also > need to consider those not yet using Clojure, possibly even because of > a lack of 1.0. > > I joked about book authors, but I'd like to make it clear that I think > it is very important that Stuart's book correspond to a release of > Clojure. It would be huge for newcomers coming to Clojure find a book > that says "Covers Clojure 1.0", and a compatible download for 1.0.x > with the latest fixes. > > Stuart has worked hard on tracking the latest changes, as have I in > trying to get in those changes that would be breaking as soon as I > could before 1.0. I'm presuming it's not too late to get "Covers > Clojure 1.0" in there (Stuart?), and, if so, it is a factor in this > decision. > > I'll also add that there is plenty more I'd like to do, and as soon as > I get into that trunk will again be changing rapidly. There simply has > to be a branch for fixes only. > > As to the feedback: > > A library management system seems like a tall order for a language > 1.0. It is certainly an interesting and useful pursuit, but given the > variety of approaches and opinions therein, it seems a bit out in > front of us. Advantages of Maven vs Ivy vs whatever should be > separate. Git is not going to happen any time soon, great as it may > be, given the current lack of infrastructure (google code) and tools > support. Is there some respect in which this impacts the core? It > would seem dangerous to marry any single approach in the language > itself. > > A deprecation policy is a good idea. Backward compatibility mode is > unlikely. > > As for tests, there are tests in: > > http://code.google.com/p/clojure-contrib/source/browse/#svn/trunk/src... > > Anyone who wants more tests can contribute them. > > Overall, I'm getting feature requests (more change!) and not a strong > drive for 1.0 stability. If you feel otherwise, please speak up. > Otherwise, my conclusion is that 1.0 may be more important for not-yet- > users wary of working from source. > > Rich --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
update/update-in
Hi, I was wondering why there was no "update" to "update-in"? But there is an "assoc" to "assoc-in" and a "get" to a "get-in". - Mike --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: update/update-in
Thanks for the quick reply and I understand that's the functionality of it. But just like get-in is the recursive form of get - I'm just wondering why there's no singular form of update-in. I know it's not much more work to go (update-in map [:single-key] conj 3) - but from experience there tends be really good reasons behind these kinds of decisions and I'm just curious. On Apr 29, 4:05 pm, David Nolen wrote: > Because update-in can use any function to do the update. > > On Wed, Apr 29, 2009 at 6:54 PM, mifrai wrote: > > > Hi, > > > I was wondering why there was no "update" to "update-in"? But there is > > an "assoc" to "assoc-in" and a "get" to a "get-in". > > > - Mike --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Are agents transaction'y in dosync?
This is probably a dumb question answered somewhere else, but I couldn't find it :( I noticed that there's a send-off in the dosync clause of ants.clj Does send-off hold off enqueue'ing the action when a dosync fails/ repeats or do the actions keep getting added? If it doesn't - well, ant's behave enqueues itself, so does that mean the agent queue will keep growing? --~--~-~--~~~---~--~~ 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: Are agents transaction'y in dosync?
Great! Thanks for your reply, it turned out I had a bug somewhere in my code and I was bleeding send-offs. On Jun 5, 12:06 am, Tassilo Horn wrote: > mifrai writes: > > Hi! > > > I noticed that there's a send-off in the dosync clause of ants.clj > > > Does send-off hold off enqueue'ing the action when a dosync fails/ > > repeats or do the actions keep getting added? > > send and send-off actions will only be enqueued if the transactions > succeeds. > > Bye, > Tassilo > -- > Richard Stallman wrote the compiler God used. The Big Bang was the > Universe's first segfault. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
new ns macro, excluding clojure fns?
Is there a preferred way to do the following with the ns macro: (in-ns 'myns) (refer 'clojure :exclude '(map)) or is that the only way? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Reclaiming scan and touch
I know it's minor and nit-picky but so long as we're rolling out so many breaking changes is it possible to reclaim scan and touch instead of leaving dead functions that need an :exclude? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
