7:38 parth_m: Hello. I just started using clojure.contrib. I have basically added clojure-contrib.jar to the classpath. Just wanted to check it thats the recommended way of doing things. Seems to be working fine.
9:16 cemerick: rhickey: you said earlier this week you were looking (or planning on looking) at the >18 arguments issue I posted about; any ideas there? I ask only because it looks like the netbeans profiler is choking on that bytecode...
9:17 rhickey: cemerick: have you gotten the NB profiler to profile Clojure code at all?
9:19 cemerick: I was trying just a moment ago (not to profile clojure code specifically -- just an app that happens to have some clojure stuff floating around at the periphery). It's pretty unsuccessful -- an exception occurs with roughly the same message as what I posted.
9:19 rhickey: cemerick: Ok
9:19 was focusing on getting lib in first - that's done
9:20 cemerick: Sure, absolutely.
9:27 hoeck: rhickey: built-in lib support rocks, just on par with cl's defpackage and a bit of asdf :)
9:28 rhickey: hoeck: thanks to Steve Gilardi et al
9:28 hoeck: did you ever post the print multimethod?
9:29 hoeck: no, sorry, will do so as soon as i'm home from work
9:39 Chouser: The "requir" exception last night got me thinking -- I think it'd better if the :keywords and functions for ns had exactly the same name.
9:40 The declarative sense of "uses" and "requires" is nice, but if it's good enough for the ns keywords then I think we should use it for the function names too.
9:42 having ns do English grammar transforms on users' code seems like a bad idea. Rails does that and I don't think it turned out well.
9:59 rhickey: what do you think. Are you dead-set on leaving it how it is now?
10:00 rhickey: Chouser: why/when would you use the functions now?
10:01 Chouser: also, there is a difference in that one set are macros and the other needs quoted data
10:01 I had thought about changing the function names to the more declarative ones
10:01 Chouser: I don't plan to use the functions, but my main concern is the attempt to compute English grammar within the API
10:02 rhickey: I don't understand
10:02 Chouser: ...and the fact that that makes the public API less simple with little benefit.
10:03 the ns macro programmatically converts :requires to 'require and :uses to 'use.
10:03 I guess it's lucky there's not a 'try that needs to be computed from :tries
10:03 rhickey: Chouser: that's an implementation detail
10:04 could just as easily be a map
10:05 Chouser: yes, but it's exposed in the public API of providing the keywords and the functions, and in the stack traces produced when you forget (understandably) to use the present-perferct form form because you're inside the ns call.
10:06 it seems like complexity (in the programmers head and in the ns implementation) with very little benefit.
10:07 rhickey: Chouser: I understand and am not strenuously opposed, but you are speaking from the perspective of one who has been using the functions a la carte. For instance, you get alias from using :as
10:07 but I wouldn't call alias as nor :as :alias
10:07 Chouser: I understand, and if the a la carte functions were made private, I think my argument would be much weaker.
10:08 rhickey: My thinking was - the new method would be to use ns. Everything is declarative and the names are good...
10:09 then, at the repl you need to reload something, seems weird to call (requires ...)
10:11 so, if unified, the keywords would be :use, :import, :require - I'd be ok with that. But there's still the difference in API - quoted vs not, that make them incompatible - the bigge issue last night wasn't requir, it was the quoted data in :requires
10:11 Chouser: I can certainly see how we arrived here, and in a vacuum I'd probably prefer (requires ...), but with the existance and eventual prevalence of :requires, I think having (require ...) is actually more confusing.
10:11 rhickey: I would really like to discourage use of the functions in source
10:11 to the extent of saying tools will only analyze ns declarations
10:13 Chouser: well, I've lodged my complaint and I think you understand my argument.
10:13 Maybe I'm extra-skittesh on this one because of how far Rails took it
10:14 ...and what a poor choice that now seems to be (although I'm surprised how few complaints I hear about it).
10:14 rhickey: anyone else? on the table is changing :uses/:imports/:requires to :use/:import/:require in the ns macro
10:14 what is the Rails problem?
10:15 Chouser: they do it everywhere. The prominent example is that class names are generated from table names, but are converted from plural to singular along the way.
10:15 A table named customer-entries is handled by a class named CustomerEntry
10:16 rhickey: that's pretty common ORM I think, ORM being awful in the first place
10:17 Chouser: well, you'd better be sure your understanding of the rules of English grammar are exactly the same as Rails', or you're going to have trouble. ...and grep is suddenly much less useful.
10:17 anyway, as I said I don't actually hear people complain about it, but having written my one big Rails app, it seems like a big ol' waste.
10:18 rhickey: I understand, but the problem is in the approach to data as much as the names
10:18 I'm ok with :use/:require/:import
10:18 Chouser: clearly the (ns) issue is smaller because you're in complete control of both ends (both the ns API and the underlying functions).
10:25 rhickey: changed :requires/:uses/:imports in ns macro to :require/:use/:import
10:26 cemerick: FWIW, +1 on that
10:28 Chouser: what I hear from my Ruby colleagues is that, once you're past some initial prototyping stage, using the autogenerated stuff is a no-go (due to database performance issues)
10:31 rhickey: ORM is a bad idea
10:31 OODB is a bad idea
10:33 Chouser: cemerick: I think that's actually a separate issue. Even if you don't use the tool-generated code, the underlying ORM still uses that computed name mapping. I think. ;-)
10:34 cemerick: I'm completely not a ruby programmer, but from what I've heard, high-volume sites end up dropping the ORM entirely.
10:34 or, the automated ORM, to be precise -- one ends up specifying mappings between columns and attributes, etc.
10:35 Chouser: oh, wow. huh.
10:35 well, I'm apparently not a rails programmer either, then. :-) Ruby was probably my favorite language pre-clojure.
10:41 cemerick: keep in mind, that's not much more than rumor -- just what I hear from friends :-)
11:33 DrewR: cemerick: High volume sites end up dropping Rails, not just ORM. :-)
11:34 Having written a few highish-volume Rails sites I can officially say all the convenience it affords makes you yell profanity later.
11:35 Ruby is a difficult framework language.
11:36 It's great when you're building a framework because it's flexible, but it sucks when someone else needs to reverse engineer.
11:36 And because the abstractions usually leak in very bad ways, you always have to do the latter.
11:37 It's what drove me back to Python. What a clear, modular language.
11:37 Clojure is well on its way there and I'm excited.
11:40 Anyway, all that said, I vote for unambiguity in ns. :-)
11:40 ...which it looks like rhickey just checked in.
11:41 rhickey: drewr: yup
11:43 it's weird to be over 1000 checkins...
11:43 DrewR: Congratulations.
11:44 I'm really impressed you stuck with this for so many years.
12:32 ozzilee: Is anyone working an an http library for Clojure? The amount of code needed to issue a PUT in Java is ludicrous.
12:32 Chouser: from the client side?
12:34 ozzilee: Chouser: Yeah.
12:39 I haven't tried that out, but I remembered it being mentioned.
12:40 ozzilee: Hmm, I'll take a look.
12:40 I'm trying the apache commons httpclient right now, might be ok.
12:40 Chouser: sure
13:11 abrooks: Wow, I've been using FoxMarks for 10 minutes and already have 42 backup IDs (revisions).
13:11 This seems a bit excessive.
13:11 I don't think I've made that many changes.
13:11 er.... wrong channel.
13:11 * abrooks needs less allergies.
13:29 abrooks: sf.net is getting slower and slower it seems. I just pulled the entire clojure mercurial mirror in 7 seconds. It takes as much as twice (somtimes even more) that long to do most operations that involve the Subversion server. (Although it takes only 2.5 seconds to do a noop svn update.)
15:06 notyouravgjoel: is there any clojure OO implementation, or is it most common to do oo stuff in Java?
15:07 also, do clojure ints have a max size, or will they automatically become bigint-like things?
15:13 DrewR: notyouravgjoel: As a functional language, Clojure doesn't support the OO paradigm.
15:14 Arguably you can create much better abstractions.
15:15 notyouravgjoel: well, what about a struct system, then?
15:15 DrewR: To your second question, they grow automatically.
15:15 user> (* 99999 99999999999999999999)
15:15 Yep, it's got structs and generic functions.
15:15 notyouravgjoel: fun fun
15:16 ugh, poor xchat for windows
15:16 kotarak: notyouravgjoel: struct + multimethods are probably more flexible than the average OO system in <yourfavoriteOOlanghere>.
15:17 notyouravgjoel: I believe it
15:25 what about using random standard java things, such as hibernate?
15:55 notyouravgjoel: thanks for the answers =)
15:57 one last thing: I'm thinking of writing a web bot in clojure, which will basically behave like a browser, parse web pages, and do actions based on the content. Any advice/sensible libraries/considerations?
16:06 fyuryu: notyouravgjoel: check out HttpUnit
16:09 notyouravgjoel: thanks =)
16:15 hoeck: notyouravgjoel: there is also http-client.clj in the files section of the google group
16:46 abrooks: rhickey: Are things all set for your Sept. 29th Boston Lispers talk?
16:47 rhickey: Yes
16:47 abrooks: Very cool. If the current plans stick, I'll be there. What's the topic?
16:49 rhickey: It will be about the Lisp nature of Clojure, Clojure as a Lisp, why I wrote a new Lisp etc
16:49 I can presume the audience knows Lisp, and dig in a bit more
16:50 kotarak: will the slides or video be available afterwards?
16:50 rhickey: kotarak: If it's a good talk :)
16:51 kotarak: rhickey: it will be. :) No doubt.
16:53 the talks I give are limited to being overviews/introductions
16:53 kotarak: That would be nice. I know Webex from work.
16:54 rhickey: would people be willing to 'meet' regularly for a study group?
16:54 I guess time zones would be an issue
16:54 kotarak: Most likely.
16:57 How much does yugma cost? I know our local solution work to be quite expensive.... But that's for a company. There everything is twice the price.
17:00 rhickey: kotarak: I think it's free for ad-hoc sessions of 10 people, full-featured is $10/10, $30/30 $70/100 per month
17:02 kotarak: rhickey: o.O That's nice. Our service charges per minute and participant.
17:03 abrooks: There's some features (such as whiteboard) which are only free for 15 days after signup on the personal plan, it appears.
17:03 rhickey: abrooks: right
17:21 roblally: I've been playing with the new ns feature in head. Very nice. But I've been seeing one strange side-effect. I can load a file with (use) if I embed it in a (ns) call. But if I call the function (use) outside of the (ns) call I get an error. Am I using it correctly?
17:21 kotarak: What kind of error do you get?
17:22 roblally: Exception in thread "main" clojure.lang.Compiler$CompilerException: all_tests.clj:1: Unable to resolve symbol: bowling-tests in this context
17:22 Where I'm calling (use bowling-tests)
17:22 kotarak: (use 'bowling-tests) Not the quote
17:23 roblally: Thanks, the odd thing is that (ns anything (use bowling-tests)) works fine.
17:23 kotarak: It's because it's a macro, while use is a function.
17:24 So bowling-tests is evaluated before it is passed on to use.
17:24 roblally: That makes sense.
17:24 kotarak: Since there is no variable of that name you get the Exception.
17:24 ns is macro. So it can decide itself whether to evaluate bowling-tests or not.
17:25 roblally: Is there an advantage to use being a fn rather than a macro in this context? I'm thinking purely of consistency.
17:25 kotarak: Maybe the ns should behave the same as use/require and friends?
17:25 Same thought. :)
17:26 roblally: Thanks for the help. I'll get to grips with this soon ... honest.
17:27 kotarak: roblally: take your time. Speed is often dangerous.
17:27 roblally: Particularly when you're stumbling around blindly!
18:07 rhickey: anyone with google code experience? They now support EPL license (successor to CPL) and so now is an option for Clojure
18:08 at this point I'm not using SF for anything but SVN
18:09 kotarak: They only support SVN, IIRC. I prefer Mercurial, but to be honest I have no experience with it.
18:09 Google Code, I mean.
18:09 rhickey: I'm fine with SVN
19:46 kid_meier: anybody active in here?
20:09 DrewR: kid_meier: Sure.
20:10 kid_meier: trying to figure out some stuff with the classpath..
20:10 any idea why the new load-resources does not use the RT.baseLoader() to find the resource?
20:18 DrewR: Hm. I haven't had the chance to play with it yet.
20:20 kid_meier: its puzzling. Rich also recently added (add-classpath) but thats the not the classloader used by (load-resources)
20:21 i must be missing something. or perhaps I'm doing something silly.
20:49 rhickey: kid_meier: no, that's wrong - Steve switched from using classloaders to using RT.loadResourceScript which doesn't use any - I'll look into it...
20:59 kid_meier: rhickey: good to know. it felt like I was going to have to write a separate function to load resources off of RT.baseLoader(). thanks.
21:01 rhickey: kid_meier: try the latest (rev 1012)
21:05 kid_meier: rhickey: Thanks! that does it