6:45 fliebel: Where can I see which bugs are going to be included in 1.3?
6:46 Dranik: _bugs_ ??
6:46 fliebel: Dranik: Uhm, fixes of course
6:47 Like Jira stuff that's going to be addressed before 1.3
6:56 Dranik: fliebel, did u check this link? http://
6:58 fliebel: Dranik: No, where did you find that?
6:58 and, only 6 issues left? cool!
6:58 Dranik: these are the issues from the roadmap
7:00 fliebel, do you use clojure for commercial projects?
7:01 fliebel: Dranik: uhm, not really. Why?
7:01 Dranik: just curious. still searching for the real-life use cases for clojure
7:03 fliebel: Dranik: I'd use it for most stuff where I get to decide anyway... But that's mostly side projects :(
7:04 Dranik: for example: which projects?
7:06 Dranik: fliebel, is logos your project?..
7:06 fliebel: Dranik: No, it's a fork of dnolen.
7:07 Dranik: and utterson?
7:07 fliebel: Dranik: huh, weird... oh, right, dnolen renamed the original.
7:07 Dranik: actually, I'm also trying to adopt clojure for web projects
7:07 but it's environment is still very poor
7:07 fliebel: Dranik: Utterson is a project of me and devn, but as I said, I need to learn to finish stuff :(
7:09 I took up finishing Utterson a few weeks back, but then someone put an email in my inbox labeled "I want to work with you", so now I'm doing some Python stuff.
7:09 Dranik: ))
7:10 fliebel: Dranik: What kind of web stuff do you do with Clojure?
7:10 Dranik: fliebel, nothing special, just simple blog engine right now
7:11 fliebel: Dranik: Not a static one I suppose? :P
7:11 Dranik: yep :-)
7:11 I'm just investigating whether I can achieve some speed up with some of clojure features such as DSL's with macros
7:12 fliebel: Dranik: (not= DSL macro) ;)
7:13 Dranik: well, I'm not so educated in DSL's :-) but trying to get the right way with SICP
7:14 * fliebel is writing smileys in the repl
12:42 gfrlog: ah
12:42 that is an unhelpful error message
12:42 but it looks like your (if-let) has too many arguments
12:43 ,(if-let [a 12] a a a)
12:43 clojurebot: java.lang.IllegalArgumentException: if-let requires a vector for its binding
12:43 gfrlog: yep
12:43 so if-let works like if, where the second argument is the true condition, and the third, if it exists, is the false condition. Having more than three arguments doesn't make sense.
12:43 do you think when-let is more what you want?
12:44 ,(doc when-let)
12:44 clojurebot: "([bindings & body]); bindings => binding-form test When test is true, evaluates body with binding-form bound to the value of test"
12:44 tufflax: ah ok, thank you
12:44 gfrlog: no prob
13:04 raek: if-let used to be written as (if-let variable test-expr then-expr else-expr) instead of (if-let [variable test-expr] then-expr else-expr) in some old version of clojure
13:06 the error message tells what people had to change to update their code
13:06 gfrlog: ah hah
13:11 __name__: raek: What's the point of the new syntax?
13:11 gfrlog: I imagine it's more like (let)
13:14 raek: __name__: uniformity in syntax, I presume (vector means binding). this happened long before I got into clojure though, I think
13:14 * __name__ nods
13:23 chouser: pre-1.0
13:23 __name__: Thanks chouser
13:28 chouser: I've got a stream of objects I'd like to capture fully and then make available as a seq.
13:28 It would be nice to be able to release the head of this seq as its consumed
13:28 If not for that, a vector would be perfect
13:29 but a seq on a vector will keep the whole vector in memory until the *whole* seq is released
13:29 a persistent queue came to mind, but since I'll fully populate the queue before anyone begins consuming it, it'll act the same as the vector above.
13:30 so ... what other option?
13:30 gfrlog: chouser: a list is bad because you're building it backwards?
13:30 chouser: copy into a vector and then copy *again* into a list, which means I'll have the whole ... right
13:30 well, forwards
13:30 gfrlog: it's the O(n) reverse operation you're trying to avoid?
13:31 or will that not work for some other reason?
13:31 chouser: I'm trying to avoid having the whole sequence in memory twice
13:32 actually, a seq on a vector achieves that
13:33 I guess I was hoping for having it in memory only once, and then progressively freed as it is consumed.
13:33 gfrlog: right
13:33 I guess you want a special seq on a vector
13:34 chouser: A vector can't be shrunk from the left
13:34 oh. A finger-tree would do. ha.
13:34 gfrlog: I thought of that and just assumed you were the last person to mention that to :)
13:35 chouser: seems like I should have thought of that sooner.
13:35 gfrlog: go back and watch chouser's talk on finger-trees
13:36 I wonder if I would have thought of finger trees sooner if anybody else were asking the question
13:36 chouser: :-)
13:48 gfrlog: chouser: Your stream emits the first object first? I'm having a hard time convincing myself that a simple list doesn't work...e.g., why not use (lazy-seq) and pass it through (doall) before returning?
14:17 chouser: simple lists grow to the left. I'll be adding objects to the right (like a vector does)
14:17 hm, but maybe I can figure out a way to use lazy-seq
14:17 the problem is I can't return. I don't have control of the loop.
14:17 gfrlog: yeah I was thinking that lazy-seq does exactly that -- lets you add objects to the right
14:18 chouser: I have to call a function that adds to the right of a mutable thing (I've been using a vector in an atom) and then is done.
14:19 ah, so not a lazy-seq, but a similarly-chained mutable-once thing. I bet I could build that...
14:19 gfrlog: I can imagine accomplishing that with an ugly mess of concurrency primitives
14:20 a list of promises?
14:21 chouser: right, like that.
14:22 gfrlog: hurrah for weaseling out of finger-trees
14:25 arohner: is there a convenient way to get the number of times a regex matches a string? the only way I've found is to use .start on an re-matcher
14:25 seems like there should be a more straightforward way
14:25 gfrlog: arohner: (count (re-seq ...)) isn't what you want?
14:26 arohner: gfrlog: aha! re-seq is exactly what I wanted. I didn't know it existed
14:26 gfrlog: no probalo
14:51 babilen: sigh
16:46 Somelauw: Are you all former ruby programmers? Or where do all those clojure programmers get from?
16:52 kencausey: Somelauw: We all come from many places, some of us are quite old and predate most languages.
16:52 dnolen: Somelauw: from what I can tell, it's pretty diverse community, Java, C++, Common Lisp, Haskell, Scheme, Ruby, Python, etc.
16:53 seancorfield: Somelauw: i'd probably consider myself a C++ / Java programmer but i've used a *lot* of languages (including, in recent years, Groovy and Scala)
16:54 but i was doing functional programming back in the early/mid 80's before OO "happened" (in the mainstream)
16:55 Somelauw: I think FP has never been really mainstream.
16:59 dnolen: Somelauw: I think Haskell, Scala, and Clojure are helping to change that. It's not going to happen overnight, but I think in 10 years or so, FP no longer be a niche paradigm. multicore is the driver.
17:01 Somelauw: Yes, I understood it was easy to write multicore programs in clojure (Although I haven't really exploited or studied its multicore features in detail yet).
20:11 Derander_: I've been evangelizing learning an FP language to all of my < 18 year old programming buddies
20:11 get 'em while they're young :_)
21:41 JohnnyL: "Lot's a irc users talkin, few of them know, soul of Clojure was create.... belowww"
21:41 "Lot's a irc users talkin, few of them know, soul of Clojure was created.... belowww"
23:59 lawfulfalafel: do people use cedet when editing clojure code?