#clojure log - May 09 2011

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

0:01 zrilak: 6am, time to hit the proverbial sack... big thumbs up to all you wonderful folks

0:01 tomoj: huh, I hadn't heard of that one

0:01 clojurebot: Cool story bro.

0:02 tomoj: "This in-depth look also shows Ruby and Python developers that Closure is just as expressive and sophisticated with one added advantage"

0:02 BAH

0:03 brehaut: the typo?

0:03 tomoj: didn't even notice that, but, damn, yeah

0:03 I BAH at "just as"

0:03 amalloy: also "one" added advantage

0:03 what advantage is that? the advantage of "having lots of advantages"?

0:04 tomoj: "all the resources of the JVM"

0:04 that ugly (though often quite useful) thing strapped to our backs

0:04 TheMoonMaster: lol

0:05 tomoj: bad analogy, it's the foundation I suppose

3:08 markoman: Hi guys. I have this kind of situation: (do 1 (for [r (range 2 4)] r)) -> (2 3) but I need result to be (1 2 3)

3:09 is there some way to add first clause on do to the beginning of the sequence?

3:10 again this is simplified example with numbers. actually numbers are vectors

3:12 maybe this being more real example: (do [1] (for [r (range 2 4)] [r])) which should return ([1] [2] [3])

3:14 _mst: markoman: I think you want (lazy-seq (cons [1] (for [r (range 2 4)] [r])))

3:15 raek: markoman: as _mst pointed out, you can use 'cons' to add something to the beginning of a sequence

3:16 you probably don't want to use (do x y z) here, since what it does is to evaluate x y z (in that order) and then throw away x and y and return z

3:19 markoman: ok, i was trying to use merge instead of do at some point cause i figured do gives only the last evaluation

3:20 raek: you can use concat if you want to glue together the results of multiple sequence expressions

3:20 markoman: (cons [1] (for [r (range 2 4)] [r])) is not enough here? why need for lazy-seq?

3:20 raek: ,(cons (range 2 4))

3:20 clojurebot: java.lang.IllegalArgumentException: Wrong number of args (1) passed to: core$cons

3:20 raek: ,(cons 1 (range 2 4))

3:20 clojurebot: (1 2 3)

3:21 raek: ,(concat [1] (range 2 4))

3:21 clojurebot: (1 2 3)

3:22 raek: markoman: lazy-seq is not needed here, but is good to use if you are going to generate a longer sequence (for example, 'for' uses it internally to be able to process infinite sequences)

3:26 markoman: thanks, got it working

4:17 tufflax: ,`(abc `(def))

4:17 clojurebot: DENIED

4:17 tufflax: &`(abc `(def))

4:17 sexpbot: java.lang.SecurityException: You tripped the alarm! def is bad!

4:17 tufflax: &`(abc `(de))

4:17 sexpbot: ⟹ (clojure.core/abc (clojure.core/seq (clojure.core/concat (clojure.core/list (quote clojure.core/de)))))

4:18 tufflax: what's with the seq, concat and list?

6:56 SLLCLL: sup

6:57 why does this http://pastebin.com/Biyf0Tfi produce a stack overflow when run with (sieve (range 2 1000000))

7:00 I thought lazy-seq was supposed to prevent that

7:24 why does this http://pastebin.com/Biyf0Tfi produce a stack overflow when run with (sieve (range 2 1000000))

7:32 raek: SLLCLL: it happens because you end up building up a big nested (remove ...) expression

7:32 SLLCLL: hm....

7:33 raek: in order to take the first element of one remove, it needs to take the first element of the next remove, and so on

7:33 SLLCLL: ah....

7:33 raek: when a lazy-seq is forced, it creates a stack frame

7:33 SLLCLL: well how should I do it

7:34 raek: SLLCLL: a workaround is to put doall around the remove call

7:34 SLLCLL: ok

7:34 raek: then you will actually filter out one number each iteration

7:35 *all numbers divisible by next-prime

7:36 SLLCLL: seems to work slow :)

7:36 raek: the larger input sequence you have, the more filtering needs to be done at each step...

7:39 SLLCLL: unfortunately time macro stops working

7:40 raek: SLLCLL: since the resuling seq is lazy, you need to wrap the expression in (doall ) to time the whole thing

7:41 SLLCLL: also, this problem seems to be a common one :) http://stackoverflow.com/questions/2992123/clojure-avoiding-stack-overflow-in-sieve-of-erathosthene

7:41 SLLCLL: :)

7:41 raek: and http://clj-me.cgrand.net/2009/07/30/everybody-loves-the-sieve-of-eratosthenes/

7:41 SLLCLL: is there a difference between mod and rem fns

7:42 clojurebot: clojure-mode is an Emacs mode for Clojure, found at git://github.com/jochu/clojure-mode.git

7:43 raek: SLLCLL: yes, they behave differently for negative numbers

7:44 SLLCLL: since I throw an error for negative numbers, which is faster for positive cases

7:47 neotyk: Hi *

7:48 SLLCLL: there's something wrong with this sieve

7:48 neotyk: do you guys get slow performance out of maven-clojure-plugin?

7:49 SLLCLL: if I take 100 from sieve of 1million it takes 6 seconds.... if I try to take all then it take 10 min (and still not finished)

7:49 that's illogical, after doing first 100 primes the remaining sequence should be pretty short with so many numbers eliminated

8:12 neotyk`: anyone knows status of https://github.com/stuartsierra/new-clojure-maven-plugin ? is it usable, ready to bu used?

8:12 s/bu/be/

8:20 SLLCLL: since that sieve operated slowly as hell I created a new one

8:20 http://pastebin.com/PzsneVjf

8:20 I use no recursion yet it has stack overflow

8:21 oh wait

8:21 it was same thing

8:21 had to put doall in front of remove....

8:26 neotyk`: to answer my own question, new-clojure-maven-plugin is not able to test yet

8:29 cemerick: neotyk`: I think it'll be a while before it catches up.

8:34 neotyk`: cemerick: I found out that problem was not c-m-p but rather my code :-/

