#clojure log - Jun 01 2010

The Joy of Clojure
Main Clojure site
Google Group
IRC
List of all logged dates

0:23 mebaran151: I'm having some slime trouble

0:23 whenever I try to C-c C-k it fails to compile-file-for-emacs

0:31 Raynes: mebaran151: It fails to find the command?

0:32 mebaran151: wrong number of args passed

0:32 slime starts up, and I can run basic commands, but I can move any clojure from the edit buffer to the repl

0:32 Raynes: Wrong number of args passed to compile-file-for-emacs?

0:32 mebaran151: yep

0:33 wrong number of args passed to basic$eval--986$compile-file-for-emacs

0:33 thrown by a working slime

0:33 Raynes: C-c C-k is bound to slime-compile-and-load-file

0:33 Not compile-file-for-emacs.

0:34 Try doing M-x slime-compile-and-load-file and see what happens.

0:34 mebaran151: same problem

0:35 actually C-c C-c works

0:36 Raynes: Hrm.

0:36 mebaran151: it got a def

0:36 could it be a mismatch between my slime and clojure versions

0:36 I downloaded clojure-1.2 and I think I'm running swank-clojure-1.2

0:37 Raynes: mebaran151: Are you using leiningen for this project?

0:37 The latest version of swank-clojure is 1.2.1.

0:37 mebaran151: right now I'm not using leiningen

0:38 Raynes: Shouldn't be any problems with whatever version of Clojure you're using.

0:38 mebaran151: I just swank-clojure-project to slurp up the jars in my lib dir

0:38 Raynes: mebaran151: I'd suggest asking on the swank-clojure mailing list, perhaps linking to this discussion.

3:07 bozhidar: hey, guys - how can one access the a resource in the resources folder of a lein application?

3:08 in Java I'd do a getResourceAsStream("/the/package/the_resource")

3:08 should I use the same code or is there something more idiomatic?

3:14 tomoj: as far as I know there is nothing more idiomatic

3:14 I think something like (.getResourceAsStream (clojure.lang.RT/baseLoader) ...)

3:15 bozhidar: I see

3:17 lessthantristan: yeah, I've always just used the line tomoj suggested. i've never asked about a more idiomatic form tho :)

3:21 bozhidar: lessthantristan: I have nothing against the Java interop, after all I'm a Java dev

3:22 that said I enjoy idiomatic clojure a lot more, when available ;-)

3:33 tomoj: I guess ideally this bit of java interop will be wrapped over with pretty clojure

3:33 I mean, e.g. enlive wraps over it so that a user of enlive never has to write it

4:06 LauJensen: Morning guys

4:06 bozhidar: Morning :-)

4:08 spariev: morning Lau

4:24 bartj: morning Lau

4:36 er, is it possible to call c++ from clojure (planning to call webkit functions)

4:38 LauJensen: bartj: There's a project which was/is called clojure-native (see the group), which allows you to do that

4:43 bartj: I am only able to see chouser's clojure-jna

4:43 Licenser_: mornin g

4:43 LauJensen: http://groups.google.com/group/clojure/browse_thread/thread/f0cc00d87912878b/467dc469f45498bd?lnk=gst&q=clojure+native#467dc469f45498bd

4:43 @ bartj

4:45 esj: Morning All

4:45 LauJensen: Morning esj

4:48 chuckler: anyone here using emacs23 and clojure-mode?

4:49 tomoj: plenty

4:51 LauJensen: chuckler: all the cool kids

4:51 and tomoj ...

4:51 :)

4:51 tomoj: :(

4:59 bozhidar: m2

4:59 :-)

5:40 bartj: a bit off topic - a question on sampling

5:41 A= (1 2 3 4 5), B = (1 2 3)

5:42 clearly B is a subset of A, but if I choose the wrong sampling set ie. (4, 5) then I will conclude wrongly

5:42 how do I prevent this?

5:43 ie. what is the best way to sample so that, I can check for common elements?

5:47 LauJensen: bartj: Do you just want to know if they intersect ?

5:47 tomoj: you want to guess whether B is a subset of A based on a limited number of inclusion checks?

5:48 LauJensen: $(clojure.set/intersection #{1 2 3 4 5} #{1 2 3})

5:48 sexpbot: java.lang.ClassNotFoundException: clojure.set$intersection$fn__5560

5:48 LauJensen: $(intersection #{1 2 3 4 5} #{1 2 3})

5:48 sexpbot: java.lang.Exception: Unable to resolve symbol: intersection in this context

5:48 tomoj: "B subset A" means "if it's in B, it's in A", so seems like picking random elements from B and checking whether they're in A would be the best way

5:48 LauJensen: ok, experiment in your own rpel :)

5:48 and swap letters where appropriate

5:49 bartj: LauJensen: actually, what elements should I pick from a given set to know that they intersect

5:50 ie. if two sets A and B intersect, and all my samples are from (A-B) then, I would conclude that they don't intersect

5:51 is there any way I can avoid this...

5:51 tomoj: suppose A and B each have 1000000 elements, and their intersection has just one element

5:51 you're gonna have to get pretty damn lucky no matter how you sample

5:52 bartj: tomoj: yeah you are right!

5:54 tomoj: we could perhaps set a limit of 10%?

5:54 tomoj: it shouldn't be too hard to find the probability, hmm

5:55 bartj: trouble is, if all the 10,000 elements you picked are from (A-B)?

5:55 tomoj: right, but we can calculate the probability of that

5:55 and so get some idea of how likely it is that they intersect given the evidence

5:55 do you know the sizes of the sets?

5:56 bartj: 5L and 1L

5:56 have another one which is 1M and 2L

5:57 G0SUB: LauJensen:

5:57 tomoj: what's "L" stand for?

5:57 bartj: lakh

5:57 G0SUB: what?

5:57 clojurebot: what is wrong with you

5:57 konr: Just out of curiosity: do you guys still use common lisp? If so, for what?

5:57 bartj: 5L = 5,00,000

5:57 tomoj: ah, 100000?

5:57 G0SUB: bartj: are you from India?

5:58 bartj: GOSUB: yep!

5:58 I guess we use that here a lot...sorry!

5:58 tomoj: in america we are doomed to say 500K I guess

5:58 G0SUB: bartj: I am from India too.

5:58 tomoj: two extra characters :(

5:59 I think you want to be sampling from the smaller set

6:01 bartj: tomoj: I still wouldn't want to pick all the 200,000 entries to compare against the 1M...

6:02 tomoj: that is, I do not want the sample size to be 200,000

6:02 tomoj: right

6:03 but you will have a better chance of discovering the intersection if you sample from the smaller set

6:04 G0SUB: LauJensen: did you read my blog post on protocols?

6:07 tomoj: bartj: hmm.. the probability that you will discover the intersection with N checks depends on the size of the intersection

6:07 LauJensen: G0SUB: I did actually :)

6:07 tomoj: so it's more difficult than I thought

6:07 LauJensen: And I find your style of writing very compelling, must loot

6:07 G0SUB: LauJensen: oh, thanks, Lau. it's very valuable.

6:08 tomoj: I guess we can assume you've made N checks and haven't found any common elements

6:09 bartj: tomoj: yes you are right

6:10 tomoj: one obvious way would be to increase the size of N

6:10 tomoj: but, I want to know the upper limit of N

6:16 tomoj: well, hmm

6:23 bozhidar: G0SUB: can you post a link to this blog article?

6:23 tomoj: I don't think you can get any good handle on the probability that there is any intersection at all

6:23 G0SUB: bozhidar: http://freegeek.in/blog/2010/05/clojure-protocols-datatypes-a-sneak-peek/

6:23 tomoj: I think you may be able to get a good idea about the probability that there is an intersection of some size X

6:23 bozhidar: G0SUB: 10x

6:25 tomoj: if you sample 50% of the smaller set, I think you can be only 50% sure that there is no intersection at all

6:25 but if you look for intersections of size X instead of any intersection you can do much better

6:28 bartj: tomoj: I am not sure I understand

6:29 tomoj: there is always the possibility that the sets share only one element

6:29 and in that case, the problem is just to find that element

6:29 bartj: tomoj: yes

6:30 tomoj: which means if you sample 50% of the smaller set, you can only be 50% sure there is no such element

6:31 Licenser_: hmm is there any template engine in clojure that is somewhat like erb?

6:31 tomoj: :(

6:32 bartj: tomoj: yes

6:43 G0SUB: bozhidar: did you read it?

6:44 bozhidar: G0SUB: just started

6:44 G0SUB: bozhidar: oh, OK. feedback appreciated :)

6:52 bozhidar: G0SUB: great article, you've introduced a new concept in a clear and very understandable way

6:52 the swine flu part was very funny :-)

6:53 and I was surprised to find out that there is now a workaround allowing one to extend final Java classes(like String) in Clojure

6:54 G0SUB: bozhidar: thanks a lot.

6:54 LauJensen: hehe. Im glad we spent 56 billion USD on Swine Flu vaccines that nobody wanted, imagine if the whole world went around sneezing for 3 days :)

6:54 bartj: tomoj: thanks

