Re: On Stuart's Book
On Apr 18, 3:38 pm, Rayne disciplera...@gmail.com wrote: So you want him to write something that Rich hasn't said on his website to market his book? :\ If not you're going to clarify a bit. Rayne, I think you are getting stuck on the very point I was. It feels very odd paying for Stuarts book, when Rich has done so much and I've not given him a dime. It's only because Rich is strongly encouraging the book that I purchased it, and I suspect I'm not the only person with that discomfort, so I suggested that Stuart add Rich's recommendation to his web page, to alleviate that issue. Just my two cents. g --~--~-~--~~~---~--~~ 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: IFn?
Generally, if you see this in a runtime exception, you tried to call something that does not implement the IFn interface. On Apr 18, 11:37 pm, tmountain tinymount...@gmail.com wrote: Sorry for the newbie question, but can someone tell me what IFn means exactly? I keep running into it in the docs particularly in the keyword documentation, and Google has yet to expain. Thanks, Travis --~--~-~--~~~---~--~~ 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: On Stuart's Book
Oh, I apologize. I didn't realize that Rich wrote that for Stu's book. I paid more attention to the insides of the book than the foreward :p. On Apr 19, 1:44 am, George Jahad andr...@blackbirdsystems.net wrote: On Apr 18, 3:38 pm, Rayne disciplera...@gmail.com wrote: So you want him to write something that Rich hasn't said on his website to market his book? :\ If not you're going to clarify a bit. Rayne, I think you are getting stuck on the very point I was. It feels very odd paying for Stuarts book, when Rich has done so much and I've not given him a dime. It's only because Rich is strongly encouraging the book that I purchased it, and I suspect I'm not the only person with that discomfort, so I suggested that Stuart add Rich's recommendation to his web page, to alleviate that issue. Just my two cents. g --~--~-~--~~~---~--~~ 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: Help Improving Game Of Life in clojure
Hi Michael,
Larry recently posted something similar
http://groups.google.com/group/clojure/browse_thread/thread/773e628953b40d9f
Which generated also quite a lot of discussion which you might also be
interested in.
(def matrix #{[-1 -1] [-1 0] [-1 1] [0 -1] [0 0] [0 1] [1 -1] [1 0] [1 1]})
(defn neighbours
All direct neighbours around [pos] and pos itself
[pos]
(defn translate [[x y]] [(+ x (first pos)) (+ y (second pos))])
(map translate matrix)
)
Nothing wrong with it, but using def or defn inside a defn exposes a
new global var. In this case 'translate' is now a global function
which will have values relative to the last time neighbours was
called. You could make it locally scoped by doing something like:
(let [matrix #{.}]
(defn neighbours
All direct neighbours around [pos] and pos itself
[pos]
(let [translate (fn [[x y]] ..)]
(map translate matrix
This is not really any nicer I'm only bringing it up to make sure you
are aware of the scoping implications of using defn (or def) inside a
function.
You can write an equivalent function without using matrix or
translate:
(defn neighbours
All direct neighbours around [pos] and pos itself
[[x y]]
(for [dx [-1 0 1] dy [-1 0 1]] [(+ x dx) (+ y dy)]))
new-board (map
(fn [[x y]] (if (alive [x y] board) [x y] nil))
(all-neighbours bsize board))
]
It might have been more convenient to define alive such that instead
of returning a boolean, it returns pos or nil. Then you could avoid
wrapping it in an anonymous function and just do
(map alive (all-neighbours bsize board))
(set (filter #(not (nil? %)) new-board
You can use the 'identity' function instead of not nil? to be more
concise:
user= (filter identity [1 nil 2])
(1 2)
(defn to-string
creates a string representation of a board
([board] (to-string size board))
([bsize board]
(def axis (range bsize))
(reduce
(fn [text x]
(str text (reduce
(fn [text y]
(str text (if (contains? board [x y]) # _))
)
axis)
\n)) axis)))
; untested but I think you could write this along the lines of:
(str (for [i (range bsize)]
(concat \newline
(for [j (range bsize)]
(if (contains? board [i j]) # _
(defn demo
runs a simple board 10 times
[]
(map
#(println (to-string %))
(take 10 (iterate next-board start-board))
))
map creates a lazy sequence. for side-effects to be realized the
sequence needs to be forced. This can be a bit of a trap if you are
expecting side-effects (like printing) but they never occur. Consider
using doseq instead of map in such a scenario:
(doseq [b (take 10 (iterate next-board start-board))]
(println (to-string b)))
Regards,
Tim.
--~--~-~--~~~---~--~~
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: On Stuart's Book
On 19/04/2009, at 6:32 PM, Rayne wrote: Oh, I apologize. I didn't realize that Rich wrote that for Stu's book. I paid more attention to the insides of the book than the foreward :p. On Apr 19, 1:44 am, George Jahad andr...@blackbirdsystems.net wrote: On Apr 18, 3:38 pm, Rayne disciplera...@gmail.com wrote: So you want him to write something that Rich hasn't said on his website to market his book? :\ If not you're going to clarify a bit. Rayne, I think you are getting stuck on the very point I was. It feels very odd paying for Stuarts book, when Rich has done so much and I've not given him a dime. Why not? There's a donation link for Clojure. You don't need to feel odd. It's only because Rich is strongly encouraging the book that I purchased it, and I suspect I'm not the only person with that discomfort Just for a counter data point, I have no problem paying for documentation and books - something that most o/s/ software is completely lacking. It's the task that virtually no-one wants to do (with a few significant exceptions). I've bought every Scala book available, and I'll do the same for Clojure to encourage the market for books in niche markets. If I use Clojure commercially, I'll certainly pay for it. Apart from the fact that I believe one should do so, it has the practical benefit of encouraging those who would do such work, especially in the field of development tools. Antony Blakey - CTO, Linkuistics Pty Ltd Ph: 0438 840 787 Did you hear about the Buddhist who refused Novocain during a root canal? His goal: transcend dental medication. --~--~-~--~~~---~--~~ 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: On Stuart's Book
On Apr 19, 3:20 am, Antony Blakey antony.bla...@gmail.com wrote: Why not? There's a donation link for Clojure. You don't need to feel odd. You are right of course. I just made a donation. g --~--~-~--~~~---~--~~ 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: IFn?
Thanks, makes sense. Travis On Apr 19, 12:47 am, Kevin Downey redc...@gmail.com wrote: ifn? returns true for things that implement clojure.lang.IFn, IFn is the interface for things that can be put in the operator position in a s-expr: functions vectors maps sets keywords symbols ...? fn? returns true for just functions On Sat, Apr 18, 2009 at 9:37 PM, tmountain tinymount...@gmail.com wrote: Sorry for the newbie question, but can someone tell me what IFn means exactly? I keep running into it in the docs particularly in the keyword documentation, and Google has yet to expain. Thanks, Travis -- And what is good, Phaedrus, And what is not good— Need we ask anyone to tell us these things? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Modifying data structures without changing their interface
Hi, I'm wondering about how to change a data structure without breaking the API used to access it. For example, let's assume that I have a library for dealing with records of people and I'm storing them in structs. (defstruct person :name) The users of my library access the data stored in the records like any other map. (:name some-person) When the library's been in use for a while, I realize that I need to make a change to the data structure. (defstruct :first-name :last-name) The problem is that making this change would break all the clients using the library. The obvious and traditional solution, at least for someone used to thinking in OO terms, would be to tell the clients of the library to treat the records as opaque handles, and only use the library's accessor functions to access their contents. However, I don't like this approach because it leads to a lot of boilerplate code that's there just in case I'll need it some day. It also prevents my clients from using generic map manipulation functions on the records. In Python, my current go-to language, I can have my cake and eat it too by using class properties. # A struct-like class whose members can be manipulated directly class Person1(object): name = full name p1 = Person1() print p1.name # Like above, but with three members, one of which is calculated by # a function when it is accessed class Person2(object): first_name = first last_name = last def get_name(self): return self.first_name + + self.last_name name = property(get_name) p2 = Person2() print p2.name # The old API still works, even though the data is # stored in a different way What's the idiomatic Clojure way of dealing with this issue? -- Timo --~--~-~--~~~---~--~~ 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: Modifying data structures without changing their interface
On Apr 19, 11:00 am, Timo Mihaljov noid@gmail.com wrote:
I'm wondering about how to change a data structure without breaking the
API used to access it. For example, let's assume that I have a library
for dealing with records of people and I'm storing them in structs.
(defstruct person :name)
The users of my library access the data stored in the records like any
other map.
(:name some-person)
When the library's been in use for a while, I realize that I need to
make a change to the data structure.
(defstruct :first-name :last-name)
The problem is that making this change would break all the clients using
the library.
I won't claim this is an elegant solution, but it's similar in spirit
to your Python example:
;; Original definition of person
(defn person [record]
(fn
([key] (key record))
([key value] (person (assoc record key value)
(def p1 (person {:name Stuart Sierra}))
(p1 :name)
;;= Stuart Sierra
;; Now change the definition of person.
(defn person [record]
(fn
([key]
(if (= key :name)
(str (:first-name record) (:last-name record))
(key record)))
([key value]
(if (= key :name)
(throw (Exception. :name cannot be set any more))
(person (assoc record key value))
(def p2 (person {:first-name Stuart :last-name Sierra}))
(p2 :name)
;;= Stuart Sierra
(def p3 (p2 :last-name Halloway))
(p3 :name)
;;= Stuart Halloway
-Stuart Sierra
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Clojure group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---
a functional/persistent priority queue
Hi, In case anyone is interested in participating or consuming -- for use with clojure or otherwise: Suggestions and requests are welcome: http://code.google.com/p/jc-pheap/ Summary (besides what's at the link): If only as an exercise, I've spent a little time coding up (in java right now) a paper by Brodal and Okasaki (origially found by googling) on a functional priority queue ( http://code.google.com/p/jc-pheap/source/browse/trunk/jc-pheap/src/persistent_heap/brodal_priority.pdf) with optimal worst-case runtimes. I think one thing I will do pretty soon is compare this approach (performance and memory) to just handing out copies of arrays to consumers (or some other imperative approach), but the idea/interface could be useful even then. The implementation under the hood would just change. I think this could end up being a good chance for me to start learning macros, too, to make use in clojure easy. Another thing that seems important is to try to figure out how to add decreaseKey() in a functional setting. Also, something I'm wondering about is how heaps fit into a lazy environment. I think of it as semi-lazy because some of the sorting work is delayed until values are needed (popped off the top), but it's not really like a typical stream processor/filter where only one or two elements need to be in memory at once. Finally, for fun, I'm in the middle of playing with the data-structural bootstrapping part of the paper (that code isn't checked in yet), but it's usefulness will depend on how important meld is to people (meld seems fast enough right now, maybe). --~--~-~--~~~---~--~~ 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: a functional/persistent priority queue
I'm curious to know how this approach compares to using Clojure's sorted sets or hash tables. --~--~-~--~~~---~--~~ 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: a functional/persistent priority queue
thank you for the idea. Here's how I extrapolate in terms of doing comparisons/experimentation: If sorted-set does the sort in advance, then this would be a way to delay some of that work, but if my implementation is too terrible, then there's a chance that the sorted-set is more practical. That is, perhaps a sorted-set is able to do a complete sort in the same time (or less) that it takes the heap to just insert the elements. The first is, of course O(log(n)) (unless it uses more than one processor), and the latter in this structure is O(n), but maybe the constant is way too high. But here would be an interesting situation: what if all the Heap inserts do end up being faster, but popping every element off is slower because deleteMin()'s constant is so high? Well, then there's a cross-over point that would be nice to know about. It might be better to use the heap, when you only want, say, the top K things, but if you want the top K+1 things, than it's cheaper to just sort them all. Lastly, if a heap were found that trumps sorted-set construction when adding both insert time and the time to pop all elements, then it could make sense to implement sorted-set using a heap because of it's semi-laziness. Of course, things are seldom that simple. It could be the case that one data structure is better for some size problems and on some machines than the other, in which case both have their use. On Sun, Apr 19, 2009 at 1:34 PM, Mark Engelberg mark.engelb...@gmail.comwrote: I'm curious to know how this approach compares to using Clojure's sorted sets or hash tables. --~--~-~--~~~---~--~~ 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: a functional/persistent priority queue
oh, but there's one other little point, which is that sets typically store unique values where that requirement is lifted from heaps. On Sun, Apr 19, 2009 at 1:52 PM, e evier...@gmail.com wrote: thank you for the idea. Here's how I extrapolate in terms of doing comparisons/experimentation: If sorted-set does the sort in advance, then this would be a way to delay some of that work, but if my implementation is too terrible, then there's a chance that the sorted-set is more practical. That is, perhaps a sorted-set is able to do a complete sort in the same time (or less) that it takes the heap to just insert the elements. The first is, of course O(log(n)) (unless it uses more than one processor), and the latter in this structure is O(n), but maybe the constant is way too high. But here would be an interesting situation: what if all the Heap inserts do end up being faster, but popping every element off is slower because deleteMin()'s constant is so high? Well, then there's a cross-over point that would be nice to know about. It might be better to use the heap, when you only want, say, the top K things, but if you want the top K+1 things, than it's cheaper to just sort them all. Lastly, if a heap were found that trumps sorted-set construction when adding both insert time and the time to pop all elements, then it could make sense to implement sorted-set using a heap because of it's semi-laziness. Of course, things are seldom that simple. It could be the case that one data structure is better for some size problems and on some machines than the other, in which case both have their use. On Sun, Apr 19, 2009 at 1:34 PM, Mark Engelberg mark.engelb...@gmail.comwrote: I'm curious to know how this approach compares to using Clojure's sorted sets or hash tables. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
3 new contribs: jar, classpath, find-namespaces
Hi folks! 3 new libs in contrib for your enjoyment. clojure.contrib.find-namespaces: Functions to search files in CLASSPATH, directory trees, or JAR files for Clojure namespace declarations, without loading them. This means you can do things like load all the available namespaces that start with my.cool.library. Example: (use 'clojure.contrib.find-namespaces) (filter #(.startsWith (name %) clojure.contrib.test-clojure) (find-namespaces-on-classpath)) ;; = (clojure.contrib.test-clojure clojure.contrib.test- clojure.agents clojure.contrib.test-clojure.atoms clojure.contrib.test- clojure.clojure-main ... clojure.contrib.classpath: Small utilities for examining the Java CLASSPATH. clojure.contrib.jar: Small utilities for examining JAR files. -Stuart Sierra --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: 3 new contribs: jar, classpath, find-namespaces
Hi On Sun, Apr 19, 2009 at 8:30 PM, Stuart Sierra the.stuart.sie...@gmail.com wrote: Hi folks! 3 new libs in contrib for your enjoyment. clojure.contrib.find-namespaces: Functions to search files in CLASSPATH, directory trees, or JAR files for Clojure namespace declarations, without loading them. This means you can do things like load all the available namespaces that start with my.cool.library. Example: Nice :) [...] clojure.contrib.jar: Small utilities for examining JAR files. How about lowercasing the filename and testing against .jar instead of testing against .jar and .JAR, but leaving out .Jar and other permutations? -- Michael Wood esiot...@gmail.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Modifying data structures without changing their interface
On Apr 19, 4:00 pm, Timo Mihaljov noid@gmail.com wrote: What's the idiomatic Clojure way of dealing with this issue? I'd be tempted to use accessor functions, like: (defn get-name [person] (:name person)) When the data structure changes, I update the function: (defn get-name [person] (str (:first-name person) (:last-name person))) - James --~--~-~--~~~---~--~~ 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
On Apr 17, 2:47 pm, revoltingdevelopment christopher.jay.jo...@gmail.com wrote: Aside from that, I think you are right about the psychology of language adoption and book-buying. Declaring 1.0 to coincide with the content and publication date of Stuart's book is just an excellent idea, regardless of all the other issues raised so far. I would second that and add that having a fixed version (be it .99, ot 1.0 or 1.1 or whatever) is not useful only for the book, but also for tooling. It'd be nice to have IDE plugins versions, or Waterfront versions, that depend on a fixed stable version instead of the latest snapshot which my break or change stuff from one release to the next. Of course, once there is that first stable version with which the tool works, there's no harm in having alpha or beta release of the tool version using the latest Clojure snapshot. Plus it's always nice to be able to develop a library or whatever and assigning a language version to it, like we do with Java or .Net. --~--~-~--~~~---~--~~ 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
On Apr 17, 2:47 pm, revoltingdevelopment christopher.jay.jo...@gmail.com wrote: Aside from that, I think you are right about the psychology of language adoption and book-buying. Declaring 1.0 to coincide with the content and publication date of Stuart's book is just an excellent idea, regardless of all the other issues raised so far. I would second that and add that having a fixed version (be it .99, or 1.0 or 1.1 or whatever) is not useful only for the book, but also for tooling. It'd be nice to have IDE plugins versions, or Waterfront versions, that depend on a fixed stable version instead of the latest snapshot which my break or change stuff from one release to the next. Of course, once there is that first stable version with which the tool works, there's no harm in having alpha or beta release of the tool version using the latest Clojure snapshot. Plus it's always nice to be able to develop a library or whatever and assigning a language version to it, like we do with Java or .Net. --~--~-~--~~~---~--~~ 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: a functional/persistent priority queue
But here would be an interesting situation: what if all the Heap inserts do end up being faster, but popping every element off is slower because deleteMin()'s constant is so high? Well, then there's a cross-over point that would be nice to know about. It might be better to use the heap, when you only want, say, the top K things, but if you want the top K+1 things, than it's cheaper to just sort them all. for completeness, I forgot about QuickSelect if *all* you want is the top K, and especially in an imperative setting: http://www.scribd.com/doc/4954930/Advanced-Topics-in-Sorting so I guess another part of the use case might be that different consumers want to get a potentially different top-K. So once a single heapification occurs, each consumer can have their own view and pop in O(k log(n)) time, for whatever k they want, reusing most of a shared data structure. --~--~-~--~~~---~--~~ 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
For a 1.0 release, I think that having a number that we can point at and say this software will work with that version of the language is important. I think a little bit of polish wouldn't be bad either: I saw that Scala ships with bash and batch scripts to launch scala and scalac. I think having an easy way to start using Clojure like that would definitely help newcomers. Many languages ship with modes for different editors as well; it might be nice to include the more basic modes (i.e. not SLIME and Gorilla, but clojure-mode and a syntax file for vim) Finally, I think emulating Perl's strong commitment to unit testing the language would be a beneficial thing in the long run. Cheers, Vince On Apr 16, 12:53 pm, Rich Hickey richhic...@gmail.com wrote: People (and not just book authors :) often ask - whither 1.0? [Ok, maybe they don't use 'whither']. The fact remains, some people want a 1.0 designation, and I'm not unwilling, providing we as a community can come to an understanding as to what that means, the process it implies, and the work it will require (and who will do it). Here are some of the relevant issues, IMO: - Stability/completeness/robustness This is mostly about - does it work? Is it relatively free of bugs? Is it free of gaping holes in core functionality? I think Clojure is in a pretty good place right now, but am obviously biased. This in no way implies there isn't room for improvement. - API stability With the semantic changes of fully lazy sequences behind us, I think the syntax and semantics of existing functions is largely stable. - Development process stability Currently all new work (fixes and enhancements) occurs in trunk. There's no way to get fixes without also getting enhancements. I think this is the major missing piece in offering stable numbered releases. While I've cut a branch for each of the prior two releases, no one has ever submitted a bugfix patch for either. If people are going to want to work with a particular release version for an extended period of time, someone (other than me) will have to produce patches of (only!) fixes from the trunk for the release branch, and occasionally produce point releases (1.0.x) from that branch. I'd like to continue to do the bulk of my work in trunk, without messing anyone up or forcing everyone to follow along. - Freedom from change Numbered releases are most definitely not about absence of change in general. There are more things I want to add and change, and there will be for some time. That will keep Clojure a living language. 1.0 or any numbered release can't and won't constitute a promise of no further change. But there are different kinds of change, changes that fix bugs and changes that add new capabilities or break existing code. People need to be able to choose the type of change they can tolerate, and when to incur it. - Perception Obviously, a 1.0 designation impacts perception. I am not interested in pursuing it just to influence perception, but rather to (collectively) acknowledge a milestone in usability and stability. However there may be other perceptions, good/bad or simply wrong (e.g. that Clojure is finished). Will the general perception engendered by 1.0 be met in the large, or a mismatch? What does 1.0 mean to you? Are we there yet? Any recommendations for the organization of the release branches, patch policy etc? Feedback welcome, Rich --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Help Improving Game Of Life in clojure
Thanks for the great feedback. Michael Am 19.04.2009 11:33 Uhr, schrieb Timothy Pratley: Hi Michael, Larry recently posted something similar http://groups.google.com/group/clojure/browse_thread/thread/773e628953b40d9f Which generated also quite a lot of discussion which you might also be interested in. ... --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
