#clojure log - Oct 01 2010

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

0:00 hiredman: I started working on getting it easier to run but, uh, haven't gotten anywhere with it

0:01 the way I run it is from a repl (require 'hiredman.clojurebot)

0:02 amalloy: heh, i meant a sarcasm highlight; getting clojurebot running is too ambitious for me

0:02 i just want to learn how to play with him better

0:03 so far i've found *dispatchers*. i can't be that far from finding out what commands he accepts

0:04 hiredman: the commands all live inside files in src/hiredman/clojurebot/

0:04 amalloy: yeah, i'm seeing that

0:04 hiredman: ~scala 1+1

0:04 amalloy: slight bug at line 269 of core.clj, btw

0:04 clojurebot: how much do you knot?

0:04 clojurebot: I know 638 things

0:05 hiredman: oh, hah

0:05 well

0:07 amalloy: i'm not sure i get the regex at 270 either

0:07 (5+10)

0:08 clojurebot: (5+10)

0:08 clojurebot: excusez-moi

0:08 amalloy: anyway, thanks. i'll clone it and look around for add-dispatch-hook

0:09 clojurebot: (5 + 10)

0:09 clojurebot: 5 (for large values of 2)

0:25 TeXnomancy: hiredman: what kind of stuff did you get working in the subclassloader?

0:26 this is what I get testing clojure-http-client: http://p.hagelb.org/subclassloader-test-http.html

0:26 probably not a great test as it involves a lot of contrib stuff I guess

0:29 hiredman: just the lein tests I guess

0:30 TeXnomancy: I added in a (.printStackTrace t) in the catch in eval-in-project and now I get java.lang.ClassNotFoundException: clojure.test

0:31 hiredman: huh

0:31 TeXnomancy: also: is there a reason you set the bootclasspath of the subclassloader to the same value as the parent?

0:31 hiredman: maybe I should go back to the drawing board

0:31 TeXnomancy: seems like that could cause issues with clojure version mismatches

0:32 hiredman: uh, are you putting clojure on the bootclasspath?

0:32 TeXnomancy: yeah, to speed JVM boot

0:32 hiredman: it's because those are the classes used to boot the jvm, so presumably they are needed

0:33 cais2002: clojurebot: lunch time now

0:33 clojurebot: what time is it?

0:33 TeXnomancy: hiredman: oh... right; that's a quirk of Apple's repackaging of the JVM

0:33 hiredman: I would think that sax parser is in a jar somewhere on the bootclasspath

0:33 cais2002: clojurebot: lunch time

0:33 clojurebot: execution timeout is 10 seconds

0:34 cais2002: clojurebot: that's too short for most human

0:34 clojurebot: Titim gan éirí ort.

0:34 TeXnomancy: hiredman: actually the sax exception was what I got with some screwing around of my own; if I reset back to what you had then I get clojure.test not found in lein's tests as well as clojure-http-client

0:35 if I drop the bootclasspath I get the sax exception in http but not in lein

0:35 probably because of contrib usage in the former

0:35 so we probably want to set the bootclasspath to everything except clojure

0:37 hmm; didn't realize the bootclasspath was so heavily populated

0:38 I don't remember quite what the quirk was with OS X's bootclasspath, but there were some issues about aqua gui stuff failing somehow related to the bootclasspath

0:38 dan might remember

0:39 hiredman: also: what's with the pr-str/read-string roundtrip?

0:40 hiredman: java.lang.IllegalAccessError: class sun.reflect.GeneratedMethodAccessor9 cannot access its superclass sun.reflect.MethodAccessorImpl (lancet.clj:118)

0:40 fun

0:40 TeXnomancy: because inside the classloader the classes for things that are not java.* should be "different"

0:41 TeXnomancy: gotcha

0:41 hiredman: putting in a require of clojure.test got rid of the classnotfoundexception

0:43 TeXnomancy: hiredman: oh duh... the old version uses clojure.main -i @clojure/test.clj

0:43 which obviously won't work here

0:43 * TeXnomancy facepalms

0:43 hiredman: ah, well

0:47 TeXnomancy: bugger; because everything's wrapped in a binding we can't rely on the special-casing of top-level do where you can require and use a var in the same form =\

0:47 weak sauce special case

0:50 scottj: If you want some code to run only when your app is first started, not whenever you reload your code (interactive dev), is there a better way than (defvar run-on-start-only (do ....)) ?

0:50 hiredman: sun. may need to be added to list of classes allowed through

0:51 TeXnomancy: progress; getting java.lang.IllegalAccessError: class sun.reflect.GeneratedMethodAccessor10 cannot access its superclass sun.reflect.MethodAccessorImpl, compiling:(NO_SOURCE_FILE:0)

0:51 scottj: defonce is my weapon-of-choice for that

0:51 hiredman: pushed updated classloader branch

0:52 hiredman: expected: nil actual: java.lang.LinkageError: loader constraint violation: when resolving method "clojure.core$memoize$fn__4542.<init>(Lclojure/lang/IPersistentMap;Ljava/lang/Object;Ljava/la

0:52 ng/Object;)V" the class loader (instance of java/net/URLClassLoader) of the current class, clojure/core$memoize, and the class loader (instance of <bootloader>) for resolved clas

0:52 whoops

0:52 ok

0:52 will take a look

0:52 TeXnomancy: ended up taking advantage of the do trick by taking an optional init form for eval-in-project

0:53 "the do trick" being what Laurent described in the "Evaling forms that require" thread on the mailing list

0:53 which I am tempted to call "The Steve Gilardi problem" but will not. =)

0:55 hiredman: "The Gilardi Senario"

0:58 TeXnomancy: that's actually much better

1:00 hiredman: ugh, so what I think is happen is clojure's reflector is trying to reflect on a class via java's reflection, but java's reflection knows nothing about it because it's not visible

1:00 happening

1:00 that may nix the whole dog and pony show

1:01 TeXnomancy: not the ponies!

1:11 maybe I should start paying attention to what people are saying about osgi

1:12 but I can't really make head or tail of anything I've read about osgi... not even sure what it is.

1:12 kinda like asdf

1:12 duncanm: hmm

1:12 la la la

1:13 i'm looking into the combinatorics package, but i'm looking for a way to get all 'cycles' of a sequence

1:14 like, [0 1 2 3] could be [0 1 2 3] [1 2 3 0] [2 3 0 1] [3 0 1 2]

1:14 TeXnomancy: when I read about OSGi it's kind of like the last panel of http://achewood.com/index.php?date=08022002