6:54 tomoj: ...for your help

6:54 G0SUB: bozhidar: yeah, that basically solves the expression problem

6:55 patrkris: rhickey: just out of curiosity, which came first: persistent data structures or STM?

6:55 bozhidar: G0SUB: protocols support only single dispatching, right?

6:56 G0SUB: bozhidar: right. for arbit dispatch, you need multimethods

6:56 patrkris: rhickey: in Clojure, that is

6:56 G0SUB: bozhidar: in case you need only type/class based dispatch, use protocols :)

6:56 rhickey: patrkris: persistent data structures. Without them, I don't think STM works

6:57 bozhidar: G0SUB: I imagine so, it's just that in the beginning multimethods are always marketed as vastly superior to single dispatch based on the type

6:57 rhickey: patrkris: but thinking about how STM might work added to the desire for pds as the default

6:58 bozhidar: and later we see such a feature introduced :-)

6:58 G0SUB: bozhidar: superior, but slow :)

6:58 patrkris: rhickey: ah... but when you initially started developing Clojure, did you know that you wanted to have STM in it?

6:59 rhickey: I am just wondering whether it is correct to say that Clojure was designed from the beginning to include STM.

6:59 rhickey: patrkris: I knew I wanted another model for state

7:00 patrkris: It's not necessary like there was a clear point of "I'm going to write a language and this is what will be in it". More like a lot of ideas swirling around, among which was adding direct perception to the Actor model, which also pointed to pds and some sort of reference types

7:01 what I knew was, I wanted 'doing the right thing' with state to be automatic and enforced, without adopting a static type system

7:02 eventually there was enough alignment between all the ideas to make Clojure inevitable

7:02 patrkris: rhickey: Interesting. Another thing out of curiosity: When did you write the first line of code for what was to become Clojure? :)

7:05 rhickey: patrkris: sometime in 2005

7:06 sourceforge project started in May 2005, so at that point I knew I was doing a language, and its name

7:06 SinDoc: I evaluate [1] and get: java.lang.ClassCastException: java.lang.Boolean cannot be cast to clojure.lang.Symbol (pair.clj:1) Any ideas?

7:06 [1] http://github.com/sindoc/algorithms/blob/master/src/clojure/main/com/khakbaz/algorithms/clojure/memory/fixed/manual/pair.clj

7:06 G0SUB: rhickey: would you mind if we create your action figure? It would be a very cool addition to our office desks.

7:07 Licenser_: SinDoc: it is in a require

7:07 patrkris: rhickey: Thanks for taking your time to answer my questions. :)

7:09 SinDoc: Licenser_: I'm not sure what's wrong with that!

7:15 G0SUB: SinDoc: (:require [com.khakbaz.algorithms.clojure.memory.fixed.pair :as p])

7:17 Licenser_: SinDoc: one of the files you require is wrong

7:17 G0SUB: SinDoc: you missed the manual part

7:18 SinDoc: I was wrong. sorry.

7:18 SinDoc: G0SUB: Licenser_: There are actually two pair.clj files

7:18 G0SUB: SinDoc: saw. sorry

7:18 SinDoc: Thanks G0SUB what you said, worked

7:19 G0SUB: SinDoc: yeah, the syntax was wrong. your ns name was correct :)

7:20 rhickey: urk - why are there clojure jars in clojars?

7:20 when there is build.clojure.org

7:21 Licenser_: rhickey: I think clojars subdirectories clojars

7:21 rhickey: and is there a way to force maven to get clojure and contrib jars only from build.clojure.org?

7:21 Licenser_: but I'm not sure if that is what you mean

7:25 SinDoc: Thank you folks! See you soon ;)

7:32 G0SUB: rhickey: a lot of people are asking how protocols are different from haskell's type classes and Go's interfaces. what is the right answer to this question?

7:32 rhickey: G0SUB: sounds like 2 questions to me

7:33 G0SUB: rhickey: I grouped them together for brevity.

7:33 rhickey: you can give me two answers :)

7:36 rhickey: they differ from Haskell's type classes (from which they draw partial inspiration) in that the dispatch map isn't an independent entity passed around by the type system, and thus can't do return-type based method selection, and generally in that they are not static-type-system-based.

7:37 G0SUB: rhickey: thanks!

7:38 rhickey: they differ from Go interfaces in that Go just uses method conformance to determine interface support (vs explicit declaration of 'I implement this protocol'), and Go's interfaces, last time I checked, were only 'open' within a module.

7:38 G0SUB: ah

7:39 rhickey: If one said Clojure's protocols were like dynamic type classes you wouldn't offend me (but might offend some Haskellers)

7:39 G0SUB: heh

7:39 rhickey: but they are not very much like Go interfaces at all

7:41 G0SUB: whenever Blub programmers look at protocols, they say it's identical to the Transmogrify feature in Blub.

7:42 rhickey: G0SUB: the differences can be subtle, but are important

7:43 G0SUB: rhickey: indeed.

7:43 It's like saying Agents are identical to Actors

7:43 cemerick: rhickey: maven will grab dependencies from whereever it can get them, I believe. Stricter controls require the use of a proxy (e.g. nexus).

7:43 clojars is a bit of a swamp w.r.t. following maven conventions

7:44 rhickey: cemerick: then I'm concerned about people putting their own Clojure jars in clojars

7:44 cemerick: rhickey: yeah, it simply shouldn't happen

7:44 same goes for sha version numbers, misuse of classifiers, etc etc

7:46 I'm guessing most people don't know that they're using a maven repo, and so without indications to do otherwise, they do what seems to make sense at the time, etc.

7:46 AWizzArd: cemerick: what do you mean by thas "sha version numbers" thing? Is it that some people try to depend on a specific version via hash, and that is not good?

7:46 rhickey: but something must have driven people to use clojars for Clojure vs build.clojure.org

7:47 cemerick: AWizzArd: I mean artifacts published with a sha1 version number instead of something like 1.5.9 or whatever.

7:47 AWizzArd: Oh okay, yes.

7:47 cemerick: rhickey: I presume just not knowing what should be done. Probably best to ping whoever pushed the libs to see what's up.

7:48 bleh, no authorship notation in the accompanying poms

7:49 rhickey: I'd say ato should just rm org/clojure/*, and make that dir read-only.

7:50 *anyone* can push stuff up into clojars, which is good and bad

7:50 eh, ok, so it's probably just all bad :-)

7:52 bozhidar: cemerick: giving anyone access to something always ends bad :-)

7:53 cemerick: rhickey: if there's to be any infrastructure managed by clojure/core, dropping a nexus instance on it as well would be a wise thing, I think. That'd presumably require some coordination with technomancy|away, insofar as lein pushes at clojars by default (or, exclusively?).

7:54 bozhidar: it's fine as long as you can see who did what when :-)

7:54 rhickey: cemerick: is nexus free for open source?

7:54 cemerick: rhickey: and for closed source as well :-)

7:54 nexus pro costs, but the free version is extraordinarily full-featured.

7:55 proxying, access control, host as many repos as you want, repo aggregation, etc.

7:57 Looks like LDAP and P2 itnegration are the big additions in Pro http://nexus.sonatype.org/

7:57 integration*

7:59 rhickey: have you been following the java closure goings-on much?

8:00 rhickey: cemerick: not too much, I like #() though :)

8:00 cemerick: heh, yeah

8:01 I saw this as a "function type", and almost fell over though: #int(int, int)(throws IOException | SQLException) plusClosure = #(int

8:01 a, int b) (a+b);

8:02 rhickey: checked exceptions showing their inherent evil again, will be the downfall of Java closures

8:02 cemerick: I can't imagine anyone's going to use that stuff.

8:02 it seems like Oracle would be doing everyone a favor if they just got the non-Java language principals in the room, and did what they wanted (forgetting Java)

8:04 rhickey: getting rid of checked exceptions and adding a smattering of inference would go a long way, neither in the cards afaik

8:04 G0SUB: lol

8:06 rhickey: I'd be happiest if Java would just stay as-is, BUT, there is one very important side-effect of getting closures in to Java, which is: then (and only then?) they may start looking at the optimizations needed for higher-order functions like map et al

8:07 cemerick: gah, we'll probably have to type-hint our fns! :-x

8:07 Seems like there's a *lot* of interop pain coming down the pike.

8:07 rhickey: cemerick: nope - Object, Object, Object...

8:08 bobo_: cemerick: that example is just the absolute worst scenario though, for everyday use it wont be THAT ugly, still ugly though

8:08 rhickey: cemerick: yes, interop the problem for alternate langs. Wanna bet the reflection story for these will stink?

8:08 cemerick: rhickey: but if Java libs start requiring function params of type #int(int, int)?

8:08 oh, right, erasure

8:09 though I saw someone on the mlvm list talking about "fixing" erasure not too long ago

8:09 rhickey: cemerick: depends

8:09 cemerick: erasure is the best thing ever

8:10 cemerick: yeah; I caught a glimpse of what D. Miller is having to deal with with ClojureCLR, and felt bad for him.

