8:18 wlr: rhickey: i would be interested in your study group.
9:29 rhickey: wlr: ok, that makes one so far :)
9:33 wlr: rhickey: sounds like a "crash course" before your Boston lisp session ;-)
9:34 rhickey: wlr: I may not get the study group up and running before that. I also have the JVM Languages Summit coming up
9:34 kotarak: rhickey: make it two, but it heavily depends on the time (I'm in Germany)
9:35 what kind of topics do you intend to discuss in the study group?
9:35 wlr: rhickey: np, here.
9:44 rhickey: kotarak: The idea would be to go through the language in, say, 10 weeks, instead of the 90 minutes I usually have, with more interaction and questions
9:45 Like an in-person study group/meetup, which BTW, I'd be happy to conduct in the NY area if there was enough interest
10:36 kid_meier: rhickey: Where is this first study group being conducted?
11:32 kotarak: How does one handle this Exception throwing stuff in Java? I want to rewrite my lazy-map in Java, since there were some issues with the proxy implementation. But eg. MapEntry.getValue does not throw an exception, but in my case it could happen. How do I propagate this to the surroundings?
11:42 rhickey: kotarak: one curses the abomination that is checked exceptions
11:56 hoeck_: rhickey: uploaded print.clj to the files section in the google group
11:57 rhickey: hoeck_: thanks, I'll have a look soon
13:35 kotarak: rhickey: (concerning the exceptions) I interpret your answer as "Abandon all hope!", right?
13:36 rhickey: no, what is normally done is catch the exception and rethrow a RuntimeException with the real exception as the cause
13:37 kotarak: aha. Is this "recommended" practice for Clojure connected projects? ie. can one live with it or is it even worse.
13:38 rhickey: I've had to do it many times
13:39 there's no alternative when implementing an interface that doesn't declare exceptions
13:39 checked exceptions are a serious anti-feature
13:40 kotarak: Ok. Then I will simply go with it as necessary evil. I don't know Java very well, so I don't really know, what's the Right Way(tm) in such cases. In case it's usual practice (eg. because there is no other way) that's fine with me.
13:41 I don't like such bondage'n'discipline style "features".
13:55 Ah. Works. :) Maybe not perfect, but we don't throw exceptions anyway. ;)
13:59 rhickey: Is there a special reason, why you added key and val to IMapEntry?
14:00 rhickey: originally IMapEntry didn't extend Map.Entry
14:00 kotarak: ah. ok.
21:40 blackdog: with the new library stuff do i have to put all my single clj files in their own dir?
21:41 like if i have utils/http.clj and utils/json.clj
21:41 it seems that it needs to be utils/http/http.clj etc
21:41 rhickey: each namespace needs a dir
21:41 blackdog: ok
21:42 bummer :) one thing i like about clojure is the flatness, but i realise you need it for ddebugging etc
21:44 kid_meier: blackdog: if i'm not mistaken, you could keep a flat directory structure and just use (load-resource)
21:45 blackdog: yea,
21:45 kid_meier: I agree though, my initial thoughts with the way the lib stuff worked out was that there was one more level of directory than I would prefer.
21:46 but given the desire for hierarchical namespaces, i think the approach that was taken is the most consistent and easy to understand.
21:46 blackdog: yes i agree cant argue with the logic
21:47 i just really dislike descending 5 or 6 levels of directory to get to code
21:48 well maybe thats excessive :)
21:48 kid_meier: ya true. I guess in Java-land things like Eclipse nicely hide that.
22:54 blackdog: so if I'm in a lib and i just want to load other clj that are in the same namespace then I just do (load-resources "my.clj") ?