1:17 duncanm: worst possible way: (set (repeatedly 1000 #(shuffle [0 1 2 3])))

1:17 thanks, I'll be here all week

1:18 amalloy: ,(let [list [0 1 2 3]] (map #(take 4 %) (take 4 (iterate #(drop 1) list))))

1:18 clojurebot: java.lang.RuntimeException: java.lang.RuntimeException: java.lang.IllegalArgumentException: Wrong number of args (1) passed to: sandbox$eval8345$fn

1:18 amalloy: grr

1:19 ,(let [list [0 1 2 3]] (map #(take 4 %) (take 4 (iterate #(drop 1 %) (cycle list)))))

1:19 clojurebot: ((0 1 2 3) (1 2 3 0) (2 3 0 1) (3 0 1 2))

1:19 duncanm: here's a way

1:19 (defn all-cycles [s] (for [i (count s)] (take (count s) (drop i (cycle s)))))

1:20 TeXnomancy: mine's shorter

1:20 amalloy: hah

1:20 duncanm: amalloy: mine's similar to yours, but i think it's a bit simpler?

1:20 amalloy: duncanm: your way is better

1:21 i always forget that (for) exists

1:21 TeXnomancy: you want (range s), not (count s)

1:21 duncanm: TeXnomancy: oh right

1:21 TeXnomancy: err--(range (count s))

1:22 clojurebot: for?

1:22 clojurebot: for is not a loop

1:22 amalloy: er what? i think he's assuming s is a seq

1:22 TeXnomancy: clojurebot: I thought for was underused.

1:22 clojurebot: No entiendo

1:22 TeXnomancy: clojurebot: your dumb

1:22 clojurebot: Excuse me?

1:22 amalloy: clojurebot: (5 + 8)

1:22 clojurebot: Pardon?

1:22 TeXnomancy: just kidding!

1:23 amalloy: aw man. he gave the best answer ever earlier

1:24 TeXnomancy: clojurebot: the best knock-knock joke is <reply>Oh, I know the best knock-knock joke! It goes like this... OK, you go first:

1:24 clojurebot: In Ordnung

1:38 ashleyw: Hi, can somebody help me with this please: http://pastie.org/1192755 I've tried to :exclude (spit) to no avail. What am I doing wrong?

1:40 ossareh: ashleyw: use require instead.

1:43 ashleyw: ossareh: thanks!

1:45 ossareh: :-3 )

2:01 lenw: morning all - just looking for some advice - need to persist stuff to a db and not entirely keen on doing all the low level sql - contrib sql style - is clj-record a good alternative or is there something better ?

2:04 ashleyw: Everything seems to be in order (as per the duck-streams api), but I'm getting an error on this: http://pastie.org/1192776

2:06 raek: ashleyw: for prefix lists, use parentheses

2:06 you also need to use :use, if you want to use reader without namespace qualification

2:07 since 1.2, much of the duck-streams features has been moved to clojure.java.io

2:07 http://clojure.github.com/clojure/clojure.java.io-api.html

2:08 :require only loads the lib, but do not "refer" it. (i.e. you still need to call the functions with the full namespace: clojure.contrib.duck-streams/reader)

2:10 (ns server.core (:gen-class) (:use (clojure.contrib server-socket duck-streams)))

2:11 also, there should be parenthesis around the use :use ... things

2:11 ashleyw: Okay, but see above to my question 30 mins ago, how do I refer to the lib without having that conflict error?

2:11 raek: you should only get a warning

2:12 but the answer is: use clojure.java.io instead

2:12 spit has moved into core, reader has moved into clojure.java.io

2:13 but if you really want to use c.c.duck-streams, (:use (clojure.contrib server-socket [duck-streams :only [reader]])) is more ideomatic

2:14 ashleyw: or :only [reader writer]?

2:14 or :only (reader writer)

2:14 raek: exclude is used in the same way

2:15 hrm, maybe the round parens are actually more ideomatic there

2:15 both works, I think, but the latter is what clojure.org/libs uses

2:16 so you should probably go for that

2:19 ashleyw: thanks, everything works now :D Also could you have a quick look at this please and tell me if I've got anything seriously wrong syntax-wise: http://pastie.org/1192791

2:20 (it's the first thing I've written totally on my own…)

2:36 raek: ashleyw: looks good :)

2:37 sandGorgon: ashleyw, I think apply should be changed to reduce to be more idiomatic. in this case + is a special case that can consume any number of arguments, so it doesnt matter. so (apply + (1 2 3 4 5)) is (+ 1 2 3 4 5). But if you had a function that could ONLY consume two arguments then reduce would give u the equivalent of (+(+(+ (+ 1 2)3)4)5)

2:37 raek: you might want to look at 'for' as a replacement for 'map' + anon fn

2:39 LauJensen: Good morning! :)

2:43 sandGorgon: .

2:44 lypanov: wazzzup LauJensen

2:46 ashleyw: raek + sandGorgon: thanks. Reduce definitely seems to be the better option as you said sandGorgon. :)

2:53 sandGorgon: so like this? http://pastie.org/1192824

2:59 LauJensen: Ah, Euler detected

2:59 ashleyw: That looks like proper use of reduce

3:00 (reduce + (filter #(or (zero? (mod % 5)) (zero? (mod % 3))) (range 10)))

3:01 I think something like is also worth considering, because it expresses the nature of the problem clearly, you have a list, you need a subset, then the sum

3:01 But its a matter of taste, both reads naturally

3:04 ashleyw: Cool. But what's happening with (mod % 5), where's it getting the % from?

3:05 LauJensen: #() takes an argument called %

3:05 Its just syntactic sugar

3:06 ashleyw: Ah...where can I find more info on #()?

3:06 LauJensen: #() = (fn [%] ())

3:07 ashleyw: That simple, huh, cool :)

3:19 hsaliak: hi , does anyone know if remvee's clj-android is still up to date and working? The reason I ask is that the github page still asks people to use the fork of clojure when 1.2 now works perfectly fine on eclair and froyo

3:36 AWizzArd: Moin moin

3:44 esj: allo

3:53 scottj: another month, another arch screenshot thread. included some clojure promo material in mine: https://bbs.archlinux.org/viewtopic.php?pid=834004#p834004

4:08 zmila: ,(map #([%]) (range 3))

4:08 clojurebot: java.lang.IllegalArgumentException: Wrong number of args (0) passed to: PersistentVector

4:09 zmila: ,(map (fn [x] [x]) (range 3)

4:09 clojurebot: EOF while reading

4:09 zmila: ,(map (fn [x] [x]) (range 3))

4:09 clojurebot: ([0] [1] [2])

4:09 bartj: zmila, you are missing an argument

4:09 zmila, you can type faster than me :)

4:09 zmila, gah, I meant a paren

4:09 zmila: copy-pasting not typing :)

4:10 i wonder, why i can't use #([%]) in map

4:12 bartj: , (map #(conj [] %) (range 3))

4:12 clojurebot: ([0] [1] [2])

4:12 scottj: bc (fn [x] [x]) != #([%]), it equals #(vector %)

4:14 AWizzArd: zmila: it gets translated from (map #([%]) (range 5)) into (map (fn [x] ([x])) (range 5))

4:14 You try to call the function [%]

4:15 Clojures vectors *can* be called, but this is a different issue, and not what you want.

4:15 you want:

4:15 ,(map vector (range 5))

4:15 clojurebot: ([0] [1] [2] [3] [4])

4:15 zmila: ,(map #(vector %) (range 3))

4:15 clojurebot: ([0] [1] [2])

4:16 zmila: oh, yes! even simpler ^)

4:16 AWizzArd: the #() is not needed, you can directly pass in the fn itself

4:16 zmila: i see


4:16 thx

4:16 AWizzArd: ,(map vector (range 5) [10 20 30 40])

4:16 clojurebot: ([0 10] [1 20] [2 30] [3 40])

4:34 lypanov: whats the "richest" web thingy for clojure?

4:34 i'm used to rails.

4:34 scottj: conjure

4:35 compojure/ring/moustache are more popular, but they're sinatra like

4:46 lypanov: scottj: know of anything mustache like?

4:47 (for templating)

4:47 ah

4:47 ignore. enlive is better.

4:48 raek: enlive rocks.

4:48 bobo_: indeed

4:48 raek: Ring + Moustache + Enlive is my favourite combo

4:49 AWizzArd: So, you want to generate html?

4:49 lypanov: raek: thats what i'm looking at also

4:49 raek: are there any tuts on that combo?

4:51 raek: well, there's this http://github.com/swannodette/enlive-tutorial and the ones by LauJensen on http://www.bestinclass.dk/blog.html

4:51 I like Moustache because it is easy to compose routes in an hierarchial way

4:53 also, http://moustache.cgrand.net/syntax.html is neat

4:54 esj: yes, its very tidy indeed.

4:54 raek: it is a library with very clear boundaries

5:02 _na_ka_na_: ,(get {(long 15} :found} 15)

5:02 clojurebot: Unmatched delimiter: }

5:03 _na_ka_na_: ,(get {(long 15) :found} 15)

5:03 clojurebot: nil

5:03 _na_ka_na_: guys I'm confused by the map behavior

5:03 see

5:03 http://gist.github.com/605953

5:04 somewhere in my code the key is getting converted to Long

5:04 and if I try to find it i cant

5:05 ,(get {(long 15) :found} (long 15))

5:05 clojurebot: :found

5:05 _na_ka_na_: do i need to convert everything to long ?

5:06 ,(= 15 (long 15))

5:06 clojurebot: true

5:07 _na_ka_na_: ,(get {(long 15) :found} 15)

5:07 clojurebot: nil

5:07 _na_ka_na_: anyone?

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

5:07 raek: the 1.3 branch is supposed to fix this problem, but I don't know what the best way to solve it in 1.2 is...

5:07 _na_ka_na_: is it a bug?

5:08 raek: there should be discussions about this in the google group

5:08 well

5:08 it is an unfortunate consequence of how things work currently, if I have understood things correctly

5:09 jlr: is this on the 1.3 snapshot?

5:09 oh raek's got it

5:09 _na_ka_na_: i'm sure this will lead to a lot of subtle bugs in 1.2 :(

5:09 i mean people who use 1.2

5:10 raek: there used to be branches called num, equal and equiv. I think I heard that they got merged into 1.3

5:10 jlr: there's a good explanation about the behaviour, looking for it

5:11 http://dev.clojure.org/display/doc/Enhanced+Primitive+Support

5:14 raek: I think the new 1.3 behaviour will be to make numbers longs by default

5:16 cais2002: hi guys, is there an existing function that does this (split-by #(= 0 (mod %1 3)) [1 2 3 4 5 6]) => ((1 2 4 5) (3 6))

5:16 jlr: _na_ka_na_: specifically re: maps look down in that link under heading "Objective - normalize arithmetic semantics between boxed and primitive numbers", it says hash maps and sets now use = for keys, and right above talks about the new behaviour (including "all long-or-smaller integers are boxed as long"

5:17 clojurebot: ant clean and rebuild contrib

5:18 mrBliss: ,(clojure.contrib.seq-utils/separate #(zero? (mod %1 3)) [1 2 3 4 5 6])

5:18 clojurebot: [(3 6) (1 2 4 5)]

5:19 mrBliss: cais2002: ^^

5:19 cais2002: mrBliss: looks good, thanks

5:42 rrc7cz: one of the things I love about strictly typed languages like Haskell and Scala is the Maybe/Option type that forces callers to deal explicitly with nonexistance as a return value. Are there any tricks to enforce a similar caller constraint in Clojure?

5:45 design by contract a la post conditions helps deal with protecting against nonexistance as a return value, but it doesn't enforce anything on the caller in cases where you want to return nil. The only thing I could think of was making my own Maybe type, then adding a type hint in my fn defs. Has anyone done anything like this?

5:46 mrBliss: rrc7cz: clojure has nice support for preconditions (but you probably knew this already) http://blog.fogus.me/2009/12/21/clojures-pre-and-post/

5:48 rrc7cz: mrBliss: yeah, I actually found out about them before they were in the documentation because I posted a Stackoverflow question about design by contract in Clojure. Finding out there was native support for it was awesome

5:49 mrBliss: i'm actually a huge fan (and user) of DbC in Java and Clojure, but as I mentioned, this doesn't actually enforce callers to deal with nonexistence (nils) as return values; it only restricts the domain of valid function IO

5:51 mrBliss: rrc7cz: I think enforcing callers to deal with nils is quite problematic in a dynamic language.

5:53 raek: one common way is to return nil when given nil (if that makes sense for that function)

5:53 rrc7cz: mrBliss: on the other hand, so are NPEs. I think there needs to be a balance.. I can imagine a public API layer requiring more enforcement than perhaps internals, which might get away with pre/post to spot bugs

5:54 raek: but how does that enforce the caller deal with nil return values instead of blowing up with an NPE?

5:54 raek: hrm, I see your point...

5:55 (also, 'fnil' is an interesting function)

5:57 rrc7cz: raek: i didn't know about fnil. You're right, it does look very interesting.. thanks for the tip

5:57 raek: but it doesn't help with enforing constraints on the caller...

5:57 which, as mrBliss said, probably isn't possible in Clojure

5:58 but fnil is a cool way to "patch" a function that can't handle nils

5:58 rrc7cz: raek: well, I think it's possible, just not native. By that I mean I can make my own Maybe type, then type hint the return type of my fns as Maybe

5:58 AWizzArd: Since when is Java 6 Update 22 out?

6:00 rrc7cz: but how can you type hint a return value? it's easy on parameters, but I don't see in the docs how to do this on a return value. Perhaps it would be part of 1.3's ^:static stuff?

6:01 raek: I think I recall that it hasn't been possible before

6:01 there was something about putting the metadata on the param vector

6:02 rrc7cz: raek: yeah, I don't see it listed as supported. I guess in that case you guys are right: there's no way to enforce the caller to handle nils

6:02 mrBliss: type hints don't enforce anything, except when used on static functions like you mentioned. (If I remember correctly)

6:02 raek: hrm, maybe that was for #"def(type|record)"

6:23 quizme: when i do "lein deps" ring 2.0 gets installed. to install ring 3.0, would I have to upgrade leingingen? "lein upgrade" ?

6:25 mrBliss: quizme: change the version number of ring in your dependencies (project.clj file)

6:25 quizme: ohhh

6:25 kk

6:25 thanks

6:27 that's brilliant

6:58 cemerick: Raynes: double queen rooms are sorta standard :-)

7:03 esj: cemerick: coming to the US for the first that was really unexpected.

7:03 "but I only need half of half of that !"

7:03 cemerick: esj: In general, we think along the lines of "How much space is there? OK, I'll use all of it!" ;-)

7:04 _na_ka_na_: what contrib jar do i use with clojure-1.3.0-alpha1 ?

7:04 cemerick: esj: coming to the US from....?

7:04 esj: and there is so much space to go around.

7:04 cemerick: in my case the UK via SA.

7:04 rrc7cz: esj: I got you beat, I'm coming all the way from Prague ;-)

7:04 esj: bah, SA via the UK

7:05 rrc7cz: South Africa ?

7:05 rrc7cz: Czech Republic

7:05 esj: so I don't have you beat; I thought you were coming from UK

7:05 SA would be much farther to fly

7:05 esj: rrc7cz: hehe.

7:05 rrc7cz: hell of a hike :-)

7:06 esj: it would be a lot of fun though

7:07 cemerick: I'll have to add nationality to the next State of Clojure survey

7:08 _na_ka_na_: presumably there's a clojure-contrib-1.3.0-alpha1?

7:09 esj: cemerick: naaah - nationality is as outmoded as mutability :)

7:11 cemerick: esj: You, sir, are ahead of your time.

7:11 And probably overly optimistic, but that's good. :-)

7:34 _na_ka_na_: cemerick: lein fails to download it

7:35 cemerick: it fails with an exception trace

7:39 cemerick: _na_ka_na_: looks like there may not be an alpha-1 contrib: http://build.clojure.org/snapshots/org/clojure/contrib/complete/

7:39 Try 1.3.0-SNAPSHOT, and see how you fare.

7:52 _na_ka_na_: cemerick: thanks for the tip, i'll try that .. I tried to build from master. . but it failed :(

7:53 no even SNAPSHOT fails

7:54 cemerick: _na_ka_na_: can you paste your project.clj?

7:54 along with the stack trace

7:54 _na_ka_na_: (defproject temp "" :dependencies [[org.clojure/clojure "1.3.0-alpha1"] [org.clojure/clojure-contrib "1.3.0-SNAPSHOT"]])

7:56 cemerick: [org.clojure.contrib/complete "1.3.0-SNAPSHOT"]

7:59 _na_ka_na_: cemerick: even that fails .. http://gist.github.com/606104

8:01 narkisr: Good morning (night etc..), is there a way to exit repl when using lein interactive?

8:01 _na_ka_na_: cemerick: I think this is working org.clojure.contrib/complete "1.3.0-alpha1"

8:01 narkisr: Iv tried C-D and C-C

8:01 (System/exit 0) not working either

8:03 _na_ka_na_: cemerick: no, even org.clojure.contrib/complete "1.3.0-alpha1" fails

8:12 cemerick: oh, complete is a pom, not a jar

8:15 That doesn't seem right at all.

8:18 abrenk: org.clojure.contrib/complete "1.3.0-SNAPSHOT" should work

8:19 just browse http://build.clojure.org/snapshots/org/clojure/ and have a look what's there

8:28 okay, the snapshot repo seems to have a defunct maven-metadata.xml

8:28 it specifies build 42 as the most recent one but that isn't really there

8:30 http://twitter.com/stuartsierra/status/25436736752

8:32 specifying a classifier "bin" works

8:34 [org.clojure.contrib/complete "1.3.0-SNAPSHOT" :classifier "bin"]

8:35 cemerick: Perhaps the notion of "complete" contrib should be dropped entirely. It's already large, and going to get larger.

8:35 AWizzArd: It would be great if the single jars could be offered in one big zip, in one folder.

8:35 Currently that complete .zip includes all the jars, but in funny folders.

8:35 abrenk: should be okay if it's just a pom having dependencies on all the other, small libs

8:36 AWizzArd: I need a script to flatten that folder structure, so I can put clojure-contrib/* on my CP.

8:36 abrenk: AWizzArd: mvn dependency:copy-dependencies

8:36 AWizzArd: abrenk: what is the command for Ant? :)

8:36 No Maven here.

8:37 abrenk: I feared so...

8:37 cemerick: AWizzArd: still no network either?

8:37 AWizzArd: I don't find it good to offer Contrib in a Maven-friendly .zip only. It would be helpful to have a basic version, just the plain .jar files.

8:37 abrenk: And I have to admit that to figure out how to get to the complete jar you'd have to know maven pretty good

8:37 cemerick: well, that could be made trivially simple

8:37 AWizzArd: Also Contrib should not be Ant or Ivy specific, or have a Leiningen specific format, or one for Gradle.

8:38 cemerick: I wouldn't doubt that it's complex to warn people off of wanting the full boat

8:38 (which *no one* uses)

8:38 abrenk: is stuart still working to get the build right?

8:38 LauJensen: Zzzz, is the #maven? :)

8:39 abrenk: and is there like a google docs document listing all the needs and wishes?

8:39 AWizzArd: The full Contrib would be nice, as it can be CPed with a * placeholder

8:39 cemerick: He's the one who's on point last I knew, though the scope of the modularization is being explanded AFAIK.

8:39 abrenk: I understand all the complains about maven like the discussion yesterday...

8:40 ...but I think if everything would just be working fine for everyone there wouldn't be any complains

8:40 I'd be willing to take a shot at the build process on my machine

8:40 cemerick: Things are in flux. 1.3.0 is decidedly not in a released state. Pain should be expected.

8:41 abrenk: if only to realise that indeed it's not fixable ;-)

8:42 AWizzArd: When starting my repl from an ant task it is okay to include all of Contrib in the CP, and also during compilation. Only during the jar stage I will specify exactly which jars to put into my Überjar.

8:47 abrenk: would be nice if these requirements and nice-to-have's were listed somewhere. I mean we have for osgi and nrepl etc. why not for the build-related stuff?

9:18 cemerick: the osgi notes are there because I saw a lot of people working on the problem alone

9:18 the nrepl notes are there because that's a fundamentally political problem, not a technical one

9:19 build processes are a tricky thing -- adding another cook to the kitchen makes things very difficult, if not impossible

9:19 abrenk: ^^ If you'd like to help, I'd suggest offering it on the clojure-dev list, and see what SS says.

9:23 chouser: I just found myself thinking: "maybe the style of solution we've discussed for nrepl would work for build too"

9:24 cemerick: chouser: did you catch the upshot from last night's discussion?

9:24 chouser: "pom.xml is canonical, but a simplified tool could be used to build clojure and/or contrib for our needs without all the steps"

9:24 cemerick: ah, maybe not. will read.

9:24 "so if I could just understand maven well enough to see what parts could be reused, and which could be left out ..."

9:25 ^^^somebody shoot me

9:25 cemerick: chouser: you're scaring the shit out of me this morning though :-)

9:25 LauJensen: chouser: who were you quoting?

9:25 chouser: LauJensen: my own crazy crazy thoughts

9:25 LauJensen: hehe

9:26 Had a good nights sleep? You dont quite seem yourself this morning

9:26 * esj reaches for his flak jacket.

9:26 * cemerick is always comforted by the fact that *other* people bring up build issues

9:27 chouser: actually, I'm rather sick, though better than yesterday

9:27 stuartsierra: Maven is like theodicy. You try to take just a piece and eventually realize it's inescapable

9:27 cemerick: chouser: maven is definitionally modular. It doesn't know how to do a `clean` or even talk about dependencies without plugins for such things.

9:27 chouser: stuartsierra: like a prison

9:28 fogus_: more like the gulag

9:28 stuartsierra: but with more output

9:29 esj: "you can check-in any time you like, but you can NEVER build"

9:30 oh dear, that was even worse that I thought :(

9:30 LauJensen: hehe, no it was funny :)

9:31 lpetit: "trying to make money with open source leads to legacy open source"

9:33 esj: lpetit: somebody tell facebook.

9:34 LauJensen: esj: face..what? ooh you mean that legacy app? :)

9:34 esj: only my granny uses THAT now

9:34 lpetit: ?

9:35 I escaped the facebook hype from the beginning. Am I a looser ?

9:35 :)

9:35 LauJensen: lpetit: If you are, then we both are ... which is likely I guess :)

9:35 esj: lpetit: far from it.

9:40 cmiles74: I coded up a stomp parser, if anyone has a moment I'd really be thankful for any feedback on my implementation. :)

9:40 http://github.com/cmiles74/clj-stomp/blob/master/src/com/nervestaple/stomp/common.clj

9:42 chouser: cemerick: ok, read up on nrepl

9:42 stuartsierra: where is nrepl, by the way?

9:42 lpetit: nREPL on github

9:42 cemerick: stuartsierra: http://github.com/cemerick/nREPL, with notes linked at the bottom of the readme

9:43 stuartsierra: cool, thanks

9:43 LauJensen: cmiles74: That looks like an attempt at imperative programming in Clojure. If you ask me there are 15 excessive swap!s and some odd constructs like (if (not (and (not (and (....)))...

9:44 chouser: cemerick: do you want to allow for ides that have sent a partial expr (from the user's "repl" window) still be able to execute commands necessary for autocomplete and such?

9:44 stuartsierra: cemerick: It's a plain java.net.ServerSocket?

9:44 cemerick: stuartsierra: as of now, yes

9:44 stuartsierra: ok

9:45 cmiles74: LauJensen: This is the first parser I've codd in Clojure. I don't want to use regular expressions bumt still need to build up the frame components...

9:45 lpetit: cmiles74, LauJensen: there certainly is a smell , just by counting the nbr of ! / lines of code

9:45 cemerick: chouser: a tool that provides for autocomplete would presumably have code that searches available vars and matches against a partial string -- not simply sending partial expressions....?

9:46 cmiles74: The other thing I tried was emitting a sequence of characters and a symbol to denote what part of the frame it bleonged to, then assembling those. But in that case I loose the lazy rendering of the body.

9:46 LauJensen: cmiles74: You're using atoms to build lists, which is something we always try to do functionally, like (reduce conj '() [1 2 3]), where instead you do (reduce #(swap! some-global %) [] .....)

9:46 chouser: cemerick: yeah, I was afraid my description was too weak. ok, more words...

9:47 cemerick: chouser, stuartsierra: I'm currently working on a final decision re: stomp. I'm leaning towards pushing on that for now, at least until a clojure stomp client and broker are available in a quasi-stable state.

9:47 Raynes: Functions should never get that long.

9:47 Ever.

9:47 chouser: would an IDE that supports autocomplete perhaps have some code on the server side (or perhaps send such code as needed) to look up available namespaces, vars, class methods, etc.?

9:48 LauJensen: Raynes: well, sometimes they should

9:48 chouser: sending something like (autocomple-options-for "split-")

9:48 Raynes: LauJensen: When?

9:48 chouser: and expecting a nice readable vector of strings in return

9:48 LauJensen: ~source for

9:48 lpetit: LauJensen: hmmm, good idea for a heuristic for a warning in ccw : ratio of ! at the end of symbols per lines of code, and if threshold reach => publicity for conjlabs if user located in europe. Are you with me ? :)

9:48 cmiles74: Does anyone know of a recursive descent parser coded in Clojure that takes a different tactic?

9:48 LauJensen: ~source doseq

9:48 Raynes: Just to mentioned a few examples coded by Rich himself

9:49 cemerick: chouser: yes; the thought is that there will be (a) some standard tooling helpers that would be available for all in a separate project, and (b) in general, tools will check for/load in whatever code they need for their functionality as soon as they connect to a new repl.

9:49 lpetit: chouse:r definitely

9:49 chouser: ^^

9:49 LauJensen: lpetit: Thats a sweet idea - Could you do a little popup with a link to conj-labs.eu if you detect a code smell? :D

9:49 Raynes: The Clojure coding standards on the assembla wiki explicitly mention that you shouldn't write functions as long as doseq.

9:49 LauJensen: Raynes: Do you think Rich is ignorant of the standards?

9:49 chouser: cemerick, lpetit: ok, good.

9:49 so, then...

9:49 lpetit: LauJensen: yeah. Now let's talk financers :)

9:50 LauJensen: lpetit: cemerick will pay you once you get to the US, now implement!

9:50 cemerick: heh

9:50 Raynes: I'm sure he had a part in writing them. I don't remember there ever being a message sent out that doseq is a canonical example of a well-written macro that would be nice to see.

9:50 lpetit: ahah

9:50 stuartsierra: cmiles74: The JSON parser in contrib is an example of a recursive-descent parser in Clojure

9:50 chouser: is it likely such an IDE might also have a repl pane where user's input is sent line-at-a-time such that it can support interactive behavior like (println :got (read-line))

9:51 lpetit: but definitely, this could be seen as a feature. User assistance

9:51 LauJensen: Raynes: "Never" means "Not ever". Here's a case where Rich broke your rule, ie your rule is both broken and crushed.

9:51 Raynes: It isn't my rule, and that macro was written long before those standards were ever thought of.

9:51 LauJensen: Raynes: Just give it up, Rich has code-killed your argument

9:51 Raynes: I imagine that clojure.core is a little different.

9:51 cemerick: chouser: I'm also pondering my *in*/*out* approach. It's a tricky little bastard.

9:51 chouser: you can blame doseq on me. I something like doubled its size.

9:52 Raynes: You're a bad troll. :\

9:52 cemerick: I firmly believe (read) is a red herring.

9:52 LauJensen: cemerick: Whats a red herring?

9:52 chouser: hm

9:52 cemerick: If you're using nrepl, then you're using a tool.

9:52 Thus, it can either check for a complete expression before sending, or require ctrl-enter or whatever to force a send.

9:53 Either way, I feel like that's a UI issue.

9:53 chouser: cemerick: you think interactive use of *in* doesn't need to be supported

9:53 ?

9:53 cemerick: I wouldn't go that far.

9:53 chouser: oh

9:53 cemerick: I think it's a 1% case that will end up complicating my implementation significantly.

9:53 0.0001%, perhaps.

9:54 I've yet to see any real code that (read)s from stdin that isn't a repl itself.

9:54 * cemerick waits for the exceptions to prove the rule to start pouring in

9:55 lpetit: cemerick: probably everybody which writes unix admin tools in java and likes to go for coffee everytime he launches one

9:55 * lpetit exits the romm

9:55 lpetit: s/romm/room

9:55 chouser: LauJensen: http://lmgtfy.com/?q=wikipedia+red+herring

9:56 LauJensen: chouser: I've already googled it, but thanks for being a wannabe

9:56 lpetit: We french guys currently and definitely seem to have a problem with romm(s) (ahah)

9:56 sorry

9:56 chouser: cemerick: (read) is one thing, (read-line) is something else.

9:56 cemerick: really?

9:56 LauJensen: chouser: and (read-lines) is something else entirely again

9:57 cemerick: (read-line) pulling from stdin screams "command line tool" to me, which is a non sequitur w.r.t. nREPL, no?

9:57 chouser: well, isn't that exactly the kind of thing cake is up to

9:58 [disclaimer: I have yet to use *any* of the tools nrepl is meant to replace.]

9:58 cemerick: Yeah -- which ninjudd and I have butted heads over already.

9:59 This is all sorta moot, insofar as I'll (very, very reluctantly) support *in* anyway

9:59 stuartsierra: What would stdin mean in a remote context anyway?

10:00 chouser: *in* on the remote server would be connected to something like *in* on the client? why not?

10:00 cemerick: stuartsierra: binding *in* to a PipedReader that had content shoved into it from follow-on messages coming from the connected client.

10:00 chouser: what he said

10:00 stuartsierra: hm, ok

10:00 cemerick: Just the thought of it just screams "WRONG" to me, but…

10:01 Raynes: I'm so happy I never decided to write anything like that.

10:01 stuartsierra: Anybody had this problem with Ring: ...

10:02 A handler throws an exception...

10:02 Which gets caught by wrap-stacktrace...

10:02 Which throws a NullPointerException...

10:02 Which hides the original exception?

10:02 Raynes: I think I have.

10:02 stuartsierra: I'm trying to make a test case but failing so far.

10:02 Raynes: I don't remember how.

10:03 stuartsierra: One problem I know is that wrap-stacktrace only catches java.lang.Exception, not java.lang.Throwable

10:04 But I think the NullPointerException is actually in clojure.stacktrace, and therefore my fault.

10:06 clojure.stacktrace/print-trace-element applies a regex to the class name in a StackTraceElement

10:06 Which will throw NullPointerException if the class name is null...

10:06 Which is theoretically impossible, but I swear I've seen it happen.

10:09 cemerick: chouser: was it you that was talking with Rich about the difficulties of separating expressions-requiring-discrete-responses from random content on *in*?

10:10 chouser: cemerick: possibly, yeah.

10:10 LauJensen: stuartsierra: shouldnt that be a pre-condition of print-trace-element then, that the class is non null ?

10:11 chouser: I believe I was raising concerns and he was asserting it was possible.

10:11 * cemerick needs a minority report-esque UI to the #clojure logs

10:11 stuartsierra: LauJensen: StackTraceElement claims the "class" field can never be null.

10:12 LauJensen: stuartsierra: Even still?

10:12 chouser: I wonder if anyone's done research on topic classification of english text with IRC-post-sized pieces.

10:12 stuartsierra: LauJensen: what do you mean?

10:12 chouser: I'd love to have auto-threading or topic grouping of IRC logs

10:12 cemerick: chouser: that sounds absolutely delicious

10:12 chouser: but intermingled conversations, non-sequitors, etc. strike me as overwhelmingly difficult to deal with.

10:13 stuartsierra: chouser: Yeah, what does "lol" refer to? :)

10:13 esj: chouser: ouch ! dejumbling the multiple concurrent conversations active at one time would be a nightmare !

10:13 LauJensen: stuartsierra: In practical terms it is already a pre-condition, just one you dont think will happen. If you add it as an explicit :pre condition, you'll have lost nothing but gained certainty next time (if) it breaks

10:13 stuartsierra: I think that will have to wait for strong A.I.

10:13 chouser: then again I wouldn't have guessed unsupervised part-of-speech tagging was possible at all, let alone in 300 line of Clojure.

10:13 cemerick: given timestamps and handle references, I'll bet a little bayesian training would go a *long* way

10:14 LauJensen: chouser: I know of one such system, but Im afraid its proprietary

10:14 chouser: stuartsierra: exactly. though, in that particular case it may not matter much.

10:14 stuartsierra: LauJensen: I can avoid the error just by calling `str`, but I'm trying to find a case where that field can be null as an example.

10:14 cemerick: LauJensen: Dude: http://aria42.com/blog/?p=48

10:15 I get the sense that Aria's a beast -- and he's coming to UMass next year. :-)

10:15 esj: impressed: Gibbs samplers et al.

10:16 chouser: cemerick: so I guess if every message from the client has a unique id, the repl server can tag each return-value response with the input-message-id that triggered the eval

10:16 LauJensen: cemerick: wow, that'll take a while to consume

10:17 chouser: cemerick: that could be many-to-many if the client were undisciplined

10:21 LauJensen: Are the 1.3 snapshot artifacts ready to go with static functions?

10:24 stuartsierra: LauJensen: as far as I know, yes

10:24 LauJensen: kthx

10:26 cemerick: stuartsierra: You asked about serversocket earlier -- feel free to toss any protocol/transport comments over the wall.

10:27 stuartsierra: none yet

10:27 I want to explore Netty and/or other NIO frameworks

10:27 although you could probably drive the whole thing over a message queue library

10:28 cemerick: Yeah, that's been in the hopper :-)

10:29 I need to wait on that front until there's a e.g. clojure stomp client and broker ready to use.

10:29 That's one yak too far for me right now.

10:30 When they appear (in a CA-suitable way), I'll move.

10:30 stuartsierra: Why STOMP in particular?

10:30 esj: cemerick: I've been playing today with Jim Duey's conduit.rabbitmq and its super easy.

10:30 cemerick: stuartsierra: AFAICT, it's the most widely-supported, in terms of clients.

10:30 LauJensen: esj: cemerick doesn't buy into 'easy', he wants 'big' and 'enterprise'

10:30 stuartsierra: ah

10:31 esj: you two boys !

10:31 cemerick: also simple enough to have a pure clojure impl

10:31 chouser: actually, the opposite in this case.

10:31 cemerick: LauJensen: bollocks

10:31 LauJensen: cemerick: sorry :|

10:31 cemerick: esj: I need to keep the dependencies down in this context.

10:31 chouser: though rhickey didn't like my analogy

10:31 esj: cemerick: no worries, just thought it mention its awesomeness.

10:32 cemerick: Thanks for the tip; I'm thankfully not touching any MQs anymore these days aside from my abuse of couchdb. :-)

10:34 LauJensen: which contrib artifact goes with org.clojure/clojure "1.3.0-master-SNAPSHOT" ?

10:36 oh... no single contrib artifact anymore

10:36 cemerick: chouser: where can I find this ansi terminal wonkery you have for coloring stuff?

10:37 stuartsierra: LauJensen: there's a "complete" jar but it doesn't work as a dependency yet

10:37 LauJensen: stuartsierra: any timeframe for when that will be up ?

10:38 stuartsierra: as soon as somebody figures out how to make it work ;)

