11:08sot: If I use a def form to bind a variable to the return value of a funtion, am I correct that the function will only ever be called once? My functionn return a zermq socket, and I do not want that code to be called more than once.

11:15pdk: i don't see why binding a def stops the function from being called twice

11:16 maybe you should stick a precondition on the function that the value of the def you bound must be nil before it runs to prevent it from being run twice

12:12 the-kenny: if you want a real answer you'll have to be more specific about what you want to test :)

12:12fliebel: the-kenny: But if you don't like choosing, clojure.test sounds like an easy choice :)

12:13gfrlog: yeah. The worst thing that can happen is you'll get a better idea of what you want

12:13the-kenny: gfrlog: That's the problem. I don't know what I want. I used lazytest for one project (mostly because of the autotest feature and because it generates nice reports), but one thing which drives me crazy is that 1.1.2 (Clojure 1.2.1 compatible) has swank-clojure as a dependency

12:14 I also like the (given ...) macro, but that'll be removed in future versions

12:14 deftest feels a bit raw compared to lazytest, but clojure-test-mode is definitely a plus

12:14sexpbot: <the> clojure.test feels a bit raw compared to lazytest, but clojure-test-mode is definitely a plus

12:15lnostdal-laptop: is there some way to use lein only as a build/make type tool, so it doesn't download the same packages for each and every one of my new test projects but instead re-uses the common ones i already have stored locally here?

12:15gfrlog: it is a bit raw. I normally end up making a macro or two to help

12:15 I thought lein/maven kept local copies around and used them when available...

16:15scgilardi: there's a function you need to provide that means "can have children" (whether or not it currently does) based on the error message, I'm guessing that function returned false for the node you're trying to add to. you'll need to arrange for it to return true.

16:18 the zip/branch? fn returns false for the 1 node, but I don't how to get it to return true

16:20scgilardi: the doc for clojure.zip/zipper (in zip.clj in the clojure source) has some info. yes, branch? is what you need. seq-zip's version of branch? is (seq?) and (seq? 1) is false.

16:25casper1: Still not getting it i am afraid. Could you provide a tiny example of how to add a child node?

16:29scgilardi: does this help? (I don't have a small example handy. branch? is written the way it is for seq because the corresponding make-node function relies on having a seq present for it to work.)

16:56jhickner: hello all. I'm trying to figure out how to serve a specific static (in compojure) from a wildcard path. For instance, any request to tiles/* should serve up tiles/tile.png. Most of the docs out there seem to be outdated. Any ideas?

19:07davekong: I am trying to read a 120MB binary file of 32bit bytes into a vector (maybe array), is there a simple, efficient way to do this? I have this CL code for doing it: http://www.pastie.org/2089175

21:39wonginator1221: gfrlog: Ah.. ok thanks. I'm also running into a problem where I have a recursive func that works fine for small values, but i'm guessing fills that stack on larger numbers. The stacktrace is too long for my terminal to capture. Any tips?

22:11kiras: if a function produces a lazy sequence and i do something like (take 5 (the-function 10)), where 10 specifies the number of elements potentially contained in the lazy-seq produced by the-function, i should only get a lazy-seq of five elements, right? or are there times when this is not the case?

22:27kiras: seancorfield: i agree that it's just an example, but i was a little surprised when take didn't act the way i expected. i now understand why, thanks to you and gfrlog, i was just thinking that in general, you probably wouldn't write a function producing a lazy-seq that could only ever have two elements, when the second element could be so large, right?

22:28gfrlog: I'm having a hard time reasoning about whether you could interact with that thing in a partially-evaluated state... :/

22:51 it's like how half of the stuff on 4clojure.com is just reimplementing clojure.core functions

22:51seancorfield: and they're building on the example from page 115... (steps [1 2 3 4])

22:51kiras: seancorfield: i agree, that's probably a tough aspect of writing a book like this. i have to wonder if it might not have been better to just use the simple-range example instead of having both though

22:52gfrlog: I don't have the book in front of me so I'll have to trust you guys to deliver judgments :)

23:00kiras: is there a good book that covers some of the more practical areas of using clojure? like, a few weeks ago, i was in here asking about reading files and stuff. and it's kind of interesting, since you can just use java classes to do it and maybe initially that's what people did, but now it seems like you'd use clojure libraries to do so... and this will probably keep happening. so what might have been considered standard before falls

23:02 so maybe a book would be the wrong medium for something like that for this language. i think there's a tendency for this to happen with any language, but i think it might be more pronounced with clojure, since using java directly is encouraged, but inevitably, ways of doing the same thing without leaving clojure are developed.

23:02technomancy: kiras: I/O is one of the few places the language has changed since 1.0

23:03kiras: technomancy: ah. well, you would definitely know better than i

23:03technomancy: until 1.3 (or hopefully 2.0) is released, there will have been only 2 or 3 breaking changes in the past 2 years

23:04gfrlog: technomancy: does that parenthesis mean that 1.3 might be renumbered 2.0?

23:04kiras: i see things like see-saw and penumbra though, and i think they're good things, but before they were developed, would someone have been encouraged to just use opengl or swing directly?

23:05technomancy: gfrlog: it's been suggested. it makes a lot of sense given that it's going to include a number of breaking changes, but I haven't heard anything about it recently

23:06kiras: technomancy: well, i don't mean breaking changes, exactly. just that how you'd tend to do something in the language seems like it will keep changing from calling java directly to using clojure libraries that present a nicer way to do so. which is good, but it could be a challenge to keep up with. or not.

23:06technomancy: gfrlog: scala 2.8 took a long time to get released, (lots of breaking changes) and by the time it came out, the developers wished they had called it 3.0

23:07kiras: technomancy: of course, the language is still fairly young and i haven't really been around other languages early on in their development.

23:08gfrlog: technomancy: do you know if the integer changes in 1.3 effect rationals?

23:08technomancy: gfrlog: I don't think so. but I haven't been tracking it closely

23:08seancorfield: re: scala - as someone who started with 2.7 and endured the painful 2.8 process, i'll second that!

23:09 with scala 2.8, several RCs broke binary compatibility... so libraries constantly had to be recompiled

23:11 for clojure 1.3, the biggest issue for folks learning from books may be that all the examples in print will use contrib 1.2 stuff and contrib 1.2 doesn't run on clojure 1.3 - and the contrib library has been a) split up and b) many modules renamed

23:37seancorfield: i'm looking hard at c.j.j to figure out how to make the functionality more extensible and then there's the whole binding / thread thing for *earmuffed* variables (which i admit i don't fully understand yet)

23:38 davekong: i like joy of clojure - it attacks the "why" of clojure - but clojure in action and clojure programming seem to be focusing more on "how to" stuff

23:45 i just compared the ToC for Clojure in Action, Clojure Programming and The Joy of Clojure... hiredman could reasonably claim that CiA and JoC don't go far beyond the basics (although they have very different approaches) but CP is quite different

23:46 hiredman: what sort of stuff would you imagine being in Clojure: A Critique?