8:58 That doesn't have much of anything to do with compile-time though.

8:58dnolen: AWizzArd: you can provide arguments types to definterface, but you will also have to type hint your method calls and it's arguments when you use it.

8:59AWizzArd: What I like so far about the definterface: I have a macro that expands into a defn, and it type-hints its return value. And the definterface method also type-hints its return value. This allows me to call (.add (.myInterfaceFN (my-macroed-defn-that-returns-a-record-implementing-the-ITF)) (JButton. "Hi")) without throwing a reflection warning.

9:00 I don't know if I make .getContainer a Protocol fn get-container that I can also specify that get-container always returns a java.awt.Container

9:01 And also have it making use of the typehint that my macro added to my-macroed-defn

9:24mduerksen: chouser, susumu: i don't know the internals of def, but could it be caused by the fact that (def x (reduce... allocates the memory for the range twice (one for the def, and one for the evaluation of reduce). in contrast, a (reduce... alone just allocates it once, and also the (def x (let [] (reduce ... , since within the let, no var is created

9:59AWizzArd: chouser: yes, for performance reasons. Though it is in principle dependend on your editor, which could hide the type-hints.

9:59 technomancy: The swank-clojure I currently use is compatible with Clojure 1.3 Alpha 2. Is there already a version which runs 1.3.3a or even 1.3.4a?

10:00 chouser: In 1.3.3a the new thing was manually definde bindable vars. What changed in 1.3.4a?

10:00chouser: bartj: java methods can't be overloaded on only their return type, so if you hint the args sufficiently, Clojure will know the return type and can use that knowledge in subsequent expressions

11:35AWizzArd: Btw, I suggested rhickey to not implement those factories automatically, but instead wait and see how Records will be used. I think we gathered a good bit of experience and have use cases and it should now be possible to add some factories.

11:37leif-p: Hi, all. Is anyone present familiar with the labrepl exercises from Relevance?

11:42leif-p: I was doing the 'zero-sum' exercise, and as is common with exercises, the most interesting ones don't have solutions given. I don't really have any experience with concurrent programming, so I wanted to ask someone if my reasoning about the Bonus question 1 was correct.

11:48clojurebot: Please do not ask if anyone uses, knows, is good with, can help you with <some program or library>. Instead, ask your real question and someone will answer if they can help.

11:59leif-p: OK, let's say you have a set of 'bank accounts' repr. by {id (ref balance), ...} OR (ref {id balance, ...}). You have to transfer between accounts without changing the total, and you have to be able to read a consistent total. The question says "One of these approaches is the correct one. Which one, and why? Under what circumstances would the other approach make sense?" My reasoning is that transfers will be a lot more co

12:11AWizzArd: I have a seq and want to fetch the element that follows a given keyword. Do you have other ideas than this to fetch the 1000?

13:00amalloy: cemerick: i haven't been following. has the Ah-ha thread gotten bad too?

13:00cemerick: amalloy: there's any number of bad threads. The s/n ratio has completely flipped around AFAICT.

13:00 Maybe I have that impression because I only look when people send me mails/tweets/etc saying "whoa, what's up with the ML"?

13:01amalloy: cemerick: bizarre. are there enough people around who can be "trusted" to moderate without flipping out? cause it seems like even pillars of the community are getting involved in some of these threads

13:05cemerick: There was an item on HN a week or two ago about how egalitarian communities die with the influx of less engaged / more foolish members. Anyone have the link for that on hand? My google-fu fails me.

13:06technomancy: cemerick: kinda feels to me like being in university when a bunch of freshmen flood in, all wowed by this one prof.

13:10 the first approach is definitely wrong, and the second right. your reasoning about "two accounts in a transaction" is true, but is misguided; the problem is i'm having trouble quantifying where the wrong-thinking is. i think it's related to immutability, and the cheap-ness of @foo. do you have The Joy of Clojure?

13:12AWizzArd: technomancy: The swank-clojure I currently use is compatible with Clojure 1.3 Alpha 2. Is there already a version which runs 1.3.3a or even 1.3.4a?

13:13amalloy: a good general rule, though: you usually want as few reference-type objects as possible; making them bigger is a much smaller problem than making more of them

13:18leif-p: amalloy: I do not have tJoC. I was worried that if I use accounts = (ref {}), and I have 1000 people trying to do (transfer accounts from to amount), there's going to be a lot of waiting around.

13:20amalloy: leif-p: that's an interesting point. i guess i haven't had that sort of usage pattern before

13:22technomancy: AWizzArd: I just got some patches from monsieur stuart s that allegedly improve support for 1.3; lemme push to clojars

13:23amalloy: leif-p: the problem with your approach (and it is a soluble problem) is that when you do try to verify that the total is 0, you'll need to somehow deref them all in a consistent snapshot. eg (reduce + (map (comp deref key) accounts)) won't work

13:25 i think (reduce + (dosync (map (comp ensure key) accounts))) will work, but it means the whole balance-checking operation will have to reload lots of times because the constant balance-transfers are trampling it

13:29AWizzArd: technomancy: btw, is there a direct download link from clojars?

