0:00 Myoma: by the way I don't intend to hack it so maybe this is slightly off topic ..
0:01 arohner: one thing that helped me was to read the stack trace
0:02 do something that will cause a stack trace, and then read the stack trace
0:02 i.e. (foo 1)
0:02 and then start at something that looks interesting, like Repl.main or eval()
0:03 and then go over to Repl.java and follow the code
10:40 Chouser: ah! I just now got the point about a partial refer of 'clojure and then a later full default refer.
10:52 rhickey: Chouser: ok, so now what about defns?
10:53 Chouser: makes sense to me
10:53 rhickey: I can work with your patch as-is, but I think I'm locked out of checkins on SF today
10:54 Chouser: gah
10:54 I didn't hear a whole lot of objection to moving the repo to google code.
10:54 rhickey: this kind of thing has been pretty rare on SF, I wonder how Google Code compares?
10:55 Chouser: that is one of the benefits of a distributed vcs (git or hg instead of svn) -- the "central" server isn't all that important anymore.
10:56 Chouser: I'm not sure that's true - where do I put my stuff so you can get it?
10:56 Chouser: Since I'm using git-svn, I have a complete history of the clojure repo locally. I could look into importing that to google if you want.
10:56 rhickey: where's the canonic version, etc
10:57 Chouser: sure, there's still value in a generally available canonical server. But routing around damage is much easier.
10:57 rhickey: Chouser: I'll have to move to EPL before I put it up
10:57 Chouser: oh, that's right. ok.
10:58 rhickey: Chouser: I think DVCS is neat, but maybe not a good fit for the benevolent dictator model :)
11:02 Chouser: heh, well, I don't think that matters much. We're all using dvcs anyway, even if you aren't.
11:02 rhickey: right
11:02 Chouser: ok maybe not "all".
11:04 but with dvcs if you're in a situation like this where the central server's down, you can continue to do checkins, and all your data and meta-data can be synced up later -- either with the same central server or a new one (in the case of the old one going away forever).
11:04 of course the tool integration is not as deep yet.
11:05 You'll be using dvcs eventually, so I don't really feel I need to convince you right now. :-)
11:06 * Chouser mutters something that sounds like "revision control, you're doing it wrong"
11:06 rhickey: Chouser: I understand, but not having that forces a 'working head' mentality that multiple local working copies doesn't, plus far less merging (i.e. none for me)
11:07 I've used Mercurial for personal things, much more of a hassle than SVN built into IntelliJ
11:07 cemerick: I guess I'll have to get over my google code aversion issues ;-)
11:08 rhickey: I routinely work on Clojure on 3 different machines in different locations, and when I move I need to check in - the result is lots of working checkins
11:09 cemerick: what are your issues with google code?
11:10 cemerick: rhickey: nothing substantive, really. I think we had this discussion before, though. I don't trust google on a variety of levels, but that's my problem more than anything else.
11:11 rhickey: I'd love to hear from someone re: uptime etc
11:11 cemerick: I don't actually think google code provides much more than svn + trac (if you were to host such things on your own, although I'm sure there are trac hosts floating about). Given their resources, I was pretty disappointed in it.
11:12 Chouser: I'm happy to know that there are various dvcs copies of the clojure repo around -- my own, github, hg mirrors, etc. If google (or sf.net for that matter) loses all the data, we'll be able to reconstitute it with very little fuss.
11:13 rhickey: Right now Clojure doesn't even have trac, and I'm not interested in hosting anything. So the issue tracking is something I'm looking for from google code
11:13 Chouser: really? You're giving in on issue tracking?
11:13 rhickey: Chouser: I fully acknowledge the superiority of DVCS in the large
11:13 Chouser: I didn't say anyone else could enter issues
11:13 Chouser: hehe
11:14 rhickey: Well, I'm still trying for 'no known bugs'
11:14 * Chouser can hear the stress bearing down like a freight train.
11:15 cemerick: rhickey: personally, I'd much prefer something like assembla, but this is your baby :-)
11:15 rhickey: But I keep a todo list that's not web based and is private - keeping it online will let people know where things are going
11:20 albino: rhickey: the reason you don't want an issue tracker is for the perception of no known bugs?
11:21 rhickey: albino: no, I fix bugs as they are reported, rather than put them on a list
11:22 cemerick: assembla looks neat, have you used them?
11:23 cemerick: rhickey: only in passing -- we host all of our stuff in-house (our svn and project mgmt stuff reside on the only server we don't lease or have colo'd somewhere). Friends of mine have used it heavily, and have very good things to say.
11:24 I presume you'd be able to get them to set you up with a full-featured account, given that it's an open source project.
11:29 ozzilee: Does anyone know if it would be possible for multiple versions of a java library to be loaded at the same time, cordoned off in different namespaces perhaps?
11:30 rhickey: cemerick: I didn't see that offered, but did see this: http://
11:30 cemerick: ozzilee: you would need to use different classloaders -- same as in regular java
11:31 ozzilee: cemerick: Hmm. Ok thanks.
11:32 cemerick: rhickey: hrm, unapologetically in startup mode, I suppose
11:32 rhickey: cemerick: right
12:17 jgracin: default target jvm version on Java 6 is 1.4, right?
12:17 in javac, I mean
15:17 rhickey: the documentation on reader forms claims that symbols beginning or ending with : are reserved by Clojure. Surely, you didn't mean keyword literals, did you? Am I understanding something incorrectly?
15:18 rhickey: if it begins with : it's not a symbol. "reserved by Clojure" means its interpretation is reserved, i.e. it can't be used generally as a symbol
15:19 jgracin: oh, ok.
15:20 what is the equivalent of keywordp in CL? how do I check whether something is a keyword?
15:21 rhickey: keyword?
15:21 Chouser: (keyword? :foo) ==> true
15:21 jgracin: aieee! :-) how stupid can I get...
15:22 rhickey: find-doc is your friend: (find-doc "keyword")
15:22 jgracin: cool! I didn't know about that one.
15:29 wlr: will it always be the case that recompiling anything (not just macro(s)) in a :use'd ns requires recompiling a :use'ing ns for the :use'ing ns to see the new effects?
15:31 rhickey: wlr: depends on what you are trying to 'see', new definitions of existing fns are seen without any recompiling
15:31 getting refers to new names requires re-using (probably by just re-evaluating the defns form)
15:33 wlr: rhickey: that's what i thought but i swear i had to do a recompile after having changed a function in a a:use'd ns.
15:34 rhickey: wlr: shouldn't be
16:22 wlr: rhickey: just for the record, i mistakenly compared old output with (duh!) old output leading to the faulty conclusion that the change in the :use'd ns wasn't visible.
16:22 rhickey: wlr: np, glad it works
18:17 rapido: ping
20:04 joubert: Hi,
20:04 rhickey: hi
20:06 joubert: I'm trying to determine whether the parameter to a function is a map.
20:07 There is (vector?) but I am unable to find an equivalent for maps
20:07 (according to the API docs anyway)
20:07 not sure whether it is in the code base?
20:08 I guess I should look, thinking about it now
20:08 hmmm, nevermind
20:08 rhickey: (map? m)
20:09 joubert: thanks, Rich. what about a predicate for lists?
20:11 rhickey: (instance? clojure.lang.IPersistentList x)
20:11 joubert: ok, great.
20:19 btw, I see that (map?) is on the main api doc page, but not on the page for data structures where the other map forms are documented.
20:20 rhickey: not every function will appear in the descriptive docs
20:21 joubert: oh ok; but will in api main?
20:21 rhickey: there's also find-doc at the repl to help you find things that are only in the SVN and not in the API reference
20:21 API docs document the release
22:10 arohner: local variables are not vars, right?
22:21 DrewR: You mean those defined by let?
22:21 arohner: yes
22:21 DrewR: I think they're Vars.
22:21 They're immutable.
22:22 I'm not sure how to tell though.
22:22 user> (let [x 3] (class x))
22:23 arohner: well, (let [foo 5] (var foo)) doesn't complain
22:30 arbscht: I don't think they're Vars
22:30 local bindings are not variable, and Vars are mutable
22:33 arohner: that form should complain. maybe you have defined foo globally previously?
22:34 arohner: arbscht: ah, you're right
22:34 I had previously defined it
22:34 after unmapping, Caused by: java.lang.Exception: Unable to resolve var: foo in this context
22:34 DrewR: Vars are mutable?
22:35 How so?
22:35 arohner: using set!
22:36 arbscht: Vars exist for the purpose of thread-local mutability :)
22:37 DrewR: Ah, you're right. I just never use them that way.
23:11 mbeau: just wondering where I should look in the source code to understand how the '.' operator works?
23:19 arohner: mbeau: this is kind of throwing you off the deep end, but clojure/src/jvm/clojure/lang/Compiler.java
23:19 search for DOT
23:19 a lot of Compiler.java has to do with parsing the source, and it's kind of hard to escape that
23:21 mbeau: arohner: thanks, that's where I was looking around, but as you warn it is pretty tough to see what is going on
23:23 ok, actually I see that HostExpr is a good place to start
23:28 really, the thing I'm curious about is how the (.foo ...) syntax is implemented
23:38 arohner: mbeau: ?