10:38 cemerick: stuartsierra: Oh?

10:38 stuartsierra: cemerick: In the modularized contrib build, there's a "complete

10:38 "complete" module that depends on every other module.

10:39 cemerick: right, but that's a pom

10:39 stuartsierra: But it doesn't work as a Maven/Leiningen dependency. Can't figure out why.

10:39 LauJensen: stuartsierra: I thought you were the go to guy ?

10:39 stuartsierra: LauJensen; I was and I failed utterly.

10:39 LauJensen: stuartsierra: ah ok. How about we restart and try accomplishing it with Cake instead?

10:39 stuartsierra: what's Cake?

10:40 LauJensen: stuartsierra: Its a new build system, a little similar to lein on the outside, but has a different task system and its now based on Ivy instead of Maven (almost)

10:40 Also supports a persistent JVM and its totally cross platform

10:40 stuartsierra: Hm. I'm suspicious of anything that deviates from the Maven model.

10:41 But anyone is welcome to give it a shot.

10:41 We might end up splitting contrib into separate repositories anyway.

10:41 LauJensen: hehe

10:42 AWizzArd: Ah, hi stuartsierra. I did not follow the discussion, but earlier today I mentioned that it would be great if there were a .zip of Contrib, that just contains all .jar files, in a flat folder.

10:43 That would make it more friendly for other systems than Maven.

10:43 stuartsierra: yeah, that's doable in the current Maven setup, just needs implementing

10:43 AWizzArd: Currently when I download the .zip I need to run through a script that copies/moves out the jars into a folder that I can CP with the * placeholder.

10:44 stuartsierra: when you say that Contrib might be split into separate repos, do you then mean "real repos" or just branches of the current one?

10:44 stuartsierra: real repos

10:44 hugod: It would also be nice to have a source jar for clojure, so slime could jump to java source from stack traces

10:45 stuartsierra: Just an idea; no planning yet.

10:45 LauJensen: You're suspecious of anything that deviates from the Maven model which has failed you so horribly?

10:45 stuartsierra: Yes. :)

10:45 I love my abuser.

10:45 LauJensen: stuartsierra: Are you cemericks cousin or something? :)

10:45 stuartsierra: No, we're just both cantankerous north-east elitists. :)