8:11 rhickey: cemerick: yes, people don't realize the huge tradeoff involved in the CLR approach. It greatly complicates life for everyone, and is a poor fit for dynamic langs

8:12 G0SUB: by erasure, do we mean type erasure here?

8:12 cemerick: yeah

8:12 rhickey: I presume the DLR doesn't just make it all go away magically?

8:12 * cemerick is all about the wishful thinking

8:12 rhickey: cemerick: nope

8:14 bozhidar: rhickey: can we expect some dramatic performance improvements on JDK 7 because of http://java.sun.com/developer/technicalArticles/DynTypeLang/

8:15 I read somewhere that to reap the benefits one has to rewrite a lot of him current implementation however

8:16 his*

8:17 rhickey: bozhidar: no, most of what you can do with invokedynamic you can do without it, it's just a bit cumbersome. But we've all done it already

8:18 and few langs will want to be Java-7 only

8:19 bozhidar: rhickey: I've read some article from Charles Nutter from JRuby in which he claimed this invoke dynamic will be the holy grail of dynamic languages targeting the JVM

8:19 rhickey: It would have been better if they had just made classes themselves cheaper and faster

8:20 bozhidar: he mentioned that JRuby's performance will increase 10 fold, so I was wondering is Clojure affected in a similar manner

8:20 probably an implementation detail?

8:20 rhickey: bozhidar: is he still saying that today?

8:20 bozhidar: rhickey: let me look up some articles

8:21 bobo_: i think that mainly is because of heavy Reflectionusage they can remove

8:21 rhickey: method handles are just going to be an entirely new thing hotspot et al are going to have to be taught to optimize. They are already awesome at optimizing ordinary class method dispatch

8:22 bobo_: invokedynamic is not needed for removing reflaction

8:22 reflection

8:22 bobo_: no, but i think that is what nutter was saying.

8:22 that jruby has loads of reflection, and they might remove that with invokedynamic

8:22 rhickey: it is just a different way of doing call site caches, which you can already do today with classes and methods

8:23 bobo_: was long ago i read the article though.

8:23 bozhidar: rhickey: the only article I find is a bit old - http://blog.headius.com/2008/09/first-taste-of-invokedynamic.html

8:23 rhickey: but, you end up with a lot of classes, so, IMO, make that cheaper

8:23 bozhidar: maybe he has reconsidered indeed :-)

9:12 SinDoc: I evaluate a .clj file and would like to interact with it using REPL. How can I have REPL automatically switch to a namespace other than the user ns?

9:13 I use IntelliJ and LaClojure

9:35 bartj: is there a better way to filter nils then do - (filter (complement nil?) [nil 1 2 nil nil])

9:35 ,(filter (complement nil?) [nil 1 2 nil nil])

9:35 clojurebot: (1 2)

9:36 pjstadig: ,(remove nil? [nil 1 2 nil nil])

9:36 clojurebot: (1 2)

9:40 bartj: pjstadig: thanks

9:40 cgrand: SinDoc: (in-ns 'foo)

9:40 pjstadig: np

9:42 G0SUB: bartj: if you see yourself using double negative verbs, know that there must be a positive verb too :)

9:42 SinDoc: cgrand: I've been trying that BUT without the quote

9:43 bartj: G0SUB: thanks!

9:43 G0SUB: bartj: np :)

9:46 SinDoc: cgrand: I put (in-ns 'myns) in code but after evaluation, it's still in the user namespace

9:47 cgrand: SinDoc: enter it at the repl

9:47 SinDoc: That's kinda the reason why I asked

9:48 I was hoping to make that implicit somewhere

9:48 cgrand: how do you eval your file?

9:49 SinDoc: I create a Run configuration for it in IntelliJ and simpley 'Run' it.

9:49 Then it evaluates my definitions but goes back to the user ns

9:54 cgrand: ok, too LaClojure specific for me then, sorry

9:54 SinDoc: Thanks cgrand

9:57 bozhidar: is there some existing way to take items in frame fashion from a sequence

9:57 for example I have 1 2 3 4 5

9:57 first I take 1 2 3

9:57 then 2 3 4

9:57 3 4 5

9:58 the frame being x items wide and advancing by one each time

9:59 vu3rdd: ,(partition 3 1 [1 2 3 4 5 6])

9:59 clojurebot: ((1 2 3) (2 3 4) (3 4 5) (4 5 6))

9:59 Joreji: Hey guys, I'd like to set a clojure variable from java code, is it possible to do it like this: String path = "/data/clojure/classes"; Var.pushThreadBindings(RT.map(Compiler.COMPILE_PATH, path));

10:00 vu3rdd: bozhidar: is that what you want?

10:00 bozhidar: vu3rdd: perfect, totally forgot about partition

10:01 vu3rdd: thanks

10:01 vu3rdd: bozhidar: no problem.

10:01 G0SUB: vu3rdd

10:01 vu3rdd: G0SUB: hi

10:02 G0SUB: bozhidar: also, don't forget partition-all :)

10:02 vu3rdd: how are you?

10:02 vu3rdd: G0SUB: fine. Was sick for the past 3-4 days. Back to work today

10:02 G0SUB: vu3rdd: Can I PM you?

10:02 vu3rdd: G0SUB: sure

10:03 bozhidar: G0SUB: never new about partition-all, what is its deal?

10:04 spariev: ,(partition 3 [1 2 3 4])

10:04 clojurebot: ((1 2 3))

10:04 spariev: ,(partition-all 3 [1 2 3 4])

10:04 clojurebot: ((1 2 3) (4))

10:04 hoeck: Joreji: not shure, but I believe pushThreadBindings is the same as of binding in clojure, so it shares its limitations

10:04 G0SUB: spariev: bravo!

10:04 bartj: , (partition 3 2 [1 2 3 4 5 6 7])

10:04 clojurebot: ((1 2 3) (3 4 5) (5 6 7))

10:05 bartj: step=2 and still the same results?

10:05 G0SUB: ,(partition 3 2 [1 2 3 4 5 6 7 8])

10:05 clojurebot: ((1 2 3) (3 4 5) (5 6 7))

10:05 spariev: G0SUB: this difference struck me badly last week )

10:05 hoeck: Joreji: Var.alterRoot(...) alters the root binding, which is a bit more like "setting" the var

10:06 Joreji: though I've never interfaced clojure from java, only the other way around :P

10:07 G0SUB: ,(partition 3 2 [1 2 3 4 5 6])

10:07 clojurebot: ((1 2 3) (3 4 5))

10:07 G0SUB: bozhidar: ^^^

10:07 Joreji: hoeck: Thanks, I'll try that out!

10:08 G0SUB: ,(partition-all 3 2 [1 2 3 4 5 6])

10:08 clojurebot: ((1 2 3) (3 4 5) (5 6))

10:08 G0SUB: bozhidar: ^^^

10:08 bozhidar: I see

10:09 G0SUB: 10x

10:10 G0SUB: bozhidar: np

10:11 bartj: ,(doc partition)

10:11 clojurebot: "([n coll] [n step coll] [n step pad coll]); Returns a lazy sequence of lists of n items each, at offsets step apart. If step is not supplied, defaults to n, i.e. the partitions do not overlap. If a pad collection is supplied, use its elements as necessary to complete last partition upto n items. In case there are not enough padding elements, return a partition with less than n items."

10:12 bartj: what does "offsets step apart" mean?

10:14 cgrand: rhickey: any chance that #353 and #362 are related?

10:29 hugod: cgrand: thanks for finding the cause of #368. I have also been having issues with redefining multimethod dispatch functions which I assume is related. Makes interactive development very frustrating :(

10:31 cemerick: hugod: that's a known issue at the moment, noted in #309

10:31 hugod: cemerick: thanks, hadn't spotted that one

10:33 cemerick: seems like #368 should be moved into 1.2, no?

10:34 cgrand: who decieds what's in &

10:34 1.2

10:35 pedroteixeira: one would create a new Exception type using deftype or using someting else? is there any macro for this already?

10:36 cemerick: cgrand: Stu's the only one outside of Rich that I know of who's got carte blache to promote issue.

10:36 issues*

10:37 anyone *can* do it, of course, but that's not so polite :-)

10:37 pedroteixeira: why are you wanting to create a new Exception type?

10:38 pedroteixeira: cemerick: sometimes it's useful, isn't? instead of returning error codes for ex. Just tested and this worked fine: (deftype DomainException [Exception]) (DomainException. "oops")

10:39 cgrand: cemerick: ok, we have the same policy

10:40 cemerick: pedroteixeira: It's pretty rare for new exception types to be useful IMO. It's not really idiomatic within Clojure, certainly.

10:40 pedroteixeira: cemerick: i'm builind a large application, some part of the code might throw exceptions that have known semantic and can be handled specificly in a different part of the code.

10:41 cemeric: ok, thanks. will think about it.

10:42 Raynes: http://groups.google.com/group/clojure/browse_thread/thread/ad7f33cc59ce13cb?pli=1 This guy is officially awesome.

10:42 cemerick: pedroteixeira: if there's actually a recovery path available, then I'd consider it. Most applications don't have a reasonable recovery path though.