8:34 cemerick: neotyk`: my condolences :-)

8:34 c-m-p is pretty tight

8:35 About the only thing it's missing at this point is nREPL support, but that's minor.

8:49 SLLCLL: man

8:49 why is this so slow

8:51 http://pastebin.com/7PRQ9912 take 1500 seconds to do (time (do (sieve (range 2 1000000)) nil))

8:51 ffs why

8:58 chouser: O(n^2), allocates memory for a seq and an Integer object for each number examined, etc.

8:59 SLLCLL: Well of course it's O(n^2), any naive sieve impl is probably

8:59 but I guess this could be about 100 times faster in java

8:59 just creating a boolean array and crossing out numbers

9:00 which is same basic algorithm

9:00 except i'm using filter here

9:01 chouser: SLLCLL: well, you could try using an array and crossing out numbers in Clojure too

9:01 I think you'd find it to be significantly faster

9:02 SLLCLL: with the absence of c style for loops that kind of code usually gets excessively ugly

9:02 kind loses the point of using clojure in the first place

9:03 chouser: crossing out numbers from a fixed-sized array means that to "filter" 7, for example, only every seventh item in the array is touched at all

9:03 SLLCLL: i see your point

9:03 chouser: using filter like this means that to filter out 7, every single item in the seq is mod'ed

9:03 SLLCLL: moded?

9:04 chouser: and of course the difference between the two styles gets more and more dramatic the higher you go

9:04 SLLCLL: I thought it just said (rest seq) if predicate pans out

9:04 chouser: elim-multiples looks at every element of coll

9:05 SLLCLL: gotcha.... I shouldn't use clojure for tight algorithms

9:05 chouser: heh, well, that's not quite what I said

9:05 SLLCLL: I guess I could code it in java and call it from clojure

9:05 chouser: you could. or you could do in clojure what you would do in java.

9:06 for(i = 0; i < 10; ++i) {...} / (loop [i 0] (when (< i 10) ... (recur (inc i)))

9:07 I think I might agree with "don't use seqs for tight number-processing algorithms"

9:08 SLLCLL: but practically everything in clojure results in seqs

9:08 (or vectors which seem just as slow)

9:10 joly: practically everything in Java results in objects, but I'd use primitives for these calculations, loop indices, etc

9:10 use what fits best

9:10 chouser: Clojure has pretty good support for dealing with Java arrays, even arrays of primitives which would be a good choice for a sieve of Erotosthenes

9:16 TimMc: chouser: Is that the sexy version of the sieve of Eratosthenes?

9:18 chouser: heh

9:18 SLLCLL: this version

9:18 http://pastebin.com/a2xYvEw8

9:18 isn't actually a sieve

9:18 calculates each number separately

9:19 50000 times faster than that sieve

9:19 chouser: the previous version wasn't actually a sieve of Eratosthenes either.

9:19 SLLCLL: go figure

9:19 oelewapperke: that's not a sieve

9:19 oh right :-p

9:19 that looks like a very, very slow way of calculating primes

9:20 gfrlog: I just constructed a lazy, iterative, efficient sieve

9:20 SLLCLL: looks slow

9:21 calculated primes in first million in 0.034 msec

9:21 gfrlog: https://gist.github.com/962508

9:23 SLLCLL: I don't really get these map implementations :P

9:23 gfrlog: mine?

9:23 SLLCLL: or cgrands :)

9:23 both confuse me

9:24 gfrlog: I cannot find cgrand in the irc history :(

9:29 oelewapperke: SLLCLL: that function restarts it's prime list from scratch on every iteration

9:29 SLLCLL: bit of a stretch to call that efficient imho

9:30 SLLCLL: it is

9:30 but like I said

9:30 50000 times faster than sieve I build that basically uses filter to remove multiples

9:30 from a sequence of all examined numbers

9:30 gfrlog: addition is always much faster than division

9:31 SLLCLL: what does that mean?

9:31 gfrlog: sieve uses only addition. trial division uses lots of division

9:32 at the processor level, addition is some 50 times faster typically, I think

9:32 SLLCLL: my sieve used modulus

9:32 :P

9:32 my bad :P

9:32 gfrlog: modulus is division

9:32 SLLCLL: well it should still have many many times fewer divisions

9:32 gfrlog: I suppose I can't comment further without seeing either of them

9:36 oelewapperke: SLLCLL: presumably that's because clojure is copying the array around like crazy

9:36 I'm not actually sure how to write an efficient sieve in clojure

9:37 SLLCLL: write it in java then call from clojure :P

9:38 gfrlog: oelewapperke: https://gist.github.com/962508 ?

9:39 cemerick: SLLCLL: first result on Google for "clojure sieve of eratosthenes" FWIW http://clj-me.cgrand.net/2009/07/30/everybody-loves-the-sieve-of-eratosthenes/

9:40 dnolen: SLLCLL: I don't see why you can't just implement the Java algorithm in Clojure, esp if you're willing to try 1.3.0 alphas or master branch. The only perf difference you should see will be around the fact that Clojure only supports 64 bit arithmetic.

9:40 64 bit primitive arithmetic I mean.

9:40 SLLCLL: I know cemerick but I just can't understand his version

9:41 cemerick: SLLCLL: Fair enough, but I'm not sure if that warrants punting to Java. +1 to dnolen above, as well.

9:42 SLLCLL: tbh I'm just not good enough

9:42 cemerick: Where's your fighting spirit man? :-P

9:43 SLLCLL: I stumble around a fair bit when trying to use unchecked ops

9:43 when I try to use them I don't gain performance generally (due to my lack of knowledge)

9:44 gfrlog: it looks like cgrand's version will hold the entire set of primes in memory?

9:44 SLLCLL: but my stupid version that checks every number just outdid version of someone I know

9:44 so I'm happy with that

9:45 cemerick: SLLCLL: A saying of mine: "Clojure demands that you raise your game, and pays you back for doing so."

9:46 SLLCLL: funny thing... this guy I beat has a lot of experience in web development, has done several projects, has some startups and I'm just a junior developer at some random company

9:47 cemerick: gfrlog: yes

9:47 gfrlog: okay

9:47 ejackson: dnolen: is your native-deps plugin for leiningen still the way to go for native dependencies ?

9:48 cemerick: gfrlog: probably not a problem unless you had some serious objectives :-)

9:48 dnolen: ejackson: probably not for long, technomancy is folding into lein it sounds like.

9:48 ejackson: but for now yes.

9:48 gfrlog: cemerick: well I wouldn't be putting that into production... :)

9:48 technomancy: dnolen: actually it's already in =)

9:48 if you're running lein from git

9:48 dnolen: technomancy: sweet!

9:48 ejackson: technomancy: I'll do that then :)

9:49 gfrlog: cemerick: it would be embarrassed next to my production version of fib

9:49 ejackson: dnolen, technomancy: thanks.

9:52 gfrlog: cemerick: but isn't performance tho whole point of the discussion?

9:54 technomancy: ejackson: it doesn't support transitive native deps yet, but I'm hoping to have that in before the release

9:54 ejackson: technomancy: I think my deps are all direct, hope so :)

9:55 technomancy: yeah, it's an edge case for sure.

9:57 cemerick: gfrlog: retaining primes doesn't impact perf; it's not good if you plan on going prime-hunting in a serious way, but it's irrelevant given the limits we've been holding to (i.e. < 1e6 or whatever).

9:58 gfrlog: ah; was not aware of limits

9:58 cemerick: gfrlog: small primes seemed to be what SLLCLL was aiming for

9:59 gfrlog: gatcha

9:59 cemerick: FWIW, I wasn't saying cgrand's impl was the best possible — just that it was easily available and pedagogically useful

9:59 gfrlog: s/gatcha/gotcha

9:59 sexpbot: <gfrlog> gotcha

9:59 gfrlog: right

9:59 SLLCLL: hm

9:59 can I use aset in combination with map

9:59 cemerick: gfrlog: If you're confident in your impl, you should blog it and see how it fares in the wild. :-)

10:00 gfrlog: okay

10:00 cemerick: http://gfredericks.com/gfrlog/posts/90 :)

10:01 dnolen: SLLCLL: ? use aset on a map?

10:01 cemerick: gfrlog: ah, you're prepared! :-)

10:01 gfrlog: for once

10:01 cemerick: gfrlog: a tgz?!?

10:01 :-O

10:02 gfrlog: yes I'm so sorry

10:02 cemerick: Get thee a github repo.

10:02 gfrlog: okay one sec

10:03 cemerick: gfrlog: how fast is your impl (up to 1e6, say)

10:03 gfrlog: is that the first million primes or all primes below a million?

10:03 cemerick: below a million, sorry

10:04 gfrlog: cemerick: https://github.com/fredericksgary/lazy-prime-sieve

10:05 SLLCLL: no... use map macro with aset

10:05 gfrlog: cemerick: 1500 msec

10:06 cemerick: gfrlog: thanks; so, I'm getting 2.4s with yours vs. 1.4s with cgrand's. #slowmacbookpro

10:06 gfrlog: yeah, I would think mine would get the edge assymtotically

10:06 cemerick: gotcha

10:06 gfrlog: s/assymtotically/correct-spelling

10:06 sexpbot: <gfrlog> yeah, I would think mine would get the edge correct-spelling

10:06 cemerick: ha

10:07 dnolen: SLLCLL: do you mean the map fn? if so, if you're going for perf I would not use map, dotimes if you want some equivalent to a Java for loop.

10:07 gfrlog: cemerick: since it only holds in memory the primes up to the square root of whatever you're doing

10:07 cemerick: right; functionally constant space

10:08 gfrlog: yeah, until you get up into the septillions and such

10:08 SLLCLL: yeah seems that anything but extremely ugly implementations using just loop recurs is slow as hell

10:08 cemerick: gfrlog: you should update the post with a link to your github repo

10:09 oelewapperke: gfrlog: that code is still horribly slow here

10:09 gfrlog: oelewapperke: why can I not tab-complete your name?

10:10 oelewapperke: gravity: no clue ...

10:10 TimMc: gfrlog: worksforme

10:10 gfrlog: TimMc: and everybody else's name works for me

10:11 jarpiain: SLLCLL: there's a few more versions at http://groups.google.com/group/clojure/browse_thread/thread/c26922a0e3e99f69/

10:11 gfrlog: maybe my client has a hard-coded oelewapperke exception

10:11 oelewapperke: what did you test it on?

10:11 by which I mean what range, not what hardware

10:11 TimMc: java.lang.OelewapperkeException

10:12 gfrlog: yeah I've had to catch that one a few times

10:12 oelewapperke: gfrlog: my own machine

10:12 no offence but 3s for primes < 1000000 is horribly, horribly slow

10:12 gfrlog: oelewapperke: you did primes up to a million?

10:12 dnolen: SLLCLL: heh, quite subjective. Performance is a practical concern, you should expect practical solutions.

10:13 gfrlog: oelewapperke: like I said early, I was going for asymptotic behavior. So mine will go up to trillions and quadrillions, while the other implementations will run out of memory

10:13 s/early/earlier

10:13 sexpbot: <gfrlog> oelewapperke: like I said earlier, I was going for asymptotic behavior. So mine will go up to trillions and quadrillions, while the other implementations will run out of memory

10:14 gfrlog: different emphasis

10:15 oelewapperke: gravity: otoh it has this problem : http://xkcd.com/761

10:15 I mean gfrlog

10:15 mat1: Is there a way in clojure to mimic the behavior of ## from c macros?

10:15 gfrlog: oelewapperke: it's okay, I've gotten used to answering to gravity now

10:16 oelewapperke: given that all of this stuff is theoretical in the first place, I'm not sure what your criticism is

10:18 oelewapperke: gfrlog: I was kinda looking for an actual fast sieve implementation in clojure. To see how it's done

10:18 gfrlog: I'm starting to think there isn't any

10:18 dnolen: oelewapperke: I've been talking about how it can be done for quite a while now.

10:18 SLLCLL: well whatever you do it's still gonna be 10 times slower than java

10:19 dnolen: SLLCLL: doubtful.

10:19 gfrlog: which will be 3 times slower than C

10:19 cemerick: holy hell

10:19 SLLCLL: :)

10:19 nah java is only 1.4 times slower than C on average

10:19 cemerick: oelewapperke: what's "fast" for you?

10:20 gfrlog: people do not switch to clojure because it is faster than other things

10:20 SLLCLL: that's true

10:20 cemerick: gfrlog: sure it is: I can build X a whole lot faster in Clojure than in Java. ;-)

10:20 SLLCLL: but the reason I switched to java was because it wasn't too bad comapred to C++

10:20 oelewapperke: cemerick: it's about a million operations @ 2.6 ghz on my laptop ... so about 0.3s ?

10:20 gfrlog: cemerick: but...that's not clojure being faster

10:21 SLLCLL: when it was twice as slow it was acceptable

10:21 dnolen: gfrlog: that's not true, I certainly switched to Clojure because it was faster than the other dynamic langs, and the potential to get Java perf w/o all the headaches.

10:21 gfrlog: dnolen: I recant

10:21 SLLCLL: clojure unfortunately ( if you program idiomatically) is 4-200 times slower than java

10:21 gfrlog: some people switch to clojure because it is faster than other things

10:22 cemerick: gfrlog: "faster" is just as semantically dubious as "better"

10:22 gfrlog: cemerick: I object

10:22 fliebel: It'd be funny if languages did reverse-moore, getting half as fast every year.

10:22 SLLCLL: lisp is pretty fast

10:22 unfortunately it doesn't have java libraries

10:22 gfrlog: fliebel: and simultaneously development time does a reverse-reverse-moore?

10:23 cemerick: okay I updated it

10:24 cemerick: gfrlog: ah, fabulous

10:24 fliebel: gfrlog: I hope so :) Maybe we should just state something like this, and make it self fulfilling.

10:24 SLLCLL: my beef with clojure is that unless I hand optimize it, it's usually like 40 times slower than java

10:24 gfrlog: by 2030 all projects will be completed in under 1 second, and the mental effort involved will require resting for a decade

10:24 dnolen: SLLCLL: I often have large swaths of elegant Clojure code whose performance doesn't really matter, and other swaths of code that I beat into the ground until I see Java perf. Most languages don't afford both kinds of thinking.

10:25 gfrlog: My beef with Java is that even if I go way awkwardly out of my way to program in a functional style, it's still stupider than clojure

10:26 SLLCLL: I have yet to beat anything down to java perf

10:26 dnolen: SLLCLL: well you haven't been programming Clojure long enough to know how. Not surprising.

10:26 SLLCLL: my java code is good without any effort to think in terms of performance

10:27 I almost never have to refactor java code to gain performance

10:27 cemerick: This Java thing sounds pretty great. I should go check it out sometime.

10:28 SLLCLL: C# is better :P

10:28 dnolen: SLLCLL: but your Java code is not safe the way idiomatic Clojure code is either.

10:28 SLLCLL: that's true I suppose

10:29 klang: oelewapperke: http://fupeg.blogspot.com/2009/11/clojures-primes-shootout.html is the best sieve I've been able to find ..

10:29 SLLCLL: but for instance... a majority of lists I use never leave the method... so majority of the time thread-safety and non-mutability don't present an advantage

10:29 dnolen: SLLCLL: interoperability.

10:30 SLLCLL: most clojure core functions (map, filter, reduce) do lazy sequences which seem to be quite slow

10:30 dnolen: Clojure libraries have a greater ability to be shared w/o multithreading fears.

10:31 SLLCLL: lazy sequences aren't slow if you know what they're good for. mutually recursive algorithms being a good example.

10:31 cemerick: SLLCLL: seqs currently imply boxing, and ops over boxed numbers are slower than ops on primitives.

10:32 SLLCLL: so what should I emit? vectors, lists, seqences?

10:32 dnolen: SLLCLL: it easy to encode an aglorithm that would blow the stack in Java in a lazy-sequence, and it's going to be very fast.

10:33 cemerick: SLLCLL: You need to understand them, and use them appropriately. There's no blanket recommendation that can be reasonably made.

10:33 gfrlog: dnolen: I think any such algorithm you would do in java without using an explicit collection

10:33 ejackson: dnolen or technomancy: using the latest checkout and just running lein deps does create the native directory and calling (System/getProperty "java.library.path") yields "...../native/macosx/x86_64" correctly. However, when I try calling a function from the jar utilising the native lib I get a Cannot load JRI native library (NO_SOURCE_FILE:0). Any ideas what's wrong here ?

10:34 SLLCLL: if you have to know when to use them, why are they the default in some of the most used functions?

10:34 * gfrlog leans forward

10:34 SLLCLL: as gfrlog pointed out, in java you just do iteration and you don't blow stack

10:34 dnolen: SLLCLL: if you're not doing primitive stuff why not use them?

10:34 SLLCLL: ok

10:34 dnolen: SLLCLL: except iteration doesn't compose that well.

10:35 SLLCLL: that's true

10:35 my sieves that compose sequence operations were slow as hell though

10:35 slowest of them all

10:35 technomancy: ejackson: if you can put together a simple repro case opening an issue would be great.

10:35 ejackson: also: do you get the same thing with the native-deps plugin?

10:36 ejackson: technomancy: I'll check with naitve-deps plugin and come back to you.

10:36 gfrlog: SLLCLL: I think the idea is that most of the time slow is fine, and the code-safety/simplicity are a more valuable tradeoff

10:36 5% of the time you can speed it up enough with clojure tricks. the other 5% of the time you don't use clojure.

10:36 ejackson: technomancy: I'm attempting to bring this back to life: https://github.com/jolby/rincanter

10:38 dnolen: ejackson: and you actually have a native lib dir in your project after running native-deps ?

10:38 ejackson: dnolen: yeah, it has the .jnilib there (I checked)

10:39 dnolen: ejackson: hmm.

10:39 ejackson: dnolen - I need to install ant to get your native-deps plugin going, yeah ?

10:40 dnolen: SLLCLL: hmm didn't think so.

10:40 oops ejackson I mean.

10:41 ejackson: dnolen: dammit. with the plugin I get java.lang.NoSuchMethodError: org.apache.tools.ant.util.FileUtils.getFileUtils()Lorg/apache/tools/ant/util/FileUtils; (core.clj:1)

10:42 when I try invoke lein deps

10:42 dnolen: ejackson: what version of ant do u have?

10:43 ejackson: dnolen: Apache Ant(TM) version 1.8.2 compiled on February 28 2011

10:43 dnolen: ejackson: huh, same here. did you try with a different native project?

10:44 ejackson: nope, can you point me to one please ?

10:45 dnolen: ejackson: investigating w/ Penumbra

10:45 ejackson: i'll try too

10:47 technomancy: the version of ant installed by your package manager shouldn't ever be on the classpath

10:47 ejackson: try the plugin with lein 1.5 rather than the latest git

10:48 ejackson: technomancy: will do.

10:49 gfrlog: is ^:private the same thing as #^{:private true}?

10:49 ejackson: technomancy: same issue with the plugin. lein-stable version is

10:49 Leiningen 1.5.0 on Java 1.6.0_24 Java HotSpot(TM) 64-Bit Server VM

10:49 dnolen: ejackson: Penumbra works w/ native-deps 0.5 just fine.

10:49 ejackson: how are you testing rincanter?

10:50 ejackson: git clone .....

10:50 lein deps

10:50 lein test

10:50 (after updating the project.clj to 1.2.0)

10:51 dnolen: huh, is github down for anyone else?

10:51 ejackson: yup, its just vanished on me

10:52 fliebel: nope

10:52 ejackson: actually. now back

10:53 fliebel: sweet, I just redid a piece of clojure written when 1.2 was a snapshot. Everything is so much simpler now.

10:57 ejackson: dnolen: updating that project.clj file to more current stuff: https://gist.github.com/962673

10:57 fliebel: Is there anything sweet outside old contrib for command line arguments?

10:58 chouser: fliebel: maybe something nice in javaland?

10:58 ejackson: then running lein-stable native-deps invokes your plugin, but the native dir is not created

10:58 technomancy: java people have this nasty habit of expecting a single dash before full-word arguments.

11:01 dnolen: ejackson: something else is pulling in ant, that's the problem.

11:01 ejackson: dnolen: aaah, gotcha !

11:01 dnolen: I removed autodoc from the dev-deps, and changed swank-clojure to 1.3.0

11:01 ejackson: dnolen: i dropped both

11:01 dnolen: rm -rf lib, and then lein deps, lein native-deps, which then works.

11:02 technomancy: autodoc is rather confused about what it needs to declare =\

11:02 fliebel: chouser: ah, jargs. What is this syntax about? I mean, the space. Parser.Option debug = something

11:02 ejackson: dnolen: can you lein test for me ?

11:02 dnolen: you need to erase lib, if ant is in there it breaks lein.

11:02 ejackson: ah ok, yeah I see the JRI bug now.

11:03 ejackson: dnolen: is your native dir populated ?=

11:04 dnolen: ejackson: yes, but I note that there is not JRI.jar in lib itself, that is suspect.

11:04 SLLCLL: how would I paralelize something in clojure

11:04 ejackson: dnolen: hmmm.....

11:04 SLLCLL: for instance earlier I had a seqence and I checked each number separately for being a prime, how would I check 8 numbers at the same time

11:05 dnolen: ejackson: oops, no I see it.

11:05 ejackson: if I use the git version of leiningen, and lein deps, I do get a JRI.jar

11:05 chouser: fliebel: I don't even know what you're talking about. :-)

11:06 SLLCLL: (defn primes [n] (filter prime? (range 3 (inc n)))) <- how can I paralelize running prime?

11:06 zippy314: I have ref of a has that generates a stack overflow when printed on the repl because it includes an item that points back to the top level ref. How can I override the printing behavior of the repl to get around this?

11:06 SLLCLL: I've tried pmap but it ended up using 2 cores out of 4

11:09 dnolen: ejackson: the rincanter code is a bit ... odd.

11:09 ejackson: dnolen: Do you think there is any charm for me to build JRI from source myself and see if I can make any headway.

11:09 dnolen: aaah.

11:10 zippy314: like this:

11:10 ,(let [z (ref {})] (dosync (alter z assoc :z z)))

11:10 clojurebot: {:z #<Ref@1bc6f41: {:z #<Ref@1bc6f41: {:z #}>}>}

11:11 zippy314: wow. On my repl (emacs slime to swank clojure) that throws a stack-overflow.

11:14 S11001001: zippy314: set *print-level*?

11:14 dnolen: ejackson: k, (System/loadLibrary "jri")

11:14 ejackson: Library not loaded: /Library/Frameworks/R.framework/Versions/2.10/Resources/lib/libR.dylib

11:15 it looks like its looking for that.

11:15 ejackson: aaaaah

11:15 is your R_HOME set ?

11:15 dnolen: ejackson: no, don't know anything about R really :)

11:15 ejackson: dnolen: ignore me, mine is and I get the same

11:16 dnolen: it's looking for 2.10, I see I have 2.12

11:16 ejackson: dnolen: aaaaaaaaaaaaaah

11:16 zippy314: S11001001: That does the trick! Thanks.

11:16 ejackson: me too

11:16 i'd JUST seen that :D

11:17 * ejackson proceeds to add horrendous symlinks and light the blue paper...

11:18 ejackson: dnolen: and that works.

11:18 dnolen: ejackson: nice.

11:18 ejackson: I'll see if I can find the hardcoded link

11:19 dnolen: thanks for you help on this, I really appreciate it

11:19 dnolen: ejackson: np, good to know it's not a native-deps thing.

11:19 ejackson: yes, I apologise for casting that shadow on its good name :)

11:19 dnolen: ha!

11:21 ejackson: now the question is where has the OA hidden the source for jriengine :)

11:22 * dnolen wonders if Clojure could somehow expose invokeDynamic to get the benefits of late binding so we can sanely add metadata to Java objects yet still delegate to them...

11:28 ogrim: Should libraries be licensed under the Eclipse Common Licence as Clojure is?

11:29 technomancy: ogrim: it isn't legally required or anything, but it's nice.

11:31 ogrim: technomancy: I'm pretty sure I've read it somewhere, but I cannot find any official recommandation :)

11:32 Fossi: it makes using things easier ofc

11:36 raek: ogrim: one thing to watch out for is that GPL:ed code can't be combined with EPL:ed code (the GPL does not allow it). LGPL should be fine though, I think.

11:37 ogrim: thanks a lot! I will probably be using the ECL for my masters project

12:57 seancorfield: mornin'

12:57 dnolen: SLLCLL: seive as fast as Java, https://gist.github.com/962877

12:57 and w/ some macro fu, it's not even all that ugly.

12:59 SLLCLL: will only work on 1.3.0 of course.

13:00 SLLCLL: actually I cheated, it's actually faster than Java because of my identical? check.

13:00 if that's removed, same perf as Java w/o long arithmetic.

13:00 sorry w/

13:03 * dnolen will one day tire of proving to people that Clojure is as fast Java, but not today

13:05 amalloy: dnolen: i plan to invent a product, and rather than actually implement it, just tell you it's slower than it would be in java

13:05 so don't change anytime soon

13:10 TimMc: dnolen: Even Clojure 1.2, passing around lots of primitives?

13:11 dnolen: TimMc: ?

13:11 fliebel: amalloy: Will your product be in amalloy-utils?

13:11 dnolen: TimMc: my gist would be tedious in 1.2, because of lack of *unchecked-math* and tedious type hinting.

13:12 TimMc: OK

13:14 amalloy: fliebel: yeah, and i'll start charging $20 per git clone so i can finally make some money on (insert future brilliant product here)

13:33 fliebel: Strange, how I would use a Java lib last updated in 2005, while hesitating to use anything Clojure from last year.

13:44 dysinger: CAKE!

13:44 dnolen: https://gist.github.com/962877, sieve updated with idiomatic use of areduce. I'm not sure how much more idiomatic this little fast snippet of Clojure could be.

13:44 pyr: hi guys, what would you say is the best way to schedule a serialised access to a possibly non thread safe object

13:44 i use agents for that

13:45 but i always get bugged by the fact that the agent's value is of no use

13:46 chouser: pyr: that's probably the best as of today. keep your eyes open for news about pods, though.

13:47 pyr: pods ?

13:47 a clojure 1.3 thing ?

13:49 fliebel: What about classic locking?

13:49 chouser: I thought pods where about transients, not about random unsafe mutable data.

13:50 amalloy: pyr: make the agent's value be the unsafe resource itself?

13:50 pyr: yeah, that's what i do :)

13:51 dnolen: fliebel: transients are unsafe mutable data they're not supposed to leak out of the construction site.

13:51 pyr: fliebel: sure

13:51 amalloy: (send agent #(doto % (.write 10)))

13:51 pyr: amalloy: yep

13:51 amalloy: it's a usage of agents recommended by JoC, so it gets my seal of approval

13:53 pyr: good to know

14:18 dnolen: huh, anybody tried to mess w/ InvokeDynamic on OpenJDK 7 OS X before?

14:28 technomancy: dnolen: headius had some links in his tweets, but it may have been a while back

14:28 dnolen: technomancy: funny enough I just came across one of his gists. Yeah looks like all the old InvokeDynamic stuff floating around on the web is not obsolete.

14:28 s/not/now

14:28 sexpbot: <dnolen> technomancy: funny enough I just came across one of his gists. Yeah looks like all the old InvokeDynamic stuff floating around on the web is now obsolete.

14:31 * fliebel can't find a templating language he likes

14:32 scottj: any libraries that take a date and give you one of those short descriptions like "a week ago" or "about 3 months ago"

14:33 don't see anything for that in clj-time or joda but might have missed something

14:33 fliebel: scottj: I suspect these are to case-specific to have a general implementation, but I'd love to be wrong.

14:34 I remember Twitter releasing a lot of their stuff lately, maybe there is something in there>

14:34 technomancy: scottj: isn't that often done client-side these days?

14:35 TimMc: technomancy: To allow caching?

14:35 technomancy: yeah, and I think if you do it client-side you can avoid storing TZ data as part of your account records?

14:35 scottj: technomancy: yeah I've seen js ones http://ejohn.org/blog/javascript-pretty-date/

14:35 amalloy: scottj: you could steal the one sexpbot uses

14:36 $seen rhickey

14:36 sexpbot: rhickey was last seen quitting 1 week and 2 days ago.

14:36 fliebel: I hoped you'd find one here: http://twitter.github.com/commons/apidocs/index.html#com.twitter.common.util.DateUtils

14:36 TimMc: technomancy: Well, intervals may be TZ-independent, but the client still has to make sure to use the same TZ as the provided dates.

14:38 dnolen: wow, InvokeDynamic was first mentioned by Gilad Bracha in fall 2005.

14:46 Raynes: scottj: https://github.com/cognitivedissonance/sexpbot/blob/master/src/sexpbot/utilities.clj For sexpbot's implementation. I worked really, really hard on... getting amalloy to write that for me. :>

15:02 fliebel: What is the preferred settings storage format? XML, Clojure, JSON, YAML?

15:05 hiredman: fliebel: support both clj and json together is pretty easy, and json provides nice interop with other tools

15:05 technomancy: depends on who's writing the settings

15:06 fliebel: me

15:06 technomancy: yeah, use clojure then

15:06 fliebel: But I also realized I already have email header style settings in another place, so it's proably going to be that.

15:06 code reuse ftw

15:08 hiredman: :(

15:08 technomancy: ,((comp clojure.java.io/read-string clojure.java.io/slurp clojure.java.io/resource) "clojure/test.clj")

15:08 clojurebot: java.lang.Exception: No such var: clojure.java.io/read-string

15:08 technomancy: oops

15:08 hiredman: use java properties then

15:09 technomancy: ,((comp read-string slurp clojure.java.io/resource) "clojure/test.clj") ;; <= re-use

15:09 clojurebot: java.lang.IllegalArgumentException: No implementation of method: :make-reader of protocol: #'clojure.java.io/IOFactory found for class: nil

15:09 technomancy: wat

15:09 wfm

15:10 amalloy: technomancy: jvm permissions. he can't open files

15:11 technomancy: security policy stuff?

15:11 amalloy: yeah

15:11 ,(.exists (java.io.File. "test"))

15:11 clojurebot: java.security.AccessControlException: access denied (java.io.FilePermission test read)

15:13 fliebel: hiredman: The properties thing sound like what I want. Now I just need to find a reader that can read up to an empty line.

15:15 hiredman: no, you need to read the javadocs

15:15 fliebel: :)

15:15 amalloy: java properties, really? sends shivers down my spine. if you want something that doesn't interop well you might as well use native clojure structures, which will be easy to work with

15:15 if you want something that interops well, use json. problem solved

15:15 fliebel: amalloy: I want something that goes nicely together with markdown.

15:17 amalloy: what. why would you want that. you want the user-facing and machine-friendly versions of your config file to be the same?

15:17 fliebel: it'll be like "title: blah \n tags: foo, bar \n\n # markdown #"

15:18 technomancy: amalloy: well I used resource in order to get at the file in the jar

15:23 ordnungswidrig: how can I detect how often a stm tx is retried?

15:33 amalloy: technomancy: fwiw i wouldn't expect resource permissions to be any more lax. ssl private certs could be stored in the jar, for example, so if you aren't trusted to read files you probably shouldn't read jars either

15:33 Lemur13: is there some way I could merge sorted sequences

15:34 for instance (1 8 10 34) + (2 4 6 9 10 22) = (1 2 4 6 8 9 10 22 34)

15:34 technomancy: (doc into)

15:34 clojurebot: "([to from]); Returns a new coll consisting of to-coll with all of the items of from-coll conjoined."

15:35 amalloy: Lemur13: sounds like you want just the merge half of a merge-sort

15:35 Lemur13: yes

15:35 also eliminating doubles

15:35 duplicates

15:35 amalloy: uh, then something that is not a merge-sort at all :P

15:35 Lemur13: :D

15:35 well I can make a fn I guess

15:36 amalloy: Lemur13: you can maintain a sorted-set

15:36 if you can avoid doing the work of sorting the second sequence elsewhere, and move that effort to the sorted-set, it should be at least as efficient as sorting then merging

15:37 Lemur13: the sequence is pre-sorted

15:41 fliebel: Okay, Clojure settings it'll be.

15:43 Lemur13: Check merge* for the merge part of a merg-sort https://gist.github.com/951553

15:44 Lemur13: btw

15:44 is using peek and pop on sequences ok

15:44 or should I be always using first and rest

15:44 fliebel: &(peek (list 1 2 3))

15:45 sexpbot: ⟹ 1

15:45 chouser: peek/pop don't work on seqs, but using them on lists is perfectly ok

15:45 fliebel: First and rest are the way to go for lists.

15:45 * chouser squares off

15:46 fliebel: squares? ( I was kind of surprised to see that pee work)

15:46 *peek

15:47 chouser: fliebel: peek/pop use the (probably somewhat misnamed) IPersistentStack interface, which is explicitly supported by lists, queues, and vectors

15:48 fliebel: Oh, right. And PersistentQueues also implement the lis thing, right? I found this in clojureatlast the other day.

15:49 chouser: I believe we have a little chart in "joy" to help you choose

15:49 ,(pop ())

15:49 clojurebot: java.lang.IllegalStateException: Can't pop empty list

15:49 chouser: ,(rest ())

15:49 clojurebot: ()

15:49 chouser: etc

15:50 fliebel: Uhm, the book is in my reading queue :)

15:50 chouser: :-)

16:04 arohner: technomancy: are there any clever solutions for lein projects that have both regular dependencies and dev-dependencies?

16:04 markoman_: how can i convert "67" string to long?

16:05 cemerick: ,(Long/parseLong "67")

16:05 clojurebot: 67

16:05 cemerick: markoman_: ^

16:05 technomancy: arohner: I played with the notion of letting dev-dependencies inject code into the project process. too clever and not obvious though.

16:06 markoman_: thanks :)

16:07 arohner: technomancy: thanks. I'll keep thinking about it. I have a lein plugin (to daemonize a process) that needs to call code in the runtime child. In my case, it might not be too bad to just jam the code in eval-in-project's init section

16:07 technomancy: arohner: you could take it from the commit before I removed it from lein if you feel like taking a walk on the crazy side =)

16:08 https://github.com/technomancy/leiningen/commit/f8831ed80f3982b67d44e048541ca238e3b6c9fe

16:09 arohner: technomancy: interesting. a simpler solution for me would allow a dev-dependency to create an additional normal dependency. or vice-versa

16:09 if I could do that, a normal lein deps would fix my issues

16:09 technomancy: :both-dependencies? heh.

16:10 if it's just clojure code that needs sharing and you know there's not chance of collision, that inject code may be feasible.

16:10 scottj: Are war files/servlets not supposed to start up long-running threads for cron-like jobs (reporting, polling, sending updates)? Adding a future to an init method on a servlet causes tomcat to complain about vars not being freed and tomcat quickly runs out of memory, not sure if separate threads not tied to responding to http requests have to be put in separate app.

16:10 technomancy: I don't want to include it in lein because the chances of collision are too high

16:11 S11001001: scottj: due to unloading/reloading the webapp?

16:13 scottj: S11001001: I think I experience even on the first load.

16:14 mefesto: scottj: is it a permgen error?

16:14 scottj: mefesto: yeah

16:14 mefesto: scottj: on jboss i've had some trouble with that and had to increase the perm size

16:14 scottj: clojure creates many classes which eat up perm mem

16:15 scottj: S11001001: do you know what happens to a running future when an app gets reloaded?

16:15 tomoj: lolwtfbbq https://gist.github.com/eb2f4c6b6daaff8c4bb4

16:15 relevant bit: https://gist.github.com/f8f1e3c6e06b2f1d0d6a

16:15 scottj: mefesto: so it's fine to have a servlet start up several background threads for various tasks not responding to requests?

16:16 mefesto: and is init method the place to do it?

16:16 mefesto: scottj: not sure. i believe the springframework uses a job scheduler called quartz which does something like that

16:16 S11001001: scottj: no idea, but it's easy to clean them up manually in a servletcontextlistener that calls shutdown-agents

16:16 mefesto: but i don't really know so i don't want to lead you down the wrong path

16:17 tomoj: oh.. is that one of the things they fixed in 1.2.1, I hope, desperately?

16:19 hiredman: mefesto: evaling code (actually compiling) is the only thing that generates classes, so unless you are doing that, which seems unlikely

16:20 tomoj: yes indeed :D

16:21 mefesto: hiredman: just a guess. expanding the perm size fixed the issue for me

16:22 hiredman: some containers like tomcat have known issues with permgen size

16:23 mefesto: yeah, especially if your app uses hibernate which a lot of java webapps do

16:30 scottj: this thread might be of interest: http://groups.google.com/group/clojure/browse_thread/thread/b9e64ea3807b6c58/8703ddceb307ec0a?lnk=gst&q=permgen#8703ddceb307ec0a

16:39 hiredman: im confused. when does compiling *not* happen in clojure?

16:40 hiredman: mefesto: it doesn't happen at runtime

16:40 it happens at most once per compilation unit, unless the compilation unit does something like call eval

16:40 mefesto: hiredman: isn't it compiled to bytecode at runtime unless explicitly aot'd?

16:40 hiredman: once

16:41 technomancy: yo dawg, &c.

16:41 hiredman: so (def a (fn [a] ...)) that function is compile once, and (a) just runs the compiled function, and (a) runs the compiled function again

16:41 mefesto: hiredman: right, that is what i thought

16:46 micahmartin: technomancy: Any more thoughts on putting recent Leiningen releases on Clojars?

16:47 gfrlog: does ring parse query params, or is that done by jetty?

16:47 technomancy: micahmartin: no, I haven't thought through the implications of turning leiningen into a library

16:47 micahmartin: gfrlog: Jetty does the querystring parsing

16:48 gfrlog: ah hah. kay thanks.

16:48 technomancy: I'm still not sure why you don't leave the parts that need to be in leiningen in the plugin

16:48 micahmartin: technomancy: If there's no harm in it... I could really use a recent release.

16:49 Well, I think they are still in the plugin... but when running my plugin through the shell wrapper, leiningen isn't in the classpath.

16:50 technomancy: can't the shell wrapper just call lein for some tasks?

16:51 micahmartin: Yeah... and pay the price of two JVM boots

16:51 technomancy: not if the shell wrapper just has a list of which tasks go to which tool

16:51 micahmartin: But what's more... I can't test my code that uses leiningen stuff... cuz the existing library is out of date.

16:51 technomancy: that's how it handles rlwrap right now

16:51 that's what :eval-in-leiningen is for

16:52 micahmartin: Do you mean I should edit the shell wrapper script?

16:53 I guess I need to research :eval-in-leiningen...

16:53 technomancy: sure, the shell wrapper can dispatch plugin tasks to the plugin and non-plugin tasks to your own tool.

16:54 tufflax: I want to make a game. I've read a few times about developing with the application running, and that it's the lisp way to do things. That sounds good but how do I actually do it? The repls I've used blocks while computing stuff. I mean, do set it up "manually" using two threads or is there some kind of standard?

16:54 s/blocks/block

16:54 sexpbot: <tufflax> I want to make a game. I've read a few times about developing with the application running, and that it's the lisp way to do things. That sounds good but how do I actually do it? The repls I've used block while computing stuff. I mean, do set it up "manually" using two threads or is there some kind of standard?

16:58 micahmartin: technomancy: The shell wrapper it generated... is there a simple way to specify use a custom shell script?

16:58 S11001001: tufflax: that's usually the easiest, though it depends on how easy it is for you to start your stuff from the repl

16:58 arohner: technomancy: why is the handler argument to eval-in-project deprecated? is there any other way to modify the Java object before it's run?

16:59 micahmartin: Also... this still doesn't answer the need to unit test my code that uses leiningen.

16:59 tufflax: S11001001 you mean 2 threads?

17:01 S11001001: tufflax: yeah

17:02 I mean, you've got a main function, maybe that sits in a UI loop, so instead of (main-) say (future (main-)) at the repl

17:02 but if you're trying to test a webapp inside of tomcat proper, for example, then that's something entirely different

17:04 technomancy: micahmartin: yeah, sure; lemme see

17:04 tufflax: S11001001: OK. thank you!

17:05 technomancy: micahmartin: it's :shell-wrapper {:bin "bin/foo"}, which gets called with format, so put %s %s in for the classpath and -main namespace.

17:07 arohner: the only use I knew for altering the Java object was to change the classpath. did you have something else in mind?

17:08 arohner: technomancy: yes, I want to call (.setSpawn java true). Let me see if that works, first

17:10 micahmartin: technomancy: cool thanks. What about testing my code? Anyone who's building a plugin has got to be in the same situation.

17:10 ... can't unit test code that uses leiningen directly.

17:12 technomancy: micahmartin: testing plugins with :eval-in-leiningen has worked well for me

17:14 is that not working?

17:14 micahmartin: I haven't tried it because it I typically don't run tests using lein command

17:15 technomancy: it will also make repls and swank sessions run in the lein process

17:22 lnostdal: hi guys.. is the latest swank-clojure (from git) known to work with the latest slime (also from git)?

17:24 technomancy: lnostdal: known to not work

17:24 lnostdal: ok, thanks

17:28 micahmartin: technomany: Looking at Leiningen source code... I think I see where you're going with :eval-in-leiningen... I'm gonna mull this over during my commute home.

17:29 * technomancy wonders if the needs of the technomany outweigh the needs of the technofew

17:35 pjstadig: technoutilitarian!

17:35 lnostdal: downgrading slime at the moment, but perhaps emacs is too new also? .. i'm using 24.0.50.1

17:36 technomancy: lnostdal: that's what I'm on. it's the version of slime that it's picky about; see the swank-clojure readme

17:38 lnostdal: i can't see anything specific about slime version there, i think .. just that it should be newer than the one usually provided by distros

17:38 rcg: technomancy: "... or the technoone" - technospock is always right

17:38 scnr

17:39 technomancy: rcg: but of course

17:39 lnostdal: the version you want is on marmalade-repo.org, or you can look on my github fork of slime if you want to do it by hand.

17:41 lnostdal: technomancy, your repo works .. awesome; thank you ..... :) .. (i like knowing what the hecks going on; so just git and simple non-auto-type tools to begin with)

17:42 technomancy: sure, suit yourself

18:06 arohner: technomancy: (.setSpawn java true) works (on OSX and linux at least). Should I just use handler, or would you like a different patch for eval-in-project?

19:11 _Vi: When I use "(use 'my.namespace :reload-all)" second time (after changing the source) in "lein repl" it fails to output error message if there is error. How to get the error message?

19:24 dnolen: new blog post: Lispers know the value of everything and the cost of nothing, http://dosync.posterous.com/lispers-know-the-value-of-everything-and-the

19:24 KirinDave_: Void style.

19:25 * hiredman wrote an emacs mode to display the ouput of javap when opening a class file

19:26 hiredman: it makes me feel like I have a handle on the cost of things, until I look at the macro expansion of the logging macros from contrib logging

19:44 seancorfield: bay area clojure user group tonight - who's going?

19:50 hiredman: I have a test run that will take from now till the heat death of the universe, so not going anywhere in seattle, let a lone in the bay

19:51 Derander: hiredman: you are one hour from me

20:06 carllerche: What do people do when editing java files? Do you jump to an IDE or use emacs? (the java mode seems to be pretty bad)

20:06 hiredman: why would I edit java files?

20:08 carllerche: i still have java I need to use and don't feel like rewriting it in clojure yet

20:32 zrilak: I can't Java in Emacs, seriously. Java requires much more information on screen than what I can get from Emacs, and CEDET etc. don't even come close to what you get in modern, mature IDEs, let alone refactorings. Java is just like that, it wants heavy scaffolding around the code.

20:33 justinlilly: zrilak: if you find an acceptable solution, I'd give you money.

20:33 zrilak: Actually I'm doing pretty fine in IntelliJ IDEA + La Closure -- just a few percent of what Emacs does, but enough for comfortable work

20:33 justinlilly: not sure how much.. but definitely some.

20:34 zrilak: A solution to what exactly? :)

20:35 justinlilly: I want eclipse/intellij for emacs, basically.

20:35 zrilak: eh.

20:35 oh hey, how about Emacs for IDEA? That might be doable

20:35 justinlilly: actually eclipse has a reasonable emacs mode

20:35 zrilak: better than IDEA's, in fact

20:36 justinlilly: yep. emacs+ is what its called. 3rd party.

20:36 zrilak: yeah, it even supports marks, IIRC

20:36 and kill ring

20:37 justinlilly: yep. Still not the same though. Totally lacks the ability to write a little function to do some repetitive task.

20:38 zrilak: the solution is easy

20:38 rewrite Emacs in Clojure i.p.o. ELisp, and hook it up to Eclipse/IDEA's windowing system instead. O:-)

20:39 oh, and assign extra meta keys for all those IDE-specific bindings

20:39 hiredman: I opened intellij the other day, saw it opened class files, never having written elisp before I wrote a mode and hook for file loading that opened a buffer with the javap output when you open a class file in emacs

20:40 the hook took about an hour, the mode (syntax hilighting) took a few days to figure out

20:40 zrilak: sounds cool

20:40 hiredman: https://github.com/hiredman/javap-mode/blob/master/javap.el

20:41 http://www.thelastcitadel.com/images/javap-mode.png

20:41 in intellij you just get method signatures when you open a class file

20:42 zrilak: obligatory "I like the color theme"

21:03 dnolen: hiredman: that javap.el thing is pretty cool.

21:03 hiredman: thanks, I am very proud of it given it is my first elisp :)

21:18 joshua__: Hey, what is infinity in Clojure?

21:19 tomoj: a double?

21:20 is that a trick question?

21:20 Raynes: &Double/POSITIVE_INFINITY

21:20 sexpbot: ⟹ Infinity

21:20 Raynes: joshua__: ^

21:20 joshua__: Raynes, Thanks

21:21 tomoj, Nope. I thought there was a Clojure specific Infinity.. =/

21:22 tomoj: huh, didn't realize that prints unreadably

21:22 er.. unevalably?

21:23 ..readably but wrongly

21:23 dnolen: &Float/POSITIVE_INFINITY

21:23 sexpbot: ⟹ Infinity

21:26 Dumas: =

Logging service provided by n01se.net