10:46 LauJensen: hehe

10:46 AWizzArd: Btw, I noticed that most jars contain plain .clj files. I have no problem with that, I just wondered why it is not AOTed .class files.

10:46 stuartsierra: AWizzArd: binary-compatibility

10:46 cemerick: stuartsierra: I'd say we're pragmatists, but OK.

10:46 stuartsierra: heh

10:47 AWizzArt; AOT-compiling means the JARs only work on the version of Clojure they wre compiled with.

10:48 But seriously, Maven made the modularized contrib build *possible*. I wouldn't have attempted it with anything else.

10:48 But it's still too big and unweildy, so I want to split it up further.

10:49 chouser: cemerick: http://gist.github.com/606301

10:50 AWizzArd: Is it that it depends on the *version* of Clojure, or is it even the concrete clojure.jar that makes the contrib jars incompatible when AOTed?

10:50 cemerick: yikes

10:50 LauJensen: AWizzArd: the concrete jar

10:51 AWizzArd: LauJensen: mama mia, that is indeed problematic then.

10:51 chouser: cemerick: too much \033 for you? :-)

10:51 AWizzArd: LauJensen: Do you know why that is so?

10:51 cemerick: chouser: INSANITY

10:51 stuartsierra: Not necessarily the concrete JAR, but anytime the Clojure compiler changes, it breaks AOT-compiled classes

10:51 chouser: cemerick: try it though -- it's pretty

10:51 LauJensen: Ah, Clojure is catching up: http://www.google.com/trends?q=python%2C+clojure&ctab=0&geo=all&date=all&sort=0

10:51 AWizzArd: ok

10:51 LauJensen: AWizzArd: No

10:51 stuartsierra: This was a big problem going from 1.0 to 1.1, but may still be a problem with newer releases.

10:52 chouser: LauJensen: "Python eats Australian family dog" "23-foot python found basking in sun" "Monty Python Reunion! Monty Python Reunion! Monty Python Reunion!"

10:52 stuartsierra: Uncompiled Clojure source code is more resilient to changes in the compiler.

10:52 LauJensen: chouser: I think you meant that for twitter :)

10:52 AWizzArd: stuartsierra: yes, that I understand

10:52 cemerick: chouser: I'm sure it is. I just prefer (.setStyleRange some-text-area-widget style-obj-to-make-text-red)

10:53 fogus_: http://www.google.com/trends?q=python+programming,+clojure&ctab=0&geo=all&date=all&sort=0

10:53 AWizzArd: I just thought that even if just one tiny bit changed in the clojure.jar that AOTed contrib is incompatible then.

10:53 chouser: cemerick: heh, ok.

10:53 stuartsierra: AWizzArd: I don't think it's quite that bad.

10:53 AWizzArd: good :)

10:53 chouser: I have a version with prettier source code -- sets some constants so I can do like #(println RED % NORMAL)

10:54 cemerick: chouser: Are there many like you? (i.e. people that use cmd line repls semi-exclusively)

10:54 AWizzArd: stuartsierra: btw, do you know a bit about Clojures DynamicClassLoader?

10:54 stuartsierra: a very little bit

10:54 chouser: ...but it's part of a larger thing for work, so shouldn't share

10:54 AWizzArd: ok

10:55 cemerick: *ahem* http://www.indeed.com/jobtrends?q=scala%2Cclojure%2Cpython&l=

10:55 AWizzArd: Because there is potentially an implication for using Clojure to program Applets or Web Start Apps when Contrib contains .clj files.

10:55 cemerick: buzz is a leading indicator, but nothing real on its own

10:55 chouser: cemerick: beats me. I wonder if it would work with emacs inferior mode or whatever that's called.

10:56 LauJensen: Which lein-swank artifact goes with clojure-1.3 ?

10:57 chouser: cemerick: if there are others like me, they probably keep quiet to avoid ridicule.

10:57 cemerick: chouser: Would it make sense for me to make nrepl's main emit such codes on any unix?

10:57 screw it, fly that flag

10:58 chouser: cemerick: most commands that can generate ansi color codes only do so optionally, so that would probably be best.

10:58 AWizzArd: ~max people

10:58 clojurebot: max people is 313

10:58 chouser: does anyone know how many people have registered for clojure-conj so far?

10:59 cemerick: chouser: lots

10:59 chouser: stuartsierra: you're our mole in corporate HQ, right? Heard anything?

10:59 cemerick: excellent. :-)

11:00 stuarthalloway: 155

11:00 stuartsierra: And I'm not physically in corporate HQ most of the time, so I don't have the latest gossip.

11:00 stuarthalloway: stuartsierra: it's on the f**ing radiator :-)

11:00 cemerick: oh, and I thought the number was hush-hush for some reason

11:00 stuartsierra: stuarthalloway: whatever ... ;)

11:00 so did I

11:00 cemerick: Now I have one less reason to bug stuartsierra :-P

11:01 stuarthalloway: I just asked big boss Alan if it was a secret and he said no

11:01 cemerick: stuartsierra: are you still in NYC?

11:01 stuartsierra: yes

11:01 chouser: gonna be fun

11:01 cemerick: I had no idea -- thought you had moved.

11:01 stuartsierra: I would have rung you up two weeks ago had I known.

11:02 chouser: you'll make it for more than one day? ;-)

11:02 chouser: already been there once in a dream, but there were only about a dozen people. rhickey gave me stern advice, peering over spectacles.

11:02 cemerick: and here I had wagered 265

11:02 This is why I don't bet on games or horses.

11:03 LauJensen: chouser: "peering over spectacles" ?

11:03 chouser: cemerick: oh yeah, I'm all over this one.

11:03 cemerick: Excellent.

11:03 (said in proper Burnsian affect)

11:03 with*

11:04 LauJensen: it's his default position: http://farm4.static.flickr.com/3229/2613013337_ecc41f4123_o.jpg

11:04 :-D

11:04 chouser: heh, yeah, something like that.

11:06 stuartsierra: stuarthalloway: Just added a bug on clojure-dev

11:07 abrenk: stuartsierra: doesn't [org.clojure.contrib/complete "1.3.0-SNAPSHOT" :classifier "bin"] work as a lein dependency for the "complete" artifact

11:07 stuartsierra: not correctly

11:07 It downloads all the individual module JARs *and* the "complete" uberjar.

11:07 abrenk: stuartsierra: as I said earlier: I'd be willing to give it a try to fix the maven build

11:08 stuartsierra: go for it

11:08 abrenk: is there a list of requirements?

11:08 stuartsierra: make it work :)

11:08 well, ok...

11:08 LauJensen: cemerick: ah, thanks for clearing that up :)

11:08 stuartsierra: - must be able to build/deploy all modules with 1 command

11:09 abrenk: okay, I'll just have a go at it and flex my maven muscles and maybe write some stuff down while at it

11:09 stuartsierra: - must be able to depend on a single module to get all of contrib

11:09 - should build a complete uberjar for non-maven-aware environments

11:09 point 2 is currently the problem

11:10 abrenk: Thanks. I'll take a look at it.

11:11 cemerick: stuartsierra: did you try shade?

11:11 stuartsierra: cemerick: no, not yet

11:11 cemerick: that's what will get you point 2 cleanly

11:12 i.e. without carrying along the submodule dependencies themselves for downstream projects

11:13 stuartsierra: hm.

11:13 abrenk: stuartsierra: at the moment a classifier=bin dependency only pulls down the single "complete" jar

11:14 stuartsierra: What I hoped was that depending on a module with <packaging>pom</packaging> would get you all of its transitive deps without trying to download its jar.

11:14 cemerick: nope

11:14 pom artifacts can only ever be parents

11:14 stuartsierra: oh. Wish I'd known that.

11:14 cemerick: or, they can be dependencies, but that's a no-op

11:14 (effectively)

11:14 abrenk: but looking at the snapshot repo it seems wrong that build 41 is just a pom and build 42 is just a jar.

11:18 stuartsierra: abrenk: I made a lot of mistakes, flailing aroudn trying to get 1.3.0-alpha1 out the door.

11:19 slyrus_: fogus_: the lisp interpreter aside, the html layout on lithp is brilliant

11:20 fogus_: slyrus_: It's not mine. It's generated by a tool named Pycco

11:20 slyrus_: ah, ok. still, it makes me want that for all of my code.

11:22 fogus_: slyrus_: Indeed

11:23 abrenk: stuartsierra: the build is started by hudson? what's the mvn command line that is run?

11:24 stuartsierra: abrenk: mvn --fail-at-end clean install

11:24 abrenk: thanks

11:25 stuartsierra: stuarthalloway: BTW something broke clojure.contrib.jmx at Clojure commit cc8372f12074b4cccbdd9cde3cfacfae069c57d3

11:26 http://build.clojure.org/job/clojure-contrib/218/org.clojure.contrib$jmx/console

11:26 AWizzArd: A nice read: http://norvig.com/lispy.html

11:33 cemerick: chouser: a decent half-feature would be for the logs to add a class attr to every <p> containing the handle's name, with a filter input field fixed at the bottom of the page.

11:33 chouser: cemerick: so as to see posts only from one user?

11:33 cemerick: ~3 lines of jquery, sorta-kinda threading

11:33 clojurebot: Gabh mo leithscéal?

11:34 cemerick: or many, e.g. "cemerick,chouser,rhickey,ninjudd" in my case right now

11:34 chouser: oh, I see. hmm.

11:34 cemerick: filter + reset buttons. It'd be shiny

11:35 Extra credit for finding the closest matching msg on-screen at the time of the filter, and scrolling to that line after hiding the non-matching msgs.

11:36 chouser: I'm planning on getting rid of the up/down arrows. I think that's a failed featuer.

11:36 featuer.

11:36 feature

11:37 cemerick: They seem to do random things :-)

11:37 chouser: :-P yeah

11:37 cemerick: chouser: It'd be great if spaces in msgs were turned into nbsp's as well.

11:37 chouser: nooo

11:37 cemerick: heh

11:37 already down that path?

11:38 chouser: you want each post to be just one line?

11:38 cemerick: chouser: OK, what I mean is, any space in a block of more than one space replaced with nbsp

11:39 e.g. this was an outline: http://clojure-log.n01se.net/date/2010-09-30.html#19:45e

11:39 chouser: oh, to maintain multi-space spacing. yeah, I should try to do that.

11:40 cemerick: I simply don't see how *in* and commands can be delineated from a single stream.

11:41 abrenk: technomancy: is it possible to specify a dependency of <type>pom</type> (in pom.xml) in project.clj?

11:42 lpetit: cemerick: right. Or would have to find a special char eg in the unicode charset, etc., but that's horrible

11:43 cemerick: lpetit: Rich was saying it's possible yesterday, but I don't see it.

11:43 lpetit: cemerick: Rich is like Socrates ...

11:44 cemerick: a tool committed to being synchronous could just start sending on *in* after each send of code

11:44 But I think he was implying something more transparent than that.

11:45 lpetit: why were you placing this on the table again, btw ?

11:45 cemerick: I'd like to support it as long as it doesn't impinge upon any of the other priorities.

11:46 I think cake could do exactly what I just mentioned

11:46 ninjudd: ping?

11:49 lpetit: ok

11:49 Bahman: Hi all!

11:49 lpetit: wasn't it one of, hum hum, earlier suggestions ? ;-)

11:50 cemerick: lpetit: it, what?

11:50 lpetit: nevermind

11:51 aborted auto-satisfaction tentative

11:53 abrenk: stuartsierra: how/when's the assembly plugin called?

11:53 stuartsierra: abrenk: I think I deleted that; it's in older commits in the "complete" pom

11:53 abrenk: stuartsierra: ah, okay

12:02 ninjudd: cemerick: yo

12:02 lpetit: ninjudd: hello!

12:03 ninjudd: cemerick: what's up? (reading the logs now)

12:03 lpetit: hi

12:03 lpetit: ninjudd: I hadn't understood you're the one behind cake. Great work !

12:03 ninjudd: lpetit: oh. well thanks

12:03 hehe. hum hum is right

12:03 lpetit: ninjudd: when do you drop the ruby dependency ? :)

12:04 ninjudd: cemerick: i mentioned that exact idea to rich, but he didn't seem to much like it

12:05 lpetit: well, i need some fast client script. it's either ruby or perl, and my ruby is much less rusty

12:05 cemerick: ninjudd: If I'm thinking of the same exchange, you were talking about timing though, right?

12:06 chouser: ninjudd: someday we'll get you some fast-startup clojure runtime, ok? You can port the client to that then.

12:06 cemerick: the clojure->scheme->C idea came up a few night ago again

12:06 chouser: cemerick: yes

12:07 oh, I misread. "good"

12:07 lpetit: ninjudd: once you have a running background jvm, couldn't the cake binary just be a lightweight wrapper in shell(unix)/bat(windows) to talk to the background jvm ? (maybe I'm saying nonsense)

12:07 ninjudd: cemerick: only in the context of solving the multi form paste problem. the main debate was about whether to have separate command and in streams

12:07 cemerick: ninjudd: and your position is?

12:08 (waaaay too many logs to scan over here)

12:08 ninjudd: that you need separate streams and that it is possible

12:08 LauJensen: ninjudd: lpetit: No whining about the Ruby code, it works wonders

12:09 lpetit: LauJensen: well, harder to leverage from third party tool such as ccw, he ?

12:09 cemerick: ninjudd: to pair send code requests with corresponding segments of *in*?

12:09 ninjudd: lpetit: it could, but i'd prefer to write it once in ruby than twice in bash and bat. ruby is more platform independent than either of those, obviously

12:09 LauJensen: lpetit: use Emacs

12:09 lpetit: violons ...

12:09 cemerick: LauJensen: sorta like asking RMS to use Eclipse, no?

12:09 lpetit: LauJensen: no thanks, I'm not stuck in the 20ies :-p

12:10 LauJensen: cemerick: sorta, but that way around it would be silly, no ? :)

12:10 ninjudd: cemerick: i was thinking that they don't need to be paired, but they could by clearing *in* after every command i suppose

12:10 cemerick, chouser: did you see that i added stream support to clj-stomp?

12:10 cemerick: yes

12:11 chouser: ninjudd: hm, I didn't.

12:11 lpetit: ninjudd: Oh you too have written a stomp port !

12:11 cemerick: ninjudd: you need to fix your (.read *in* buf 0 len) call -- you won't always fill that buffer in one call

12:12 ninjudd: cemerick: what a nightmare it was to get buffering correct. took my a few hours to figure out that the default implementation of read(buf,offset,len) in InputStream reads everything until EOF

12:12 TeXnomancy: abrenk: I think :type "pom" in the dependency vector does it

12:13 ninjudd: cemerick: you aren't supposed to fill the entire buffer if the data isn't available yet

