#clojure log - Jul 30 2010

The Joy of Clojure
Main Clojure site
Google Group
List of all logged dates

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://www.google.com/search?sourceid=chrome&ie=UTF-8&q=clojure+cake

0:14 got a link?

0:15 qbg: http://github.com/ninjudd/cake

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://clojure.org/file/view/clojure_cake.png/42336345/clojure_cake.png

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://github.com/ninjudd/cake/issues/issue/11

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://groups.google.com/group/clojure/browse_thread/thread/e04ab3f6e17f85c4 ?

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://getclojure.org:8080/examples/hash-set says "false" here

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://weavejester.github.com/compojure/docs/routes-in-detail.html

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://github.com/cgrand/moustache for routing. A bit more idiomatic - designed around the idea of destructuring.

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://paste.lisp.org/+2F6J as a possible syntax

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://weavejester.github.com/compojure/docs/routes-in-detail.html i dont know to much except for that page. There are some examples in the tests aswell i think

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://clojure.org/downloads

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://build.clojure.org/releases/org/clojure/clojure-contrib/1.2.0-RC1/

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://maven.apache.org/ant-tasks/examples/install-deploy.html

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://maven.apache.org/wagon/ which let me deploy with ftp

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://github.com/liebke/incanter/blob/1.0/modules/incanter-parent/pom.xml

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://maven.apache.org/ant-tasks/examples/install-deploy.html

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://www.assembla.com/spaces/clojure/tickets/417-add-more-information-to-changes-txt-for-case-and-vector-of

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://bit.ly/aFSaq8

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://bit.ly/bZBQPC

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://build.clojure.org/releases/org/clojure/clojure/1.2.0-RC1/

11:11 Raynes: Awesome.

11:13 fogus: Spread the word: http://news.ycombinator.com/item?id=1561327

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://www.staringispolite.com/likepython/

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://stuartsierra.com/2010/07/30/lazytest-churn

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://github.com/technomancy/leiningen/commit/c461fa75dd552c1080dd293af7db782570c2f16b#diff-2 is the specific patch if you want to build your own copy.

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://www.ee.ryerson.ca/~elf/hack/academic.html

20:23 i really think the persistent JVM thing is awesome

20:23 lancepantz: BobFunk: http://github.com/ninjudd/cake

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://www.flickr.com/photos/13326626@N05/4844589927/

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?

Logging service provided by n01se.net