Language feature request: auto-promote int to long with unchecked-divide
Hello, This should work (I think): (unchecked-divide 1257316459070 1000) http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Running out of memory when using loop/recur and destructuring
On Tue, Nov 3, 2009 at 1:53 AM, Alex Osborne wrote: > The new loop uses the outer-let to get around this: > > (let [G__13697 s > [x & xs] G__13697 > y xs] > (loop* [G__13697 G__13697 > y y] > (let [[x & xs] G__13697 >y y] >...))) > Now, if that were (let [G__13697 (java.lang.ref.SoftReference. s) [x & xs] (.get G__13697) y xs] (loop* [G__13697 (.get G__13697) y y] (let [[x & xs] G__13697 y y] ...))) instead ... --~--~-~--~~~---~--~~ 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: (into) improvement
(into [] (concat [1 2] [3 4])) Different tools for different jobs. And Mark makes a great point about assuming too much from a particular usage. On Nov 3, 7:56 pm, mbrodersen wrote: > Currently (into) takes 2 parameters (destination and source): > > (into [] [1 2]) => [1 2] > > but not more than 2: > > (into [] [1 2] [3 4]) => Wrong number of args... > > It would be nice to have (into) work for more parameters: > > (into [] [1 2] [3 4] [5 6 7]) => [1 2 3 4 5 6 7] --~--~-~--~~~---~--~~ 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: Is it possible to implement break or return in Lisp?
I'm pretty sure there was an example of this using continuations in Dybvig's book on Scheme. I just flipped through it and didn't readily find it, but I think that is where I saw it. On Nov 1, 8:04 pm, CuppoJava wrote: > Hi, > For the purposes of a DSL that I'm writing, it would be very > convenient to have a break/return statement that early exits from a > subroutine. > > Is it possible to implement this in Clojure? or any Lisp-like > language? > > I've given it some thought and it seems it has to be a compiler level > feature. Am I right? > > Thanks > -Patrick --~--~-~--~~~---~--~~ 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: Running out of memory when using loop/recur and destructuring
I agree that seqs carry a large degree of risk. You have to work very hard to avoid giving your large sequences a name, lest you accidentally "hang on to the head". In Clojure's early days, I complained about this and described some of my own experiments with uncached sequences. Rich said he was experimenting with another model for uncached iterator-like constructs, I think he called them streams. As far as I know, none of that has ever made it into Clojure. So I still feel there's a need here that eventually needs to be addressed. Clojure's built-in "range" function (last time I looked) essentially produces an uncached sequence. And that makes a lot of sense. Producing the next value in a range on-demand is way more efficient and practical than caching those values. I think that Clojure programmers should have an easy way to make similarly uncached sequences if that's what they really want/need. (Well, obviously you can drop down into Java and use some of the same tricks that range uses, but I mean it should be easy to do this from within Clojure). --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Baffled by NPE
I'm working the exercises in SICP using Clojure and learning Clojure as I go. I've stumbled across a mystifying NullPointerException. I'm implementing exercise 2.23, where you're supposed to implement a "for-each" method that takes a function and a list of items. It applies the function to teach item. Here's what I tried. (defn for-each [f items] (if (not (empty? items)) ((f (first items)) (for-each f (rest items) ; line #3 (for-each (fn [x] (println (* x x))) (list 1 2 3 4 5)) Here's the output: 1 4 9 16 25 Exception in thread "main" java.lang.NullPointerException (ex2.23.clj:0) at clojure.lang.Compiler.eval(Compiler.java:4620) at clojure.lang.Compiler.load(Compiler.java:4934) at clojure.lang.Compiler.loadFile(Compiler.java:4901) at clojure.main$load_script__7261.invoke(main.clj:210) at clojure.main$script_opt__7298.invoke(main.clj:262) at clojure.main$main__7322.doInvoke(main.clj:337) at clojure.lang.RestFn.invoke(RestFn.java:413) at clojure.lang.Var.invoke(Var.java:359) at clojure.lang.AFn.applyToHelper(AFn.java:173) at clojure.lang.Var.applyTo(Var.java:476) at clojure.main.main(main.java:37) Caused by: java.lang.NullPointerException at user$for_each__1.invoke(ex2.23.clj:3) at user$for_each__1.invoke(ex2.23.clj:3) at user$for_each__1.invoke(ex2.23.clj:3) at user$for_each__1.invoke(ex2.23.clj:3) at user$for_each__1.invoke(ex2.23.clj:3) at user$eval__4.invoke(ex2.23.clj:5) at clojure.lang.Compiler.eval(Compiler.java:4604) ... 10 more I tried replacing the list in the last line with a vector. Same result. Suggestions welcome! dean -- Dean Wampler coauthor of "Programming Scala" (O'Reilly) - http://programmingscala.com twitter: @deanwampler, @chicagoscala Chicago-Area Scala Enthusiasts (CASE): - http://groups.google.com/group/chicagoscala - http://www.meetup.com/chicagoscala/ (Meetings) http://www.linkedin.com/in/deanwampler http://www.polyglotprogramming.com http://aquarium.rubyforge.org http://www.contract4j.org --~--~-~--~~~---~--~~ 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 release of Enclojure for Netbeans is up - enclojure-plugin-2009-11-3.nbm
There was a considerable faux pas on my part with the enclojure- plugin-2009-09-22-patch1.nbm in which I used Java 1.6 to build it. This release addresses the above as well as some bugs on Windows and enhancements. Selected highlights from the git log: > Added support for loading all source from a given source group for a project > into a repl. > Fixed some bugs in order to support other java project types (web projects) > on repl startup. > Added functionality for inspecting java platforms. Added the :java-exe to the > repl-data for startup Changed the project and stand alone repl startups to > use the full path of the java-exe for the default platform. > Fixed a bug where the Project REPLs were not guaranteed to use the assigned > Java Platform in their project. > Added USERPROFILE environment variable for preferences on Windows platforms; > fixes #16 Added context menu for loaded selected clojure source files. > Added test dirs to projects. > Fixed a completion bug where the context was getting confused in some cases > causing no symbols to be suggested at all. > Author Eric Thor: Fixed a completion bug when there was no context. Thanks again for all the feedback and bug reports! Eric --~--~-~--~~~---~--~~ 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: (into) improvement
On Tue, Nov 3, 2009 at 7:56 PM, mbrodersen wrote: > It would be nice to have (into) work for more parameters: > > (into [] [1 2] [3 4] [5 6 7]) => [1 2 3 4 5 6 7] If you did this, it would be very easy to get confused and think that: (into [] [1 2] [3 4] [5 6 7]) would yield [[1 2] [3 4] [5 6 7]] --~--~-~--~~~---~--~~ 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: Periodic tasks
> I'd love to hear success stories from people using nailgun to actually > run frequent scripted tasks out of cron, as opposed to for > development. It would make clojure more palatable for my work > environment. Nailgun has been a boon to me. I don't believe Nailgun has a problem with dynamic classes - only that you have to remember to stop/start Nailgun to ensure its ClassLoader gets the latest classes (I would be genuinely interested in any details that show otherwise). F.E. I can: 1. (def q (vec (range 100))) 2. use jvisualvm to see q takes up ~20MB RAM; 20 bytes / Integer. 3. (def q "abc") 4. use jvisualvm and it will show the 20MB has been GC'd just fine. (I'm not sure what sort of dynamic class / unload/ GC? issue you were referring to). Since it takes Spring a long time to instantiate all of the configured objects using Nailgun really does save me time. I have a lot of nifty command line tools that help me resolve support issues and waiting for Spring (not the JVM really) to instantiate and wire everything up really slowed me down. Nailgun solves the speed problem and I haven't had any problems with it. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
(into) improvement
Currently (into) takes 2 parameters (destination and source): (into [] [1 2]) => [1 2] but not more than 2: (into [] [1 2] [3 4]) => Wrong number of args... It would be nice to have (into) work for more parameters: (into [] [1 2] [3 4] [5 6 7]) => [1 2 3 4 5 6 7] --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
(info) improvement?
Currently (into) takes 2 parameters (destination and source) (into [] [1 2]) => [1 2] but not more than 2: (into [] [1 2] [3 4]) => Wrong number of args... It would be nice to have (into) work for more parameters: (into [] [1 2] [3 4]) => [1 2 3 4] --~--~-~--~~~---~--~~ 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: Cross platform clojure
> I would propose no changes to Clojure, no > conditional compilation techniques or reader modifications. Just > things like macros that have simple functionality and that at most > check one flag to conditionalize output. I wouldn't immediately object to reader macro conditionalization here. Imagining each port of Clojure to be like a different Lisp implementation (yes, I know, it's not), one sees this all the time: #+:sbcl (defun foo (x) (bar)) #-:sbcl (defun foo (x) (noz)) It's not a big stretch to imagine that being #+:clojure-clr and # +:clojure-jvm. --~--~-~--~~~---~--~~ 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: Continuous Integration Server & Maven/Ivy Repo
I forgot to mention that there is still one small issue https://www.assembla.com/spaces/clojure/tickets/208-pom-uses-old-artifactId that needs fixed. org.clojure clojure-lang 1.1.0-alpha-SNAPSHOT Until it's fixed you can use ^ On Nov 3, 5:10 pm, dysinger wrote: > Hello, > > Today Phil Hagelberg, Rich Hickey and myself setup a CI server for > clojure & contrib ->http://build.clojure.org(hudson -> github) > > If you use maven-ant-tasks (+1) or maven 2.x (or ivy too) you can do > something like this in your settings.xml or pom.xml > > > clojure-snapshot > http://build.clojure.org > > false > > > true > > > > Then you can add clojure snapshot as a project dependency > > > org.clojure > clojure > 1.1.0-alpha-SNAPSHOT > > > :) #l8r --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Continuous Integration Server & Maven/Ivy Repo
Hello, Today Phil Hagelberg, Rich Hickey and myself setup a CI server for clojure & contrib -> http://build.clojure.org (hudson -> github) If you use maven-ant-tasks (+1) or maven 2.x (or ivy too) you can do something like this in your settings.xml or pom.xml clojure-snapshot http://build.clojure.org false true Then you can add clojure snapshot as a project dependency org.clojure clojure 1.1.0-alpha-SNAPSHOT :) #l8r --~--~-~--~~~---~--~~ 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: Syntax highlighting clojure code
I have used SyntaxHighligter (http://alexgorbatchev.com/) on my blog with the Clojure brush from http://www.undermyhat.org/blog/2009/09/list-of-brushes-syntaxhighligher/ It seems to work fairly well. /Patrik On Nov 3, 9:02 am, Christophe Grand wrote: > pygments (which is used by github) does a good job too. > > On Tue, Nov 3, 2009 at 12:41 AM, Stefan Arentz wrote: > > > I want to post some Clojure code to my blog. Does anyone know of a > > simple, preferably online, code highlighter for Clojure or Lisp that > > turns code into simple html with either a stylesheet or just > color=""> tags? > > > S. > > -- > Professional:http://cgrand.net/(fr) > On Clojure:http://clj-me.cgrand.net/(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: Running out of memory when using loop/recur and destructuring
I understand the pragmatism of your approach, but it's really unfortunate. Seqs are a really convenient abstraction, and the ability to model arbitrarily large or infinite ones (with laziness) is really useful. In my opinion, only using seqs when all of the data can be fit into memory really undermines the value of the abstraction (by narrowing its usages so severely), and also makes laziness far less useful (except possibly as a way to amortize costs over time, rather than as a way to model infinite things). This path has been well-tread, but the danger of hanging on to the head of the list is due to the caching behavior of lazy seqs, which is important for consistency - otherwise, walking the same seq twice might result in different results. As with most engineering efforts, there are trade-offs, but I've been willing to accept the extra caution I need to employ when dealing with lazy seqs. I've run into a few of these kinds of bugs over time, and I'm guessing it's generally because in my uses, I'm dealing with millions of records, and far more data than I can fit in memory. I'm not sure that this indicates that seqs are the wrong tool in this instance (as you seem to say), but the answer isn't clear to me. On Nov 3, 1:20 pm, Brian Hurt wrote: > We finally said "don't use a seq unless you don't mind all the elements > being in memory!" and wrote a producer class. The producer class is similar > to a normal Java iterator, in that getting the next element updates the > state of the object- however maps and filters are applied lazily, and there > is an additional close function which says that no more elements need to be > produced (allowing for the closing the underlying file descriptor, for > example). > > I disbelieve in golden hammers. Seqs (aka lazy lists) are incredibly useful > in a lot of places, and I'm glad that Clojure has them. On the other hand, > there are times and uses where seqs are the wrong tool to use. Of course, > the same can be said of producers. --~--~-~--~~~---~--~~ 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: Running out of memory when using loop/recur and destructuring
In the particular case given below, I'd assume that during the invocation of print-seq, the binding to "s" (the head of the sequence) would be retained, because my mental model for the execution environment of a function is that it is the environment in which they were declared, extended with the bindings for their parameters. So, anything inside that function execution should have a reference to that environment, and I would expect those bindings to exist until the function has completed. I seem to recall that in clojure's implementation, environments aren't reified as such, but I believe the behavior is the same. If certain JDKs are smart enough to avoid this, I consider that an implementation detail of that JDK, and thus (as with most optimizations), it's not something you should depend upon for correctness. I can't dispute your point that subtle bugs can occur with seqs, but I think that in most cases, it isn't that bad. I'm hopeful that as we find these kinds of bugs in core clojure forms, that we can get them addressed. Most of the bugs of this sort that I've introduced in my own code have been relatively straightforward to diagnose and debug. On Nov 3, 2:47 pm, Brian Hurt wrote: > I agree. I don't like having to ditch seqs. And producers bring their own > downsides- for example, being imperative constructs, they open the door for > race conditions on multi-threaded code in a way that seqs don't. If > anything, producers have a more-limited range of applicability than seqs, or > even iterators, do. Also, polluting the meme-space with three constructs > which are very similiar, but subtly different, is also a problem I'm not > happy with. > > But here's an example of the sorts of problems we were hitting. OK, we all > know that doseq doesn't hold on to the head of the seq. But what if I > write: > (defn print-seq [ s ] > (doseq [ x s ] > (println x))) > Does this code hold on to the head of the seq (in the argument to the > function)? I'm honestly not sure- and strongly suspect that the answer > depends upon (among other things) which JVM you run the code on (and which > optimizations it will perform), and how long the code has been running (and > thus what optimizations have been performed on the code). > > And even if it doesn't, then I have no doubt that with a little > complication, I can develop code that does (or at least might) hold on the > head of the seq unnecessarily. Which means this is not only an issue for > the original writer of the code, but also the maintainer. > > It's not clear. If you know that millions of records are as large as you're > going to see, then seqs are the right tool- and if you load everything into > memory, oh well. If the number of records might creep into the billions or > trillions, then seqs (with their risk of wanting to keep everything in > memory) are a bad choice IMHO. --~--~-~--~~~---~--~~ 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: Baffled by NPE
On Nov 3, 9:41 pm, jan wrote: > When you only have a single branch in `if' it is more conventional to > use `when', or in this case `when-not'. And defn sets up a recur point > so there's no need for the explicit loop either. I thought "when" was mainly used for side-effects? "if" seems more appropriate if you just want the return value. - 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 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: Baffled by NPE
On Tue, Nov 3, 2009 at 4:22 PM, Brian Hurt wrote: > > > On Tue, Nov 3, 2009 at 4:21 PM, Dean Wampler wrote: > >> Ah, of course. Thanks. This works: >> >> (defn for-each [f items] >> (if (not (empty? items)) >> (let [] (f (first items)) (for-each f (rest items) >> >> > Or: > > (defn for-each [ f items] > > Argh. Hit send when I didn't mean to. Sorry. Try again: (defn for-each [f items] (if (not (empty? items)) (do (f (first items)) (for-each f (rest items) Of course, you don't have tail call optimization in Clojure (dang jvm). So this is probably better: (defn for-each [f items] (loop [ curr items ] (if (empty? curr) nil (do (f (first curr)) (recur (rest curr)) Brian --~--~-~--~~~---~--~~ 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: Baffled by NPE
On Tue, Nov 3, 2009 at 4:21 PM, Dean Wampler wrote: > Ah, of course. Thanks. This works: > > (defn for-each [f items] > (if (not (empty? items)) > (let [] (f (first items)) (for-each f (rest items) > > Or: (defn for-each [ f items] > (for-each (fn [x] (println (* x x))) (list 1 2 3 4 5)) > > On Tue, Nov 3, 2009 at 3:13 PM, Kevin Downey wrote: > >> >> (f (first items)) => nil >> ((f (first items)) (for-each f (rest items))) => (nil (for-each f >> (rest items))) => (.invoke nil (for-each f (rest items))) => calling a >> method on nil is a NPE >> >> lists are function applications >> >> On Tue, Nov 3, 2009 at 9:33 AM, Dean Wampler >> wrote: >> > I'm working the exercises in SICP using Clojure and learning Clojure as >> I >> > go. I've stumbled across a mystifying NullPointerException. I'm >> implementing >> > exercise 2.23, where you're supposed to implement a "for-each" method >> that >> > takes a function and a list of items. It applies the function to teach >> item. >> > Here's what I tried. >> > (defn for-each [f items] >> > (if (not (empty? items)) >> > ((f (first items)) (for-each f (rest items) ; line #3 >> > >> > (for-each (fn [x] (println (* x x))) (list 1 2 3 4 5)) >> > Here's the output: >> > 1 >> > 4 >> > 9 >> > 16 >> > 25 >> > Exception in thread "main" java.lang.NullPointerException (ex2.23.clj:0) >> > at clojure.lang.Compiler.eval(Compiler.java:4620) >> > at clojure.lang.Compiler.load(Compiler.java:4934) >> > at clojure.lang.Compiler.loadFile(Compiler.java:4901) >> > at clojure.main$load_script__7261.invoke(main.clj:210) >> > at clojure.main$script_opt__7298.invoke(main.clj:262) >> > at clojure.main$main__7322.doInvoke(main.clj:337) >> > at clojure.lang.RestFn.invoke(RestFn.java:413) >> > at clojure.lang.Var.invoke(Var.java:359) >> > at clojure.lang.AFn.applyToHelper(AFn.java:173) >> > at clojure.lang.Var.applyTo(Var.java:476) >> > at clojure.main.main(main.java:37) >> > Caused by: java.lang.NullPointerException >> > at user$for_each__1.invoke(ex2.23.clj:3) >> > at user$for_each__1.invoke(ex2.23.clj:3) >> > at user$for_each__1.invoke(ex2.23.clj:3) >> > at user$for_each__1.invoke(ex2.23.clj:3) >> > at user$for_each__1.invoke(ex2.23.clj:3) >> > at user$eval__4.invoke(ex2.23.clj:5) >> > at clojure.lang.Compiler.eval(Compiler.java:4604) >> > ... 10 more >> > >> > I tried replacing the list in the last line with a vector. Same result. >> > Suggestions welcome! >> > dean >> > >> > -- >> > Dean Wampler >> > coauthor of "Programming Scala" (O'Reilly) >> > - http://programmingscala.com >> > >> > twitter: @deanwampler, @chicagoscala >> > Chicago-Area Scala Enthusiasts (CASE): >> > - http://groups.google.com/group/chicagoscala >> > - http://www.meetup.com/chicagoscala/ (Meetings) >> > http://www.linkedin.com/in/deanwampler >> > http://www.polyglotprogramming.com >> > http://aquarium.rubyforge.org >> > http://www.contract4j.org >> > >> > > >> > >> >> >> >> -- >> And what is good, Phaedrus, >> And what is not good— >> Need we ask anyone to tell us these things? >> >> >> > > > -- > Dean Wampler > coauthor of "Programming Scala" (O'Reilly) > - http://programmingscala.com > > twitter: @deanwampler, @chicagoscala > Chicago-Area Scala Enthusiasts (CASE): > - http://groups.google.com/group/chicagoscala > - http://www.meetup.com/chicagoscala/ (Meetings) > http://www.linkedin.com/in/deanwampler > http://www.polyglotprogramming.com > http://aquarium.rubyforge.org > http://www.contract4j.org > > > > --~--~-~--~~~---~--~~ 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: Cross platform clojure
On Nov 3, 9:08 am, Sean Devlin wrote: > My understanding is that the current expectation is to allow > differences in the way each platform does its job. Contrib currently > is expected to behave differently on the CLR and the JVM. For > example, the str-utils and sql-utils libraries would need to be > completely re-written to work w/ the CLR. It would be relatively easy to translate str-utils to the CLR. It would make no sense to translate sql-utils (JDBC wrapper). I can't speak to all the nuances of Rich's thinking on the subject, but I'm pretty sure letting "each platform [do] its job" certainly applies to sql-utils. In other words, a library which is a wrapper around a Java library does not need to be on the CLR platform, and conversely. For str-utils, I think the question is more interesting. It will take a relatively small set of edits to make it run on the CLR implmentation, things like changing type hints, modifying method names -- .toLowerCase becomes .ToLower, for example. I've done this sort of thing to port core.clj, core_print.clj, etc. The manipulations are fairly straightforward. I have done them as manual edits. In fact, I have tried (successfully) to modify them without even disturbing the original line numbers, to ease moving changes over from the JVM version. For the core libraries, I think things need to remain this way. For other libraries, things in clojure-contrib such as str-utils, the question is whether there are a few coding techniques that, if followed, make it easy to write cross-platform code rather than doing ad-hoc manual editing.I would propose no changes to Clojure, no conditional compilation techniques or reader modifications. Just things like macros that have simple functionality and that at most check one flag to conditionalize output. Word of warning: even this level of bother may violate Rich's intent. In which case, I'll go away. I have a few ideas for this, but welcome design input from anyone with an interest. It's this, or write a a really nasty Perl script. :) -David --~--~-~--~~~---~--~~ 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: Running out of memory when using loop/recur and destructuring
We encountered similar problems at work trying to wrap I/O up into lazy seq's. The problem is that it is very easy to accidentally hold on to the head of a seq while enumerating it's elements. In addition, we had problems with not closing file descriptors. A common pattern was to open a file, produce a lazy seq of the contents of the file, closing the file when the last element was read. The seq would then be passed off to other parts of the code, which would read some of the elements, and then drop the seq- leaking the open file handle (at least until the gc got around to it). We finally said "don't use a seq unless you don't mind all the elements being in memory!" and wrote a producer class. The producer class is similar to a normal Java iterator, in that getting the next element updates the state of the object- however maps and filters are applied lazily, and there is an additional close function which says that no more elements need to be produced (allowing for the closing the underlying file descriptor, for example). I disbelieve in golden hammers. Seqs (aka lazy lists) are incredibly useful in a lot of places, and I'm glad that Clojure has them. On the other hand, there are times and uses where seqs are the wrong tool to use. Of course, the same can be said of producers. Brian --~--~-~--~~~---~--~~ 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: Baffled by NPE
Also Clojure has doseq which defeats the learning exercise but nets a nicer golf score of 14: (defn for-each [f items] (doseq [i items] (f i))) --~--~-~--~~~---~--~~ 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: Cross platform clojure
On Tue, Nov 3, 2009 at 7:09 PM, dmiller wrote: > I have a few ideas for this, but welcome design input from anyone > with an interest. > > It's this, or write a a really nasty Perl script. :) You dare to threaten us??! :) --~--~-~--~~~---~--~~ 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: Baffled by NPE
Brian Hurt writes: > Of course, you don't have tail call optimization in Clojure (dang jvm). So > this is probably better: > (defn for-each [f items] > (loop [ curr items ] > (if (empty? curr) > nil > (do > (f (first curr)) > (recur (rest curr)) When you only have a single branch in `if' it is more conventional to use `when', or in this case `when-not'. And defn sets up a recur point so there's no need for the explicit loop either. (defn for-each [f items] (when-not (empty? items) (f (first items)) (recur f (rest items -- jan --~--~-~--~~~---~--~~ 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: Baffled by NPE
Ah, of course. Thanks. This works: (defn for-each [f items] (if (not (empty? items)) (let [] (f (first items)) (for-each f (rest items) (for-each (fn [x] (println (* x x))) (list 1 2 3 4 5)) On Tue, Nov 3, 2009 at 3:13 PM, Kevin Downey wrote: > > (f (first items)) => nil > ((f (first items)) (for-each f (rest items))) => (nil (for-each f > (rest items))) => (.invoke nil (for-each f (rest items))) => calling a > method on nil is a NPE > > lists are function applications > > On Tue, Nov 3, 2009 at 9:33 AM, Dean Wampler > wrote: > > I'm working the exercises in SICP using Clojure and learning Clojure as I > > go. I've stumbled across a mystifying NullPointerException. I'm > implementing > > exercise 2.23, where you're supposed to implement a "for-each" method > that > > takes a function and a list of items. It applies the function to teach > item. > > Here's what I tried. > > (defn for-each [f items] > > (if (not (empty? items)) > > ((f (first items)) (for-each f (rest items) ; line #3 > > > > (for-each (fn [x] (println (* x x))) (list 1 2 3 4 5)) > > Here's the output: > > 1 > > 4 > > 9 > > 16 > > 25 > > Exception in thread "main" java.lang.NullPointerException (ex2.23.clj:0) > > at clojure.lang.Compiler.eval(Compiler.java:4620) > > at clojure.lang.Compiler.load(Compiler.java:4934) > > at clojure.lang.Compiler.loadFile(Compiler.java:4901) > > at clojure.main$load_script__7261.invoke(main.clj:210) > > at clojure.main$script_opt__7298.invoke(main.clj:262) > > at clojure.main$main__7322.doInvoke(main.clj:337) > > at clojure.lang.RestFn.invoke(RestFn.java:413) > > at clojure.lang.Var.invoke(Var.java:359) > > at clojure.lang.AFn.applyToHelper(AFn.java:173) > > at clojure.lang.Var.applyTo(Var.java:476) > > at clojure.main.main(main.java:37) > > Caused by: java.lang.NullPointerException > > at user$for_each__1.invoke(ex2.23.clj:3) > > at user$for_each__1.invoke(ex2.23.clj:3) > > at user$for_each__1.invoke(ex2.23.clj:3) > > at user$for_each__1.invoke(ex2.23.clj:3) > > at user$for_each__1.invoke(ex2.23.clj:3) > > at user$eval__4.invoke(ex2.23.clj:5) > > at clojure.lang.Compiler.eval(Compiler.java:4604) > > ... 10 more > > > > I tried replacing the list in the last line with a vector. Same result. > > Suggestions welcome! > > dean > > > > -- > > Dean Wampler > > coauthor of "Programming Scala" (O'Reilly) > > - http://programmingscala.com > > > > twitter: @deanwampler, @chicagoscala > > Chicago-Area Scala Enthusiasts (CASE): > > - http://groups.google.com/group/chicagoscala > > - http://www.meetup.com/chicagoscala/ (Meetings) > > http://www.linkedin.com/in/deanwampler > > http://www.polyglotprogramming.com > > http://aquarium.rubyforge.org > > http://www.contract4j.org > > > > > > > > > > > -- > And what is good, Phaedrus, > And what is not good— > Need we ask anyone to tell us these things? > > > > -- Dean Wampler coauthor of "Programming Scala" (O'Reilly) - http://programmingscala.com twitter: @deanwampler, @chicagoscala Chicago-Area Scala Enthusiasts (CASE): - http://groups.google.com/group/chicagoscala - http://www.meetup.com/chicagoscala/ (Meetings) http://www.linkedin.com/in/deanwampler http://www.polyglotprogramming.com http://aquarium.rubyforge.org http://www.contract4j.org --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Determining whether tests pass.
It would be very useful for integrating into automated build systems if clojure.test/run-tests returned a true/false value depending on whether the tests pass. It's pretty easy to do this by changing report's :summary method as shown below. Thoughts? -Phil diff --git a/src/clj/clojure/test.clj b/src/clj/clojure/test.clj index 37cdd7e..214d3cc 100644 --- a/src/clj/clojure/test.clj +++ b/src/clj/clojure/test.clj @@ -579,7 +579,8 @@ Chas Emerick, Allen Rohner, and Stuart Halloway", (with-test-out (println "\nRan" (:test m) "tests containing" (+ (:pass m) (:fail m) (:error m)) "assertions.") - (println (:fail m) "failures," (:error m) "errors."))) + (println (:fail m) "failures," (:error m) "errors.")) + (= 0 (:fail m) (:error m))) (defmethod report :begin-test-ns [m] (with-test-out --~--~-~--~~~---~--~~ 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: Running out of memory when using loop/recur and destructuring
On Tue, Nov 3, 2009 at 5:19 PM, Paul Mooser wrote: > > I understand the pragmatism of your approach, but it's really > unfortunate. Seqs are a really convenient abstraction, and the ability > to model arbitrarily large or infinite ones (with laziness) is really > useful. In my opinion, only using seqs when all of the data can be fit > into memory really undermines the value of the abstraction (by > narrowing its usages so severely), and also makes laziness far less > useful (except possibly as a way to amortize costs over time, rather > than as a way to model infinite things). > > I agree. I don't like having to ditch seqs. And producers bring their own downsides- for example, being imperative constructs, they open the door for race conditions on multi-threaded code in a way that seqs don't. If anything, producers have a more-limited range of applicability than seqs, or even iterators, do. Also, polluting the meme-space with three constructs which are very similiar, but subtly different, is also a problem I'm not happy with. But here's an example of the sorts of problems we were hitting. OK, we all know that doseq doesn't hold on to the head of the seq. But what if I write: (defn print-seq [ s ] (doseq [ x s ] (println x))) Does this code hold on to the head of the seq (in the argument to the function)? I'm honestly not sure- and strongly suspect that the answer depends upon (among other things) which JVM you run the code on (and which optimizations it will perform), and how long the code has been running (and thus what optimizations have been performed on the code). And even if it doesn't, then I have no doubt that with a little complication, I can develop code that does (or at least might) hold on the head of the seq unnecessarily. Which means this is not only an issue for the original writer of the code, but also the maintainer. > This path has been well-tread, but the danger of hanging on to the > head of the list is due to the caching behavior of lazy seqs, which is > important for consistency - otherwise, walking the same seq twice > might result in different results. > > As with most engineering efforts, there are trade-offs, but I've been > willing to accept the extra caution I need to employ when dealing with > lazy seqs. I've run into a few of these kinds of bugs over time, and > I'm guessing it's generally because in my uses, I'm dealing with > millions of records, and far more data than I can fit in memory. I'm > not sure that this indicates that seqs are the wrong tool in this > instance (as you seem to say), but the answer isn't clear to me. > It's not clear. If you know that millions of records are as large as you're going to see, then seqs are the right tool- and if you load everything into memory, oh well. If the number of records might creep into the billions or trillions, then seqs (with their risk of wanting to keep everything in memory) are a bad choice IMHO. Brian --~--~-~--~~~---~--~~ 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: Baffled by NPE
(f (first items)) => nil ((f (first items)) (for-each f (rest items))) => (nil (for-each f (rest items))) => (.invoke nil (for-each f (rest items))) => calling a method on nil is a NPE lists are function applications On Tue, Nov 3, 2009 at 9:33 AM, Dean Wampler wrote: > I'm working the exercises in SICP using Clojure and learning Clojure as I > go. I've stumbled across a mystifying NullPointerException. I'm implementing > exercise 2.23, where you're supposed to implement a "for-each" method that > takes a function and a list of items. It applies the function to teach item. > Here's what I tried. > (defn for-each [f items] > (if (not (empty? items)) > ((f (first items)) (for-each f (rest items) ; line #3 > > (for-each (fn [x] (println (* x x))) (list 1 2 3 4 5)) > Here's the output: > 1 > 4 > 9 > 16 > 25 > Exception in thread "main" java.lang.NullPointerException (ex2.23.clj:0) > at clojure.lang.Compiler.eval(Compiler.java:4620) > at clojure.lang.Compiler.load(Compiler.java:4934) > at clojure.lang.Compiler.loadFile(Compiler.java:4901) > at clojure.main$load_script__7261.invoke(main.clj:210) > at clojure.main$script_opt__7298.invoke(main.clj:262) > at clojure.main$main__7322.doInvoke(main.clj:337) > at clojure.lang.RestFn.invoke(RestFn.java:413) > at clojure.lang.Var.invoke(Var.java:359) > at clojure.lang.AFn.applyToHelper(AFn.java:173) > at clojure.lang.Var.applyTo(Var.java:476) > at clojure.main.main(main.java:37) > Caused by: java.lang.NullPointerException > at user$for_each__1.invoke(ex2.23.clj:3) > at user$for_each__1.invoke(ex2.23.clj:3) > at user$for_each__1.invoke(ex2.23.clj:3) > at user$for_each__1.invoke(ex2.23.clj:3) > at user$for_each__1.invoke(ex2.23.clj:3) > at user$eval__4.invoke(ex2.23.clj:5) > at clojure.lang.Compiler.eval(Compiler.java:4604) > ... 10 more > > I tried replacing the list in the last line with a vector. Same result. > Suggestions welcome! > dean > > -- > Dean Wampler > coauthor of "Programming Scala" (O'Reilly) > - http://programmingscala.com > > twitter: @deanwampler, @chicagoscala > Chicago-Area Scala Enthusiasts (CASE): > - http://groups.google.com/group/chicagoscala > - http://www.meetup.com/chicagoscala/ (Meetings) > http://www.linkedin.com/in/deanwampler > http://www.polyglotprogramming.com > http://aquarium.rubyforge.org > http://www.contract4j.org > > > > -- 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 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: Running out of memory when using loop/recur and destructuring
Ah -- I hadn't understood that when using destructuring, that subsequent bindings could refer to the destructured elements. I should have, since clojure "only" has let*, and this behavior seems consistent with that, for binding. Eeww. It seems like quite a thorny issue to solve, even if simple to describe. What's the procedure for creating a ticket for this? Is it at least acknowledged that this IS a bug? I don't see it in the list of assembla tickets for clojure. --~--~-~--~~~---~--~~ 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: Baffled by NPE
> I thought "when" was mainly used for side-effects? "if" seems more > appropriate if you just want the return value. It's perfectly appropriate and idiomatic when you want the alternative return value to be nil, and you don't want to confuse matters by having a one-element `if`, or an `if` that returns nil. --~--~-~--~~~---~--~~ 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: Cross platform clojure
My understanding is that the current expectation is to allow differences in the way each platform does its job. Contrib currently is expected to behave differently on the CLR and the JVM. For example, the str-utils and sql-utils libraries would need to be completely re-written to work w/ the CLR. Good luck. On Nov 3, 7:58 am, Jim Downing wrote: > Hi all, > > I've been watching the development of ClojureCLR with some interest - > my research group have roughly equivalent APIs in C# and Java and > we're going to want to formalize the arrangement soon. At the same > time I've been using Clojure as a functional JVM lang. It would be > sweet to write this library once in Clojure such that it would run on > either platform. > > I'd assumed that a good way to proceed would be to favour use of > libraries, to create an idiomatic way of denoting platform-native > functions (similar to using ! to highlight side-effects), and then > maybe to work out a way to rebinding native function names to their > platform specific implementations at runtime. > > I'm not sure I'm in line with community wisdom here though - I get the > impression that there's a directive to make fairly heavy use of the > underlying platforms, and that ClojureCLR will therefore be a parallel > implementation of Clojure, rather than an alternative core under a > larger pure Clojure universe of contrib libraries and developer code. > > Have I understood this right? What will be the best way to go about > writing and managing a cross-platform Clojure library? > > Best regards, > jim --~--~-~--~~~---~--~~ 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 is two!
On Oct 19, 9:25 pm, ngocdaothanh wrote: > For most programming languages, I only need 2 books: an introduction > one and a cookbook one. +1 for a Clojure cookbook. The same combo for Perl was very effective for me. -Ross --~--~-~--~~~---~--~~ 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: Is it possible to implement break or return in Lisp?
On Nov 3, 12:03 am, CuppoJava wrote: > But I'm writing a DSL for others to use. People that don't have > experience with functional programming, and for them it's easier to > have a break/return. That doesn't seem like a good idea to me. Clojure is a functional programming language; trying to treat it as an procedural language is a bad habit to get into, and there are many hidden gotchas with things like lazy evaluation of sequences. - 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 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 -~--~~~~--~~--~--~---
Cross platform clojure
Hi all, I've been watching the development of ClojureCLR with some interest - my research group have roughly equivalent APIs in C# and Java and we're going to want to formalize the arrangement soon. At the same time I've been using Clojure as a functional JVM lang. It would be sweet to write this library once in Clojure such that it would run on either platform. I'd assumed that a good way to proceed would be to favour use of libraries, to create an idiomatic way of denoting platform-native functions (similar to using ! to highlight side-effects), and then maybe to work out a way to rebinding native function names to their platform specific implementations at runtime. I'm not sure I'm in line with community wisdom here though - I get the impression that there's a directive to make fairly heavy use of the underlying platforms, and that ClojureCLR will therefore be a parallel implementation of Clojure, rather than an alternative core under a larger pure Clojure universe of contrib libraries and developer code. Have I understood this right? What will be the best way to go about writing and managing a cross-platform Clojure library? Best regards, jim --~--~-~--~~~---~--~~ 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: Generalizing -> & ->>
On Nov 3, 1:43 am, Alex Osborne wrote: > Sean Devlin wrote: > > This is slightly unrealted, but how does one pronounce ->, ->> and the > > like? Is this documented? > > The doc-strings usually give you a nice hint. I usually use "thread" > for -> and "thread last" for ->>. The actual symbols I think of as > "arrow" and "double arrow". > > Then -?> in contrib is "short-circuiting thread". Not sure about the > symbol, perhaps "questionable arrow"? ;-) I'd probably call the macro I wrote 'nest' if it weren't for the precedent set by the other two. --~--~-~--~~~---~--~~ 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: Syntax highlighting clojure code
pygments (which is used by github) does a good job too. On Tue, Nov 3, 2009 at 12:41 AM, Stefan Arentz wrote: > > I want to post some Clojure code to my blog. Does anyone know of a > simple, preferably online, code highlighter for Clojure or Lisp that > turns code into simple html with either a stylesheet or just color=""> tags? > > S. > > > > > -- Professional: http://cgrand.net/ (fr) On Clojure: http://clj-me.cgrand.net/ (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 -~--~~~~--~~--~--~---