12:13 abrenk: TeXnomancy: thanks, I'll try that.

12:13 TeXnomancy: may be new in 1.4.0-snpashot

12:13 abrenk: it's at least not in sample.project.clj

12:14 LauJensen: Enjoy the weekend everybody

12:14 TeXnomancy: abrenk: right, because it hasn't been released yet

12:14 lpetit: LauJensen: you too, bye

12:14 ninjudd: cemerick: the only case i can think of where that is correct is non-interactive input (i.e. files)

12:14 cemerick: ninjudd: I'm confused: you *need* to fill that buffer in read-body, no?

12:15 ninjudd: cemerick: no

12:15 cemerick: all right nm

12:15 * cemerick has no intention of actually understanding the protocol

12:15 cemerick: at least right now

12:15 duncanm: la la la

12:15 lpetit: starsky & hutch ?

12:15 ninjudd: cemerick: http://download.oracle.com/javase/1.4.2/docs/api/java/io/BufferedInputStream.html#read(byte[],%20int,%20int)

12:16 cemerick: Buffered input stream returns less than the requested number of bytes if the underlying stream does not have them available, but it always returns at least 1 byte and no more than len

12:17 cemerick: ninjudd: right, what I'm saying is, if a message comes along that's *large*, it won't all be available in one read

12:18 ninjudd: i read all available bytes unless the len passed is shorter than that

12:19 cemerick: but you need to read length bytes, not all available bytes

12:19 ninjudd: read is allowed to return less than len bytes

12:20 Reads up to len bytes of data from the input stream into an array of bytes. An attempt is made to read as many as len bytes, but a smaller number may be read, possibly zero. The number of bytes actually read is returned as an integer.

12:21 cemerick: ninjudd: I understand the spec. The underlying stream may block before you've read as many bytes as specified in the frame's headers.

12:22 ninjudd: cemerick: you mean the socket?

12:22 cemerick: or the inputstream from whatever transport is being used, yes

12:23 ninjudd: cemerick: i see. you're saying that i shouldn't read the whole frame at once

12:23 cemerick: not at the moment, no

12:24 I'm saying this is not always going to be true: (== (.read *in* buffer 0 length) length)

12:25 ninjudd: cemerick: oh. we're talking about two different things.. haha

12:25 cemerick: read-body, http://github.com/ninjudd/clj-stomp/blob/master/src/stomp.clj#L58

12:25 ninjudd: cemerick: i was talking about my implementation of .read in stomp/streams.clj

12:26 cemerick: oh

12:26 no

12:26 ninjudd: cemerick: sorry. my fault. still too early for me

12:26 cemerick: read-body, dammit, read-body! :-D

12:27 ninjudd: ii thought: "cemerick must be crazy calling input-read read-body, but i won't say anything..."

12:28 cemerick: got it. i think that explains why hornetq seems to hang sometimes. thanks!

12:28 cemerick: ninjudd: too perfect :-)

12:29 ninjudd: i was worried that hornetq was just buggy, but i hoped it was something in my code

12:29 cemerick: Bugs are never in others' code, only ever in one's own.

12:30 Except when they're not, and then you're screwed.

12:30 ninjudd: true. especially when your code is 3 days old and their code has been around for quite a while

12:31 cemerick: ninjudd: but while we're on the topic, returning a lazy seq of chars in body would be ideal (what I think cmiles74 is aiming for).

12:31 ninjudd: cemerick: i bet this is responsible for stompserver and CoilMQ not working too. seems that they only worked if i set ack:client

12:32 cemerick: ninjudd: do you have a CA lodged?

12:32 ninjudd: yeah, i sent cmiles74 a message to see if he'd like to combine our efforts and tackle a pure-clojure broker too

12:32 cemerick: yes

12:32 cemerick: good on both points

12:34 ninjudd: cemerick: how would i make it a lazy-seq of characters? it seems that receiving the next frame before the lazy-seq is realized will break things

12:37 cemerick: ninjudd: change (receive-frame s) to (locking s (receive-frame s))

12:38 ninjudd: cemerick: oh, nice

12:39 cemerick: though send- and receive-frame should be taking inputstreams or readers, not the socket

12:39 for transport independence

12:40 ninjudd: cemerick: right, i just noticed i need to change that to make it a lazy seq anyway

12:41 cemerick: i have to run now, but i'll check in these fixes in a few hours. thanks for the help!

12:41 cemerick: sure

12:41 ninjudd: FYI, I'm pushing ahead for now with my sockets; once a stable 1.1-ready client and broker are available, I'll switch over.

12:41 hopefully you and cmiles74 and whoever else can beat it down

12:42 ninjudd: cemerick: i was just going to ask if you are still stuck on the 1.1 bit

12:42 cemerick: I'm not personally, but I think it's unavoidable.

12:43 ninjudd: cemerick: i think i can write it so that the majority of the code is the same for a protocol and non-protocol version

12:43 cemerick: Definitely a drag, but them's the breaks for a little while, anyway.

12:43 Yeah, I wouldn't expect it to be too painful.

12:43 ninjudd: since the heavy lifting is in send-frame and receive-frame

12:43 cemerick: ninjudd: all contributors need to be CA-settled FYI

12:44 there should be a "get your CA done now" table at the conj

12:44 ninjudd: cemerick: ok, do you know if cmiles74 is? should i get a separate CA from contributors? or does the clojure one apply?

12:44 cemerick: ninjudd: nrepl will be going into contrib, so the usual one applies

12:45 I don't know if cmiles74 is yet, I'll bother him later :-)

12:45 ninjudd: cemerick: ok

12:45 be back in an hour or so

12:53 Raynes: cemerick: I was talking about 1.1 yesterday. I didn't realize it was still in widespread use.

12:53 I haven't seen many projects still using it.

12:53 cemerick: most clojure projects aren't open source

12:54 as long as stu's book is selling well, tools will need to support 1.1

12:54 or, tools that want to maximize their usage, I guess

12:54 Raynes: Stu's book was aimed at 1.0 AFAIK.

12:57 We are talking about SH, right? Not SS.

12:58 D'oh well. Good thing I don't have important projects. I don't thing I've got any code that I still work with that isn't on 1.2 now.

12:58 :p

12:59 cemerick: Raynes: I think you might be right

13:01 * dnolen thinks supporting 1.0, 1.1 is counter productive when community is so small, backwards compat is good, and even the closed source projects seemed to have been tracking 1.2 for the 8 months it was in dev

13:02 cemerick: In any case, not having futures or promises is a dealbreaker for nrepl

13:02 dnolen: there's a big difference between the closed-source guys that are active in the community and those that aren't

13:03 There are plenty of people still using 1.1, and they've never been in channel or on the google group.

13:03 or, *posted* to the gg, that is

13:03 dnolen: cemerick: but are there a ton of closed-source guys that aren't active in the community? I'm honestly curious. Don't those people need support?

13:04 cemerick: apparently not

13:05 good thing too -- if you *had* to be as engaged as we were to use clojure effectively....

13:05 we'd be like CL :-P

13:05 * cemerick runs, hides

13:06 dnolen: interesting, the Invisible Clojurians

13:06 cemerick: I mean, there's what, 3500 people on the gg?

13:06 dnolen: 4200+

13:07 cemerick: whatever -- that's surely not the entire userbase

13:07 or even the majority of it, I'd wager

13:07 ninjudd: i tend to agree with dnolen. besides, nREPL will be a compelling reason for them to upgrade to 1.2

13:07 cemerick: heh

13:08 dnolen: I taked OS X stance - basically forced upgrade

13:08 drag em kicking and screaming

13:08 cemerick: if defrecord and protocols aren't compelling enough, nREPL isn't going to be the feather that pushes them over the line

13:09 ninjudd: then they probably won't use nREPL anyway

13:10 dnolen: Clojure is just cutting edge tech, people who adopt it are early adopters - but what do I know. A real survey would be informative.

13:10 cemerick: dnolen: If all of the toolmakers say, go 1.2, I'll go 1.2

13:11 They're the direct users *shrug*

13:11 dnolen: cemerick: which dev envs are not 1.2? ccw? vim-clojure?

13:11 cemerick: ccw and enclojure actively support < 1.2 (all the way back to 1.0, I think, but I can't cope with that)

13:11 don't know about the others

13:12 ninjudd: people can always use old versions of the tools if they really must use 1.1

13:12 cemerick: ninjudd: tool versions are totally unrelated to deployment targets

13:12 * cemerick still ships commercial product targeting java 1.4

13:13 ninjudd: i intended to have cake support 1.1, but i started using clojure.java.io and didn't realize i broke it for a month at least

13:14 cemerick: not totally. repl and swank and test have to run in the project classpath

13:14 cemerick: you mean in cake?

13:15 defn: did somebody say cake?

13:18 ninjudd: and swank and lein and anyone who wants nREPL to connect to their project

13:19 * ninjudd isn't here though...

13:25 anonymouse89: is there a way, when using map, to get the index of the item in the list being mapped?

13:26 cemerick: anonymouse89: see map-indexed

13:27 anonymouse89: cemerick: do you happen know of an equivalent for pmap?

13:27 abrenk: stuartsierra: http://github.com/abrenk/clojure-contrib/commit/d6b88cba1065c4ae9c7df2c0966147dd428c1c41

13:28 stuartsierra: abrenk: thanks! will try this out later today

13:28 cemerick: anonymouse89: (pmap your-parallelized-fn (map-indexed vector some-seq))

13:28 abrenk: stuartsierra: I will add a couple of comments.

13:28 chouser: cemerick: CA table at the conj -- brilliant

13:29 just a stack of blank forms and a drop-box.

13:29 cemerick: absolutely

13:29 abrenk: stuartsierra: there are some other possibilities. perhaps we could discuss those on monday?

13:29 TeXnomancy: ,(#'while :form :env :test :body) ; <= is this behaviour intentional or undefined?

13:29 clojurebot: (clojure.core/loop [] (clojure.core/when :test :body (recur)))

13:29 stuartsierra: abrenk: Monday I'll be back on client work.

13:29 abrenk: stuartsierra: are you around on the weekend?

13:29 chouser: TeXnomancy: undefined

13:30 stuartsierra: probably not

13:30 TeXnomancy: chouser: good to know; thanks.

13:30 abrenk: okay, then some time in the future

13:30 chouser: TeXnomancy: subjuct to change without notice

13:30 TeXnomancy: fascinating though

13:30 chouser: TeXnomancy: you're not technomancy are you.

13:31 TeXnomancy: chouser: I had an account on someone's IRC bouncer that I haven't figured out how to turn off; it keeps taking technomancy and forcing me back to my alternate nick

13:31 I really am, honest.

13:31 chouser: TeXnomancy: heh, ok.

13:32 TeXnomancy: I remember reading about Jim Weirich in this situation and someone was like, "If you're really Jim Weirich, implement the Y-combinator in Ruby from memory" and he was all --- bam! here you go.

13:33 I don't think I could do that, but you can ask me questions about Chesterton or Achewood to be sure.

13:33 hiredman: TeXnomancy: who is a special boy!

13:33 TeXnomancy: phillipe!

13:34 hiredman: legit

13:34 anonymouse89: cemerick: thanks for the help!

13:34 TeXnomancy: http://freezepop.net/listen/songs/Freezepop_Here%20Comes%20a%20Special%20Boy.mp3

13:36 pyrtsa: Hey, what's the shortest way to filter out all nil's (or alternatively falsey values) from a collection?

13:37 chouser: keep

13:37 pyrtsa: Great, thanks.

13:37 TeXnomancy: chouser: keep leaves false in

13:37 =(

13:37 chouser: actually, that depends. keep is like filter+map

13:39 hiredman: (remove (comp false? boolean) …

13:39 pyrtsa: Is there no function in clojure.core or clojure.contrib that tests for trueyness or falseyness?

13:39 hiredman: ,(boolean nil)

13:39 clojurebot: false

13:39 hiredman: ,(boolean false)

13:39 clojurebot: false

13:39 hiredman: ,(boolean 1)

13:39 clojurebot: true

13:39 pyrtsa: Ah, right.

13:39 hiredman: etc

13:39 pyrtsa: So (filter boolean xs) would work as well.

13:40 hiredman: poor remove, almost never used

13:41 TeXnomancy: filter identity is the same, I think

13:41 speaking of which, identity should be the default predicate for filter/remove/every?, right?

13:41 pyrtsa: TeXnomancy: I was just about to suggest that.

13:42 chouser: TeXnomancy: yeah

13:42 TeXnomancy: ISTR suggesting it on the mailing list a month or so ago; didn't go anywhere. I guess a ticket would be the next step.

13:42 chouser: I'm not sure it'd be useful on remove, but yeah. take-while

13:43 pyrtsa: Possibly it should be the default for any function taking a predicate and collection.

13:43 TeXnomancy: actually yeah, if you have it on filter it's not needed on remove

13:43 pyrtsa: (That was a bold statement by me, I know.)

14:01 laurus: Is there a way to clear all user-defined variables, etc. from a REPL without restarting it?

14:01 stuartsierra: laurus: remove-ns gets you part way there

14:02 laurus: stuartsierra, your book is fantastic, by the way!

14:02 stuartsierra: laurus: thanks!

14:02 got to go now

14:02 laurus: Wow, that was awesome.

14:02 Didn't expect to get help from the author of the book I'm reading! :)

14:03 At user=>, I see ::foo is equivalent to :user/foo. But isn't :foo also equivalent to :user/foo? Or am I missing something.

14:04 technomancy: ,(= :foo ::foo)

14:04 clojurebot: false

14:04 laurus: technomancy, right, but why?

14:04 Isn't everything namespaced anyway?

14:05 technomancy: :foo is "bare"; not every keyword has a namespace

14:05 laurus: Does that apply to other data types as well?

14:05 technomancy: vars are the only thing that has to have a namespace, I think

14:06 laurus: Ah, right, I forgot there's a big difference between a var and a floating piece of data.

14:06 So in other words, vars get "auto-namespaced", but data doesn't.

14:07 cemerick: vars are defined within an ns

14:07 technomancy: keywords and symbols are the only things that may optionally have namespaces, I think. symbols are auto-namespaced only if they're inside a backquote.

14:07 oh... and for the purposes of this and every other discussion, we pretend with-local-vars does not exist.

14:07 because seriously

14:08 cemerick: heh

14:08 laurus: technomancy, I've never heard of that function, so that's fine with me! :) Hehe

14:09 Er, wait a minute...

14:09 chouser: symbols and keywords don't really have namespaces as such, just prefixes

14:09 ...that can be used to find namespaces

14:09 laurus: :user/foo refers to a keyword called foo in the user name space. But how can someone look that up unless it is bound to a variable?

14:10 cemerick: :user/foo *is* that keyword

14:10 chouser: keywords aren't looked up anywhere. each keyword is its own value

14:10 laurus: Hmm, I think this book needs more examples.

14:11 chouser, so what is the point of "namespacing" a keyword?

14:11 technomancy: keyword praemium suum est

14:12 chouser: laurus: so that it's less likely to get confused with other people's keywords when they show up in the same place

14:12 laurus: Oh, so it's more for the programmer than for the system then?

14:12 cemerick: ,{:size 5 :foo/size 6}

14:12 clojurebot: {:size 5, :foo/size 6}

14:13 chouser: laurus: mainly for when you're messing around with other peoples objects -- add your own key to some other lib's hash-map, or some metadata to an object that lots of libs might want to add metadata to.

14:14 the original case was the global 'isa?' hierarchy

14:14 cemerick: without that, you'd be doing :size 6, :my-size 12

14:15 laurus: cemerick, but does :foo/size actually refer to the keyword :size in the foo namespace?

14:15 Or does it just refer to a keyword called ":foo/size"

14:15 cemerick: it definitely has two components, though it doesn't really carry a namespace reference

14:16 (name :foo/name)

14:16 chouser: laurus: in reality, just the latter.

14:16 cemerick: ,(name :foo/name)

14:16 clojurebot: "name"

14:16 cemerick: ^^ a string, not a namespace

14:16 laurus: chouser, okay. That's a little confusing ;)

14:16 Thanks for the clarification.

14:16 chouser: but because we have the double-colon shortcut, and just out of convention, it's good to use your own namespace as the prefix of your qualified keywords

14:16 amalloy: laurus: if you like getting help from the author of books you're reading, you should get the Joy of Clojure - chouser's on irc a lot more than stuart sierra

14:17 laurus: chouser, thank you! That makes a lot of sense now.

14:17 chouser: stuart sierra is probably an asset to his employer.

14:17 amalloy: haha

14:17 laurus: amalloy, well it's not out yet in paper form :p Also, the Joy of Clojure isn't introductory is it?

14:17 chouser, heh

14:17 joly: I just ordered JoC; really looking forward to getting into it this weekend

14:18 chouser: joly: cool, thanks!

14:18 amalloy: laurus: i read it as my first clojure book, after maybe two weeks' experience with common lisp. it was a little heavy, but not overwhelming

14:19 chouser: honestly i'd be willing to sacrifice some of SS's usefulness to his employer

14:19 laurus: amalloy, oh, I see. I had some basic experience with Emacs Lisp but that's it. Also the Joy of Clojure looked more chatty than Practical Clojure, not that that's necessarily a bad thing

14:19 chouser: well, his employer is Clojure/core now, right, so it's a win either way. :-)

14:20 amalloy: chouser: is it? i guess that's okay then

14:20 chouser: laurus: but it's chatty with a bibliography! :-)

14:21 laurus: chouser, really, bibliography?

14:21 Sounds like it might be useful, I might check it out after I finish Practical Clojure when I can see the paper version. I'm not a big fan of reading books on the screen

14:21 chouser: yeah, fogus_ has that thing chock-full of references to papers and books I really ought to get around to reading.

14:21 rlb: Might want to add a mention in the docs that sort and sort-by are stable (assuming that's guaranteed)...

14:22 laurus: chouser, neat, that's great. I wish more books were like that.

14:23 It's interesting that (get) doesn't return a java.lang.IndexOutofBounds exception when you specify an index that is out of bounds of what you're passing as the first argument :P

14:23 chouser: but nth does

14:24 laurus: Oh, right.

14:25 abrenk: My version of the clojure-contrib build now produces a dependency for a single, large uberjar (named "standalone") and a dependency for multiple, small jars (named complete). See the last two commits on http://github.com/abrenk/clojure-contrib/commits/abrenk-build.

14:26 laurus: I see I can use hash-map and sorted-map functions to specify the underlying implementation of a map. How do I specify an array for the underlying implementation?

14:27 amalloy: ,(array-map)

14:27 clojurebot: {}

14:27 laurus: amalloy, oh, hah, thanks.

14:27 amalloy: laurus: surprise! :)

14:28 cemerick: abrenk: nice -- interesting you used assembly instead of shade

14:28 abrenk: cemerick: perhaps I should get to know "shade"...

14:28 cemerick: never heard of it

14:29 chouser: laurus: note that conj on an array-map may return a hash-map

14:30 laurus: chouser, thanks for the warning.

14:30 abrenk: cemerick: the second commit using the dependency instead of assembly plugin is nicer for the user because no need to specify a classifier

14:30 cemerick: yes, definitely preferable

14:31 abrenk: I'll take a look at the shade plugin later on. Need to get something to eat and then enjoy the friday evening.

14:32 cemerick: abrenk: What you have may be superior

14:36 abrenk: cemerick: I don't know when stuartsierra will have time to look at this. Feel free to merge into clojure-contrib.

14:36 cemerick: abrenk: I'm not a committer

14:36 it'll require a submitted patch, in any case

14:36 abrenk: Is there a copyright on build scripts...? *ggg*

14:37 cemerick: abrenk: do you have a lodged CA?

14:37 abrenk: not yet

14:37 cemerick: you'll need to do that before submitting patches

14:37 technomancy: abrenk: according to the FSF legal team, contributions under 20 LOC are not copyrightable

14:37 abrenk: I should do so, also re: my clojure.test contributions

14:37 cemerick: http://clojure.org/contributing

14:37 technomancy: but that doesn't apply to Clojure =\

14:38 cemerick: all you need is a 21-liner to slip through...

14:38 abrenk: technomancy: thank god I copied over a hundred lines of dependencies... ;-)

14:38 technomancy: fun

14:39 AWizzArd: flatten is lazy yes?

14:39 hmm yes, returns the result of filter

14:39 btw, that filter could be replaced by remove

14:40 then the call to complement could go away

14:50 ninjudd: cemerick: hmm, looks like your locking trick won't work because the lazy seq may never be realized

14:50 amalloy: AWizzArd: remove is implemented as (filter (complement pred) coll)

14:50 clojurebot: Reader syntax of collections has gotchas

14:51 cmiles74: I took everyone's comments (which I really appreciated :)) on my STOMP parser to heart and took another stab at it. I think this looks a lot better, if anyone could spare a glance at it I'd appreciate it. This is the first parser I've coded up in Clojure.

14:51 cemerick: ninjudd: hrm, crap. You're right.

14:51 ninjudd: cmiles74: there you are. did you get my message on github?

14:51 amalloy: AWizzArd: er...which is an argument in favor of your point, not against it. sorry, not really thinking

14:51 cmiles74: ninjudd: I did, I'm reading it over right now. :)

14:52 ninjudd: I would gladly help you with your project. :) It was also very nice of you to say kind things about my stomp parser code.