13:30technomancy: AWizzArd: there is somewhere; couldn't tell you off the top of my head

13:34amalloy: the problem is that @foo, even in a ref, is an instant snapshot of foo's current value; only *writing* to a ref (or ensuring it, which is basically a dummy write) will ever make a transaction retry

13:41leif-p: amalloy: Erk. The labrepl ex. has the (dosync (reduce + ...) code I described, and it says "change total-balance to read within a transaction, which guarantees that all reads are from the same point-in-time." So that's wrong?

13:59clojurebot: contains? is for checking whether a collection has a value for a given key. If you want to find out whether a value exists in a Collection (in linear time!), use the java method .contains

14:12 stu is 100% right on that one: it's not specified in the docs specifically because it's an implementation detail. it might change at any time, and you should only pass sets into clojure.set/difference

14:19bartj: amalloy, (a-set element) -> checks for the presence of the element in the set, right?

15:07cemerick: The former, plus Collections/enumeration, and the whole lot that hangs with them.

15:07livingston: I haven't used spit much (I'm assuming that's the preferred way to write out a list), I'm calling (spit "file" *foo*) where *foo* is a (def *foo* (some list thing)) I keep seeing only clojure.lang.LazySeq@6580f481 in my output .. how do I ensure I get the list output?

15:57chouser: It is an interesting question. Since we have come to say that lists are mainly for code and sequential data is more often held in vectors, why shouldn't conj on nil be changed to create vectors?

15:57rata_: I want a set... and I was doing (update-in m [k1] dissoc k2), but the right thing was (update-in m [k1 k2] #{})

15:57bartj: There are about five lines referencing clojure.core* and clojure.lang* which repeat ad-infinitum

16:16chouser: that part is ok. it's only a problem if million-items is actually a lazy seq on a lazy seq on a lazy seq...

16:17bartj: chouser, hmm, ok; would you say Clojure is ill-suited for this task of

16:17 removing a small number of items from a very large set; until the large set is empty

16:18chouser: no, I wouldn't say that. I would say that as you push limits of the JVM (stack size, heap size, etc.) it's important to understand the implications of what you're actually doing when designing your solution.

16:20 I couldn't recommend a different solution without understanding better what you're trying to do

16:20amalloy: chouser: right. so far the best solution for bartj's task is (let [million-items []]) - just empty the large list :)

17:02devn: i heard a really funny quote by raganwald (a prominent figure in the ruby community (and proponent of functional programming techniques))

17:02 "They call them s-expressions, but if you're used to Lisp s-expressions, a Lisp s-expressions is like Ikea or Scandinavian furniture design, and Ruby's s-expressions are like what you find in the dumpster after Goodwill has picked through it and decided they don't even wanna sell that stuff."

17:26devn: but amalloy is right -- hate for other languages and companies and all of that. it's easy to descend from informed discussion into a lynch mob of smart people (who are notoriously good at being critical), bashing everything to hell

17:32LauJensen: Just a quick heads up. ClojureQL is now in its final form for the 1.0 release, so what you see now on Github/Clojars is what will be release around 1/1/11 as 1.0 final. http://github.com/LauJensen/clojureql

18:46ossareh: where would I find a good instructive piece on the scoping of functions attached to defrecords? I'm pretty hit and miss with function resolution with my records; (defprotocol A (m1 [this])) (defrecord B [] A (m1[this] (prn "B-m1"))). If these are in namespace "myns" I can access the m1 function on an instance of B - but in other namespaces where these are imported they're not always available (notable difference is in test cases.

18:54raek: ossareh: the protocol methods are vars just like those introduced by defn. you require/use the methods of the protocol, rather than the record

18:55 the namespace of the defrecord must of course be loaded too, to make that record type's implementation of the protocol available

18:57 the record type must also be :imported (like a java class) if you want to access the constructor without the package prefix from another namespace

19:00 ossareh: but if you have those defninition you showed in the same namespace, I don't see why using/requiring the protocol methods should not work.

19:05ossareh: thanks raek , with those examples I may have simplified it such that it does actually work. From what you've written I seem to get it

19:06 i.e. I'm using and importing according to what you have written - I think I might be missing something super simple - I'm now spellchecking my imports / etc :)

19:10 this was all working until I restructured the project, so I've brought in an issue at that point I guess.

19:12raek: it can be a good idea to clear all namespaces (simplest way is perhaps to just restart the repl) every now and then to check that you haven't forgot a use or require somewhere

19:13 I tend to have to fix a lot of require/use problems when I restart my bot

19:14ossareh: raek: ye - I just fixed it, thanks for your help. I was being told it couldn't find an imported class, though I was unsure why, it seems there is some subtle relationship between using a namespace and the records in that namespace.

19:15sexpbot: <ossareh> raek: ye - I just fixed it, thanks for your help. I was being told it couldn't find an imported class, though I was unsure why, it seems there is some subtle relationship between using a namespace and importing the records in that namespace.

21:58Raynes: brehaut: If you see anything you'd like to steal in my implementation, steal away. I feel much better about your implementation than my own simply because I have very little interest in XML-RPC, and I probably never would have implemented a server-side unless I needed it badly.