6:11maacl: I get "java.lang.RuntimeException: You need to use "Import Library" to add processing.core.PGraphicsJava2D to your sketch." when I try to run the clj-processing example, even if I and PGraphicsJava2D to the imports ((:import (processing.core PApplet PGraphicsJava2D)) - any ideas anyone ?

8:02antifuchs: how so? not behaving properly or are you getting errors?

8:02maacl: antifuchs: I get "java.lang.RuntimeException: You need to use "Import Library" to add processing.core.PGraphicsJava2D to your sketch." when I try to run the clj-processing example, even if I and PGraphicsJava2D to the imports ((:import (processing.core PApplet PGraphicsJava2D))

15:03johanm: I have a question regarding swank-clojure, if anyone is up for it: if I eval a (ns ...) expression with C-M-x, my *slime-repl clojure* does not switch to that namespace. I can switch to it at the repl (and the imports have been picked up, etc.), but consequent evals from my source file is evaluated for the default "user" namespace (meaning I can't use my imports). Am I doing it wrong?

15:08dysinger: how do I get auto-indentation in the command line repl like I can for emacs? Is there any .inputrc trickery to be had?

15:46AWizzArd: johanm: if you eval a (ns ..) in a code file, then in that file you will be in that namespace from that moment on. All functions that you write into that same file and that you eval there, will become available in the repl under that namespace.

15:59johanm: AWizzArd: yeah, but when I eval the (ns ...) i emacs the slime repl does not change to the specified namespace (as indicated by the prompt), like it does when you're running clojure-mode without slime, for example (I'm using slime, swank-clojure and clojure-mode from cvs/git)

16:04Lau_of_DK: This is border-line off topic, but since Im driving with compojure, I figured you'll cut me some slack: I have an menu which dynamically expands when you hover your mouse on it, problem is, it pushes the entire rest of the page down when expanding - how do I avoid this?

16:18astor: I've been away from clojure for a few months, and after updating to the latest lazy-seq stuff, I'm faced with the following issue. (def *foo* (some-lazy-func)) gives java.lang.ClassCastException: clojure.lang.LazySeq cannot be cast to clojure.lang.IFn

18:07AWizzArd: And apply is one of those funny functions that one can not write on the same level on which one is writing the rest of the program. Although antifuchs made a nice macro that can fake apply for most practical cases ;)

18:09cmvkk: i'm not sure what you mean, though. apply isn't a special form; it's written in clojure.

18:10astor: Thinking about the problem I mentioned earlier, a macro - (loop-seq sequence bindings &body) could be imagined which will go through a sequence and where bindings is used to keep state and where the exit of the loop is a (cons...). It seem that this macro is very hard to implement since there is not way to add extra arguments to (recur..).

18:10chessguy: anyway, enough brain-bending for tonight. i'm off to hang out with some friends. thanks ya'all!

19:43Puzzler: I don't know the implementation details, but I've used PLT Scheme enough to say that function calls are not implemented using a limited stack that can "blow". Eventually, you'll run out of overall memory on your machine, but far after mainstream languages would blow a stack.

19:46Puzzler: To put it in perspective, in Clojure, you have to be very careful about writing non tail-recursive traversals of really long lists (like simple implementation of map).

19:47 In PLT Scheme, if the list can fit in your memory, you'll have no problem with the accumulated function calls fitting in memory too. So basically, you can write your function in the naive way, without worrying about stack.

19:48 That's cause in most languages the stack is only a small percentage of overall memory.

19:48dnolen: cmvkk: the TCO, is tail call optimization, recursion is one case as far I understand the issue.

19:48cmvkk: but i think his point is that PLT scheme won't blow the stack, even if you don't take advantage of TCO.

19:50Puzzler: Right cmvkk, you'll eventually run out of memory, but after you've used all 3GB of RAM on your machine (not likely to happen), rather than after 3000 function calls deep, or some other arbitrary number.

19:51cmvkk: although that might be the case, i don't think it makes it okay to write naive recursive algorithms

19:51 you're right though: "At the same time, recursion does not lead to particularly bad performance in Scheme, and there is no such thing as stack overflow;"

20:06 I'm working on code right now that can't really be trampolined or turned into TCO, but potentially has a fair amount of depth.

20:06cmvkk: it's a problem when you do tree recursion. since trampolines only work on tail calls too...

20:07Puzzler: I'd probably have to do something analogous to lazy-seq, storing a delay to the next node of the tree.

20:08 Fortunately, the stack limitation hasn't bitten me yet on this particular code, but it bothers me that it is fragile in this respect.

20:10qwert666: i`m searching for some benchmarks results of clojure and other langs do you know any good source of info. ? i usually was using http://shootout.alioth.debian.org/ but no clojure code there :(

20:10Puzzler: Hmmm, I wonder if there is a clever way to use futures to return immediately, like a delay, but continue building the tree immediately on a separate thread.

20:30clojurebot: "([branch? children root]); Returns a lazy sequence of the nodes in a tree, via a depth-first walk. branch? must be a fn of one arg that returns true if passed a node that can have children (but may not). children must be a fn of one arg that returns a sequence of the children. Will only be called on nodes for which branch? returns true. Root is the root node of the tree."