10:43 Otherwise, IllegalArgument, IllegalState, IOException, etc. are good for 95% of the "oh, shite" error conditions that are likely to arise.

10:43 nDuff: What's the appropriate concurrency device to use for hashing a large tree of files? Agents, promises and futures all look potentially interesting.

10:43 pedroteixeira: cemerick: my current case is to handle possible ConflictException that has an entity with version. Different use cases, might retry and some might just return an error to the user.

10:44 cemerick: alright, i'm aware of those also ;)

10:46 hugod: pedroteixeira: you might also want to look at clojure.contrib.condition

10:47 pedroteixeira: hudod: thanks! looks useful

10:54 islon: how can I access an inner java class in clojure? I want to use javax.mail.Message.RecipientType

10:54 spariev: javax.mail.Message$RecipientType , IIRC

10:55 pedroteixeira: hudod: i think clojure.contrib.condition suits my needs fine.. one generic exception to rule them all :)

10:55 islon: thanks =)

11:17 jfields: can you memoize method calls on an instance of a java object?

11:19 cgrand: jfields: you have to wrap the method call in a fn: (memoize #(.substring s %))

11:19 pedroteixeira: jfields: memoize operates on pure functions, you can probably more easily just wrap this java call to a particular object..

11:20 jfields: cgrand, pedroteixeira: cool, thanks.

11:22 cgrand: hugod: http://github.com/richhickey/clojure/commit/f47b3d6f028e0370c495383731a449092d0ae451 fixes #368 too

11:22 pedroteixeira: jfields: sometimes, you don't want memoization for the entire lifecycle of your app (i.e. for memory constraints), then you can just bind the memoized function (the return of memoize) to a local scope.

11:38 hugod: cgrand: excellent :)

11:43 pedroteixeira: are there any recommended way to serialize clojure records? (with-in-str (binding [*print-dup* true] (pr-str (Foo. "bar"))) (read)) gives an exception.

11:43 _fogus_: dnolen: ping

11:43 dnolen: _fogus_: pong

11:43 _fogus_: dnolen: Do you mind if I use clj-cont in a presentation?

11:44 dnolen: _fogus_: not at all, I saw that you forked it.

11:44 _fogus_: what is the presentation going to be about?

11:45 _fogus_: dnolen: Thanks! Delimited continuations (probably)

11:48 hiredman: ping?

11:48 clojurebot: PONG!

11:48 _fogus_: dnolen: I was going to use Scala for the preso, but thought better of it

11:49 dnolen: _fogus_: interesting, do you find the ideas easier to express in Clojure?

11:51 _fogus_: dnolen: I hadn't thought about it that way, but I would probably say yes.

11:57 LauJensen: _fogus_: glad you sobered up

11:59 Raynes: LauJensen: He puffed the magic dragon too many times last night.

12:00 * _fogus_ only thinks about Scala when drinking

12:01 LauJensen: _fogus_: You shouldn't focus on Scala daily, spend a little more time with Clojure before you finish the book please :)

12:13 _fogus_: LauJensen: What?! You don't like the latest chapter "Typed Clojure" ? :p

12:13 LauJensen: haha

12:21 dnolen: _fogus_: so where do you feel that Scala's type system comes in handy when writing real programs? I've been wondering whether good type systems still make certain kinds of real world programming more tedious.

12:24 _fogus_: dnolen: Scala's type system has benefited me in a couple of ways. 1) We have a fairly static system that we spent many moons agonizing over the design and Scala's types served as (sort-of) documentation. and 2) Because our types are rock solid, I've found that if it compiles then it's correct.

12:25 However, I wouldn't want to do that same exercise (agonizing design) on every project

12:31 cemerick: _fogus_: I didn't agonize enough on my first scala project -- so when things had to change in some tiny way, I was faced with a boil-the-ocean refactoring. Not fun at all.

12:32 _fogus_: cemerick: That was definitely a problem at first, but I (erm.. we) buckled down and solidified the API.

12:32 cemerick: Right. More work always makes problems go away. ;-)

12:33 _fogus_: cemerick: I like to think I didn't work harder but.... uhhhh... well not smarter either. :p

12:33 cemerick: I generally assume I'm going to bork my first four shots at something, and it's oh-so-nice to just add a slot to a map that gets passed around everywhere instead of having to shatter my carefully-crafted domaint types.

12:34 _fogus_: cemerick: The borked part was the previous system.

12:41 naeu: hi there

12:42 I'm currently playing around with type hints trying to remove use of reflection for the core pathways of my system

12:42 however, I'm not having much luck in a particular case: (.write out-stream bytes)