14:54 ninjudd: cmiles74: have you had a chance to look at my code? how hard to you think it would be to merge the two projects?

14:55 cmiles74: at least they have the same name ;)

14:55 cmiles74: ninjudd: ha!

14:55 I will look at it next. I feel better about my parser, the first pass I knew was pretty weak.

14:56 I don't have a lot of code, I can't imagine it'd be too hard. :P

14:56 ninjudd: cmiles74: the fun part is going to be writing the broker ;) have you started on that at all?

14:56 cmiles74: ninjudd: I haven't, but I've been reading through the Netty documentation and it does look nice.

14:57 cemerick: ninjudd, cmiles74: gozirra might be a good reference impl to look at, if only because it's very small :-)

14:58 cmiles74: ninjudd: I work for a hospital, I have to write a lot of little applications to route or alter these messages that go from system to system (i.e. radiology over to registration, etc.) I've been writing my own socket code for these and I'm starting to get to point where I need my own protocol. Stomp sounds better than memaking something up.

14:58 clojurebot: http://clojure-log.n01se.net/date/2009-10-13.html#12:02

14:58 ninjudd: i was planning to just use ServerSocket, because that's what i've used in the past, but i'd like to learn Netty

14:59 cemerick: nREPL can't require netty

14:59 cmiles74: ninjudd: I hadn't heard of Netty before but it does do some nice things. It would be a dependency, however.

14:59 chouser: if you use netty you might as well use an existing stomp implementation

14:59 cemerick: I mean, just FWIW

15:00 or, hornetq for that matter :-)

15:00 cmiles74: If we use Netty, it will be easier to change the transport layer out from under the service. For instance, supporting the STOMP client and server over webscoket as well as TCP.

15:01 ninjudd: cemerick: well then you have to let us use protocols so we can swap out different socket implementations

15:01 dnolen: down with 1.1

15:01 ninjudd: cemerick: you choose: 1.1 support, or no Netty dep ;)

15:01 cmiles74: cemerick: Why can't nREPL require Netty?

15:02 * dnolen goes back to work

15:02 cemerick: You guys can use whatever you want, but I'm not letting protocol or transport concerns influence nREPLs deps

15:02 cmiles74: cemerick: I'm not trying to talk you into anything, I'm just curious.

15:03 cemerick: cmiles74: see Deployment Considerations here: http://bit.ly/nreplnotes

15:03 * dnolen foresees nREPL, oREPL, pREPL ... xREPL

15:03 AWizzArd: ,(.getClassLoader Object) ; why is it like this?

15:03 clojurebot: nil

15:03 ninjudd: cemerick: i agree that we should be able to just depend on ServerSocket, which is why we should use protocols

15:03 cemerick: eh, we already went 'round on that

15:03 AWizzArd: Should it not be the bootstrap CL?

15:04 ninjudd: right, where did we leave it? need input from the tools developers on whether they are ok with dropping 1.1?

15:04 chouser: is the performance requirement such that we need protocols instead of multimethods?

15:04 cmiles74: Doesn't Horent use Netty as well?

15:05 chouser: cmiles74, ninjudd: I think the ideal would be swappable implementations

15:05 cemerick: ninjudd: I heard grumbling about dropping 1.0.

15:05 ninjudd: chouser: it isn't a performance thing. more of an expression/elegance thing

15:06 cemerick: I'd rather save my powder for convincing tool leads to adopt the thing.

15:06 chouser: no dep, pure clojure, feature-lean client and server that can each interoperate with each other or with the featureful implementation such as provided by hornetq

15:06 ninjudd: who wants to write a 1.1 implementation of defprotocol using multimethods?

15:06 cmiles74: chouser: You are correct, I was just typing something like that. :) In the case of nREPL on someone's desk inside Eclipse or whatever, we could use our own.

15:07 chouser: ninjudd: any elegance protocols have over multimethods can be matched by a simple macro

15:07 cemerick: Man, protocols are, what, 6 months old and they're already must-haves?

15:07 chouser: cmiles74: 'zactly

15:07 ninjudd: chouser: perfect, so you're volunteering?

15:07 laurus: Why doesn't rseq work on a quoted list?

15:07 chouser: ninjudd: I have such a macro.

15:08 you want it?

15:08 cemerick: ha

15:08 ninjudd: chouser: absolutely

15:08 chouser: I wrote it for illustration purposes for my Strange Loop talk. I didn't think anyone would actually want it.

15:09 ninjudd: http://gist.github.com/606678

