#clojure logs

2008-08-30

08:18wlrrhickey: i would be interested in your study group.
09:29rhickeywlr: ok, that makes one so far :)
09:33wlrrhickey: sounds like a "crash course" before your Boston lisp session ;-)
09:34rhickeywlr: I may not get the study group up and running before that. I also have the JVM Languages Summit coming up
09:34kotarakrhickey: make it two, but it heavily depends on the time (I'm in Germany)
09:35kotarakwhat kind of topics do you intend to discuss in the study group?
09:35wlrrhickey: np, here.
09:44rhickeykotarak: 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
09:45rhickeyLike an in-person study group/meetup, which BTW, I'd be happy to conduct in the NY area if there was enough interest
10:36kid_meierrhickey: Where is this first study group being conducted?
10:37rhickeykid_meier: just an idea right now - online on something like yugma: http://www.yugma.com/
11:32kotarakHow 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:42rhickeykotarak: one curses the abomination that is checked exceptions
11:56hoeck_rhickey: uploaded print.clj to the files section in the google group
11:57rhickeyhoeck_: thanks, I'll have a look soon
13:35kotarakrhickey: (concerning the exceptions) I interpret your answer as "Abandon all hope!", right?
13:36rhickeyno, what is normally done is catch the exception and rethrow a RuntimeException with the real exception as the cause
13:37kotarakaha. Is this "recommended" practice for Clojure connected projects? ie. can one live with it or is it even worse.
13:38rhickeyI've had to do it many times
13:39rhickeythere's no alternative when implementing an interface that doesn't declare exceptions
13:39rhickeychecked exceptions are a serious anti-feature
13:40kotarakOk. 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:41kotarakI don't like such bondage'n'discipline style "features".
13:55kotarakAh. Works. :) Maybe not perfect, but we don't throw exceptions anyway. ;)
13:59kotarakrhickey: Is there a special reason, why you added key and val to IMapEntry?
14:00rhickeyoriginally IMapEntry didn't extend Map.Entry
14:00kotarakah. ok.
21:40blackdogwith the new library stuff do i have to put all my single clj files in their own dir?
21:41blackdoglike if i have utils/http.clj and utils/json.clj
21:41blackdogit seems that it needs to be utils/http/http.clj etc
21:41rhickeyeach namespace needs a dir
21:41blackdogok
21:42blackdogbummer :) one thing i like about clojure is the flatness, but i realise you need it for ddebugging etc
21:44kid_meierblackdog: if i'm not mistaken, you could keep a flat directory structure and just use (load-resource)
21:45blackdogyea,
21:45kid_meierI 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:46kid_meierbut given the desire for hierarchical namespaces, i think the approach that was taken is the most consistent and easy to understand.
21:46blackdogyes i agree cant argue with the logic
21:47blackdogi just really dislike descending 5 or 6 levels of directory to get to code
21:48blackdogwell maybe thats excessive :)
21:48kid_meierya true. I guess in Java-land things like Eclipse nicely hide that.
22:54blackdogso 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") ?