12:43 I tried: (.write #^java.io.OutputStream out-stream bytes)

12:43 but the reflection warning still flags that line

12:43 (call to write can't be resolved.)

12:45 cemerick: naeu: there are both int and byte[] overloads for .write

12:45 naeu: cemerick: oh ok, so how would I find that out?

12:45 do i need to inspect the javadoc, or is there a way i can ask clojure for this information?

12:45 cemerick: hrm; be familiar with the signatures of the methods you're calling, or have javadoc ready :-)

12:46 naeu: also, how would i type-hint byte[]

12:46 cemerick: it would be nice if the reflection warnings could point at whether the invocation target's type is unknown, or if it's trying to choose from a number of known overloads

12:46 naeu: #^bytes should do it if you're using a pre-1.2 build

12:47 otherwise, it's ^bytes

12:47 naeu: cemerick: haha, I keep reading overlords instead of overloads

12:47 I like the idea of choosing from a number of known overlords

13:16 * arkahn prefers more supply depots ....

13:18 KirinDave: cemerick: pingggggg

13:19 DeusExPikachu: if I want to generate a fn that's code depends on runtime information, must I use eval?

13:19 KirinDave: If you want to let outside input build code, that is what eval does.

13:20 But it's very rare that it's necessary.

13:23 DeusExPikachu: so to be more precise, I want a `(fn [] ~@(for [f# my-runtime-vector-of-fns] (f#)), I'm thinking I can't use defmacro for this cause at compile time my-runtime-vector-of-fns is not defined

13:27 hmm, I think that code is wrong too, cause f# needs to be symbols not fns...

13:28 ericthorsen: cemerick: you still having frequent NB crashing?

13:28 wroiong window

13:46 bsteuber: is it documented somewhere that it's not a clever idea to call a record field "size"?

13:47 say (defrecord Foo [size]) (:size (Foo. 42)) -> 1

13:56 cemerick: bsteuber: that's a bug from a few weeks ago that was fixed. Try a newer snapshot?

13:57 LauJensen: cemerick: is it just me, or does it seem that there is an increase in bugs recently ?

13:58 bsteuber: cemerick: ah, I froze my clojure version for swank

13:59 cemerick: LauJensen: Not sure you could characterize it as that. Part of it is stuff new in 1.2 being shaken out, which is going to produce some regressions.

13:59 LauJensen: Sounds like you expected that?

14:00 cemerick: it's inevitable as things draw up to a release, no?

14:00 I'd be more concerned if issues weren't being raised -- that'd indicate a lack of thorough testing.

14:00 LauJensen: Relative to your workflow I presume

14:00 kotarak: LauJensen: I got the impression that 1.2 broke way more often than the versions before. The only things similar annoying was the initial use/require move.

14:00 LauJensen: That matches my experience kotarak

14:01 kotarak: cemerick: and (sometimes trivial) things won't get fixed... At least not contemporary...

14:01 LauJensen: contemporary ?

14:01 cemerick: I think he means lately.

14:02 LauJensen: Aha

14:03 kotarak: Ok. Dictionary issue. contemporary <=> zeitnah, meaning close in time. Things are reported now and fixed two months later <=> not contemporary. :/

14:03 cemerick: ah, timeliness

14:04 LauJensen: Ok - Also sometimes the magnitude of the bugs surprises me, like the effect of removing numbering in fns for instance

14:04 cemerick: The best I can suggest is to make noise about it, here and on the dev list.

14:05 LauJensen: Yes that would be the next move - Just wanted to be sure I wasn't the only one feeling it

14:05 stuarthalloway: late to the conversation ... feeling what?

14:05 kotarak: Well. This is nothing new. I hope things approve with the new leutnants.

14:06 stuarthalloway: what did removing numbering cause?

14:06 LauJensen: stuarthalloway: feeling an increase in bugs, both frequency and magnitude

14:06 kotarak: stuarthalloway: that it takes sometimes quite long to fix things. (even with patch available)

14:06 LauJensen: stuarthalloway: Caused toplevel macros to be un-redefinable, see hugods bugreport

14:06 stuarthalloway: ok, will discuss with Righ

14:07 (Rich)

14:07 LauJensen: Ok

14:08 cemerick: Even if that were true, I'm not sure what the "solution" would be.

14:08 "Don't cause bugs"? ;-)

14:08 LauJensen: cemerick: right, I was just poking to verify and maybe guess the cause, change in workflow, whatever

14:09 cemerick: well, many fundamental things have changed over the last months, so I'd expect that.

14:10 kotarak's issue with the cadence of patches being applied is a separate issue though; the same thing applies in contrib as well, which Chousuke raised as an issue on the dev list a while back.

14:11 kotarak: cemerick: I kind of complained also. is stuarthalloway now kind of leutnant to Rich? That would help things, I think. (I know, that Rich has a lot to do. A leutnant team would allow him to focus...)

14:15 cemerick: kotarak: I presume that's what clojure/core is meant to accomlish.

14:15 kotarak: cemerick: yeah *thumbsup*

14:15 cgrand: stuarthalloway & LauJensen, http://github.com/richhickey/clojure/commit/f47b3d6f028e0370c495383731a449092d0ae451 fixed #368 too

14:17 LauJensen: Yea i noticed

14:24 bsteuber: is there a function converting a lazy seq into another lazy seq with all duplicates removed?

14:26 nevermind - I should use find-doc more often :)

14:26 kotarak: oeh? Does someone have trouble with current git?

14:26 I get a NPE in a macroexpansion in protocols.clj line 11 (a defprotocol)

14:27 LauJensen: kotarak: when compiling, using, what?

14:27 kotarak: compiling with ant

14:27 LauJensen: k, sec

14:28 kotarak: Does it need mvn now?

14:28 LauJensen: Rich hates mvn :)

14:28 kotarak: (Man! I'm disconnected with the 1.2 at the moment.... :/ )

14:29 LauJensen: kotarak: core.protocols compiles fine here

14:29 kotarak: what changeset?

14:29 LauJensen: changeset? I just cloned HEAD

14:30 kotarak: Hmm... Me too.

14:30 LauJensen: build.clojure.org gives the green light as well

14:30 kotarak: geez

14:31 Caused by: java.lang.NullPointerException (protocols.clj:11)

14:32 LauJensen: kotarak: Could it be caused by the fact that you've renamed all the functions in core to have german names ?

14:32 kotarak: LauJensen: hehe. Unlikely.

14:32 cemerick: kotarak: sounds like you just need a clean build?

14:32 kotarak: cemerick: I did a fresh checkout. ant clean. ant.

14:33 will iterate

14:33 cemerick: kotarak: what's the sha you have?

14:33 kotarak: f47b3d6f028e

14:35 Hmpf.

14:35 Works now.

14:36 cemerick: good here

14:36 heh

14:36 kotarak: cemerick: I hate such errors. :(

14:36 cemerick: kotarak: it's those neutrinos hitting the DRAM :-)

14:36 kotarak: cemerick: dawn butterflies. ;)

14:37 damn

14:37 cemerick: kotarak: just not your day, huh?

14:37 kotarak: cemerick: seems so.

14:37 cemerick: kotarak: are you still an hg loyalist?

14:38 kotarak: cemerick: yup

14:38 LauJensen: Oh yes he is :)

14:38 And I've got the "git sucks" inbox to prove it

14:38 kotarak: geninterface methods might also be strings, right?

14:38 cemerick: kotarak is the only hg evangelist I've had much of any contact with, so I wonder from time to time. :-)

14:39 kotarak: cemerick: I just like it more than git. So much easier to use.

14:39 cemerick: stuarthalloway: I love the change to name, FWIW. Thankyouohthankyou. :-)

14:39 kotarak: I like my SCM as cryptic as possible. Keeps out the riff-raff. ;-)

14:41 LauJensen: cemerick: change to name?

14:41 * nDuff (as a former GNU Arch proselytizer moved on to Bazaar and then retired holding strong opinions on the subject) watches with amusement.

14:41 kotarak: cemerick: yeah. git is probably pretty cool. I just don't use it often enough to hardwire things in my spine. I can return to hg after work with git and everything works immediately. The other way around? No way.

14:41 nDuff: well. nothing new. The usual "git's interface sucks" argument. But I use both, prefering hg. I'm not even sure, that svn is the enemy.

14:42 cemerick: kotarak: that ;-) should've been in bold. I'm actually a tech populist, and would rather have hg's UX but git's guts. But I'm also pragmatic.

14:42 stuarthalloway: hey all, was on the phone a few minutes, would love to go back and respond to several things

14:42 cemerick: LauJensen: Second System

14:42 bah

14:42 LauJensen: http://github.com/richhickey/clojure/commit/4bea7a529bb14b99d48758cfaf0d71af0997f0ff

14:43 LauJensen: k :)

14:43 stuarthalloway: cemerick: rich is reviewing the thread on the dev list re: #352 (macro clearing meta). there may be subtleties there so I wasn't going to answer without his input

14:43 nDuff: kotarak, I remember Arch's interface enough that while I think git takes the wrong approach in asking users to learn to think in its terms, it's not exactly unprecedented. :)

14:44 cemerick: stuarthalloway: I didn't have any questions on #352?

14:44 stuarthalloway: doh! sorry, that was cgrand

14:45 too much multitasking

14:45 LauJensen: relax stuarthalloway, you are among friends :)

14:45 stuarthalloway: LauJensen: I have been working to add tests for both new code and for regressions as they are fixed

14:45 LauJensen: Great, thanks alot on behalf of the community

14:46 stuarthalloway: but that doesn't necessarily prevent some short-term pain

14:46 LauJensen: of course

14:47 stuarthalloway: also, I think that tickets have been moving through more quickly than in the past. Perception is often a lagging metric for such things

14:48 kotarak: the NPE at line 11 in protocols could be caused by reloading the code for a protocol, if that protocol called itself during the reload while things were in a half-baked state

14:49 when that has been a problem in the past it is a heisenbug -- very irritating to track

14:49 kotarak: stuarthalloway: I think I understand what happens. I'm trying to address the - in interface method names issue.

14:49 stuarthalloway: interface or protocol? interfaces can't have - in their names

14:50 kotarak: stuarthalloway: (when (some #(-> % first name (.contains "-")) methods) (throw ...)) in generate-interface causes the NPE.

14:50 cgrand: stuarthalloway: great to know (#352)

14:50 kotarak: stuarthalloway: right. the thread from the list, you said, gen-interface/definterface should error out.

14:50 stuarthalloway: working on a patch

14:50 stuarthalloway: kotarak: cool

14:51 kotarak: stuarthalloway: obviously defprotocol somehow calls into gen-interfae

15:01 oeh. I'm in trouble with name.

15:02 I insert internal_reduce. A symbol. But name returns nil.

15:06 Borkdude: how do I maximize a list of things based on their content?

15:07 like this: [[1 2] [1 3]] => [1 3]

15:07 list comprehension with for?

15:08 kotarak: Borkdude: max-key?

15:08 (doc max-key)

15:08 clojurebot: "([k x] [k x y] [k x y & more]); Returns the x for which (k x), a number, is greatest."

15:08 Borkdude: great

15:08 kotarak: ,(apply max-key second [[1 2] [1 3]])

15:08 clojurebot: [1 3]

15:09 Borkdude: kotarak: what a relief this exists :)

15:10 kotarak: locals named after core functions. In particular "name". Pfff

15:13 tgk: What is the idiomatic way to return false for an expression when it evaluates to nil?

15:13 kotarak: tgk: return nil

15:14 tgk: What if it is used in a function with a foo? name? Idiomatically I wouldn't want foo? to return nil.

15:15 I could use (not (nil? ...)), but is there a nicer way?

15:16 LauJensen: hehe, "what is the idiomatic way to return false?" "return nil" - are you kidding kotarak ? :)

15:16 kotarak: ,(boolean nil)

15:16 clojurebot: false

15:16 kotarak: tgk: see above

15:16 tgk: Oh, cool. Thanks.

15:18 * _fogus_ just fainted looking at #int(int, int)(throws Exception | Error) plusClosure = #(int a, int b)(a+b);

15:19 kotarak: What a look there are languages with type inference.

15:19 luck

15:21 _fogus_: kotarak: Hey, it is able to infer the return type on the RHS :p

15:22 kotarak: Wow. I'm impressed. ;) What's that? Scala?

15:23 _fogus_: kotarak: Java7

15:23 kotarak: o.O

15:41 bartj: ,(find-doc "lazy-cons")

15:41 clojurebot: nil

15:42 bartj: er, is "lazy-cons" a function - if yes there isn't any documentation? - http://en.wikibooks.org/wiki/Clojure_Programming/Examples/Lazy_Fibonacci

15:42 hiredman: lazy-cons hasn't existed since before 1.0 was released

15:42 sexpbot: leave me alone

15:43 kotarak: bartj: It's now named lazy-seq. See http://clojure.org/lazy

15:44 bartj: kotarak: thanks!

15:44 hiredman: lazy-seq is not lazy-cons with a new name

15:45 kotarak: hiredman: I know.

15:45 _fogus_: ,(doc cons)

15:45 clojurebot: "([x seq]); Returns a new seq where x is the first element and seq is the rest."

15:47 _fogus_: with a combination of what kotarak said

16:00 timcharper: I'm wanting to do this: write a function that receives a writer and a list of headers, and then returns a function that receives a hash map and writes the data to the writer

16:01 It needs to be able to be called by multiple threads in parallel, so it should process writes serially

16:01 I'm thinking that agents are the best tool to use for this.

16:01 Am I wrong to reach for this?

16:03 neotyk: bartj: this example caused quite some confusion in my head as well, should be updated

16:04 bartj: neotyk: I thought I was the only one with a head-ache now

16:04 neotyk: any simple examples on lazy-seq?

16:05 timcharper: .... agents it is then

16:06 neotyk: bartj: not really, let me think

16:08 tomoj: timcharper: but if you send off to the agent multiple times, the IO won't happen serially, will it?

16:09 neotyk: ,(doc lazy-seq)

16:09 clojurebot: "([& body]); Takes a body of expressions that returns an ISeq or nil, and yields a Seqable object that will invoke the body only the first time seq is called, and will cache the result and return it on all subsequent seq calls."

16:11 neotyk: ,(take 10 (lazy-seq (cycle [1 2 3])))

16:11 clojurebot: (1 2 3 1 2 3 1 2 3 1)

16:11 neotyk: bartj: though it doesn't make sense, as

16:11 tomoj: ,(take 10 (cycle [1 2 3]))

16:11 clojurebot: (1 2 3 1 2 3 1 2 3 1)

16:11 neotyk: ,(take 10 (ccyle [1 2 3]))

16:11 clojurebot: java.lang.Exception: Unable to resolve symbol: ccyle in this context

16:11 neotyk: as exactly tomoj says

16:12 bartj: since cycle itself is lazy, why are we passing it through lazy-seq again?

16:12 tomoj: no good reason

16:12 neotyk: so whats use of lazy-seq?

16:13 tomoj: cycle already returns a lazy seq

16:13 kotarak: bartj: (lazy-seq (cons (do (println "huhu") :first) nil))

16:13 tomoj: not everything returns a lazy seq

16:13 neotyk: bartj: was trying to come up with some body that will generate seq

16:13 kotarak: bartj: try in the repl, first (def x (lazy-seq ...) Then (first x)

16:14 tomoj: ,(take 10 ((fn fib [i j] (lazy-seq (cons i (fib j (+ i j))))) 1 1))

16:14 clojurebot: (1 1 2 3 5 8 13 21 34 55)

16:14 bartj: an example which doesn't involve recursion would be good

16:15 tomoj: I don't think I've ever used lazy-seq without recursion

16:15 kotarak: bartj: see my example above

16:15 bartj: it shows the effect of lazy-seq

16:17 bartj: er, it looks like a seq was not created at all?

16:18 neotyk: (let [x (lazy-seq (conj '() (do (println "ein") 1) (do (println "twei") 2)))] (first x))

16:18 ,(let [x (lazy-seq (conj '() (do (println "ein") 1) (do (println "twei") 2)))] (first x))

16:18 clojurebot: 2

16:18 ein twei

16:19 kotarak: neotyk: you have to nest the lazy-seqs

16:20 neotyk: ,(let [x (lazy-seq (cons (do (println "ein") 1) (lazy-seq (cons (do (println "twei") 2) nil))))] (first x))

16:20 clojurebot: 1

16:20 ein

16:21 bartj: kotarak: I am sorry I don't get it

16:22 kotarak: bartj: the thing inside the lazy-seq is not evaluated until you actually access it.

16:22 see in neotyk's example

16:22 twei is not printed

16:22 ,(let [x (lazy-seq (cons (do (println "ein") 1) (lazy-seq (cons (do (println "twei") 2) nil))))] (second x))

16:22 clojurebot: 2

16:23 ein twei

16:24 kotarak: bartj: in his first example twei is printed because it is evaluated in the same lazy-seq

16:24 neotyk: it was evaluated by cons

16:24 not lazy-seq

16:28 bartj: does it makes sense?

16:29 bartj: , (let [x (cons 1 (cons 2 nil))] (second x))

16:29 clojurebot: 2

16:29 bartj: er, same result without the lazy-seq?

16:30 neotyk: bartj: yes, but sideeffects are missing

16:30 tomoj: ,(take 10 ((fn fib [i j] (cons i (fib j (+ i j)))) 1 1))

16:30 clojurebot: java.lang.StackOverflowError

16:30 tomoj: :)

16:30 kotarak: bartj: no. not the same

16:30 neotyk: bartj: include side effects and do (first x)

16:31 kotarak: ,(let [x (cons (do (println "eins") 1) (cons (do (println "zwei") 2) nil))] (first x)

16:31 clojurebot: EOF while reading

16:31 kotarak: ,(let [x (cons (do (println "eins") 1) (cons (do (println "zwei") 2) nil))] (first x))

16:31 clojurebot: 1

16:31 eins zwei

16:31 kotarak: bartj: compare to lazy-seq example with first

16:31 bartj: , (let [x (cons (do (print "test") 1) (cons 2 nil))] (first x))

16:31 clojurebot: 1

16:31 test

16:32 neotyk: ,(let [x (cons (do (println "ein") 1) (cons (do (println "twei") 2) nil))] (first x))

16:32 clojurebot: 1

16:32 ein twei

16:32 kotarak: ,(let [x (lazy-seq (cons (do (println "ein") 1) (lazy-seq (cons (do (println "twei") 2) nil))))] (first x))

16:32 clojurebot: 1

16:32 ein

16:33 kotarak: no "twei"

16:33 bartj: kotarak: yes!

16:35 I guess I was trying with the wrong examples!

16:58 tomoj: one need not mention the "exit" condition while writing a lazy-seq?

16:58 tomoj: that is a bit hard to get over at first

16:59 tomoj: that's part of the point of laziness

16:59 (iterate inc 0) is the natural numbers, all of them

16:59 but only as many as you need will be generated

17:01 I've liked my eeepc but haven't tried any others, so..

17:02 oops

17:02 wrong channel

17:07 KirinDave: Did anyone ever make good on that lazy hash idea?

17:08 Cumbayah: Hi clojurians. Newb alert. What would be an ideomatic way of providing a lazy sequence over floats serialized to a file from java? thanks a bundle

17:09 KirinDave: Cumbayah: Check out lazy-seq

17:09 Cumbayah: It really works with I/O

17:11 Cumbayah: thx for the pointer

17:13 tomoj: then you end up with the stream left open if you don't consume the whole seq, though

17:14 KirinDave: tomoj: That is a problem with laziness.

17:14 Another possibility is to eat the file entirely into memory

17:14 But if you're making a lazy seq it's probably because the file is ginormous.

17:14 In that case, you need to make sure the stream is closed. preferably by a finally clause.

17:14 Cumbayah: potentially huge files, want to avoid reading into mem as it can be processed sequentially

17:15 KirinDave: Cumbayah: So just be aware that the file can close. And if you close the file while the lazy seq has it, it'll chuck an exception.

17:15 Lazy seqs can handle streams, so it's fine.

17:15 tomoj: avoiding holding the head will prevent keeping everything into memory, right?

17:15 KirinDave: Right

17:15 Or so I'm told

17:16 arkahn: I'd like to (doall map prn (line-seq rdr)) and catch the IOException so I could continue reading the file at a later time, i.e. "tailing". What syntax would I use to specify java.io.IOException in the catch clause?

17:16 KirinDave: Cumbayah: The easiest example of a lazy-stream is something like iterate

17:16 Cumbayah: (defn forever [start] (lazy-seq (cons start (forever (inc start)))))

17:16 arkahn: the prn will be replaced with another fn

17:16 KirinDave: So (take 5 (forever)) is (0 1 2 3 4)

17:17 hiredman: clojurebot: exceptions?

17:17 clojurebot: http://paste.lisp.org/display/74305

17:19 bartj: for this function:

17:19 ,(defn my-iterate [f x] (lazy-seq (conj [x] (my-iterate (f x)))))

17:19 clojurebot: DENIED

17:19 bartj: why can't I do a - (my-iterate inc 0)

17:21 KirinDave: bartj: Why conj?

17:21 bartj: But anyways, note that you're passing (my-iterate (f x))

17:21 Which is wrong

17:21 I think you meant

17:22 (my-iterate f (f x))

17:23 bartj: KirinDave: my knowledge of clojure functions is a bit limited

17:23 yes, you are right

17:23 KirinDave: bartj: I don't know why you're putting everything in a vector.

17:23 See my previous code for something like iterate

17:23 bartj: but, I use lazyseq and *still* get a stackoverflow

17:24 KirinDave: Try

17:24 (defn my-iterate [f x] (lazy-seq (cons x (my-iterate f (f x)))))

17:24 And then say (take 5 (my-iterate inc 0)))

17:24 err, ))

17:25 Infinite seqs are like hot lava. Unless you set up your repl to handle them, they're gonna burn you upon contact. :)

17:25 naeu: hot java lava

17:27 ninjudd: if i have an implementation of a protocol method that is the same for two different calls to deftype, what is the appropriate way to keep the code dry?

17:27 should i just call deftype without the protocol and then use extend, merging my methods into a hash of the default implementations?

17:28 naeu: ninjudd: is it possible to defn the method and pass the method name to deftype?

17:28 bartj: thank you all for helping me write my first lazy-seq

17:29 ninjudd: naeu: oh, does that work?

17:29 naeu: ninjudd: I have absolutely no idea :-)

17:29 'twas but a guess

17:30 ninjudd: i'll try it

17:33 naeu: i can't do what you suggested, but i can call the method from my implementation, though that results in an extra method call, rather than calling my implementation directly

17:34 naeu: hmm that's frustrating

17:35 I wonder what the speed difference actually is

17:36 it would be interesting to do some performance tests

17:36 perhaps hotspot optimises away that extra method call

17:37 ninjudd: yeah, i doubt the performance hit would be significant. i'm more concerned with what the generally accepted idiom is for doing it

17:38 naeu: ninjudd: I wonder if an idiom has had chance to form yet...

17:38 :)

17:41 ninjudd: clojure.contrib.io uses extend to share implementation: http://github.com/richhickey/clojure-contrib/blob/master/src/main/clojure/clojure/contrib/io.clj

17:41 but it doesn't use deftype

17:43 chouser: do you know what the right way to share implementation with deftype is?

17:43 kotarak: ninjudd: using extend with a map and eg. merge

17:45 ninjudd: kotarak: ok, so just call deftype and leave the protocol out, then do extend

17:45 kotarak: ninjudd: yes

17:45 ninjudd: kotarak: cool, thanks

17:47 kotarak: the deftype fields won't be accessible directly to those methods, right? or will they?

17:47 kotarak: ninjudd: you'll have to use (.field instance)

17:48 arkahn: I'm in the process of writing something that tails a file. Can anyone tell me why the following exits when it 'should' infinitely loop? http://gist.github.com/421550

17:48 ninjudd: kotarak: k

17:49 kotarak: arkahn: because repeatedly is not a loop. It create a lazy sequence, which gets never realised.

17:49 You probably want loop/recur or so

17:49 Or (while true ...)

17:49 arkahn: kotarak: oh - ok, thank you

17:59 DeusExPikachu: is there a function that simply executes its argument? similar to how identity simply returns its argument? basically a name for #(%)?

18:01 turbofail: ,(apply (fn [] "Foo"))

18:01 clojurebot: java.lang.IllegalArgumentException: Wrong number of args passed to: core$apply

18:01 turbofail: doh

18:01 works on my older version of clj

18:02 bartj: DeusExPikachu: what do you mean by simply execute?

18:02 raek: ,(apply (fn [] "Foo") [])

18:02 clojurebot: "Foo"

18:02 DeusExPikachu: #(%)

18:02 basically a name for that

18:03 turbofail: is there some reason you need a name for it?

18:04 DeusExPikachu: clarity, readability, nothing more really

18:04 turbofail: well, you could always make one

18:04 tomoj: hrmm

18:04 so you have foo and you're doing (#(%) foo) ?

18:04 DeusExPikachu: I know I can, just wanted to know if there was one already in core

18:05 turbofail: the closest thing is "apply," but that requires an extra arg

18:05 DeusExPikachu: tomoj, no, more like (map #(%) vector-of-fns)

18:05 tomoj: ah, I see

18:06 ((apply juxt vector-of-fns)) heh

18:08 defn: http://gist.github.com/421584

18:08 how can I turn that lazy-cons into a lazy-seq

18:09 tomoj: I think lazy-cons is (lazy-seq (cons ...)) ?

18:09 defn: yeah that sounds right

18:09 not sure if the if needs to be inside though

18:10 tomoj: nope

18:10 defn: k cool, thanks

18:10 need to get my markov on :)

18:16 bhenry: is there a function to which i can pass a symbol (representing a function) that tells me what namespace said symbol is defined?

18:17 tomoj: no

18:20 lancepantz: stuarthalloway: there was a discussion in the mailing list about splitting up contrib into individual jars, do you see this happening?

18:20 stuarthalloway: lancepantz: yes

18:20 tomoj: bhenry: can you maybe give an example of what you want?

18:20 lancepantz: that will be awesome

18:20 stuarthalloway: lancepantz: but not before beta1

18:21 lancepantz: but before 1.3?

18:26 bhenry: tomoj: a project uses all kinds of namespaces eg ns1 . . . ns10

18:27 tomoj: i look through the project and see (fn-1 some stuff here)

18:27 i was wondering if i could do (somefunc fn-1) to see what namespace it was in

18:28 tomoj: aha, in that case, yes

18:29 ,(resolve '+)

18:29 clojurebot: #'clojure.core/+

18:30 bhenry: haha derrr. doc will do it too

18:30 tomoj: yeah, that too

18:30 best to use require or use :only, I think

18:30 I mean, :require or :use :only

18:31 bhenry: yeah. i didn't write this project. but that seems like a good practice to adopt

18:33 tomoj: best for the people who will have to read your code later :)

18:37 bartj: trying to write a lazy-seq for generating prime numbers

18:38 and realized that I would have got the field's medal or something similar if I could write one....

18:38 FML

18:38 tomoj: where's my field's medal? :(

18:39 bartj: tomoj: I mean there is no function which will predict the next prime number, right?

18:39 tomoj: sure there is

18:40 bartj: hmm?

18:40 which is?

18:40 tomoj: the simplest example is the function that just keeps looking until it finds another prime..

18:41 defn: bartj: depends on what you mean by predit

18:41 predict

18:42 i could conceive of a function which guesses the next prime, but isn't always accurate

18:42 tomoj: but why bother when we can just make a function which is always accurate?

18:43 defn: *shrug* -- maybe for massive primes it's not a terrible idea to try

18:43 tomoj: oh, yeah, for massive primes my simple function will just run until you die

18:43 defn: :)

18:44 bartj: (defn is-prime? [x] (loop [i 2] (if (>= i x) true (if (= (rem x i) 0) false (recur (inc i))))))

18:47 candera: IIRC there are algorithms that can be run to determine with a lower bound on the probability that a number is prime. So if you're cool with a sequence of numbers that is highly likely to be prime, you could pull that off.

18:47 tomoj: I don't understand

18:47 we can write a function which returns a lazy seq of all and only the prime numbers

18:48 candera: But it's horrendously inefficient to use the Sieve of Erasthenese.

18:48 tomoj: so what?

18:49 candera: If you only need the first n, for small n, then yep, so what?

18:51 bartj: (defn get-primes [] (lazy-seq (is-prime? (iterate inc 2))))

18:52 tomoj: ,(doc filter)

18:52 clojurebot: "([pred coll]); Returns a lazy sequence of the items in coll for which (pred item) returns true. pred must be free of side-effects."

18:52 bartj: returns an error of - clojure.lang.Cons cannot be cast to java.lang.Number

18:52 candera: (defn get-primes [] (filter is-prime? (iterate inc 2))

18:53 bartj: candera: I was enthusiastic to use lazy-seq

18:54 also why doesn't (take 5 (get-primes)) work?

18:54 tomoj: you will rarely need to use lazy-seq

18:55 bartj: tomoj: why not in the above case?

18:56 tomoj: iterate already returns a lazy seq

18:57 (take 5 (get-primes)) should work

18:58 bartj: clojure.lang.Cons cannot be cast to java.lang.Number

18:59 tomoj: candera corrected your get-primes

19:00 is-prime? expects a number, you were passing (iterate inc 2) to it, not a number

19:04 bartj: tomoj: yes, thank you

19:11 nirly: where do I need to put clojure files so I can load them with (require )?

19:18 tomoj: nirly: on the classpath

19:18 hiredman: require works on namespaces, and tries to map those namespaces to files, so if your namespaces and filenames map to each other correctly require will work

19:19 ~namespaces

19:19 clojurebot: namespaces are (more or less, Chouser) java packages. they look like foo.bar; and corresponde to a directory foo/ containg a file bar.clj in your classpath. the namespace declaration in bar.clj would like like (ns foo.bar). Do not try to use single segment namespaces. a single segment namespace is a namespace without a period in it

19:19 tomoj: just use leiningen :P

19:21 hiredman: if you just want to load a file, there is, well, a function called load-file

19:22 jashmenn: is there a way i can pass a list "unpacked" to a function. like the splat* operator in ruby?

19:26 lancepantz: jashmenn: apply

19:26 ,(apply println '("a\n" "b\n" "c\n"))

19:26 clojurebot: a b c

19:26 jashmenn: lancepantz: ah, right thanks!

19:27 lancepantz: that makes more sense at a repl )

19:27 :)

19:42 kensanata: I know very little of Java and Clojure; working on my first piece of code and getting java.lang.IllegalArgumentException: No matching ctor found for class javax.swing.JPanel for this code: (import '(javax.swing JPanel ImageIcon)) (def tile (JPanel. (ImageIcon. "empty.png"))) -- what am I doing wrong?

19:48 technomancy: kensanata: ctor means constructor, so apparently you can't construct at JPanel with an ImageIcon argument.

19:49 kensanata: Gah, I think I confused JPanel with JLabel... Must try again.

19:50 That was it. Thanks for the pointer, technomancy. :)

20:27 nuba: guys, i have this centos 5.5 32 bit which i'm migrating from vmware server into a xen running on a centos 5.5 64bit, how should I go about it, regarding kernel and para or hvm?

20:27 the part about converting the disk image with qemu-img is sorted out already

20:28 nDuff: nuba, are you sure this is the channel you mean to be in?

20:29 nuba: aww crap, sorry guys, dammit

20:29 nDuff: nuba, (Xen's HVM is pretty slow, unlike KVM's; PV will require more work, but is likely worthwhile)

20:29 nuba: wrong window, i thought i had switched irssi to #xen

20:30 heh, and that's from someone using irssi for 10+ years, sorry folks

20:31 axi: anybody know why "(import ('java.io File))" isn't working with enclojure?

20:31 tomoj: (import java.io.File)

20:32 axi: ty

20:32 strangely it works in repl 1.1.0

20:33 hrm yeah, (import 'java.io.File) works

21:37 pedroteixeira: hello, any way to keep running tests automatic just with clojure.test?

21:49 cemerick: pedroteixeira: you mean similar to infinitest or autotest?

21:49 I don't know of anything like that yet, no.

21:49 Would be pretty simple to do though.

22:06 pedroteixeira: cemerick: ok, thanks. i found stuarthalloway's circumspec now, will try to do something to watch and run-tests when things change,.

22:14 Siasia: test

22:15 Oh! Hi there!

22:15 I have some troubles with leiningen and swank

22:15 Doesn't even know whats up? Just starting with clojure.

22:16 tomoj: what are your troubles

22:16 Siasia: can i drop stacktrace in here

22:16 ?

22:17 that project clj

22:17 (defproject sandbox "1.0.0-SNAPSHOT"

22:17 :description "FIXME: write"

22:17 :dependencies [[org.clojure/clojure "1.1.0"]

22:17 [org.clojure/clojure-contrib "1.1.0"]]

22:17 :dev-dependencies [[swank-clojure "1.2.0"]])

22:18 just an empty lein new

22:19 http://pastebin.com/iestTgzW

22:19 and console session

22:19 tomoj: hrmm

22:19 Siasia: so lien swank is not warking

22:20 tomoj: never seen that error before there

22:20 Siasia: oh i'm on freebsd

22:20 also i tryed swank with maven and its working perfectly

22:21 tomoj: hurrah

22:22 that project.clj works fine for me

22:23 hiredman: Siasia: you want lein-swank not swank-clojure

22:23 tomoj: oh, I see what the problem is

22:23 perhaps

22:24 hiredman: tomoj: well to start with

22:24 tomoj: Siasia: can you do (System/getProperty "os.name") and (System/getProperty "os.arch") ?

22:25 hiredman: Siasia: doesn't matter

22:25 er

22:25 tomoj

22:25 tomoj: I thought we want swank-clojure not lein-swank nowadays

22:25 hiredman: why do you think it doesn't matterL

22:25 hiredman: oh

22:25 right

22:26 I thought it was the reverse

22:26 tomoj: I think this is what's causing the error...

22:26 hiredman: tomoj: what?

22:26 tomoj: Siasia's os.name or os.arch aren't known by leiningen

22:26 Siasia: i was afk

22:26 so

22:27 hiredman: tomoj: I highly doubt that

22:27 tomoj: well, the stacktrace seems pretty clear to me

22:27 Siasia: user=> (System/getProperty "os.name")

22:27 "FreeBSD"

22:28 tomoj: exactly

22:28 Siasia: user=> (System/getProperty "os.name")

22:28 "FreeBSD"

22:28 tomoj: native-names in compiler.clj has no key for FreeBSD

22:28 Siasia: sorry

22:28 tomoj: and thus the NullPointerException

22:28 Siasia: so how can i work this around?

22:29 tomoj: maybe you can override os.name? :/

22:29 I think you should report this, but don't know where leiningen bugs are reported

22:29 Siasia: and how can i pass this to lein?

22:29 tomoj: I don't know any way to do that, sorry

22:30 Siasia: any solutions?

22:30 tomoj: the only one I can think of is to fix leiningen

22:31 Siasia: kinda

22:32 tomoj: I believe adding "FreeBSD" :freebsd to the native-names map should fix your problem

22:32 but maybe leiningen should not explode on an unknown os.name..

22:32 hiredman: technomancy is kind of a linux snob

22:33 I've been trying to tell him to use something other than #!/bin/bash in the shebang for lein for a while

22:34 tomoj: Siasia: your best bet may be to follow the directions under "Hacking" in the leiningen readme and make the patch

22:35 Siasia: mokay. already cloning lein :)

22:44 yep that's working

22:44 cemerick: why does lein care about the os.name?

22:52 tomoj: cemerick: native lib path

22:53 cemerick: really

22:53 tomoj: ayup

22:54 cemerick: not sure what to think of that

22:54 axi: when I create a class using ns/gen:class.. how do I expose variables

22:58 :gen-class*

23:10 tomoj: you need to access these variables from java I guess?

23:11 axi: hrm.. gen-class :exposes only works for inherited protected members :(

23:11 tomoj, i'd like to be able to do both

23:12 access from java code and other clojure namespaces

23:13 tomoj: does :state not do what you want?

23:16 axi: how would I make use of that?

23:17 (. instance state member) - unable to resolve symbol

23:17 tomoj: in the gen-class, you do like :state foo

23:17 axi: I did

23:17 tomoj: then (.foo instance)

23:18 axi: No matching field found

23:19 cemerick: axi: do you have an :init function that sets the :state?

23:20 axi: no

23:20 i have

23:20 (ns x.y (:gen-class :state state :init init))

23:20 (defn -init [] ...code... )

23:22 cemerick: that should work

23:22 tomoj: but what does -init return?

23:22 cemerick: regardless of that, he shouldn't be getting 'no matching field'

23:23 if -init returns an 'improper' value, the :state field will just be nil

23:24 axi: are you compiling the relevant namespace, and then starting a new repl with the classpath appropriately set up to be able to load the AOT-compiled class?

23:34 tomoj: so you can only have one state field?

23:34 cemerick: in gen-class, yes

23:35 tomoj: I guess it is only really meant to store a ref/atom/whatever?

23:35 cemerick: you can drop any object there if you so choose

23:35 tomoj: but the fact that it's final and there's only one...

23:35 cemerick: right, it leads you to certain good defaults

23:36 deftype and defrecord are there and quite preferable unless you really need gen-class' interop features

23:36 tomoj: what if you wanted to implement the state object in clojure?

23:37 cemerick: how do you mean?

23:37 tomoj: maybe what I'm asking is, what tools would we use to write refs/atoms in clojure

23:37 cemerick: ah, that's exactly what deftype is for

23:37 tomoj: deftype doesn't give you something java can hook onto, does it?

23:38 or does it, hmm

23:38 cemerick: it emits fields

23:38 far better to define an interface and implement that in the type IMO

23:38 for java interop, that is

23:39 field access is quite non-idiomatic in java

23:39 tomoj: but then how does java get ahold of an actual concrete class

23:39 cemerick: AOT-compile a deftype, and you've got a class

23:39 tomoj: ah, yes, ok

23:39 only, it can't subclass anything

23:39 cemerick: right

23:40 extending concrete subclasses opens up a whole can of worms. That's why gen-class is sticking around.

23:40 tomoj: so if the java lib you're working with defines it's plugin api in terms of abstract classes instead of interfaces, you're out of luck

23:40 cemerick: (and proxy, for that matter)

23:40 tomoj: oh, can we use deftype with abstract classes?

23:40 cemerick: no

23:40 tomoj: but it would be less of a can of worms than extending concrete classes?

23:41 I wish I could somehow sneak deftype into the system

23:41 cemerick: sorry, I meant any class

23:41 tomoj: ah

23:41 cemerick: as opposed to interfaces

23:42 tomoj: I feel like there should be universal pressure on jvm developers to define their shit in terms of interfaces not abstract classes

23:42 cemerick: If you need the full-boat java interop, that's what gen-class and proxy are for.

23:42 yeah

23:42 Lots of history there.

23:42 tomoj: maybe there is some reading material

23:43 I want to know why solr uses abstract classes

23:43 cemerick: probably because lucene uses abstract classes

23:43 :-P

23:43 godawful choice that was

23:43 tomoj: is there something you gain in java for using abstract classes?

23:43 hiredman: you can inheriting implementation

23:43 cemerick: default implementations

23:45 tomoj: I see

23:45 gstamp: I was wondering if anyone could suggest a good way to avoid repeating the call to key-pressed? in the code at http://codepad.org/ZeqvTmut. condp seems to be almost what I want but I'm not sure how I'd make it apply to this particular case.

23:45 tomoj: so maybe what java devs should do is define public interfaces and use them all over, but use abstract classes internally?

23:45 (if needed)

23:45 cemerick: That's the ideal, yeah.

23:46 tomoj: I guess this style is evident in clojure's java sources, eh?

23:46 never thought much about the I's and A's there

23:47 wonder how much work it would be to fix solr and lucene :(

23:48 cemerick: tomoj: never, ever, ever going to happen :-)

23:49 tomoj: nooo

23:49 this is just a nightmare I will wake up from soon

Logging service provided by n01se.net