15:10 laurus: ,(rseq '(1 2 3 4))

15:10 clojurebot: java.lang.ClassCastException: clojure.lang.PersistentList cannot be cast to clojure.lang.Reversible

15:10 laurus: ,(rseq (seq '(1 2 3 4)))

15:10 clojurebot: java.lang.ClassCastException: clojure.lang.PersistentList cannot be cast to clojure.lang.Reversible

15:10 laurus: Why does this happen?

15:10 cemerick: for some reason, that exchange made me cast vader:obiwan::ninjudd:chouser http://www.icanhasinternets.com/wp-content/uploads/2010/09/darthobi.jpg

15:10 ninjudd: chouser: awesome. so simple

15:11 chouser: note the "protocol name" in there (DataRow in the example) is completely ignored. Included only to be arg-for-arg with defprotocol

15:11 ninjudd: yup

15:11 ninjudd: i'm vader?

15:11 ataggart: that's pretty cool

15:11 cemerick: just in my head

15:11 :-)

15:11 chouser: heh

15:12 laurus: there's no way to lazily walk a list from the far end

15:12 laurus: so they don't support rseq

15:12 ninjudd: maybe Anakin

15:12 laurus: chouser, hmm, okay, I'll just take your word for it and not dig deeper

15:12 This isn't an important concept to go more in depth into is it?

15:13 chouser: laurus: it's a small aspect of an important concept

15:13 it more often comes up as "why is (seq? [1 2 3]) false?"

15:13 laurus: Well a vector is not a sequence, right?

15:13 chouser: righto

15:13 alexyk: ninjudd: do you have a separate channel for protobuf?

15:14 laurus: But why does rseq have to lazily walk the list? I tried to convert the list into a sequence manually there.

15:14 ninjudd: no, i just use #jiraph

15:14 chouser: laurus: ISeq also doesn't support rseq. You can use 'reverse' if you want, instead of 'rseq'

15:15 laurus: ,(seq? '(1 2 3 4))

15:15 clojurebot: true

15:15 laurus: So why doesn't rseq work on that seq?

15:16 chouser: rseq is for collections that have order and can be efficiently walked from right to left

15:16 laurus: Oh, okay. So it doesn't just simply "reverse a sequence."

15:16 chouser: no, that's what 'reverse' does

15:16 ,(reverse '(1 2 3 4))

15:16 clojurebot: (4 3 2 1)

15:17 chouser: reverse is O(n) -- walks the whole seq so it can get to the last item and start by returning that. non-lazy.

15:17 thus you can understand the cost when you call it.

15:17 laurus: Hmm, okay. I guess I thought all sequences were "the same" regardless of what kind of collection they came from in the first place.

15:17 raek: which is most ideomatic: foo->bar or foo-to-bar?

15:17 chouser: rseq's docs explicitly state constant time, so must be supported by the underlying collection.

15:18 raek: I noticed that the former appeared in JoC...

15:18 laurus: So underneath each sequence is actually the original collection is what you're saying?

15:18 chouser: laurus: generally, yes, or at least a portion of it.

15:19 laurus: chouser, interesting. Thanks for that detail!

15:19 chouser: ...or the code to produce it.

15:19 laurus: Right :) Heh.

15:19 chouser: if all you have a seq, that seq still promises to give you the rest of the data if you call rest enough times. So all the data (or the code to produce it) has to be there.

15:20 laurus: Right.

15:21 chouser: ,((juxt class identity) [1 2 3])

15:21 clojurebot: [clojure.lang.PersistentVector [1 2 3]]

15:21 chouser: ,((juxt class rseq) [1 2 3])

15:21 clojurebot: [clojure.lang.PersistentVector (3 2 1)]

15:21 chouser: oh

15:21 ,(class (rseq [1 2 3]))

15:21 clojurebot: clojure.lang.APersistentVector$RSeq

15:21 chouser: ,(class (seq [1 2 3]))

15:21 clojurebot: clojure.lang.PersistentVector$ChunkedSeq

15:23 laurus: It's interesting that (first "ant") returns \a and not "a".

15:25 AWizzArd: I am currently fighting with those multiple variants of seqs for my serializer

15:26 chouser: AWizzArd: I would hope their concrete classes wouldn't matter.

15:26 AWizzArd: chouser: well, I will for now implement a serializer which can serialize them all, but then return a PersistentList when deserializing.

15:28 I started off by implementing one that returns exactly the same class again, such as PersistentVector$ChunkedSeq or APersistentMap$KeySeq or APersistentMap$ValSeq or LazySeq

15:28 chouser: hm

15:28 AWizzArd: that was too much work, and most likely not too useful

15:28 * chouser is reading, right now, http://home.pipeline.com/~hbaker1/ObjectIdentity.html

15:30 chouser: I'm sure it has something to say on this matter

15:30 AWizzArd: I see, so I should maybe also have a look on this

15:31 chouser: well, rhickey promotes it frequently. I've started reading it before, but never yet finished.

15:32 dnolen: huh, never realized clojure.set has basic db style operations

15:32 AWizzArd: And from what you have read so far, would you say that when you serialize a clojure.lang.APersistentVector$RSeq you want such a thing back?

15:33 chouser: AWizzArd: I don't see how I could care.

15:34 I might care that I get back something that implements ISeq, Counted, Obj, IndexedSeq, Iterable, Sequential, etc.

15:36 labatitude: I want to use clojure.xml/parse, which takes a stream, but I have a string. How can I make my string into a stream?

15:36 (I've done this before but forgotten again.)

15:38 hiredman: ByteArrayInputStream

15:38 AWizzArd: chouser: if I want to save Clojure images I should probably really save all those concrete classes

15:40 But for now I want to come closer to publish that lib soon, and will just return PersistentLists.

15:42 labatitude: hiredman: I'm getting "java.lang.String cannot be cast to [B"

15:42 does this look like the right way?

15:42 (java.io.ByteArrayInputStream. "<?xml version='1.0'?><stuff>And more</stuff>")

15:42 hiredman: uh

15:43 that's because you need to turn the string into a byte array first

15:43 ~jdoc String

15:43 ~jdoc java.io.ByteArrayInputStream

15:43 labatitude: ok, its all in java. I'll go read that right now. Thanks

15:49 hugod: cemerick: the *in* thing I mentioned is now working in swank-clj, fwiw

15:49 cemerick: ok

15:49 AWizzArd: chouser: much more I am worried about deeply nested collections

15:49 cemerick: hugod: trying to keep feature-competitive? ;-)

15:50 AWizzArd: My current approach is (like Clojures printer) recursive serialization. This would fail for a list that is nested deeper than 16k levels.

15:50 cemerick: hugod: more on-point: if you might be interested in writing a swank adapter for nREPL, that'd be stellar.

15:51 labatitude: hiredman: working now, thanks.

15:51 hugod: cemerick: there are some differences eg. message id's are client generated in swank

15:52 cemerick: hugod: that's no problem -- I had originally allowed for user-generated IDs in the API

15:52 hugod: Any swank-compatability-related changes that would be helpful, I'll make.

15:53 hugod: cemerick: my main drive is to get jpda working at the moment. The *in* thing is something supported by swank but that wasn't in swank-clojure

15:54 cemerick: I understand.

15:55 hugod: What I'm saying is, if at all possible, I want to encourage SLIME compat.

15:59 alexyk: is there a standard process of updating 1.1 code to 1.2? e.g., can use/require seq-utils be just dropped, and same for other things folded into core?

16:07 stuartsierra: ~seen abrenk

16:07 clojurebot: abrenk was last seen in #clojure, 89 minutes ago saying: technomancy: thank god I copied over a hundred lines of dependencies... ;-)

16:09 cemerick: stuartsierra: he pushed something he said was working well

16:09 stuartsierra: yes I saw.

16:09 My question is: does he have a CA?

16:09 cemerick: nope

16:09 stuartsierra: drat

16:10 cemerick: he has other patches lingering, so hopefully we can make fun of him until he relents :-)

16:10 stuartsierra: not sure if you saw this before: there should be a lodge-your-CA-here table at the conj. Pass it on to the right folk.

16:10 stuartsierra: will do

16:10 cemerick: no one should leave on Friday without being settled

16:11 stuartsierra: Conj boss Alan officially notified.

16:12 * wooby makes a note

16:13 cemerick: wooby: sorry, should've gone to you directly :-/

16:13 stuartsierra: nicknames confuse me

16:13 cemerick: handle out of sight, out of mind :-(

16:13 stuartsierra: real names are hard enough

16:13 charliekilo: ztellman , sorry to bother with a stupid question : I'm playing around with aleph and are tying to figure what the preferred way is to add functionality in the communication ... I tried wrap-channel, but that does not seem to work (see http://gist.github.com/606776)

16:14 ztellman: charliekilo: messages for tcp servers are ChannelBuffers

16:15 wooby: good progress on the conj front today btw, t-shirts and goody bags ordered

16:15 ztellman: trying to put that in a str will cause issues, I think

16:15 let me play around with it a bit

16:17 cemerick: ninjudd: do you still have a use case for an incremental progress API if nREPL is going to support streaming *out*, *err*, System/out, and System/err?

16:18 charliekilo: ztellman: ah, ok ... I thought it did automagic conversion ... is 'wrap-channel' the right function in this case or is there a better/preferred way?

16:18 ztellman: charliekilo: wrap-channel is the right function

16:18 ninjudd: cemerick: no, i think i just needed that for streaming

16:18 cemerick: ok, back burner for now then

16:19 ztellman: charliekilo: there's some more automagical conversion stuff sitting on my computer that I haven't submitted yet

16:19 cemerick: ninjudd: any issues with my reusing some of cake's multiplexing bits?

16:19 ztellman: once that's in, I think you'd see "Response: <ChannelBuffer ...>"

16:20 ninjudd: cemerick: the multi-outstream stuff?

16:20 abrenk: stuartsierra: The CA is coming out of the printer right this moment.

16:20 cemerick: and such, yes. Not sure if I can reuse it as is, but I figured I'd ask ahead of time.

16:20 stuartsierra: abrenk: awesome

16:21 ninjudd: cemerick: go for it.

16:21 charliekilo: ztellman : gotcha ... I think that points me in the right direction ... I will keep an eye out for it in the next commits

16:21 ztellman : thanks

16:22 ninjudd: cemerick: the most confusing part about that is how it supports an atom for the root binding of *outs* and *errs*

16:22 ztellman: charliekilo: once I check that stuff in tonight, this should do what you want: http://gist.github.com/606792

16:22 ninjudd: cemerick: that makes it so futures and Threads will print to the most recently registered stream

16:24 charliekilo: ztellman : thanks

16:25 ninjudd: cemerick: though i think rhickey said yesterday that any code that relies on printing in a future without establishing *out* is broken, so you may just be able to remove that part

16:26 cemerick: very, very true

16:26 I have a couple of ideas, but they're longshots

16:26 Allowing clients to opt into listening to System/out and err on a per-connection basis is the next best fallback.

16:26 And desirable otherwise, anyway.

16:27 ninjudd: cemerick: it would also me nice if you could just bind *out* and it would take care of System/out for you. but you'll have to deal with decoding and encoding the characters

16:27 cemerick: *out* related a requested code eval and listenting to System/out have to be kept separate

16:29 ninjudd: cemerick: not sure i follow

16:30 cemerick: I don't ever want System/out to get into content sent back as *out* -- clients that would prefer to show them separately wouldn't be able to do so.

16:30 ninjudd: cemerick: i see. that makes sense. but System/out should still be separate per thread

16:31 cemerick: for futures and such you mean?

16:31 ninjudd: no, just for code that prints directly to System/out

16:32 java code

16:32 cemerick: why separate per thread?

16:32 ninjudd: well that is what multi-outstream does

16:33 cemerick: otherwise you could get some other thread's System/out in your repl

16:33 cemerick: very confusing when it happens

16:34 cemerick: Oh, I see what you're saying.

16:39 hugod: cemerick: sorry, phone call - I don't see a big difference between nrepl and swank-clj

16:39 cemerick: That's good.

16:40 hugod: or, are you saying you're not sure why we're not just using swank-clojure? ;-)

16:42 ninjudd: The thing about the wonky System/out stuff that cake does is, e.g. (future (.println System/out "fooey"))

16:42 hugod: cemerick: kind of, yes

16:43 ninjudd: cemerick: just bind the root of *outs* to the original System/out

16:43 cemerick: hugod: no clojure client, tied to whatever the SLIME people want to do with it

16:45 and, as things go along, nREPL will be STOMP-ified, and a lot more flexible

16:45 hugod: cemerick: well, a clojure client would need writing anyway

16:45 cemerick: hugod: think: distributing code to N nodes...

16:46 ninjudd: cemerick: like i said the wonky stuff with letting the root be an atom and using the most recently registered stream can be removed if you want

16:46 or optional

16:46 technomancy: we could fork the swank protocol. we kinda already do that by saying "only this one revision from early 2010 is supported"

16:46 for the record, hugod is rather more of an authority on swank than I am; my understanding of the protocol is rather superficial

16:47 ninjudd: technomancy: don't you lose the benefit of nREPL and Stomp if you wrap the server with a swank compatibilty layer?

16:48 hugod: you could put stomp into swank clojure easily enough

16:48 ninjudd: seems like the best way to go is to write an elisp nREPL client

16:48 technomancy: I haven't been keeping up with the nrepl discussions; just responding to hugod's comments.

16:48 lancepantz: i would be a fan of moving away from the swank protocol all together, even though i understand that would be throwing away a lot of work, either that, or atleast document it better

16:48 i could find no documentation of the protocol and the code was a mess

16:49 cemerick: ninjudd: being able to use SLIME is the motivator in that case

16:49 I doubt many people are very motivated to write elisp to replace it.

16:49 hugod: I am working on adding jpda support and have refactored swank-clojure significantly in my swank-clj repo

16:51 ninjudd: cemerick: you're probably right. making swank-clj a stomp client will be much less work

16:52 cemerick: ninjudd: swank-clj is a server

16:52 ninjudd: cemerick: i know

16:54 cemerick: but it will also have to be a stomp client to communicate with nREPL. or were you thinking of talking to nREPL library functions directly?

16:54 cemerick: ninjudd: it seems like the simplest paths would be to write a swank wrapper for nREPL, or write an nREPL client in elisp, and hook it into SLIME somehow

16:56 AWizzArd: Is there a problem with the current slime repl?

16:56 ninjudd: cemerick: i suppose i am proposing a third option: writing a swank library that communicates with nREPL using stomp

16:57 cemerick: so you'd need two servers?

16:57 ninjudd: aye

16:57 cemerick: *shrug*

16:57 ninjudd: three if you count the broker

16:57 indirection ;)

16:57 very flexible from what i hear...

16:57 cemerick: well, in that scenario, nREPL is a client too

16:58 AWizzArd: Why so many servers? The current emacs + slime setup seems to be working well?

16:58 cemerick: AWizzArd: But does nothing for those using other tools.

16:58 lancepantz: AWizzArd: the issue is that it only works in emacs

16:58 AWizzArd: yes

16:58 cemerick: AWizzArd: see the Premise here: http://bit.ly/nreplnotes

16:58 AWizzArd: okay, I will read it :)

16:59 lancepantz: the talk is about a replacement that works with all tools

16:59 ninjudd: cemerick: yes, there are no servers anymore. just clients and brokers ;)

16:59 AWizzArd: My current naive thought is that all others could just try to use swank then. But I will see what I find behind that link :-)

16:59 cemerick: I'm happy with whatever makes the emacsen happy, fundamentally.

17:00 ninjudd: cemerick: but you'd probably be happier if they use your external network api rather than try to hook into you implementation directly

17:00 cemerick: ninjudd: yeah, the value is in the tool interop, not in the actual REPL impl

17:01 ninjudd: cemerick: if the swank-clj implementation calls your functions directly, you will be stuck never changing them

17:01 cemerick: I can't see why swank-clj would ever do that. No value there.

17:02 actually, once nREPL is using STOMP, then an elisp stomp/nREPL client may be the only reasonable option

17:02 That's either really good or really bad.

17:02 ninjudd: that's what i said!!!

17:02 cemerick: no it wasn't -- it doesn't involve swank-clj at all

17:03 ninjudd: the first thing i said, before i proposed the intermediate server/client/swank/stomp bridge idea

17:03 cemerick: anyway, my speculating on what's best for emacs users is fairly absurd

17:03 oh, right

17:03 yes

17:03 I was agreeing with your initial suggestion :-D

17:04 hugod: :), I just want to use slime

17:04 cemerick: right -- no one gives a hoot about protocols :-)

17:04 lancepantz: world are colliding omg!

17:04 fbru02: can i ask an OT question ?

17:04 lancepantz: s/world/worlds/

17:04 sexpbot: <lancepantz> worlds are colliding omg!

17:04 ninjudd: i really think the server/client/swank/stomp bridge will be the easiest to implement

17:05 cemerick: That is, until they make it so that you can't connect to my app that uses REPL server A, and I can't connect to your app that uses swank-clj.

17:05 hugod: the protocol is half the story - there are also all the functions that get called in the repl

17:05 cemerick: ninjudd: what about embedded REPLs in deployed apps though?

17:06 ninjudd: cemerick: good point. i guess you would have to run a swank-bridge on your local box

17:06 cemerick: yack

17:06 Or, hey, whatever. Peace, man.

17:06 ninjudd: cemerick: your .emacs could start it up for you ;)

17:07 cemerick: i checked in the fix to read-body http://github.com/ninjudd/clj-stomp/commit/72be202f05106388348bda5b0d636742fd746ae5

17:07 cemerick: nifty

17:07 ninjudd: cemerick: thanks again! looks like that fixed my locking problem with hornetq

17:07 cemerick: fbru02: ask away

17:08 ninjudd: (stompserver and coilmq still appear to not implement ack:auto correctly though)

17:08 cemerick: ~ask

17:08 clojurebot: No entiendo

17:08 cemerick: ~Ask?

17:08 clojurebot: Gabh mo leithscéal?

17:08 ninjudd: ~ask?

17:08 cemerick: bah

17:08 clojurebot: I don't understand.

17:08 ninjudd: ~what is asking?

17:08 cemerick: It used to have a nifty line for that

17:08 clojurebot: Pardon?

17:08 cemerick: $ask

17:08 oh well

17:08 ninjudd: $8ball what is asking?

17:08 sexpbot: ninjudd: Concentrate and ask again.

17:09 ninjudd: hahaha

