0:12 daaku: is there a way to amortize the startup time for lein? java's already slow, and having to wait for two instances to load for running a couple of tests takes 12-13 seconds for me. i was wondering if there's a way to hold on to the lein process and keep poking it when i need the tests to be re-run so it can skip it's own startup time
0:14 qbg: daaku: It sounds like cake would help, but it isn't lein, and it is a bit young
0:14 daaku: qbg: this didn't yield anything: http://
0:14 got a link?
0:15 qbg: http://
0:15 daaku: thanks
0:15 qbg: Persistent JVM
0:15 lancepantz: daaku: you can actually put cake in autotest, then it watches for files to be reloaded and runs your tests
0:16 do 'cake autotest'
0:16 not docs for it yet, but i think its really useful
0:16 daaku: sweet
0:16 it supports project.clj too?
0:16 qbg: Yes
0:16 daaku: should i be using this instead of lein?
0:17 lancepantz: daaku: we're still ironing out the kinks
0:17 daaku: cool
0:17 lancepantz: we've been using it internally for a month or so, i really like it
0:17 daaku: out of curiosity, was it java startup time which led to this?
0:17 qbg: One problem that I've encountered with cake is that you can't (read) from the repl
0:18 lancepantz: actually it wasn't
0:18 we just wanted a task dependency model because our build was getting pretty complex
0:19 qbg: open an issue for it on github if you don't mind
0:19 daaku: lancepantz: cool
0:19 qbg: lancepantz: Okay, I will
0:20 lancepantz: daaku: it's easy to install though, if you have ruby up to date, just do 'gem install cake' form your project root
0:21 daaku: huh! cake test takes like 0.10s -- while lein test takes 12s -- which would mean it's lein's own startup that takes 12s. that's a bit odd
0:21 lancepantz: already got it running :)
0:21 lancepantz: nice
0:21 qbg: Totally needs to be the logo for cake: http://
0:21 lancepantz: daaku: that sounds about right
0:21 daaku: qbg: nice
0:21 lancepantz: qbg: nice! done.
0:22 where did you find a link to that image?
0:22 qbg: It was on clojure.org when Clojure turned 2
0:22 I had to do google-foo to find the link...
0:22 lancepantz: sweet
0:27 daaku: lancepantz: i'm trying to start a jetty server in the bg running in a cake repl -- but it doesn't seem to include the stdout/stderr from the thread, any suggestions on how to fix that?
0:29 lancepantz: well, in short you can't
0:30 everything is going over the socket, so there isn't really a difference between the two anymore
0:31 i think ninjudd made it just swallow up stderr if i remember right
0:31 i think i can fix it though, we dont really have that use case
0:32 do you mind creating a ticket for it on github?
0:33 i'll do it actually
0:33 daaku: hey, sorry, just saw the msgs
0:33 i can do it if you like
0:34 and thanks :)
0:34 lancepantz: go for it, i'll let you know when its fixed
0:36 daaku: done: http://
0:36 lancepantz: ty
0:36 it may be next week before we get to it
0:37 ninjudd did the repl and he's on vacation, and i'm way backed up on shit
0:38 slyrus: daaku: there was some talk on the lein mailing list today about the slow startup times and a possible fix
0:41 daaku: slyrus: cool, i need to subscribe i guess..
0:41 slyrus: is this the thread: http://
0:41 slyrus: the problem seems to be in the way lein looks for hooks at startup.
0:41 yeah
0:43 daaku: slyrus: totally worth dropping imho if it can cut down startup time by 12 seconds on a fairly recent mbp!
0:43 slyrus: yeah, I agree
0:43 as long as lein swank works, everything else can go to hell, AFAIAC
0:43 :)
0:43 daaku: hehe
0:44 i've only gotten started, but i'm not sure i can switch from vim to emacs
0:45 vim + repl in screen works pretty well. i just need to figure out how to get the repl to reload code with a vim keybinding or just auto reload
0:46 * jorgeb tests.
0:50 slyrus: I don't suppose Joshua Choi ever hangs out here?
1:05 tomoj: rarely
1:08 daaku: lancepantz: thanks for cake :) -- it's going to make this learning process a lot more pleasurable!
1:09 lancepantz: daaku: cool dude, glad you like it
1:09 most of the credit is due to my co-worker, i just play bass :)
1:15 daaku: lancepantz: i was dreading testing because of the startup time, and now i'm at the other spectrum with autotest -- that's awesome
1:15 in fact, i feel like cake repl is faster than clj
1:15 which makes no sense?
1:15 or is cake repl faking it
1:15 lancepantz: as far as start up time, or general performance?
1:15 daaku: and the socket's just being opened in the bg
1:16 startup time
1:16 lancepantz: it's faking it
1:16 daaku: ok, makes sense
1:16 lancepantz: the jvm persists
1:16 daaku: oh!
1:16 i didn't get that part
1:16 lancepantz: we just reload your source files when you run the cake command
1:17 daaku: i should obviously read the readme
1:17 lancepantz: and i haven't documented autotest yet, but the "." being printed means all of your tests passed
1:17 it's pretty incomplete still
1:17 daaku: yep, i figured
1:17 lancepantz: we haven't announced it or anything yet
1:17 i've just talked in the channel about it some
1:17 daaku: cool
1:18 i'm happy to be a beta tester
1:18 lancepantz: great, please file any issues you find on gh
1:20 daaku: will do
1:36 defn: lancepantz: you around?
1:37 lancepantz: with cake should I be including a :dev-dependencies [[swank-clojure "1.3.0-SNAPSHOT"]]?
2:14 raek: good morning, #clojure
2:18 defn: morning raek
2:22 slyrus: ok, fnparse is starting to make sense...
2:26 defn: hehe
2:26 is it now?
2:26 slyrus: explain it to me! :)
2:27 slyrus: well, first of all, make sure you have the develop branch. fnparse3 looks much better.
2:27 then read the json.clj example.
2:38 hiredman: clojurebot uses fnparse
2:54 slyrus: cool. and hopefully chemiclj will soon... it's coming along.
3:02 hiredman: who wrote clojurebot?
3:05 hiredman: I did
3:08 slyrus: ah, cool. I assume you used fnparse2?
3:08 hiredman: I'm not even sure, must have been
3:09 yes 2.2.4
3:09 slyrus: ok. now I'm trying to figure out how to get contexts to work. neat stuff so far!
3:11 unfortunately joshua choi hasn't gotten around to the fnparse 3 documentation yet :(
3:24 lenw: hi all - can anyone help a newbie ?
3:26 slyrus: raek: looks like i'll have to check out your clojure-mode mods
3:33 raek: just clone my form and M-x customize-variable clojure-mode-use-backtracking-indent
3:33 *fork
3:33 we should test the backtracking indent more to see if it's stable
3:34 (it was done by the previous maintainer and no one knows if it really works)
3:34 I merely added updated rules for the new forms
3:53 neotyk: lenw: Hi, most likely, someone will be able to help
4:02 lenw: cool - am using the clj-mail stuff - a wrapper around javamail and acessing my mailbox all fine : (def msgs (get-msgs ...)) all fine
4:02 Bahman: Hi all!
4:03 lenw: no i want to walk through the msgs and am getting confused how to do that
4:07 zmila: ,(= (hash-set :a :b :c) #{:a :c :b})
4:07 clojurebot: true
4:08 zmila: evaluator at http://
4:13 raek: lenw: of what class is the message collection?
4:13 i.e. (class (get-msgs ...))
4:14 lenw: (pr msgs) is (#<IMAPMessage com.sun.mail.imap.IMAPMessage@256ef705>)
4:14 raek: you can do seq on java collections do get a sequence of their elements
4:14 is that one message or many?
4:14 lenw: its a list of one at the moment
4:14 raek: ah, I see the parens
4:15 you want to access stuff in the messages?
4:15 lenw: yes i want to process each message
4:15 for example i have a fn to dump the hearders
4:15 (defn dump-header [header]
4:16 (println (. header getName))
4:16 (println (. header getValue)))
4:16 raek: lenw: just a tip, try doing 'bean' on one of the messages
4:16 lenw: wow thats cool !
4:17 raek: that will make a map-like object that run getFoo when you lookup key :foo
4:17 lenw: thanks raek - refactoring now :)
4:18 raek: so, did you want help with how to do things for each element in a sequence or something else?
4:19 lenw: yes - so i am using (apply fn list) ?
4:19 for the messages
4:20 raek: (apply process [1 2 3 4]) will do (process 1 2 3 4), which might not be what you had in mind
4:21 ,(map inc [1 2 3 4])
4:21 clojurebot: (2 3 4 5)
4:21 lenw: thats what i am beginning to see
4:21 raek: ,(let [l (list 1 2 3 4)] (for [element l] (str element)))
4:21 clojurebot: ("1" "2" "3" "4")
4:22 raek: ,(for [x [1 2 3 4]] {:inced (inc x), :stred (str x)})
4:22 clojurebot: ({:inced 2, :stred "1"} {:inced 3, :stred "2"} {:inced 4, :stred "3"} {:inced 5, :stred "4"})
4:22 lenw: aaah
4:22 raek: ,(doseq [x [1 2 3 4]] (println x))
4:22 clojurebot: 1 2 3 4
4:23 lenw: so apply just puts the list in as the params to a fn
4:23 raek: yes
4:23 lenw: for does the fn to each element in the seq
4:23 raek: well, map does that
4:23 for is more advanced
4:23 it can "iterate" over multiple lists
4:24 lenw: yes as in
4:24 raek: (for [x (range 4) y (range 4) :when (< x y)] [x y])
4:24 ,(for [x (range 4) y (range 4) :when (< x y)] [x y])
4:24 clojurebot: ([0 1] [0 2] [0 3] [1 2] [1 3] [2 3])
4:24 lenw: ,(for [x [1 2 3 4]] {:inced (inc x), :stred (str x)})
4:24 clojurebot: ({:inced 2, :stred "1"} {:inced 3, :stred "2"} {:inced 4, :stred "3"} {:inced 5, :stred "4"})
4:25 raek: maps is more convenient when you have already the function
4:25 you could do (map (fn [x] {:inced (inc x), :stred (str x)}) [1 2 3 4])
4:26 lenw: making much more sense now thanks
4:26 raek: I hope this will get you started :)
4:26 lenw: yes there is a glimmer of light :)
4:26 raek: feel free to ask here if you have any questions
4:26 lenw: much appreciates
4:48 Lajla: ->(let [me "Worship" your "Shadow"])
4:48 sexpbot: => nil
8:20 pdk: can count be assumed to be o(1) or o(n)
8:22 rhickey: pdk: no universal answer, O(1) for most things other than sequences. There is also counted? predicate
8:33 weissj: is there a way to free memory in a swank repl session? It's the highest mem consuming process on my system right now (58mb resident)
8:36 pdk: weissj (. System gc) perhaps?
8:36 weissj: pdk, tried that, no effect
8:36 pdk: hm
8:36 weissj: does swank keep references to all the return values or something?
8:36 even then i'm surprised it's this high. my program isn't using large data structures.
8:37 if it *did* keep references to return values, that'd be a nice feature which I have not seen documented :)
8:39 raek: the clojure repl keeps the last three return values
8:39 weissj: raek: how do you access them?
8:39 raek: they're bound the the vars *1, *2 and *3
8:39 weissj: ah thanks
8:40 raek: so if you eval three things, they should be flushed out, I think
8:40 weissj: yeah that doesn't free any mem to the OS
9:02 lenw: using compojure how do i specify the params on the route - trying (POST "/url" [p1] (...)) fails with p1 unresolvable in thie context ?
9:03 bobo_: lenw: you mean this? (GET "/primes/:num/:color" [num color] (print-primes num color)))
9:04 or ah post!
9:04 dnolen_: lenw: http://
9:04 bobo_: (ANY "/do" {params :params} (do-login :session params))
9:04 lenw: bobo_: thanks let me try that
9:05 dnolen_: lenw: personally I prefer http://
9:05 pdk: can defmultis have multiple arities like defns
9:06 stuartsierra: pdk: yes, just make your dispatch function variadic
9:06 lenw: dnolen_: thanks
9:06 pdk: hmm
9:06 cypher23: back
9:06 pdk: oh yeah you don't write the arglist in the defmulti i guess
9:08 tcrayford: you don't
9:08 pdk: that was a smooth move
9:09 tcrayford: stuartsierra: how's lazytest going these days?
9:09 stuartsierra: tcrayford: slowly but surely
9:10 hoping to do some more work today
9:10 tcrayford: are you happy with it yet?
9:10 stuartsierra: no
9:10 tcrayford: :/
9:10 stuartsierra: still trying to define the separation between code and assertions
9:10 tcrayford: right
9:10 stuartsierra: trying to enforce things like "one assertion per test" is hard
9:11 tcrayford: unfortunately :(
9:11 stuartsierra: and there has to be a workaround for when you really need multiple assertions in a test
9:11 tcrayford: something like do?
9:11 :/
9:12 stuartsierra: tcrayford: yes, actually
9:12 and I considered just using "do"
9:13 * tcrayford was going to suggest remote pairing on lazytest, but realises US afternoon is not UK afternoon :(
9:13 stuartsierra: but with "do" then I can't parse the assertion expression
9:13 tcrayford: right
9:13 language for that concept seems kinda tricky as well
9:13 stuartsierra: yes
9:14 I'm intrigued by the given/when/then syntax of Spock, but having trouble adapting it without assignment
9:15 tcrayford: yep, looks tough
9:15 what did you think of brian marick's clojure testing stuff?
9:15 stuartsierra: Last night, came up with http://
9:17 tcrayford: given would assign stuff to the scope of all the its and the whens?
9:17 stuartsierra: tcrayford: yes
9:18 tcrayford: re Marick, I see his point, but remain skeptical
9:18 I don't like using functions under test in the tests.
9:18 But then again, I find myself doing this.
9:18 tcrayford: heh, aye
9:21 lenw: bobo_: using that (ANY "/do" {params :params} (do-login :session params)) i get "Unable to resolve params" ?
9:22 fogus: stuartsierra: Looks like you and Bradford are united against macros
9:23 stuartsierra: In the comic-book world of Clojure, macros are the femme fatale.
9:23 bobo_: lenw: hm, weird? maybe you need to use wrap! on the session. im not sure. dont have al the code at work :/
9:24 fogus: Yes, they are quite alluring
9:24 stuartsierra: Occasionally helpful, but never trustworthy.
9:24 fogus: trustworthy?
9:24 * tcrayford has been bitten by macros too much to use them a lot
9:25 lenw: bobo_: is there a link to something i could read on this ?
9:25 * tcrayford I'm wondering: if you don't use macros, is there any real reason to use a lisp over a language with more approachable syntax?
9:26 * chouser is still in love with macros.
9:26 stuartsierra: I'm not saying you can't use macros, just that newcomers to Lisp tend to use macros where they shouldn't.
9:26 fogus: "approachable syntax" is highly subjective. But I would say yes. I would use Clojure simply for the state model
9:28 bobo_: lenw: http://
9:28 lenw: bobo_: thanks
9:30 chouser: I was thinking last night that in C and even C++ foo(){} is clearly a "special form" while bar() is almost always a plain function call.
9:32 fogus: stuartsierra: In many ways I think it's much more difficult to create an API using functional composition than macros.
9:32 chouser: ruby, scala, etc. violate that, but I wonder if the lack of such a visual hint in clojure is part of why people find reading it difficult at first.
9:32 stuartsierra: fogus: yes
9:32 but much better for users of that API
9:33 fogus: Agreed
9:33 chouser: stuartsierra: do you have an example of an API that is macro that should be?
9:33 stuartsierra: chouser: sure, all the macros in clojure.core
9:33 chouser: heh
9:33 stuartsierra: except "import"
9:34 chouser: well, import should clearly be a function.
9:34 fogus: Usually the macro approach involves abstracting things away from the user while composition requires that you *really* think hard about how the pieces interplay. It's tough
9:34 stuartsierra: Ideally, a macro should add syntactic capabilities without taking any away. It's the second condition that most macros fail.
9:35 rhickey: stuartsierra: import is a macro due to the limitations of Class.forName - you simply can't call that on someone's behalf
9:35 stuartsierra: but it was a function in 1.0
9:35 rhickey: stuartsierra: and didn't work well with modularity
9:35 stuartsierra: oh
9:35 * chouser tries to imagine a function version of 'for'
9:36 rhickey: since all classnames were resolved by the classloader that loaded Clojure
9:36 stuartsierra: right
9:36 hmm, so dynamically creating namespaces with function calls is out, then?
9:36 at least as far as importing Java classes is concerned?
9:38 rhickey: stuartsierra: insofar as a ns is just a map of vars, no problem. But you aren't really compiling code relative to a dynamic import anyway are you?
9:38 stuartsierra: I was when I was playing around with RDF stuff.
9:39 stuarthalloway: please test the RC1 download links: http://
9:39 rhickey: well you can always write a fn that calls a macro
9:39 stuartsierra: yes
9:42 stuarthalloway: testing...
9:48 fogus: stuarthalloway: I think it would be nice to add a default clause to the example (or a comment afterwards) for `case` in changes.txt
9:49 stuartsierra: stuarthalloway: downloads look fine, not available on build.clojure.org/releases though
9:49 stuarthalloway: fogus: makes sense, patch away
9:49 stuartsierra: working on it
9:49 stuartsierra: I figured
9:49 stuarthalloway: wouldn't it be cool if it were automated?
9:49 stuartsierra: yes
9:49 it could be
9:50 fogus: stuarthalloway: k
9:52 stuarthalloway: stuartsierra: I have two problems, both mvn+linux related
9:52 (1) how do I tell mvn deploy to use a different username for copying
9:52 (2) how to I set the right chowner on the box
9:53 right now I am "stuart" locally, have "root" access to build.clojure.org, and need the files, once copied, to be owned by "hudson"
9:53 stuartsierra: stuarthalloway: what if you tell mvn to deploy via SCP and let it log in as "hudson"?
9:54 stuarthalloway: I can't log in as hudson
9:54 stuartsierra: hm, that's something we can't change?
9:55 stuarthalloway: no, that's just what I am trying to do atm
9:55 stuartsierra: What if root@build.clojure.org SCPs to hudson@build.clojure.org
9:56 stuarthalloway: what's the command line to tell maven to do that?
9:56 I find maven to be google-opaque. ask a question, and the first hits are never the answer
9:57 stuartsierra: It'd be configured in the <distributionManagement> section of the POM
9:57 And the local settings.xml
9:59 stuarthalloway: where settings.xml is a magic file that lives in .m2?
9:59 stuartsierra: ~/.m2 yes
9:59 clojurebot: It's greek to me.
9:59 stuartsierra: hello, clojurebot, long time no see
10:00 stuarthalloway: you set the host and path as the deploy URL in the POM, and configure your login user and password in ~/.m2/settings.xml
10:00 stuarthalloway: we don't allow passwords
10:01 stuartsierra: it takes keys too
10:01 stuarthalloway: but it can't discover them from the environment
10:01 stuartsierra: no, you must specify an absolute
10:01 path
10:01 stuarthalloway: maven is a value subtraction layer over unix tools
10:01 stuartsierra: yes
10:01 The same could be said of Java.
10:03 stuarthalloway: is there a way to test the deploy task without being forced to run the build and tests again?
10:03 stuartsierra: probably, but I don't know
10:04 stuarthalloway: success
10:04 stuartsierra: w00t!
10:05 yep I can see it in http://
10:05 stuarthalloway: now, back to clojure itself
10:06 stuartsierra: Ant land, where even Mavens fear to tread.
10:18 stuarthalloway: is there a way to tell maven to copy a project from a local repos to a remote repos?
10:19 stuartsierra: I don't think so
10:19 Maven central just uses rsync
10:19 stuarthalloway: the local copy doesn't have all the pieces, e.g. no hash
10:20 liebke: there is a plugin for installing on remote repos, I used to use it for Incanter
10:20 stuarthalloway: otherwise I would just rsync
10:20 stuartsierra: stuarthalloway: I thought you figured that out with the addMeta option or something.
10:21 stuarthalloway: liebke: I am trying to use this : http://
10:21 liebke: I'm looking through my old pom file
10:21 stuartsierra: stuarthalloway: again, can you deploy via SCP?
10:22 stuarthalloway: yes
10:22 defn: stuarthalloway: have you ever finished infinite jest by DFW?
10:22 (sorry so OT)
10:22 stuarthalloway: defn: ha, not started
10:22 defn: one of your tweets awhile back got me interested and i just started it
10:22 it's /hard/
10:22 stuarthalloway: but that kind of talk will likely summon rhickey
10:22 defn: oh is rhickey partial to DFW?
10:23 rhickey: Infinite Jest is one of my all-time favorite books
10:23 stuartsierra: speaking of books, rhickey, I finally mailed you a copy of mine/Luke's
10:23 rhickey: stuartsierra: thanks!
10:23 stuartsierra: rhickey: you're welcome
10:23 stuarthalloway: stuartsierra: our box arrived. We were hoping for bagels :-)
10:24 defn: rhickey: interesting. what instrument (if any) did you study in college, out of curiosity?
10:24 stuartsierra: bagels are too damn expensive to ship
10:24 but maybe next time I'll bring coffee
10:24 defn: i was surprised to hear you were a trained musician
10:25 liebke: stuarthalloway: I was using Maven Wagon: http://
10:25 defn: but with the penchant for DFW in the mix, things are starting to come together :)
10:25 rhickey: defn: I was a composition major, play guitar
10:25 defn: rhickey: cool, any chance you're going to strange loop?
10:25 (anyone in here for that matter)
10:25 rhickey: defn: unfortunately not, too much travel
10:25 defn: i know chouser is counting on it
10:26 rhickey: yeah -- this is going to be my only conf. of the summer -- id like to attend the pragprog session but too rich for my blood ATM, although i hear great things and want to sell some stuff to attend :)
10:26 stuarthalloway: liebke: that part seems to be working -- I am just trying to get right settings
10:26 defn: i am having trouble parting with guitar gear :\
10:29 rhickey: anyway, any tips on reading Infinite Jest? I've heard I should read hamlet and use the notes pretty seriously
10:29 the notes in the back of IJ, that is...
10:29 liebke: stuarthalloway: okay, you can see how I configured the distributionManagement section in my old parent-pom file here: http://
10:30 stuartsierra: liebke: I think the problem is he's in maven-ant-tasks land now
10:30 liebke: ah
10:30 stuartsierra: kind of the worst of both worlds
10:30 rhickey: defn: first tip - use 2 bookmarks, one for body, one for footnotes. Do not in any circumstances skip the footnotes. Also, have a dictionary handy
10:31 defn: rhickey: should I be reading footnotes before the page, or in the middle of the page, or after? by your estimation?
10:32 as in: should i read them as they appear, or would it help to cache them up front?
10:34 maybe a silly question but im trying to get it "right" -- the first two chapters have me a bit puzzled so far
10:36 don't get me wrong I am in love with dope-smoking phone-it-in-and-hide-your-car 2 blocks from your condo, draw the blinds, etc. guy
10:37 just wondering how long I need to put up with insects on the shelf before I get the picture :)
10:37 stuarthalloway: ok, I am to the point where I need to add wagon, but in ant not maven
10:37 looking at http://
10:38 stuartsierra: ok
10:38 stuarthalloway: it seems I should be able to use the install-provider task in clojure's build.xml, using our namespace prefix "mvn" instead of "artifact"
10:38 the other "mvn" tasks work, but it tells me that the install-provider task doesn't exist
10:39 fogus: stuarthalloway: https://
10:39 rhickey: defn: as they appear
10:40 defn: ty
10:40 'gonna tackle the beast after I wake up this afternoon... thanks for the tip -- much appreciated.
10:40 * fogus blames Infinite Jest and House of Leaves for my obsession for footnotes
10:41 defn: fogus: you've read it too?
10:41 fogus: defn: Yes
10:41 both
10:41 defn: ive never touched house of leaves
10:42 stuarthalloway: success!
10:43 stuartsierra: w00t! w00t!
10:43 defn: fogus: it would seem im in good company :)
10:43 stuartsierra: Green Lantern wins again!
10:43 defn: stuarthalloway: stuartsierra: You guys need new nicks. My nick completion keeps lending preferential treatment to halloway :)
10:43 fogus: you guys and your comics book nicknames. Someone should flog the guy who started that.
10:44 stuartsierra: blame Sonian
10:44 fogus: defn: HOL is a must.
10:44 defn: fogus: ive tacked it onto my summer reading list
10:44 * stuartsierra is going out for coffee
10:44 defn: depending on how long it takes me to finish Infinite Jest
10:45 ive been really enjoying DFW's "Consider the Lobster'
10:45 liebke: stuartsierra: fogus is actually to blame for that meme
10:45 defn: so IJ is the logical next step :)
10:46 fogus: liebke: Oddly enough it started as a footnote!
10:46 defn: :)
10:46 liebke: fogus: of course :)
10:47 fogus: Manning yelled at us for all of the footnotes. :-(
10:47 defn: ha!
10:48 liebke: fogus: Is that why they put a pick-pocket on your cover?
10:48 mattrepl: it is a strange cover
10:49 defn: damn theheh
10:49 s/damn theheh/heh
10:50 fogus: It was our attempt to grab a share of the cool programming book nicknames... you know, the Red Dragon Book, the Aluminum Book , the Camel Book, etc.
10:50 liebke: :)
10:51 fogus: Ours is the Jack the Ripper book. :-o
10:51 defn: haha
10:51 mattrepl: hah
10:51 The Aristocrat Book?
10:51 defn: I'd go with "The Haberdasher book"
10:52 for the discerning haberdasher
10:52 mattrepl: yes, this ^
10:53 defn: kind of a pocket watch wielding cheap suit coat maker
10:53 fogus: The Artful Dodger Book
10:53 defn: haha
10:54 fogus: The Otis Campbell Book
10:54 * fogus is done
10:57 defn: The Saint Louis IX Book
10:57 Saint Louis IX, the King of France 1226–70, is the patron saint of haberdashers.[4][5]
10:58 stuartsierra: The Flash is Back!
10:59 With caffeine, and not just in my Java.
10:59 abedra: nice
10:59 stuartsierra: abedra; what are you doing here? you're supposed to be on vacation.
10:59 abedra: i'm at the airport
11:00 waiting for my flight to KY
11:00 so I thought i'd get some clojure in
11:00 stuartsierra: what a trooper
11:00 abedra: :)
11:00 defn: you just can't put it down, can you?
11:00 "just one more time, Emacs..."
11:00 abedra: of course not
11:01 stuartsierra: running the new build through argos right now
11:02 stuarthalloway: Clojure 1.2 RC1: http://
11:02 regardless of what abedra finds... :-)
11:02 abedra: :)
11:04 defn: Hey stuarthalloway -- if I'm ever in Raleigh can I stop by and get a tour of ThinkRelevance? :)
11:04 stuarthalloway: defn: sure
11:04 defn: I was just down there and wanted to stop in but had limited time
11:05 was down in Hillsburough
11:05 on that note, I am going to make a note of your hospitality and go lay down
11:05 cheers also, keep the clojure coming
11:05 ciao
11:07 stuarthalloway: get your app on Clojure 1.2 today: http://
11:08 defn: Great news. Thanks Stu and Co.
11:08 night
11:10 Raynes: stuarthalloway: Is the RC on build.clojure.org?
11:10 abedra: Raynes: yes it is
11:10 Raynes: Pretty much all of my projects are already on the beta. Putting them on the rc, considering it's up, is as simple as changing a few project.cljs
11:11 abedra: http://
11:11 Raynes: Awesome.
11:13 fogus: Spread the word: http://
11:21 lpetit: Hello, I'm migrating to 1.2.0-RC1. It seems that now all my calls to swap! on my atoms need to be wrapped in (dosyncs). Is this an expected API change ?
11:21 stuartsierra: No!
11:21 chouser: whoa
11:22 lpetit: (sorry, I was just kidding, sort of preparing you guys to the bunch of questions for today)
11:22 chouser: ha!
11:22 lpetit: ;)
11:22 * chouser is still laughing
11:23 * lpetit wishes there were more April Foos in one year
11:23 djpowell: I think the newlines on Windows issue should be fixed in this release. It is a known and annoying bug; I haven't seen any evidence that fixing the bug will cause issues for anyone - we've heard from several IDE authors who have no problems with fixing it. All readLine style APIs normalise both CR and CRLF anyway.
11:23 redinger: I think stuartsierra might have just had a Flash heart attack
11:23 lpetit: woops
11:23 abedra: Have a great migration to 1.2 day everybody!
11:23 stuartsierra: my heart system load went to 11.0
11:26 lpetit: djpowell, stuarthalloway: could the *newline* global var be introduced and used in 1.2, while retaining a default value of \newline for 1.2 (and adding a more OS-flavored default value for next release) ? So that djpowell & al could already rebind it, but *nobody* would be affected ?
11:27 stuartsierra: lpetit: Java already has a global newline properyt
11:28 stuarthalloway: lpetit: won't djpowell (and everyone else who hangs out here) jump on master again as soon as the num/prim/equiv comes over anyway?
11:29 lpetit: touché
11:29 stuarthalloway: and, I don't like the idea of adding bindable vars unless the use case is compelling. maybe this one is, but ...
11:30 lpetit: stuarthalloway: you're wise. Beware the hurry towards missing functionality, when close to a release
11:32 You know you've done too much clojure when you create a FunctionChouser class instead of a FunctionChooser class ;)
11:33 * lpetit wishes, yet again, he could use clojure on GWT's client side :-(
11:34 tcrayford: lpetit: How's the thinking about refactoring in eclipse going?
11:35 lpetit: tcrayford: almost same state as in our last message on github:/
11:36 tcrayford: lpetit: fair enough. I've pushed some changes to the one on github. If parsely is finalised I'll start work on making refactoring mode work with it as well.
11:36 lpetit: tcrayford: maybe you could help me motivate cgrand on parsley :)
11:37 tcrayford: it really depends on what else needs doing with it
11:37 chouser: lpetit: heh. I had that problem long before picking up Clojure.
11:38 lpetit: tcrayford: parsley works in "single-pass" parsing mode fairly well in my private branch of paredit. I also was able to implement an interesting "degraded mode":
11:38 chouser: hey ! :)
11:39 tcrayford: lpetit: if you shoot me a github mail about what else needs to be done I'll see what I can do. No promises though
11:40 stuarthalloway: rhickey: have you read the mailing list on defrecord and map equality? Would love your opinion.
11:40 lpetit: tcrayford: there's an additional :chimera tag which matches all kinds of improbable syntax, thus letting the parser do its just until the end of the stream. Example: "(foo" will become the parsetree {:tag chimera :content ["(" {:tag :symbol :content ["foo"]} ""]}
11:41 rhickey: stuarthalloway: people need to decide if they want type as part of equality or not. *not* would be in keeping with categoric equality now in place
11:41 stuarthalloway: people are interesting and all, but what does rhickey want?
11:42 djpowell: re a bindable variable for newline, I agree we could possibly do without that and just hardcode to line.separator
11:42 stuarthalloway: djpowell: that's my (tentative) plan for release.next
11:42 \
11:43 lpetit: tcrayford: I'm afraid we should let Christophe work on the missing features. There's not much left, but each of them may be hard to come up with: a/ have the possibility to declare a "garbage non-matching char" tag ; b/ incremental ( O (log2(n) ) reparsing ; c/ "projections" support (ex.: a projection could be as simple as reporting the size of the source code, or the fact that there are :chimeras in the parse ...)
11:43 chouser: does the name "release.next" allow for the possibility of it being 3.0?
11:43 stuarthalloway: rhickey: I want categoric equality. If the thread is correct, the current implementation gives neither, as it is not symmetric
11:43 * slyrus is really starting to appreciate the virtues of fnparse3 vs. doing this by hand
11:44 stuarthalloway: chouser: that's a dark horse for sure, how about 1.3 or 2.0? :-)
11:44 clojurebot: Who??
11:44 * slyrus thinks joshua choi needs an fnparse3 day
11:44 chouser: heh. oh, right. 2.0 :-)
11:44 rhickey: I think including it is probably more useful, but has the symmetry problem. We could fix that in Clojure, but not vs Java without making records non-j.u.Maps
11:45 stuarthalloway: rhickey: good candidate for summarizing the issues on dev.clojure.org and letting people think on it?
11:45 djpowell: leaving it as is for the release just encourages people to do hacky work arounds to get (println "hello")(println "world") to work properly
11:45 stuartsierra: sooner or later we're going to end up with multiple ='s just like Common Lisp
11:45 and the endless questions that leads to
11:45 djpowell: workarounds, that will probably break when we fix it
11:46 chouser: :-(
11:46 rhickey: djpowell: there is simply not enough time now to shake out changing that. Will be in next release
11:46 stuartsierra: value=, type=, num=, ...
11:46 slyrus: stuartsierra: just make = return an integer for the level of =-ness :)
11:47 chouser: stuartsierra: well, that looks tons better than eq? equal? eql? = and == at least
11:47 rhickey: stuarthalloway: dunno, it's a bad place for self-centric decisions, and the bikeshedding is exhausting
11:47 stuartsierra: Or introduce "like" as in http://
11:51 lpetit: so a) what are the use cases for having strict equality (including type), and b) what are the use cases for having "fields" equality ?
11:52 stuartsierra: a) (= (EvilDude. "Stuart" "Sierra") (NiceDude. "Stuart" "Sierra"))
11:53 stuarthalloway: (b) code that still works when you start to enrich maps with type information
11:53 lpetit: If I have a hashmap h1, which is '=' to a record r1, by having this "positive =" returned, could I be "fooled" by thinking that calling some protocol interface on both should work ?
11:53 stuarthalloway: which may also be an argument for (a) :-)
11:54 rhickey: records are not collections is the first hint
11:55 lpetit: map-as-object ...
11:55 rhickey: adding a type to a map is as if you added another key
11:56 chouser: dissocing certain keys from a record will give you a collection
11:56 rhickey: which is what people are sometimes doing sans records
11:56 chouser: ?
11:57 I don't see how that matters
11:58 lpetit: stuartsierra: EvilDude and NiceDude may indeed not behave the same way, mmm
11:58 chouser: if a particular piece of code doesn't already know which specific type of map its dealing with, that type can change. Such code probably needs an equality test that honors that.
11:59 rhickey: chouser: I'm still confused
11:59 map equality tests are pretty rare, aren't they?
12:00 chouser: now I'm confused. I thought map equality tests were at the center of this conversation.
12:00 rhickey: lpetit: yes, the different behavior is also a problem. If they test =, one could presume using either wouldn't matter
12:00 djpowell: hmm - i think I put maps as keys in a map
12:01 rhickey: chouser: I simply don't understand your point
12:01 stuartsierra_: Re lazytest, here's the latest: http://
12:01 rhickey: chouser: "if a particular piece of code doesn't already know which specific type of map its dealing with, that type can change. Such code probably needs an equality test that honors that."
12:02 example please
12:03 stuartsierra_: I think chouser means having the option to replace a map with a defrecord without breaking anything
12:04 rhickey: djpowell: that's fine, but would you expect looking up {:a 1} to be the same as looking up (AnyRecordWithFieldA. 1) ?
12:04 chouser: are we only talking about maps as map keys?
12:04 rhickey: stuartsierra_: that promise should only extend as far as it makes sense. You are adding some information when adding the type
12:04 chouser: no
12:05 djpowell: rhickey: not really in my case, cause i'd know i'd added to the map
12:05 stuartsierra_: rhickey: I agree
12:05 chouser: So here's a made-up example of such a "piece of code": (defn duplicate-row? [a b] (= (dissoc a :id) (dissoc b :id)))
12:05 rhickey: son, one thing that will have to change is that {:a 1} is not longer a constructor for your thing, if you want it to be a record
12:06 so,
12:06 djpowell: rhickey: in fact (pre defrecord), I have two types of objects with different fields, so records not being equivalent would be fine
12:06 stuarthalloway: the truth revealed! chouser is rhickey's (until recently unclaimed) son! :-)
12:06 chouser: 8-O
12:07 lpetit: Let's call him Luke !
12:08 rhickey: e.g. ((fn [my-map-to-become-record] ...) {a 1}) will have to change, e.g. you'll need a factory fn, and that applies everywhere, including when you construct lookup keys etc
12:08 lpetit: chouser: but but in your example, having called dissoc on both sides almost guarantees that you're comparing two real maps, no ?
12:09 chouser: rhickey: hm, that doesn't bother me at all. I don't think I would have considered doing it that way, if I understand your example.
12:10 lpetit: all it takes is for either a or b to be a record without :id as a key, or particular sort of type that behaves similarly, and the "guarantee" is broken.
12:11 besides being a breaking change, right?
12:11 rhickey: chouser: the point is, in the few cases where you are explicitly creating maps for use in equality tests, it is constructor-like, and all such constructors must change when switching from maps to records
12:12 chouser: ah, good point.
12:12 the-kenny: Is there a version of technomancy's clojure-http-client on clojars somewhere which is compatible with 1.2-RC1?
12:13 lpetit: chouser: I don't understand
12:13 chouser: I mean, you're talking about cases that may already happen today
12:14 rhickey: structural equality obliterates the type, and if it was the default, people would need an equality that included the type. OTOH, if type-inclusive equality is the default, I doubt we'll see any clamoring for this duck-type equality from people using records
12:14 lpetit: chouser: thrown Exceptions, that is
12:16 rhickey: Now, records not being j.u.Maps (in order to fix equality symmetry) is another question
12:17 chouser: lpetit: (defrecord A [id foo]) (defrecord B [foo]) (duplicate-row? (A. 1 "two") (assoc (B. "two") :id 3)) ;=> true
12:17 lpetit: which seems "expected" to me.
12:17 lpetit: rhickey: Ok, so tomorrow you have advanced in cinc, and you have this nice protocols for the "Map" behavior. You have re-created different flavors of "Map" for different sizes : a RArrayMap type, extending protocol "Map", a RHashMap type, extending protocol "Map". If you include the type in =, what a breaking change : (= {:a 1} (hash-map :a 1)) would return false ?
12:18 rhickey: lpetit: such things will not be records
12:19 lpetit: rhickey: do you really want records to be such an exception ?
12:19 rhickey: it's not an exception
12:20 lpetit: rhickey: oh, yes, you're redefining equals() and hashcode() for records, sorry
12:20 rhickey: lpetit: right, and all records will share the same semantics
12:21 Obviously, some lines of code will have to change when moving from a map to a record, in particular all construction
12:22 lpetit: Obviously. In the "library provider side", that's not a problem. Could it be a problem in the "library user side" ?
12:23 I guess not, at least if the user of the library does not violate encapsulation beyond what is promised by the library provider
12:23 rhickey: I simply don't understand why anyone would want 2 records of different types that happened to have the same field to ever be equal
12:23 lpetit: rhickey: chouser ^^^
12:23 06:17:03
12:24 * qbg agrees with rhickey
12:24 * lpetit currently favors including type in equality
12:25 qbg: I think type based equality for records would be the right thing for at least a majority of cases
12:25 chouser: so records would never be = to any PersistentMap?
12:25 rhickey: (defrecord Bill [:charge]) (defrecord Particle [:charge])
12:25 chouser: right
12:26 chouser: imagine they had a :type key
12:26 the reasons they don't are: people don't want to see them, and, they can't be used for fast dispatch anyway
12:27 chouser: ok, at least it's a simple rule.
12:27 rhickey: but defrecord could insert a :type key and then normal semantics would apply everywhere
12:27 lpetit: I don't care if records can not be equal to persistentmaps. I much care there was an easy way to "dynamically" get a record with the same fields from a map
12:28 rhickey: lpetit: that's coming
12:29 would people mind if records had a :rec/type inserted?
12:30 chouser: that couldn't be changed?
12:30 rhickey: chouser: that's where the dragons are
12:30 chouser: yeah
12:30 gotta run
12:31 rhickey: also, {:my "fabricated" :rec/type :Foo} is not in fact of type Foo
12:31 lpetit: no, because then it would make it consistent with the fact that the equality would be based on record as data holder, and not on the real "technical" type. This opens the door to having specialized versions of records a-la arraymap versus hash-map, I guess
12:32 argh
12:36 rhickey: so, we've spent a lot of time on duck-equality. If it is type-inclusive equality, it begs the questions re: the asymmetry
12:37 I can fix the (= amap arecord) for Clojure maps, but not Java maps without dropping j.u.Map support
12:39 lpetit: You mean you can fix clojure.core/=, but not java.util.Map.equals()
12:40 rhickey: lpetit: no, (= clojure-map record), but not (= java-map record)
12:40 I'm not putting more conditionals in =
12:40 lpetit: ok
12:41 qbg: Perhaps (= record java-map) should be true?
12:42 lpetit: qbg: (=) should work regardless the args position
12:42 rhickey: qbg: but Clojure maps are Java maps
12:42 qbg: I think equals is not what we actually want ;)
12:44 lpetit: what happens if we drop j.u.Map for clojure records
12:44 edbond: where can I find doc about how to specify version in leiningen project.clj? I saw "[0.2.5,)", is there more tricks?
12:44 rhickey: lpetit: right, that's the question
12:45 lpetit: in the clojure world, no problem
12:45 from java world to clojure world: no different than from clojure maps to clojure records
12:45 rhickey: IMO, most people passing maps to Java as j.u.Maps are treating them as collections. I haven't seen many j.u.Maps-as-objects interfaces in Java libs, even where I've wanted them (e.g. Drools)
12:46 lpetit: from clojure world to java world: will need to drop something. But records are not maps!
12:47 rhickey: lpetit: but they are associative and Java doesn't have a separate interface for that
12:47 qbg: If we drop j.u.Map support, then from the Java side records would be little better than the de facto OO style of many incompatible classes to hold data
12:48 rhickey: qbg: true, but who is doing Clojure-style objects in Java?
12:48 Clojure programmers using Java explicitly
12:49 could use Clojure interfaces instead, but lose reach over Java maps
12:49 qbg: Make those interfaces protocols and extend support to maps :)
12:49 rhickey: qbg: no protocols in Java
12:50 qbg: (Just semi-joking)
12:50 It would be nice though
12:53 lpetit: rhickey: could you rephrase ^^^(06:48:48 PM)
12:55 rhickey: lpetit: who uses clojure-stype maps-as-objects in Java? Clojure programmers using Java explicitly. They could instead use the Clojure map interfaces, but lose the ability to have the same code work with j.u.Maps
12:56 slyrus: huh? "No project.clj found in this directory"
12:57 sure there is!
12:59 lpetit: rhickey: if we're talking about clojure-stype in java source code, is it a big problem ?
12:59 qbg: They could write a associative wrapper around j.u.Map
13:01 lpetit: gqb: would that work well with graphs of record instances ...
13:01 rhickey: lpetit: dunno. I sure wish there were more maps-as-objects APIs in Java. Were that to come about, records couldn't play
13:01 qbg: wrappers = evil
13:02 qbg: Working in Java = need to accept some evil, maybe
13:04 stuarthalloway: records need to be java maps
13:05 djpowell: is having records have a synthetic 'type' field on the cards?
13:06 qbg: A type key might be the best solution
13:07 rhickey: stuarthalloway: implies an asymmetry in equality without injected :type field
13:07 stuarthalloway: rhickey: java side only?
13:07 rhickey: no, any Java map on LHS
13:08 djpowell: i guess you could try to suppress the type field from clojure places - eg (keys) and print it?
13:08 stuarthalloway: djpowell: just where I was going, but I think it leads to madness
13:08 djpowell: asymmetric equals is obviously very bad
13:09 stuarthalloway: rhickey: why can't we fix that asymmetry on the clojure side?
13:09 slyrus: ah, fnparse3 needs a project.clj :(
13:09 djpowell: stuarthalloway: by reimplementing java.util.HashMap?
13:09 stuarthalloway: no, by doing something before calling .equals
13:09 rhickey: stuarthalloway: for = only? Because it adds more conditional testing to = which I don't want for perf reasons
13:10 stuarthalloway: rhickey: right, ok
13:11 rhickey: one hack would be to have record's entrySet contain the extra key, but breaks any code that uses entrySet, not just .equals
13:11 slyrus: technomancy: in leiningen.core/read-project, it would be nice if it printed the name of the file it can't find. In this case it was a borked dependency in checkouts and it wasn't immediately obvious what was broken (until looking at that exception that we basically ignore ATM).
13:12 djpowell: rhickey: having entryset bigger than keyset sounds fragile
13:12 rhickey: unfortunately there's no guarantee that .equals will call hashCode, that's the easiest
13:12 djpowell: no argument, clearly a hack
13:14 djpowell: perhaps just have the type field there, and suppress it from print by giving defrecords a nicer readable form
13:14 rhickey: djpowell: will impact count/keys etc
13:15 djpowell: urgh, it is sounding a bit like javascripts' map/object muddle
13:15 rhickey: There really should be marcker interfaces for the collection equality categories
13:15 marker
13:17 technomancy: daaku: I have plans to create a "lein interactive" mode that would sidestep JVM boot time. (scala's sbt has this, and people seem to like it.) problem is I use swank myself, so startup time never bothers me. maybe I could find someone else more motivated to implement it; hint hint =)
13:17 slyrus: yes, definitely. can you open a ticket for that?
13:17 stuartsierra: technomancy: I headed in that direction with classpath-manager
13:19 daaku: technomancy: cool -- i'm still very much a n00b, but that sounds like opening up a repl at some point, i'll see what i can figure out over the weekend
13:19 technomancy: stuartsierra: there's definitely a demand for it, just happens that I'm not one of the people affected by it.
13:19 daaku: be sure to mention it on the leiningen mailing list if you start experimenting with it.
13:20 slyrus: technomancy: issue 85
13:20 daaku: technomancy: ok, will do
13:34 rhickey: hmmm, I wonder if I could fix = without any additional branches at the top level. There is already one for IPersistentCollections
13:53 Puzzler: Just catching up on the defrecord/type equality thread. I remember when I first discovered '(1 2 3) and [1 2 3] were equal in Clojure, I thought, "Wow, that's really weird." But I must admit, in practice it's turned out to be *very* useful to not have to worry whether I'm using vectors or lists to represent my collections.
13:54 Since there are several functions that work on vectors but not lists, it seems like it's really the same issue.
13:54 Does equality mean, "These things are interchangeable", or does it mean, "I want these things to be treated as equal for filtering, hashing, etc."
13:56 DanielGlauser: I'm not sure if this was posted earlier but it seems like we could use type equality, attribute equality, and occasionally absolute equality. What about having different semantics for each?
13:56 Puzzler: The math part of me expects equality to mean "interchangeable", but I've been pleasantly surprised how useful Clojure's concept of equality has been.
14:38 chouser: logging was off there for a bit (power outage)
14:41 Puzzler: Regarding the upgrade to 1.2, right now I have some usage of contrib's io and shell-out libraries. Is there a summary somewhere of which functions changed (any functions where the args now differ, etc.)?
14:42 Oh, and duck-streams as well.
15:08 technomancy: Drakeson: it's hard for me to juggle all these projects; how about I just add you to the committers list?
15:09 Drakeson: technomancy: sure, (read your self interview :p a while back). I won't be able to help much though.
15:10 technomancy: np
15:10 what's your github name?
15:10 Drakeson: gilaras
15:11 I even made a pull request for that type fix!
15:23 technomancy: Drakeson: adddded
15:24 Drakeson: technomancy: thanks
15:36 technomancy: pushed. is it built automatically (to clojars)?
15:37 stuarthalloway: Puzzler: you still around?
15:57 wolfjb: (defn plus-one (:doc "returns an incremented number) [x] (inc x)) gives an error: IllegalArgumentException: Don't know how to create ISeq from : clojure.lang.Keyword (NO_SOURCE_FILE:46)
15:58 but remove the (:doc ) and leave the string and it works fine
15:58 stuartsierra: wrong syntax
15:58 wolfjb: ah
15:58 does (:doc ...) not work then?
15:58 * wolfjb is a n00b
15:58 stuartsierra: (:doc "string") means get the key named :doc out of the object "string"
15:59 maybe you mean (defn plus-one {:doc "..."} [x] (inc x))
15:59 wolfjb: doh!
15:59 I misread my tutorial, it is the {:doc ...}
15:59 oops
15:59 hate it when I do that
16:02 on a related note, why does it have to come before the parameter list if it is using a keyword? It seems (defn foo [parms] {:doc "doc"} (expressions...)) would be more readable? I used to document my lisp functions that way so I guess it's what your used to
16:02 stuartsierra: doesn't fit if the function has multiple arities (numbers of arguments)
16:03 wolfjb: ic
16:03 is that common?
16:04 ie, common to have multiple arities?
16:04 qbg: Somewhat
16:04 wolfjb: fascinating
16:04 this is fun
16:07 lpetit: wolfjb: yes it's common. And now, the place you're describing is for placing pre/post conditions
16:07 ,(doc defn)
16:07 clojurebot: "([name doc-string? attr-map? [params*] body] [name doc-string? attr-map? ([params*] body) + attr-map?]); Same as (def name (fn [params* ] exprs*)) or (def name (fn ([params* ] exprs*)+)) with any doc-string or attrs added to the var metadata"
16:08 lpetit: ,(doc fn)
16:08 clojurebot: "([& sigs]); (fn name? [params* ] exprs*) (fn name? ([params* ] exprs*)+) params => positional-params* , or positional-params* & next-param positional-param => binding-form next-param => binding-form name => symbol Defines a function"
16:08 lpetit: argh
16:08 ,(clojure-version)
16:08 clojurebot: "1.2.0-master-SNAPSHOT"
16:11 lpetit: there's no mention of pre/post conditions in fn's doc ?
16:11 stuartsierra: no
16:11 qbg: It is online though
16:12 lpetit: yes, on the special_forms page, not easily found
16:13 ,((fn [x] {:pre [(pos? x)]} (* x x)) 5)
16:13 clojurebot: 25
16:13 lpetit: ,((fn [x] {:pre [(pos? x)]} (* x x)) -5)
16:13 clojurebot: java.lang.AssertionError: Assert failed: (pos? x)
16:13 lpetit: ,(binding [*assert* false] ((fn [x] {:pre [(pos? x)]} (* x x)) -5))
16:13 clojurebot: java.lang.AssertionError: Assert failed: (pos? x)
16:13 * ataggart wishes special forms doc was emitted in the clojure api
16:14 lpetit: oops, *assert* a compile-time flag
16:14 (eval '(+ 1 2))
16:14 ,(eval '(+ 1 2))
16:14 clojurebot: DENIED
16:14 lpetit: wolfjb: ^^^ pre/post examples
16:33 technomancy: Drakeson: no, I will push
16:55 slyrus: hrm.... error: java.lang.OutOfMemoryError: PermGen space (smiles2.clj:2)
16:56 happens during compile. sure, it's using some memory, but not _that_ much...
16:57 flognikr: /msg nickserv set hidemail on
17:03 arohner: slyrus: is that on a long running repl, or on a clean startup?
17:06 is there a mocking library anywhere that mocks across all threads, rather than using binding?
17:07 I remember chouser talking about something similar a while ago
17:12 slyrus: arohner: both!
17:12 I mean a long running repl that was originally started cleanly :)
17:12 arohner: slyrus: did it work on the first startup?
17:13 slyrus: no, the error doesn't appear until after an hour or two of interactive development
17:13 yay heisenbugs!
17:13 arohner: k
17:13 slyrus: try adding -XX:+UseConcMarkSweepGC -XX:+CMSClassUnloadingEnabled to your JVM startup
17:13 slyrus: ok, thanks!
17:13 arohner: and -XX:MaxPermSize=256m just for good measure
17:15 slyrus: ok, I'll try that next time I need to restart
17:15 in the meantime, I think I've got all of the SMILES atom parsing stuff working, now I need to go back fill on the bonds connecting the atoms...
17:22 BobFunk: trying to get started with emacs/swank-clojure but am running into a problem with the repl and my keyboard - probably because it's not a US keyboard
17:22 when I try to insert a closing square bracket
17:22 I get an "M-+ is undefined" message
17:22 since closing square bracket on my keyboard is alt + +
17:22 any way to get around that?
17:25 arete: BobFunk: hmm, are you on a mac?
17:25 BobFunk: arete: yeah
17:26 arete: then I'd probably suggest rebinding command as meta, easier to type too
17:27 BobFunk: ok - total emacs newb, but will try to figure out how to rebind the meta key :)
17:27 arete: (setq ns-option-modifier nil) and (setq ns-command-modifier 'meta)
17:27 if you're using cocoa/nextstep emacs =) what does M-x version say?
17:27 BobFunk: using gnu cocoa emacs
17:28 arete: ahh ok, then that should work... the old name was mac-option-modifier
17:28 BobFunk: GU emacs 23.2.1
17:28 *GNU
17:38 that worked a charm - even if I'm enough of an emacs newb that I edited the conf file with vim :P
17:38 arete: hehe glad to hear it =)
17:40 having to type alt-+ every time you want and end square bracket though, ugh
17:40 reminds me of japanese keyboards where double-quote is shift-2
17:40 Derander: BobFunk: I do that alllll the time.
17:40 lancepantz: i had to alias vim to emacs on my machine
17:41 just a habit
17:41 BobFunk: life of us non-english people! :)
17:41 Derander: typically because when I'm editing my emacs file it's because it's broken and emacs only half loads all of the configs and everything is horrendous looking
17:55 Bootvis: RC1 seems to broken on Windows
17:57 Exception in thread "main" clojure.lang.LispReader$ReaderException: java.lang.Ex
17:57 ception: Invalid token: C:
17:57 if you add a bunch of paths using -cp CLASSPATH
17:57 with C: in them
18:02 BobFunk: hmm - so one problem with binding command to meta on mac is that the normal clipboard paste stops working - anyway to still paste from the os x clipboard?
18:04 Derander: BobFunk: yank works for me
18:04 BobFunk: are you using aquamacs or carbon or xemacs?
18:07 BobFunk: will try if yank works - using gnu emacs cocoa
18:09 works fine yeah - neat
18:09 raek: Bootvis: do you have any spaces in the class paths?
18:10 I don't know what could be wrong, but it would be great if you could mention this on the google group
18:27 Bootvis: nope it's the classpath generated by lein.bat and the problem disappears with 1.1.0
18:27 will be posting there
18:46 pdk: (doc iterate)
18:46 clojurebot: "([f x]); Returns a lazy sequence of x, (f x), (f (f x)) etc. f must be free of side-effects"
18:47 pdk: (doc repeatedly)
18:47 clojurebot: "([f] [n f]); Takes a function of no args, presumably with side effects, and returns an infinite (or length n if supplied) lazy sequence of calls to it"
18:47 lozh: I think you still need to pull from git to get lein working on windows
18:55 Bootvis: There are fixes in git for that problem, should be ok when Phil releases 1.2.1. http://
19:01 Bootvis: lozh: thanks
19:25 polypus: (swank.swank/start-repl port) is completely ignoring the port i pass it and is choosing it's own. anybody seen this?
19:27 slyrus: woo hoo! branched molecules support.
19:36 hiredman: polypus: worked for me yesterday
19:49 polypus: hiredman: ty. fixed it. just had the wrong version in project.clj
19:59 dnolen: ... TextMate is getting closer to being a passable editor for REPL-centric Clojure development
20:00 polypus: dnolen: what's new?
20:02 qed: Hello all
20:06 dnolen: polypus: cake use a persistent VM, so it can support evaluating little snippets of code from the command line
20:06 polypus: that makes it trivial and fast to built all the basics into TextMate, Eval, Load File, Macroexpand, Source, Jump To Definition
20:07 also means you can keep a REPL open in a Terminal and TextMate and your Terminal REPL are in sync just like they are in Emacs, or an IDE or whatever
20:07 brehaut: dnolen thats exciting, ive left textmate for eclipse currently
20:08 dnolen: brehaut: yeah I'm Emac users but I think having a good TextMate story will encourage people to try out Clojure
20:08 I'm an Emacs user, I mean
20:08 polypus: dnolen: i tried etxtmate about a year ago, and it just wasn't ready for clojure. on emacs now, but curious anyways. what's cake?
20:09 textmate*
20:09 brehaut: when i used textmate for clojure i had a repl open in a term and i got very quick at copy and paste :P
20:09 dnolen: polypus: basically a lein clone - with two amazing features, persistent VM, so JVM startup costs are less of an issue, and very good symbol completion in the REPL
20:10 brehaut: yeah no copy and paste here. Shift-Command-L to load your file, Shift-Command-X to eval selection. It's simple really hopefully people do something cooler with what I've come up with. Hoping to blog about it and push it out the door in a couple of days.
20:11 brehaut: dnolen: that sounds like an order of magnitude improvement as it is
20:11 lancepantz: dnolen: could you hold off on the blog post til we announce cake?
20:11 polypus: dnolen: sounds interesting. will be looking out for blog post
20:11 dnolen: lancepantz: of course, do you guys have something lined up. I'm ok with holding off as long as you all want.
20:12 s/something/date
20:12 lancepantz: dnolen: we've just got alot of undocumented tasks, and i got a big stack of commits to push
20:12 dnolen: appreciate it man, i think we'll probably announce it next week
20:13 dnolen: lancepantz: no problem.
20:13 lancepantz: one funny thing, the features you and others like so much were really an after thought
20:14 i think people have grown accustomed to lein and forget the importance of task dependencies in build tools
20:14 dnolen: lancepantz: haha, yes i know, cake is really meant as a build tool, but I'm really only interested in cake eval :D
20:15 lancepantz: for example, my build on lein required manually typing 8 different commands
20:15 dnolen: also probably means the Vim story could improve dramatically as well, right?
20:15 lancepantz: waiting for the jvm startup each time
20:15 now it's one :P
20:17 i think it does drastically, but we didn't think of that at all when we were working on the persistent jvm
20:17 we can probably abstract out all of the swank calls into commands passed to a cake task over the commandline
20:18 really wouldn't be too hard
20:19 ironically, we're both emacs users as well
20:19 ninjudd doesn't use swank though, which is just weird
20:19 defn: he uses slime?
20:19 lancepantz: nothing, just emacs with clojure mode
20:20 defn: weird.
20:20 lancepantz: and copies and pastes to his repl
20:20 defn: that's just wrong :)
20:20 although i sometimes think my REPL becomes a bit cluttered, I just use M-m M-o
20:20 err M-c M-o?
20:21 dnolen: lancepantz: really, cake is big news for supporting good text editors. The requirement to use Emacs or and IDE is just too much for most people.
20:21 defn: im forgetting now... only know it by muscle memory
20:21 brehaut: dnolen: some of us are subprimates, not good at tool using :P
20:22 BobFunk: what is cake?
20:22 defn: some of us are just "tool guys"
20:22 that's how it goes
20:22 I'm a "tool guy", I'd say -- but I can also be the anti-tool guy
20:23 reminds me of a great article on academic programmers....
20:23 brehaut: in the end i only care that i have colorised code and a good repl :P
20:23 defn: http://
20:23 i really think the persistent JVM thing is awesome
20:23 lancepantz: BobFunk: http://
20:23 defn: although Ive been watching my CPU spike here and there, and have java instances which aren't shutting down nicely
20:24 lancepantz: defn: that's definitely one of the problems we need to work out
20:24 defn: cake swank && cake swank gets things up and running
20:24 BobFunk: thanks
20:24 defn: but cake stop && cake stop doesn't always shut it down
20:24 dnolen: defn: cake kill --all always works it seems
20:24 lancepantz: defn: i just use cake kill
20:24 defn: lancepantz: time to document that!
20:24 * defn goes to the wiki
20:24 lancepantz: :D
20:25 polypus: so what about the classpath, does cake always have the whole repository on it?
20:26 brehaut: defn: great link :)
20:27 defn: brehaut: :) there's a lot more great stuff on that site btw
20:27 it's worth looking around
20:27 brehaut: defn oh damn there goes my weekend :P
20:27 defn: haha
20:27 polypus: this answers my Q: "Cake tries to keep the persistent JVMs running as long as possible by reloading Clojure files that have changed. However, when .java, .class and .jar files change, Cake has to restart the project JVM"
20:27 defn: hm I wonder if Runa will like me enough to hire me?
20:28 * defn ponders
20:28 dnolen: sneak peek, http://
20:28 defn: dnolen: TM mode?
20:28 dnolen: defn: yeah uses cake
20:28 defn: or are you using cake with TM?
20:28 brehaut: random moustache question: is there some trick im missing wrt composing route handlers?
20:29 defn: ahh! good idea!
20:29 brehaut: post a gist
20:29 dnolen: brehaut: not really, you can put a moustache app anywhere you would put a handler
20:30 defn: i dont use moustache anymore due to inactivity on that project
20:30 makes me a bit nervous for a production app
20:31 dnolen: defn: haha really?
20:31 brehaut: bbl, i'll return to this question later. coffee calls!
20:31 dnolen: defn: cgrand is pretty good at adding stuff if you request it. but moustache seems to cover the routing bases pretty well
20:31 defn: dnolen: yeah maybe im being overly picky
20:32 brehaut: dnolen: the route params (eg ["foo" param]) are only available via symbols right?
20:32 dnolen: probably the one most well thought out 190 lines of Clojure code
20:32 brehaut: they dont get passed to the handler in req or anything?
20:32 dnolen: brehaut: no but you can pass them yourself with (fn [req] (handler param))
20:33 brehaut: I requested that he add delegate, a macro
20:33 that let's you do (delegate handler param)
20:33 which assumes handler's arg list looks like [request param]
20:34 brehaut: dnolen: ah right, i had seen delegate but not understood how to use it. cheers
20:37 * dnolen needs to put together this ring+enlive+moustache tutorial ...
20:38 * defn needs to rewrite walton and do his own version of clojuredocs
20:38 * defn needs to learn more about NoSQL before he can do this
20:38 * defn needs to update walton for 1.2
20:38 defn: so much to do, so little time
20:40 dnolen: defn: putting Clojure docs on CouchDB seems to me to be a wise idea. but that's my bias. I like the idea of being able to replicate a db for local use.
20:42 defn: yeah i was thinking hadoop actually
20:42 but couchdb works too
20:43 i think clojuredocs gets like 60% of the story right
20:43 but the other 40% is just wrong. granted it's an early version and all...
20:43 but i think there should be a sort of points system, or a total % of example coverage for a library to push users into contributing examples
20:44 the hardest part in automating clojuredocs is that you need some magical sandboxes to allow people to use side-effect laden functions in safety
20:45 people need to be able to use (defn ...) in their examples and have them validated by the server IMO
20:45 i also think that there are multiple sources which should be indexed and pulled into clojuredocs
20:49 but ill keep my mouth shut until i start producing
22:17 jave: I'm trying to get a Conjure hello world app working, but I'm getting a stacktrace instead of hello. Any hints?
22:17 I tried the lein setup method
22:17 dsantiago: Hey, is it possible to run multiple projects at the same time in SLIME?
22:26 jave: ok, downgrading the clojure deps to 1.1.0 solved it
22:49 Bahman: Hi all!
22:50 lyle: Hello, Bahman!
22:50 Bahman: Hi lyle!
22:50 Scriptor: hey Bahman
22:51 Bahman: Yo Scriptor!
23:01 Drakeson: technomancy: What would you think if I experiment with swank-clojure listening on an AF_UNIX socket, instead of the normal AF_INET?