17:09 technomancy: ~anyone

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

17:10 ninjudd: poor fbru02. what's your question man?

17:11 fbru02: cemerick: ninjudd and all : sorry to interrupt

17:12 we and a friend are going to Strangeloop and the conj from Uruguay (me) Argentina (him)

17:12 which is the best place to spend the days in between conferences ? St Lois or Durham?

17:14 brianstamand: ~ask

17:14 clojurebot: Huh?

17:14 brianstamand: ~what is seq

17:14 clojurebot: 'Sea, mhuise.

17:15 scottj: fbru02: how many days?

17:15 ninjudd: fbru02: i've never been to either. how are you getting from St. Louis to Durham?

17:16 fbru02: ninjudd: by car

17:16 scottj: i guess it is around 6

17:16 scottj: I would go somewhere else

17:17 fbru02: maybe forget the car thing and fly NYC ?

17:19 scottj: yeah or w/ car you could do DC or something else in NC

17:19 ninjudd: fbru02: if you're a baseball fan, you could go through Cincinnati and see the Reds in the NLCS ;-)

17:20 fbru02: ninjudd: i don't know anything about baseball it is not that popular around here

17:21 scottj: beware of MLS :)

17:21 fbru02: scottj: i might be getting picky but DC is the only city i know really well in the states, when i was a kid i was sick and went to DC 15 times (from south america)

17:22 scottj: fbru02: oh yeah don't go there then. for 6 days you can fly anywhere in the US easily

17:24 cemerick: fbru02: Chicago is not too far from St. Louis, in relative terms anyway.

17:25 fbru02: ninjudd: scottj cemerick are u guys going to conj or strange loop ?

17:26 scottj: conj

17:26 cemerick: conj

17:26 clojurebot: (conj {:a 1} (when true {:b 2}))

17:26 ninjudd: conj

17:27 defn: you're going to strangeloop, right?

17:45 the best part about fbru02's question was that it wasn't about <some program or library> at all

17:47 is there no :or destructuring form for vectors?

17:48 hiredman: if you want associative destructuring features you need to use associative destructuring

17:49 ninjudd: it would be useful for optional arguments (defn foo [required & [opt1 :or 4 opt2 :or 8]] ...)

17:49 hiredman: ,(let [{n 0 :or {n :a}} [:a]] [])

17:49 clojurebot: []

17:49 hiredman: ,(let [{n 0 :or {n :a}} [:a]] [n])

17:49 clojurebot: [:a]

17:49 ninjudd: hiredman: oh, right!

17:49 brilliant

17:49 hiredman: ,(let [{n 0 :or {n :a}} []] [n])

17:49 clojurebot: [:a]

17:50 ninjudd: hiredman: thanks

17:50 alexyk: ninjudd: how can I set java.library.path in cake?

17:51 ninjudd: alexyk: 'project.library.path = /whatever' in .cake/config

17:51 alexyk: ninjudd: only in .cake/config? no way per-project?

17:52 ninjudd: alexyk: if it was in project.clj, then everyone would have to have the exact same lib directory location as you

17:53 alexyk: yeah

17:53 ninjudd: alexyk: cake automatically adds lib/native/arch/osname

17:54 alexyk: ok

17:54 as you can guess, I'm redoing tokyocabinet :)

17:54 ninjudd: though that is more for native deps extracted from jars

17:54 alexyk: but what was there is obsolete

17:54 ztellman: what time/day are people flying back from clojure conj?

17:55 I'm making travel arrangements, and I don't know if 7pm on the 23rd would cut things too close

17:55 ninjudd: alexyk: just add [tokyocabinet "1.23-SNAPSHOT"] to your dependencies

17:55 ztellman: i am flying back at 7:15pm on the 23rd

17:56 alexyk: ninjudd: I'm running in -server -d64, and 32 bit failed

17:56 so I recompiled new one, seems to build ok on Mac

17:56 ztellman: ninjudd: do you know when things are actually finishing up on the 23rd?

17:56 ninjudd: ztellman: though i made my arrangements before i heard there was a secret after party ;)

17:57 ztellman: 5:30pm

17:57 alexyk: what problem are you having with the tokyocabinet on clojars?

17:58 alexyk: ninjudd: actually didn't try that... I needed jnilib and built locally

17:59 ninjudd: alexyk: if you're using cake, give the clojars one a try. should seamlessly extract the native deps from the jar and add them to your library path

18:00 alexyk: ninjudd: not only I'm using the cake, I'm swearing by it!

18:00 anybody driving to conj from Boston area? NH/MA?

18:01 cemerick: how are you getting to conj?

18:01 ninjudd: for some reason i imagine cemerick driving to the conj on a motorcycle

18:02 alexyk: ninjudd: it would be a long drive, and Western MA hicks are notorious for their roadblock extortions

18:03 the Scala patrol is especially bad

18:03 ninjudd: Western MA hicks, you say?

18:03 alexyk: yep

18:03 ninjudd: i can't imagine

18:04 alexyk: well it's a leap of imagination, inspired by late-night driving :)

18:04 and truck-stop brawls

18:10 ninjudd: why can't I run cake repl under rlwrap?

18:10 ninjudd: cake repl uses Readline internally, no need for rlwrap

18:11 alexyk: ninjudd: how do I search backwards, C-r?

18:12 ninjudd: alexyk: yes

18:12 alexyk: we don't use rlwrap because then you can't have completion or multi-line history entries

18:13 alexyk: ok

18:16 ninjudd: C-r does nothing for me... How does cake find readline?

18:16 ABS: I'm getting started with Clojure. While setting up my tooling on emacs (primarily slime), I wondered how more experienced folks use completion for Java members.

18:17 Or even the extent to which code completion is supposed to work.

18:17 ninjudd: alexyk: cake should warn you if it cannot find readline

18:17 ABS: The only pattern I have managed to successfully get completions on thus far is (Class/staticMember) eg (System/getProperti[Tab] completes to (System/getProperties) as one would expect.

18:17 Nothing else seems to complete for me eg can I easily see the members of the java.util.Properties instance returned by the previous call in my simple example?

18:18 ninjudd: alexyk: do you have something in ~/.inputrc or ~/.editrc that is changing your input mode?

18:18 alexyk: ninjudd: nope

18:18 but my readline is in macports, am not sure cake sees it

18:19 ninjudd: alexyk: does readline work for irb?

18:19 alexyk: although arrow-up works

18:19 dnolen: ABS: Slime has an inspector, you should be able to inspect Java objects with it.

18:19 ninjudd: alexyk: if up arrow works, then readline is working

18:19 alexyk: C-r doesn't work... will have to investigate

18:19 ABS: Yes, the inspector's nice. I have taken a look at it.

18:19 I was wondering if rapid typing-time completions work?

18:21 or can be made to work with some effort?

18:23 dnolen: ABS: hmm dunno.

18:23 ninjudd: alexyk: could have something to do with libedit on OS X

18:23 alexyk: http://bogojoker.com/readline/

18:24 http://bogojoker.com/readline/#libedit_detection

18:24 technomancy: ABS: it might be able to leverage type hints where those are found, but I don't think it could get method completions on objects for which it doesn't know the type

18:24 alexyk: ninjudd: thx! have to play to get my C-r back

18:25 ninjudd: technomancy: right. you type the method before the object it is called on

18:25 technomancy: yeah, propagating type hints from the arglist through to all its usage inside a defn may be nontrivial

18:26 ninjudd: alexyk: http://hints.macworld.com/article.php?story=20080313113705760

18:26 ABS: dnolen: Thanks.

18:26 technomancy: I see. Makes sense.

18:27 ninjudd: ABS: i use emacs dumb completion M-/

18:27 it uses the list of strings in the file as possible completions

18:28 works pretty well in a lot of cases

18:28 ABS: ninjudd: Yes, dabbrev works well for me too.

18:29 alexyk: ninjudd: thx, the hint saves irb!

18:29 ninjudd: i always though dabbrev stood for dumb abbrev.. heh, it is dynamic abbrev

18:29 alexyk: ...and cake repl

18:29 ABS: ninjudd: :-)

18:30 ninjudd: alexyk: great! want to add the fix to the cake wiki?

18:31 alexyk: ninjudd: sure

18:31 do you need to add me on github to it?

18:32 ninjudd: alexyk: should be open http://github.com/ninjudd/cake/wiki

18:32 alexyk: ok

18:32 ninjudd: needs some love

18:32 alexyk: a bit later will love it a bit :)

18:43 raek: hrm, I try to use enlive templates stored in resources/

18:43 it doesn't work, but if I place them in src/, it works

18:43 both should be on the classpath

18:44 what am I doing wrong?

18:46 hrm, nevermind... it magically started to work :)

18:47 KirinDave: Hey guys.

18:47 It's late in the day and I'm having a problem with a method that really should be easy

18:48 I'm sure that it's a trivial mistake

18:48 https://gist.github.com/8288dd764083f099d0d0

18:48 That doesn't seem to be updating internal structures

18:51 ninjudd: KirinDave: won't (assoc :headers (or headers (:headers response))) replace what you did in the previous two lines if map has :headers in it?

18:51 KirinDave: Oh yeah, huh.

18:51 See, simple mistake.

18:51 ninjudd: :)

18:52 KirinDave: I'm so tired.

18:52 Been working nonstop on this port of webmachine.

18:52 I've almost got everything in place.

18:52 All that's left to do is finish up the edges of the graph.

18:53 And finish the state threading so handlers can modify things.

18:53 ninjudd: KirinDave: is it open source?

18:53 KirinDave: It will be soon.

18:54 Let me get it actually going end-to-end on http requests and we'll opensource it.

18:54 ninjudd: cool. i'll keep my eyes out for it

18:54 KirinDave: It's really nice the way it's working out

18:54 For example, here is some of the graph

18:54 https://gist.github.com/2aff4d471c06d1c0d02f

18:54 Most of the nodes in the graph are just dead simple.

18:55 And once I update to 1.3, I'll do the ^:static thing and think about performance.

18:55 technomancy: so banksimple is the company that's secretly working on a web framework, not relevance... secrets revealed!

18:55 KirinDave: (like that method I showed does way too much work. :\)

18:55 technomancy: Yeah secret is out.

18:55 Someone tweeted it like immediately.

18:56 And now every 20 minutes I get an email or dm from someone asking for work.

18:56 Ahh, startup world.

18:56 ninjudd: KirinDave: this looks great.

18:56 technomancy: KirinDave: someone had a thread a few weeks back on the clojure mailing list something like "Do you think Relevance is secretly working on building a web framework? I hope so!"

18:56 but now we know the truth

18:56 KirinDave: No secret.

18:56 We need a REST API framework

18:56 I think clojure is the best bet for this.

18:57 I saw scala-webmachine and it's pretty opaque.

19:01 I have to say I love Clojure's # convention for gensyms

19:01 This is the first time I've been doing serious macro hacking in Clojure and it's WAY more convenient that common lisp's method.

19:01 This is so much more readable without having an extra let body: https://gist.github.com/c9e6eb3c117db6eb7dca

19:14 ninjudd: ,(meta (with-meta (iterate inc 1) {:type ::foo}))

19:14 clojurebot: {:type :sandbox/foo}

19:14 charliekilo: ztellman, stupid aleph understanding question: for a client that connects to a tcp server and (slowly) uploads binary data, a pipeline will start receiving and processing (partial) messages immediately and *not* wait until e.g. the client disconnects, correct?

19:14 ninjudd: ,(meta (drop 10 (with-meta (iterate inc 1) {:type ::foo})))

19:14 clojurebot: nil

19:14 ninjudd: hmm

19:15 ztellman: charliekilo: each packet will come through individually, yes

19:15 are you not seeing this behavior?

19:15 ninjudd: i feel like i've asked this before. should drop remove meta from a lazy-seq?

19:17 hiredman: ninjudd: the seq before the drop and wafter are not the same seq

19:19 ninjudd: hiredman: assoc, for example, doesn't remove meta though.

19:19 the maps are not the same map in that case

19:23 charliekilo: ztellman, yep, thats what I see ... currently trying to port a Netty-based Clojure application (which has a ChannelUpstreamHandler that forwards the complete message when client disconnects) to the much cleaner aleph .. probably have to rething my approach

19:24 ztellman: charliekilo: it's not hard to accumulate everything

19:26 charliekilo: ztellman, just to make I'm not completely off track, the accumulation would need to happen in the pipeline, not channel, right?

19:27 ztellman: charliekilo: http://gist.github.com/607061

19:27 yes

19:28 that's off the top of my head, mind you, that may have a thing or two wrong with it

19:29 charliekilo: ztellman, thanks, that makes sense ... and sorry about all my obvious questions

19:29 ztellman: charliekilo: if they're not obvious to you, they're not obvious

19:29 I'm trying to get the documentation as clear as possible, every question you have helps me understand how to make it better

19:32 charliekilo: ztellman, then I will continue asking if its not obvious to me and buy you a beer or two at clojure-conj (assuming you will be there)

19:33 ztellman: charliekilo: I'll be there, and keep the questions coming

20:04 ninjudd: how do i pull upstream branches into a forked repository?

20:04 using git

20:20 i think i got it. this helped http://japhr.blogspot.com/2010/09/new-upstream-branch-into-my-fork.html

20:29 technomancy: would a patch to extend clojure.contrib.generic.comparison to java.util.Date be accepted?

21:05 tomoj: anyone know of any clojure stuff which imports any common 3d model format?

21:05 I suppose I could look for java projects

22:47 TeXnomancy: Licenser: hey, let me know if you're can help with merging the lein-search plugin into leiningen or if you'd like me to do it

22:51 actually, gotta go; maybe take it to a mailing list thread

23:13 bhenry: what's the idiomatic way to format a date object?

23:16 hiredman: with style

23:24 bhenry: hiredman: perhaps you can guide me towards style away from this

23:24 (defn display-date [d]

23:24 "takes a db date and turns it into a format easily entered/read"

23:24 (str-join " " [(str-join "-" (map pad-to-2

23:24 [(+ 1900 (.getYear d))

23:24 (+ 1 (.getMonth d))

23:24 (.getDate d)]))

23:24 (str-join ":" (map pad-to-2

23:24 [(.getHours d)

23:24 (.getMinutes d)

23:24 (.getSeconds d)]))]))

23:24 KirinDave: Dude.

23:25 Please. Please. Please use gist.

23:25 bhenry: it's not that long man : P https://gist.github.com/0339a85497a2076275e1

23:26 hiredman: ~google simpledataformat

23:26 clojurebot: First, out of 37000 results is:

23:26 SimpleDateFormat (Java 2 Platform SE v1.4.2)

23:26 http://download.oracle.com/javase/1.4.2/docs/api/java/text/SimpleDateFormat.html

Logging service provided by n01se.net