#clojure log - Mar 25 2010

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

0:00 defn: brandonw: you may well be right, and your solution is fine

0:00 im just curious

0:00 brandonw: yeah, it seems like the destructuring docs of let says that you can only destructure a vec on anything that supports nth

0:01 so if you have a map as an input, you wouldn't be able to destructure it into a vec

0:02 your best bet would be to destructure the specific value you want, and then wrap it in a vector in an additional binding

0:02 ,(let [{i :foo} {:foo {:bar 1 :baz 2}} output-val [i]] i)

0:02 clojurebot: {:bar 1, :baz 2}

0:02 brandonw: hmm that didn't work

0:03 oh right

0:03 ,(let [{i :foo} {:foo {:bar 1 :baz 2}} output-val [i]] output-val)

0:03 clojurebot: [{:bar 1, :baz 2}]

0:05 brandonw: http://pastie.org/885990

0:05 with a little better indentation and a def to make it more concise

0:06 {i :foo} grabs the value mapped to the :foo key in test-val

0:06 defn: brandonw: im sorry if this is a poor quesiton but im still abit lost on how to implement it

0:06 let's say we have...

0:06 brandonw: binding output-val to [i] just wraps that val in a vector

0:06 and then you can return the vector

0:06 defn: ,(def k 5)

0:06 clojurebot: DENIED

0:06 defn: ah darn

0:06 brandonw: yeah, no defs in clojurebot

0:06 except in a let :P

0:07 unless hiredman fixed it...?

0:07 defn: brandonw: i have learned that probably a 1000 times, but there is always the hope :)

0:07 brandonw: ,(let [f (def x 1)] f)

0:07 clojurebot: DENIED

0:07 brandonw: yes he did! :)

0:08 defn: brandonw: so let's say you have {:x {:y 1 :z 2}, :xx {:yy 3 :zz 4}}

0:09 how would you create a [{:y 1 :z 2} {:yy 3 :zz 4}] with destructuring -- my first thought is an anonymous function maybe?

0:10 shales: brandonw: looking at the special forms page, I think that :ivec is just one of the keys in the init-expr map that follows, just as :j and :k are. It's not a special part of let's syntax.

0:10 defn: shales: good catch, thanks

0:11 brandonw: (let [{out1 :x out2 :xx} {:x {:y 1 :z 2} :xx {:yy 3 :zz 4}} full-output [out1 out2]] full-output)

0:11 ,(let [{out1 :x out2 :xx} {:x {:y 1 :z 2} :xx {:yy 3 :zz 4}} full-output [out1 out2]] full-output)

0:11 clojurebot: [{:y 1, :z 2} {:yy 3, :zz 4}]

0:11 brandonw: shales: thanks, i thought i had missed something

0:11 defn: wrapping a vector around two keys isn't possible in the destructuring, i don't think

0:12 defn: im trying to get a big map which is structured like the above

0:12 brandonw: you can destructure the two individual keys in a binding, but in order to wrap them in a vector, you need to explicitly create a vector with the two previously bound keys

0:12 defn: and turn it into [{:x 1 :y 2} {:xx 3 :yy 4}...]

0:12 brandonw: basically, if you have a map as your input, you can't destructure and end up with a vec i don't think

0:13 right, i don't think you can destructure directly into that

0:13 i think the closest you can get is destructuring into the {:x 1 :y 2} and {:xx 3 :yy 4} as two separate values

0:13 and then create a vec inside that binding

0:13 err in the scope of that binding

0:14 defn: heh -- i need to get my head straight

0:14 clojurebot: the world <reply>what the world needs is more higher order functions

0:17 shales: defn: if you just want a vector of all the values of a map you can do (vec (keys m))

0:17 ,(vec (vals {:x {:y 1 :z 2}, :xx {:yy 3 :zz 4}}))

0:17 clojurebot: [{:y 1, :z 2} {:yy 3, :zz 4}]

0:18 defn: bahahaha

0:18 * defn facepalm

0:18 defn: shales: thanks

0:18 brandonw: yep, that would definitely be much easier :)

0:18 that isn't technically destructuring though, right?

0:18 defn: brandonw: thanks for indulging my stupidity

0:18 :)

0:18 brandonw: we're all learning :)

0:19 shales: no it's not destructuring at all

0:19 brandonw: i liked going through that just for the sake of getting some practice with destructuring

0:19 i haven't had a reason to use it yet... i don't think...

0:19 shales: yeah, I've not destructured a map yet either

0:20 defn: me either! :)

0:21 one really handy one listed in the docs:

0:22 ,(let [{:keys [:fred :ethel :lucy]} m] m)

0:22 clojurebot: java.lang.Exception: Unsupported binding form: :lucy

0:22 defn: ,(let [{:keys [fred ethel lucy]} m] m)

0:22 clojurebot: java.lang.Exception: Unable to resolve symbol: m in this context

0:22 defn: why god, why?

0:22 brandonw: the name you want to bind to comes first in a map binding

0:23 plus, you need to have m defind as something

0:23 :)

0:23 defn: brandonw: :keys is a directive

0:23 http://clojure.org/special_forms

0:23 brandonw: ohhhh right

0:23 oh interesting

0:23 so you could get what you originally wanted, a vector of the keys in a destructuring

0:23 cool!

0:24 defn: ,(let [m {:keys [fred ethel lucy]}] m)

0:24 clojurebot: java.lang.Exception: Unable to resolve symbol: fred in this context

0:24 defn: if i knew how to tie my shoes...

0:26 brandonw: actually nevermind

0:27 that only allows you to basically do what i did, without having to do {t1 :x t2 :xx}

0:27 instead you can just do {:keys [t1 t2]}

0:27 shales: yeah, just avoids redundancy

0:27 brandonw: ,(let [{t1 :x t2 :y} {:x "hello" :y "goodbye"}] [t1 t2])

0:27 clojurebot: ["hello" "goodbye"]

0:28 brandonw: ,(let [{:keys [t1 t2] {:x "hello" :y "goodbye"}] [t1 t2])

0:28 clojurebot: Unmatched delimiter: ]

0:28 brandonw: ,(let [{:keys [t1 t2]} {:x "hello" :y "goodbye"}] [t1 t2])

0:28 clojurebot: [nil nil]

0:28 brandonw: hmm

0:29 ,(let [{:keys [t1 t2]} {:t1 "hello" :t2 "goodbye"}] [t1 t2])

0:29 clojurebot: ["hello" "goodbye"]

0:29 brandonw: there we go

0:29 shales: keys in the map must be keywords with the same name

0:29 yep

0:29 brandonw: forgot you had the values in the vector have to be the same as the keywords

0:30 clojure is fun

0:30 too bad i can't use it at work yet

0:31 shales: there's similar directives for keys that are symbols or strings too

0:31 ,(let [{:syms [t1 t2]} {'t1 "hello" 't2 "goodbye"}] [t1 t2])

0:31 clojurebot: ["hello" "goodbye"]

0:31 fanatico: just need to convince them that you want to use a new Java library called "clojure" ;)

0:31 brandonw: :(

0:31 shales: ,(let [{:strs [t1 t2]} {"t1" "hello" "t2" "goodbye"}] [t1 t2])

0:31 clojurebot: ["hello" "goodbye"]

0:31 brandonw: i don't even use java at work yet :(

0:31 heck, i'm making a web app and we don't even use an mvc framework yet

0:32 fanatico: brandonw: php?

0:32 shales: What doesn't this print anything? (.start (Thread. (fn [] (println "Other thread" (Thread/currentThread)))))

0:32 brandonw: c# asp.net forms :(

0:32 wow it is already 12:30 i should be asleep

0:32 good night

0:32 zaphar_ps: use the clr library named clojure then :-)

0:33 brandonw: well we are going to port everything over to java eventually

0:33 but we just need to finish it so it can replace the crap that is in use now

0:33 which would do pretty well on the dailywtf i think :)

0:33 goodnight

0:33 zaphar_ps: just think of all the code that will port over unchanged if it was in clojure

0:33 bmason: I notice in the compojure source some "defn-" calls... what's the difference between this and "defn" ?

0:34 shales: defn- is private

0:34 zaphar_ps: defn- make s a private function

0:34 shales: although I'm not sure what the implications are

0:34 bmason: so not accessible to things using/referring to the namespace?

0:34 zaphar_ps: it won't get exported when the namespace is used/required

0:34 bmason: cool cool

0:34 good to know

0:35 hmm, would be kinda nice to have a reader macro for that

0:35 zaphar_ps: basically it just does (with-meta fun {:private true}) to the function

0:36 bmason:

0:36 bmason: gotcha

0:37 zaphar_ps: which you can do with the #^{:private true} reader macro to shorten a bit

0:38 you can do a lot of fun stuff with metadata on clojure code

0:38 :-)

0:38 bmason: I guess that's not too bad

0:39 in fact more descriptive than C++'s "private"

0:39 zaphar_ps: lol

0:39 bmason: since you're explicitly setting meta data

0:40 instead of performing some *magic*

0:43 shales: hmm, when I run this in my slime repl (.start (Thread. (fn [] (println "Other thread" (Thread/currentThread))))), nothing is printed. Running the same thing in a command line repl does print the "Other thread" message.

0:45 why would that be?

0:45 zaphar_ps: shales: the command line repl's threads all go to the same stdout

0:45 bmason: did you check your inferior lisp buffer?

0:45 I've had stuff come out on that

0:45 shales: bingo!

0:45 zaphar_ps: but the swank repl's spawned thread goes to the lein-swank buffer probably

0:46 heh bmason beat me to it

0:46 inferiror lisp buffer in your case since mine is a little customized

0:47 shales: that's good to know. Thought I was going a little crazy

0:47 bmason: yeah, it had me scratching my head

0:47 zaphar_ps: it's because swank sets up a special *out* for slime but your thread didn't use it

0:47 shales: Know how to direct the stdout to the same buffer?

0:47 bmason: emacs has taken some getting used to

0:48 zaphar_ps: shales: not off the top of my head I'm not sure if the two threads can share the same *out* var

0:49 bmason: you should be able to bind *out* to the correct stream, I would think

0:49 but I'm not sure how you would identify the correct stream

0:49 shales: had same idea. this works: (.start (let [out *out*] (Thread. (fn [] (binding [*out* out] (println "Other thread" (Thread/currentThread)))))))

0:49 zaphar_ps: bmason: capture the value of *out* in the first thread and use it in second thread

0:50 bmason: shales: check out with-out-str

0:50 oh, actually that's a nice one shales

0:51 makes sense

0:57 shales: ah, similar story for *err*

0:59 but Thread.run catches and prints exceptions to stderr _outside_ the binding in the function. Don't think I can do anything about that one except catch and print all exceptions.

1:14 defn: How would I merge something like [{:count 2 :country "US"} {:count 5 :country "US"} {:count 4 :country "DK"} ...] so it would be [{:count 7 :country "US"} {:count ...}...]

1:16 in other words, combine all the maps which contain :country "US", reducing on the val of :count

1:23 hiredman: defn: your maps are wrong

1:23 they should be {"US" 2} {"DK" 4} etc

1:23 merge-with +

1:24 defn: hiredman: this is a slow evolution of a structure

1:24 hiredman: well, it's wrong :)

1:25 defn: originally it was like {:ip-address {:count 5 :country "US"} :ip-address-b {:count 3 :country "RU"}...}

1:25 err actually it was originally {:ip-address 5, :ip-address-b :3}

1:25 then i added countries into the map, then i removed the ip address from the map, blah blah -- it's wrong! :)

1:25 i think i need to rewrite all of this because this is clearly garbage

1:26 hiredman: (apply hash-map ((juxt [:country :count]) {:country "US" :count 1}))

1:27 ,(apply hash-map ((juxt [:country :count]) {:country "US" :count 1}))

1:27 clojurebot: java.lang.IllegalArgumentException: Key must be integer

1:27 hiredman: er

1:27 ,(apply hash-map ((juxt [country :count) {:country "US" :count 1}))

1:27 clojurebot: Unmatched delimiter: )

1:27 hiredman: gah!

1:27 anyway, if you writing it correctly it will work

1:29 your data is your schema, and schemas evolve

1:30 defn: my end goal here is to make a bar graph with incanter which shows the number of instances of IPs from all of the country codes, and then in a key have all of the IPs and the number of times they each occurred somewhere beside it in a key or something

1:30 hiredman: you could just it do with reduce

1:34 ,(reduce (fn [a {:keys [country count]}] (merge-with + a {country count})) {} [{:count 2 :country "US"} {:count 5 :country "US"} {:count 4 :country "DK"}])

1:34 clojurebot: {"DK" 4, "US" 7}

1:39 hiredman: ,(map (fn [[country count]] {:country country :count count}) {"DK" 4, "US" 7})

1:39 clojurebot: ({:country "DK", :count 4} {:country "US", :count 7})

1:48 defn: hiredman: thanks man -- that's very helpful

2:45 ihodes: hey all, I'm a bit of a Clojure newbie (coming from Java and some scheme and Python...) and am having trouble converting a list of strings to a list of chars (strings include "a" "{" etc)

2:45 could someone please point me in the right direction?

2:46 hoeck: ,(map seq ["a", "a-{", ")-"])

2:46 clojurebot: ((\a) (\a \- \{) (\) \-))

2:47 hoeck: ,(mapcat seq ["a", "a-{", ")-"])

2:47 clojurebot: (\a \a \- \{ \) \-)

2:47 hoeck: ihodes: ^^ is that what you want?

2:47 ihodes: that's superb! thanks!

2:48 hoeck: np :)

2:48 ihodes: how does that work? looks somewhat tricky

2:50 hoeck: ,(seq "my String")

2:50 clojurebot: (\m \y \space \S \t \r \i \n \g)

2:50 ihodes: ah, of course... haha thank you so much!

2:50 hoeck: seq returns a sequence of characters from a string

2:50 and mapcat calls seq on each string in the vector and concatenates the result

2:51 ihodes: that makes sense

2:51 i've got one more question – i can convert from char to an int, but back to a char from int is proving more difficult without trusty typecasting–is there a nice way to do that?

2:52 hiredman: ,(char 98)

2:52 clojurebot: \b

2:52 defn: how many core clojure fns are there nowadays?

2:52 ihodes: ,(int \a)

2:52 clojurebot: 97

2:52 ihodes: splendid :) thanks!

2:53 hiredman: clojurebot: ping?

2:53 clojurebot: PONG!

2:53 defn: ,(count (ns-publics 'clojure.core))

2:53 clojurebot: 503

2:53 defn: is that right? 500 core clojure fns?

2:55 hiredman: ,((ns-publics 'clojure.core) '*print-level*)

2:55 clojurebot: #'clojure.core/*print-level*

2:55 hiredman: not a fn

2:55 defn: ah right

2:55 lots of special vars and such in there

2:55 hiredman: not that many

2:57 _ato: ,(count (filter #(and (.isBound %) (fn? @%)) (map val (ns-publics 'clojure.core))))

2:57 clojurebot: 464

2:57 defn: ,(count (filter () (ns-publics 'clojure.core))) gah beat me to it

2:57 clojurebot: java.lang.RuntimeException: java.lang.ClassCastException: clojure.lang.PersistentList$EmptyList cannot be cast to clojure.lang.IFn

3:04 ihodes: hmmm... how can you convert a list of chars to a String? (java.lang.String. '(\a \b \c)) doesn't work, nor does (str '(\a \b \c)) or mapcat str

3:05 hiredman: why would (String. '(\a \b \c)) work?

3:05 ~jdoc String

3:06 ihodes: because you can construct a String from an array of chars, right? thought it was worth a try

3:06 hiredman: a list is not an array

3:06 hoeck: ,(apply str '(\a \b \c))

3:06 clojurebot: "abc"

3:06 ihodes: that's true, but as i'm new to clojure, i wasn't sure if it'd correctly convert :\ was worth a try.

3:06 robink: Hello

3:07 hoeck: hi robink

3:07 ihodes: thanks hoek – that, again, makes sense. i need to get the right mindset here.

3:10 hoeck: ihodes: a list would work if the java.lang.String constructor allowed java collections of Chars

3:10 ihodes: ah ok, so I could, hypothetically, "convert" the collection to an array and then use String. that way?

3:10 though, obviously, using apply makes more sense

3:14 _ato: ,(String. (char-array [\a \b \c]))

3:14 clojurebot: "abc"

3:14 hoeck: ,(String. (into-array Character/TYPE '(\a \b)))

3:14 clojurebot: "ab"

3:15 hoeck: char-array is new to me :)

3:25 ihodes: oh neat

3:28 so if i have a list of string, is there a better way of making them into chars than (map seq '("a" "1" "3"))? that gives me a nasty list of lists deal

3:29 hoeck: ihodes: with mapcat you get one big list of all chars

3:29 _ato: ,(mapcat seq ["a" "1" "3"]) ; as hoeck demoed above ;-)

3:29 clojurebot: (\a \1 \3)

3:30 ihodes: gah, so sorry. i need to get some sleep. thank you all so much–i'll idle around here in the fture so i can help future newbies and save you the trouble :)

3:31 hoeck: :)

3:32 LauJensen: Morning guys

3:38 defn: morning lau

3:41 zmila: good

3:42 defn: how to turn ({:x 1} {:x 2}) into [{:x 1} {:x 2}]

3:43 noidi: ,(into [] (list {:x 1} {:x 2}))

3:43 clojurebot: [{:x 1} {:x 2}]

3:43 hiredman: (doc vec)

3:43 clojurebot: "([coll]); Creates a new vector containing the contents of coll."

3:44 defn: (doc vector)

3:44 clojurebot: "([] [& args]); Creates a new vector containing the args."

3:44 noidi: ah, right

3:44 defn: ah, that's where i went wrong

3:44 LauJensen: ,(vec '({:x 1} {:y 2}))

3:44 clojurebot: [{:x 1} {:y 2}]

3:45 defn: (vector '({:x 1}))

3:45 LauJensen: Would be considered more idiomatic

3:45 defn: ,(vector '({:x 1}))

3:45 clojurebot: [({:x 1})]

3:45 defn: ,(vec '({:x 1}))

3:45 clojurebot: [{:x 1}]

4:10 defn: anyone familiar with incanter?

4:10 im trying to build a histogram using [{:x 1} {:y 2} {:z 3}]

4:12 (doto (incanter.charts/histogram (keys (above-structure)) :legend true) view (incanter.charts/add-histogram (vals (above-structure))))

4:14 Chousuke: is the histogram object mutable? :/

4:15 defn: im just going off of the example here

4:41 Licenser: defn: greetings, I'll have to run for work in a few but I'll fix the walton thing today

4:43 mitkok: Hey, guys. Just installed swank-clojure from ELPA, but when I run slime on clj file it fires the repl with error : https://gist.github.com/5f1f24a67550ca0bb4c6

4:43 defn: Licenser: no worries

4:43 Licenser: have you worked with incanter at all by chance?

4:45 Licenser: Nope never used it

4:45 _ato: mitkok: how are you runng slime? just M-x slime? take a look into ~/.swank-clojure -- you should have 3 jars: clojure, clojure-contrib and swank

4:46 defn: bah this is driving me nuts

4:47 mitkok: _ato: Yep, just 'slime'. I have those three under ~/.swank_clojure

4:50 _ato: hmm

4:51 mitkok: maybe try doing this from the command-line just to check it: java -cp "$HOME/.swank-clojure/*" clojure.main -e "(use 'swank.swank)(-main)"

4:51 Linnk: Hey guys, just started going through the Clojure reference to learn the language. Does #^ always designate a hashmap?

4:51 defn: Licenser: {} is a hash map

4:51 err Linnk: {} is a hash map

4:51 Licenser: I was about to ask why you tell me that :P

4:52 Linnk: Hehe :P

4:52 defn: #^ is a type hint, Linnk

4:52 (defn my-fn [#^String some-text] (println some-text))

4:53 Linnk: defn: Aha, that explains a lot

4:53 mitkok: _ato: I was $CLOJURE_EXT=~/.clojure ( there were my clojure jars ), but when I remove it gives me the same error as executing your command: https://gist.github.com/b755bae0059c4d44db12

4:55 Licenser: #^ is helpfull if you need performance in java interop

4:55 it makes it way faster ;) defn can sing a song about that I guess

4:56 _ato: mitmok: that's strange, so from the command-line it can't find the jars at all. What version are the jars you have in ~/.swank-clojure and what version of java do you have?

4:56 I have: % ls ~/.swank-clojure

4:56 clojure-1.1.0-master-20091202.150145-1.jar clojure-contrib-1.1.0-master-20091212.205045-1.jar swank-clojure-1.1.0.jar

4:57 mitkok: _ato: the same as you, java version "1.6.0_18"

4:57 _ato: may be I need to set path or classpath or something, I\m pretty new

4:58 _ato: you normally shouldn't need to add any configuration to emacs

4:58 and that java command I asked you to run should have worked

4:58 hmmm

5:04 defn: weird -- Incanter doesnt show anything in the frames it creates

5:05 _ato: mitkok: 'fraid I'm out of ideas. Unless perhaps you've got some corrupt jars. http://gist.github.com/343335

5:05 I guess you could try deleting ~/.swank-clojure and rerunning M-x slime so it downloads them again

5:09 mitkok: _ato: I've deleted the dir and the reinstall it from emacs, same error :(

5:10 _mst: 'java -jar ~/.swank-clojure/clojure-1.1.0-master-20091202.150145-1.jar' might be good for a giggle too

5:12 defn: man this is weird

5:12 incanter just refuses to produce any image in the frame it creates

5:12 mitkok: _mst: Invalid or corrupt jarfile clojure...

5:14 _mst: ah hah! interesting :) what does 'file ~/.swank-clojure/clojure-1.1.0-master-20091202.150145-1.jar' think it is?

5:16 mitkok: _mst: Zip archive data, at least v1.0 to extract

5:17 _ato: truncated maybe?

5:17 _mst: hm, so there's at least a zip file header there :)

5:17 yeah, I wonder

5:18 does 'jar tvf ~/.swank-clojure/clojure-1.1.0-master-20091202.150145-1.jar' report any errors?

5:19 mitkok: _mst: java.util.zip.ZipException: invalid END header (bad central directory offset)

5:19 _mst: ah, yick :) so it does look like those .jar files are corrupt

5:20 _ato: perhaps delete them and download manually: wget http://build.clojure.org/releases/org/clojure/clojure/1.1.0/clojure-1.1.0.jar http://build.clojure.org/releases/org/clojure/clojure-contrib/1.1.0/clojure-contrib-1.1.0.jar http://clojars.org/repo/swank-clojure/swank-clojure/1.1.0/swank-clojure-1.1.0.jar

5:22 mitkok: at last, it's working :)

5:23 thanks _mst and _ato :)

5:23 _mst: huzzah

5:23 _ato: :)

5:24 * Licenser_ is back!

5:25 defn: uh oh

5:27 esj: indeed !

5:52 licoresse: Can I undefine something in the repl?

5:56 hoeck: licoresse: (ns-unmap (find-ns 'the-namespace) 'the-symbol)

5:56 Chousuke: ns-unmap can help

5:57 hoeck: or (ns-unmap *ns* 'blah)

5:57 licoresse: great

6:34 bb_oz: so - anyone else new to clojure?

6:36 zmila: me new :)

6:36 relatively

6:37 bb_oz: why clojure?

6:39 underdev: power, sumplicity, java integration

6:39 zmila: "why" for whom? for me or for you?

6:39 underdev: simplicity

6:40 bb_oz: sorry - 'why' for you

6:40 simplicity is one. STM is another

6:40 Linnk: <- barely started, so kinda' new

6:42 cypher23: bb_oz, Power, Flexibility, Concurrency

6:42 marten: for me, because i wanted something functional, and lisp is a mess with way to many implementations, and haskell is too impractical with its purity

6:42 s/lisp/common lisp/

6:45 bb_oz: @marten: lisp. Had been toying with sbcl and ccl for a while. beautiful.

6:53 I was actually hopeful about abcl, but was unsure about the java 'match'

6:54 underdev: you just can't beat clojure's integration

6:55 bb_oz: it certainly appears to be that way. I'll shed a tear for CL though :)

6:57 underdev: its hard to compare a language spec designed in the 80s with one in the late 2ks

6:58 must have been the 80s, because i first used allegro CL in 91

7:01 bb_oz: lisp language spec is much older than the 80's

7:01 and clojure is a lisp-1 :)

7:04 Chousuke: Sometimes it feels like the fact that lisp is standardised is holding it back

7:04 CL, I mean

7:05 underdev: yeah, 1956 i believe

7:05 i meant CL

7:06 bb_oz: @underdev: ah ok - sorry :)

7:06 Chousuke: the standard is missing many things that are needed in a modern language, and then those things are implemented differently between implementations, which is counterproductive.

7:06 underdev: well, you could almost feel the lightbulbs going off in the crowd when rich was doing the "Clojure for lisp programmers" talk when he was discussing programming to abstract sequences instead of reified lists

7:07 bb_oz: @chousuke: clojure should see a lot more development. There's a few books out there as well.

7:07 Chousuke: bb_oz: Clojure's still fairly young as programming languages go, though.

7:12 underdev: my only reservation coming to clojure was that there is so much syntatic sugar (i've spent a decade in tcl, where there is exactly one grain of it). I thought i would be avoiding it, but it turns out i like it.

7:12 usually

7:13 i've seen a few functions that look "write only" to me, but very few

7:13 Chousuke: I really don't see most things in clojure as syntactic sugar anymore :P

7:13 bb_oz: so what are you using clojure for in your profession?

7:14 Chousuke: #() is, though.

7:14 but the syntax for vectors and maps isn't sugar, it's necessary.

7:14 underdev: to a tcl programmer '() is syntactic sugar :)

7:14 Linnk: #^{} is weird too, for a beginner :)

7:15 Chousuke: Linnk: that's kind of required too. there's no other way to attach read-time metadata to symbols

7:15 underdev: (list 1 2 3) (vector 1 2 3) (map :foo "bar")

7:15 not necessary

7:15 Chousuke: underdev: those are not equivalent to the [] versions

7:16 you can't do (defn foo (vector a b c) ...)

7:16 underdev: oic. like i said, i thought i wouldn't like it, but i do, and use them

7:16 :)

7:16 Chousuke: you'd need (defn foo #=(vector 'a 'b 'c) ...) :P

7:17 underdev: one could conceive of a clojure in which they aren't necessary, at least :)

7:17 Chousuke: hm, probably without quotes though. I forget it's the reader

7:17 Linnk: Chousuke: probably right, but it's not very verbose (not implying that verbosity is a good thing), so it took me some time to understand what it actually meant

7:17 Chousuke: underdev: well, yes. But I like having more syntax elements than just lists :)

7:18 underdev: it allows you to write more expressive macros for oen

7:18 one*

7:18 underdev: rt. i didn't think i would, but i do too

7:19 i love the time i spent programming in perl, but it scared my psyche somehow

7:19 HOMOGENY! GIVE ME HOMOGENY!!!

7:19 spariev: lol :)

7:19 Chousuke: the simplicity of having just lists is appealing, I admit, but the pragmatic benefits of vectors and maps as part of syntax outweighs giving up that simplicity.

7:20 underdev: Chousuke: agreed

7:20 zmila: missing one more brace-type for sets :) maybe <:a :b :c> instead of #{:a :b :c}

7:20 * Chousuke is explicitly not mentioning sets there :P

7:21 Chousuke: zmila: nah, those need to stay as symbol characters because of > and <

7:21 and others

7:22 bb_oz: goodnight people

7:32 dmiles_afk: i been imlmenting a full common lisp in java.. unlike ABCL i dont use java object ypes... i use interfaces...

7:32 underdev: neat! so what do YOU think of clojure?

7:32 dmiles_afk: my hope is sometimes i can go thru clojures code and add this LispString LispSequence interfaces to clojures objects

7:33 well i like its invokation syntax

7:33 well i love its invokation syntax

7:34 and the lack of extra work arround using any pre-existing libraries/jarts

7:34 jars

7:34 i actually for a bigish secondlife project use clojures intial prototype

7:35 underdev: cool.

7:35 dmiles_afk: so i love it.. but i also like common lisp.. i want both

7:35 i still have a learning curve to leverage certain concurrency features

7:36 what are these thnigns called?

7:37 underdev: rt

7:38 Chousuke: dmiles_afk: what things?

7:38 you mean the reference types?

7:38 Licenser_: defn: I think I fixed the no result problem

7:38 dmiles_afk: sorry other people in house talking to me.. looking it up

7:39 underdev: Chousuke: i think he was saying..

7:39 nm

7:40 dmiles_afk: Refs and Transactions

7:40 underdev: i thought he was trying to say its somewhat hard to pick which reference type and why. not hard, just keeping them sorted out. Haven't needed clojures concurrancy yet

7:41 dmiles_afk: All reads of Refs will see a consistent snapshot of the 'Ref world' as of the starting point of the transaction (its 'read point'). The transaction will see any changes it has made. This is called the in-transaction-value.

7:41 all tht stuff.. i havent epxored it yet ;)

7:41 but they must be usefull!

7:41 when someone says refernce types my mind goes : Class<Object>

7:41 non pimtives

7:43 Chousuke: dmiles_afk: there are other reference types besides refs :)

7:44 dmiles_afk: oh but what i meant is using ibteraces is adding http://larkc.svn.sourceforge.net/viewvc/larkc/branches/LarKC_CommonLisp_Extensions/platform/src/com/cyc/tool/subl/jrtl/nativeCode/type/core/LispObject.java?revision=458&view=markup to clojures holder objects

7:44 Chousuke: they all have differing concurrency semantics

7:44 dmiles_afk: ibteraces/interfaces

7:44 Chousuke: eep. SVN ;(

7:44 do yourself a favour and learn git :)

7:44 or any DVCS, really.

7:44 dmiles_afk: i work from Murcurial.. but LarKC is the downstream

7:45 underdev: in my current project i finally came up with a workable architecture, where various expert systems with varying degrees of information with be in contention with one another, with observers determining which systems make the better choices... i think i'm going to be needed all that cool concurrancy stuff pretty soon

7:45 Chousuke: ah, right.

7:45 zmila: let's start rel-war about hg-git vs svn :)

7:46 dmiles_afk: http://code.google.com/r/logicmoo-invoke-interface/source/browse/src/com/cyc/tool/subl/jrtl/nativeCode/type/core/LispObject.java?r=78adc38de481044a64f2bbc85b2ef6f62cccb1f1

7:46 ok DCVS :)

7:46 underdev: zmila: you mrsn hg vs svn-git, right ?

7:46 :)

7:46 Chousuke: zmila: I can think of *one* scenario where svn ends up being better than git, and that's when you want to store binary files in version control

7:47 dmiles_afk: oh but the cool part is the common lisp compiler targets anyhting that implments that interface

7:48 vy: xk

7:48 dmiles_afk: but there are a ton of helpers to make it easy

7:48 zmila: yes, git and hg and distributed is ok. but when you are in project whith 30 other people skilled only with svn...

7:48 dmiles_afk: i mean helper classes so clojure doesnt have to implment all 253 methods for each of its datatype ;)

7:48 Chousuke: that's a heavy interface :|

7:49 dmiles_afk: hehe i realized that after i showed it

7:49 Chousuke: I suppose it approaches the same as Clojure's interfaces, but I don't see why it's all in one

7:49 dmiles_afk: most are supposed to return a classcast excetiom like toStr()

7:50 toNumber() etc

7:50 so like intValue() is coded as toNumber().intValue()

7:50 Chousuke: Clojure's interfaces are split up so that for example, to support being invoked as a function you only need to implement IFn

7:51 dmiles_afk: but most caller expect to hit intValur() in case you are already its right class

7:52 yeah.. that kind of need to be donewith this lisp.. that IFn thing is sane ;P

7:52 oh one more url for you Chousuke: http://code.google.com/r/logicmoo-invoke-interface/source/browse/src/com/cyc/tool/subl/jrtl/nativeCode/type/core/SubLObject.java?r=78adc38de481044a64f2bbc85b2ef6f62cccb1f1

7:52 that what it will look like when its done

7:53 (LispObject.ava that is will look more like SubLObject.java .. i know i know still heavy)

7:53 but more what you described

7:54 but clojure tightens it up even saner

7:54 Chousuke: There are probably reasons why the interfaces are so huge, but I can't think of any :P

7:55 dmiles_afk: to avoid casting.. the compiler already vetted the methodcalls will not throw a abstractimplmentationerror

7:55 which is still legal to emit classes that dont fully implment an interface

7:56 (yet creatable)

7:56 Chousuke: hmm

7:56 dmiles_afk: AbstractMethodError is throw i guess

7:56 Chousuke: Clojure has AFoo things to match IFoo, so you can derive from AFoo to get default implementations

7:57 and many of the interfaces actually extend the smaller interfaces, so I guess you do end up with a "huge" interface in the end

7:58 Hm, I wonder where that clojure interface graph chouser did is.

7:58 dmiles_afk: IFoo and IBar extends IObject but maybe IOjbect isnt as big

7:58 oh but IFoo + IObject is really what IFoo is

7:59 Chousuke: http://github.com/Chouser/clojure-classes/raw/master/graph-w-legend.png This is how it was at one point, but that's probably fairly out of date

8:00 dmiles_afk: not horrid .. just well loved

8:01 though StringSeq might be big

8:02 Chousuke: That graph will have to be updated when protocols start being used seriously though.

8:02 most of the interfaces will be replaced with protocols I think

8:02 dmiles_afk: oh diamonds not that big actualy

8:02 one protcol per interface

8:02 +?

8:02 clojurebot: 5 (for large values of 2)

8:03 Chousuke: :P

8:03 dmiles_afk: or on protocal per method?

8:03 Chousuke: dmiles_afk: probably not exactly. The interfaces might get refactored in the process

8:03 dmiles_afk: protocols are basically a group of functions

8:03 dmiles_afk: on/one

8:04 do two protocals share the same functions sometimes?

8:04 Chousuke: eg. "Sequence" would be a protocol of first, rest at least

8:04 dmiles_afk: so it might overlap with COns protocol slightly

8:05 Chousuke: I think the idea is that you're not supposed to think of protocol fns as anything special

8:06 they're just normal functions; the protocol construct just allows efficiently implementing and extending them to work on numerous types

8:06 dmiles_afk: ok.. just becaue they share first() it dont mean that first() is some specific expected implmention

8:07 Chousuke: right. the interface is the clojure function "first". it might be part of a protocol, a multimethod, or a normal function. ideally you shouldn't need to care

8:07 dmiles_afk: makes sense. just like a java interface

8:08 Chousuke: protocols can be extended to work on types retroactively though

8:08 eg. Strings can implement a seq protocol like (extend java.lang.String PSeq {:seq somefn-that-returns-a-string-seq})

8:09 dmiles_afk: so can a text file of chars..

8:09 Chousuke: currently. there are many ifs in the java source to special-case seq to work on strings and other non-clojure types

8:09 dmiles_afk: so that means we can construct copy-to simpler?

8:10 Chousuke: protocols just allow that to be done without a mess of if-elseif-elseif...

8:10 dmiles_afk: i mnean to copy-from the string sequnce of the file that is a seq of chars

8:10 Chousuke: dmiles_afk: it wouldn't really change how seq works

8:10 dmiles_afk: just how it's implemented

8:11 dmiles_afk: i see.. so what you end up with is map of type<->method

8:11 (maps instead of ifthenelses)

8:11 Chousuke: kind of. with caching and other performance tricks

8:13 dmiles_afk: i hink lispers need o be able to do clojure inline to their code easier ;)

8:13 Chousuke: as a bonus, there's one fewer explicit dependency on the JVM.

8:13 dmiles_afk: hink

8:13 ttthink

8:13 good point about the dependancies

8:13 Chousuke: protocols could be implemented on various hosts in various ways

8:16 dmiles_afk: something i strive for sometimes is .NET.. actally .net provides "events" like VB6 used to

8:17 well basically subscriptions.. java has that.. its avaiblme

8:17 but just not used as pervasivly

8:17 Chousuke: you mean the delegate/event syntax?

8:18 dmiles_afk: yeah

8:18 in clojure i can set a field with a IFn?

8:18 and it calls my method when some event happens?

8:19 Chousuke: dmiles_afk: well, you don't *set* a field in Clojure usually.

8:19 dmiles_afk: because that's imperative

8:19 but the reference types do have a watcher mechanism

8:20 dmiles_afk: oh righ thtat unmodifiable as much as can get away with it

8:20 (more unmodifable now.. the faster it will be later)

8:21 Chousuke: hopefully :)

8:22 tomoj: does anyone happen to know the appropriate size for a video screencast to be put on vimeo?

8:22 dmiles_afk: sometimes the event delegate thing can be overdone. just like too much of anything

8:22 but it makes visualzing a solution for a problem easier at time

8:22 s

8:23 Chousuke: events are a bit problematic in functional programming though :/

8:23 tomoj: frp?

8:24 AWizzArd: Chousuke: can you please tell me a bit more about what you mean?

8:24 Chousuke: tomoj: yeah, that was my first thought. But I havne't quite been able to grok it. :P

8:25 AWizzArd: I think events are difficult to model functionally as they fundamentally have "time" associated with them.

8:25 tomoj: http://www.haskell.org/frp/publication.html#fruit

8:25 reading that

8:28 noidi: tomoj, interesting, thanks for the link!

8:28 Chousuke: I get the basic idea of signal -> function -> other signal but what do you do about stateful UI things like modal windows that pop up as a result of a certain signal? :/

8:29 hmmhm

8:29 dmiles_afk: well event subcription.. is like when you modify how some object B implments a method.. when that object gets somethng called on it from A.. it then reacts by calling the evenets subscribers C... the event subscribers C effectivly changed how the orignal A implments itself

8:30 C subscribes to B

8:30 Chousuke: dmiles_afk: in an imperative language it's not a problem since you can just go and change thigns

8:31 dmiles_afk: but in a functional model you need to explicitly model the transformation somehow.

8:31 I suppose you can model it as a transformation of the graph of signal connections. new signal sources and connections appear and disappear as a result of other signals (open window, close window)

8:32 dmiles_afk: yeah .. though heck there is gotta be a clean way to model it functionally

8:33 tomoj: have you both read the paper?

8:33 I just started

8:33 dmiles_afk: model the transformation.. i wonder if you have to model both states

8:33 or three states or four

8:33 Chousuke: dmiles_afk: well, Clojure already has a model for time-varying identities

8:33 dmiles_afk: though not purely functional

8:34 chouser: I'm jumping in late here, but have you looked at dgraph?

8:34 http://github.com/gcv/dgraph

8:35 dmiles_afk: or http://github.com/gcv/dgraph/blob/master/src/dgraph.clj

8:35 * dmiles_afk looking

8:42 _invis: look what I found in Labrepl

8:42 (defn zipm-4

8:42 2 [keys vals]

8:42 3 (apply hash-map (interleave keys vals)))

8:42 Why apply here ?

8:43 we can define same function without it

8:43 chouser: that looks a lot like zipmap

8:43 Chousuke: _invis: because you don't want to use the seq as the parameter, you want to use the items in the seq as the parameters

8:44 _invis: thus you need apply

8:44 _invis: but result the same

8:44 Chousuke: huh? no it's not :/

8:45 ,(hash-map '[a b])

8:45 clojurebot: java.lang.IllegalArgumentException: No value supplied for key: [a b]

8:45 Chousuke: ,(apply hash-map '[a b])

8:45 clojurebot: {a b}

8:45 _invis: ,(hash-map (interleave [:a :b] [1 2]))

8:45 clojurebot: java.lang.IllegalArgumentException: No value supplied for key: clojure.lang.LazySeq@1038a40f

8:45 _invis: emm

8:45 in my emacs it is work :)

8:46 Chousuke: it should not

8:46 _invis: (defn zipm-4

8:46 2 [keys vals]

8:46 3 (apply hash-map (interleave keys vals)))

8:46 Chousuke: you're probably doing something different

8:46 _invis: works

8:46 Chousuke: yes, that's fine

8:46 _invis: fuq

8:46 Chousuke: it has apply

8:46 _invis: I mean without apply

8:46 (defn zipm-4

8:46 [keys vals]

8:46 (hash-map (interleave keys vals)))

8:46 Chousuke: that will fail

8:47 if it appears to work, there's something else wrong

8:47 are you sure you evaluated it?

8:47 _invis: ohh yep

8:47 my fail :(

8:47 I used zipm-3... :)

8:47 that have the same effect

8:50 defn: added support for associative destrucuring for seqs by pouring them into a

8:50 map first, thus supporting associative destruring of & args

8:50 cool

8:55 _invis: why zipmap looks like http://gist.github.com/343522

8:56 (defn zipmap

8:56 [keys vals]

8:56 (into {} (map vector keys vals)))

8:56 Is second better ?

8:56 and simpler

8:56 Licenser_: defn: I'll push a new walton in a few

8:56 defn: Licenser_: you do too much!

8:57 Licenser_: defn: :P

8:57 defn: Licenser_: what piece of code that you added slowed things down considerably, out of curiosity?

8:57 is it the evaluation of code in the sandbox?

8:57 Licenser_: I think the extract-exps thing is the evil doer, bit it gives better results

8:58 http://playground.licenser.net:3000/walton.html

8:58 when you run nit as a service you can just use some kind of cache foir all exps found which will make stuff a lot faster again

8:58 chouser: _invis: yours is certanly simpler, but it also allocates a vector and lazy-seq for every pair, where core's version does not.

8:59 rhickey: name game again...

9:00 so, using mixins for getting a full implementation of map is tricky and complicated, I think now the simplest thing will be for there to be a deftype based defstruct replacement that does that

9:00 deftype would only provide hash+equals

9:00 chouser: _invis: on the other hand 'into' uses transients while core's zipmap does not (yet)

9:01 rhickey: deftype wouldn't do ILookup?

9:01 rhickey: nope

9:01 defn: Licenser_: ah yes, I didn't consider just finding the entire sequence of real expressions

9:01 rhickey: def___ would do full defstruct-style map impl

9:02 Licenser_: :)

9:02 rhickey: plus gives you named type and ability to implement protocols etc

9:02 defn: Licenser_: I must say that part of me is okay with results which don't run in the sandbox

9:02 rhickey: deftypedmap?

9:02 defn: particularly IO functions

9:02 _invis: chouser: so the core's variant if badly ?

9:02 rhickey: defmap?

9:02 defstruct2-the-revenge?

9:02 AWizzArd: oh that sounds interesting!

9:02 Licenser_: defn: with the last update it shows you everything it found when it can't poass it through the sandbox

9:02 chouser: "map" is pretty overloaded already

9:03 defn: Licenser_: ah, cool!

9:03 rhickey: I'd love to just replace defstruct, but it does a few things that would be difficult to replace

9:03 AWizzArd: rhickey: what such a defmap allow better/automatic error detection?

9:03 what ==> would

9:03 rhickey: AWizzArd: what error detection?

9:03 AWizzArd: ok ;)

9:03 defn: Licenser_: how goes clicki?

9:03 Licenser_: defn: pushed

9:03 quite well

9:03 chouser: yeah, struct is a good name

9:03 defn: Licenser_: do you intend to keep up this pace with clojure indefinitely?

9:04 you seem like you've been really digging in, in the last week or two

9:04 * Licenser_ nods

9:04 Licenser_: I love clojure

9:05 defn: yeah it's really a fantastic language -- speaking of which...

9:05 Anyone have any suggestions on "selling" clojure to management?

9:05 chouser: "typed struct"?

9:05 Licenser_: defn: I know it will be slower again at some point

9:05 chouser: deftstruct

9:05 Licenser_: defn: I don't seel it, I just use it :P

9:05 defn: Licenser_: My goal is to build this particular tool for work so well, and make it so fast, that they cannot turn it down

9:06 however, I think there still might be a manager or two who is scared of it

9:06 raek: defrecord

9:06 rhickey: chouser: wow, that's subtle, I can hardly see that t

9:06 Licenser_: rhickey: by the way. *thumbs up* again for this nice languae

9:06 defn: rhickey: yes I didn't see it either

9:07 rhickey: although they would be deft

9:07 defn: haha

9:07 chouser: could go the other way. deftypeds

9:07 defn: daftstruct

9:08 bsteuber: I like deft :)

9:09 hoeck: deftype*

9:09 Licenser_: defn: cool :)

9:09 what tool do you plan to build if I may ask?

9:09 rhickey: Licenser_: thanks!

9:10 chouser: deftypedmap

9:11 Licenser_: rhickey: thank you

9:11 :)

9:11 cgrand: defmaptype

9:11 hoeck: defr, defs, defp

9:11 lpetit: please, a synthesis on what exact beast is about to get a name ?

9:11 rhickey: I'd like to avoid "record"

9:12 lpetit: I don't understand the difference from plain usage of deftype

9:12 rhickey: lpetit: moving map impl capability into a deftype based macro, rather than the magic now in deftype

9:12 * lpetit thinks he just showed his weak understand of all of this ...

9:12 chouser: lpetit: essentially what deftype is now if you specify IPersistentMap but don't implement it

9:12 raek: record seems to be a rather unused synonym for struct

9:12 defrecord would be a simple, pronounceable name

9:13 Licenser_: ls- l

9:13 fogus: rhickey: you mean avoiding the whole (deftype foo IPersistentMap ...)?

9:13 defn: . .. bin/ lib/ src/

9:13 fogus: ah nevermind... I see

9:13 rhickey: fogus: yes

9:13 lpetit: rhickey: a kind of macro inheritence :-)

9:14 hoeck: deftype* for the limited deftype, and deftype for the one implementing IPersistentMap

9:14 rhickey: lpetit: not really, just like def* on def etc

9:14 defn: hoeck: i dont like that

9:14 too confusing IMO

9:14 not as pronounceable either

9:14 rhickey: defmap

9:14 defn: rhickey: i like that

9:15 rhickey: deftypedmap is most descriptive, but long

9:15 lpetit: rhickey: (was joking for macro inheritence). Aren't there really 2 aspects to the problem : the implementation was "magic", ok. But should the "end user" of deftype really bother having 2 different defxxx ? Or could it still be an option of deftype ?

9:15 rhickey: I like including map, since the whole point is to get a map-like object for data

9:16 lpetit: it ends up option for deftype is more complex to specify and use

9:16 cemerick: so many "map" things... :-/

9:16 fogus: defmappything, defprototype, defstructure, defbasemap ... I stink at naming

9:16 rhickey: cemerick: but this is a map thing

9:16 lpetit: rhickey: could one still do anything he could with deftype, or would some restrictions also come with "defmap" ?

9:17 rhickey: lpetit: deftype would only provide hash/=, everything else on the user

9:17 no magic impls

9:17 defn: deform?

9:17 lpetit: ok

9:17 chouser: deftype would still get some kind of mixin feature?

9:18 rhickey: chouser: maybe, but doing this first will get the magic out of the way and pave the way for a release

9:18 lpetit: and "defmap" would be an out-of-the-box map-like type maker ?

9:18 cemerick: rhickey: {} are maps, so are struct-maps. defmap, should it exist, implies a superset relation to all other maps. *shrug*

9:18 of course, it's a totally different thing.

9:18 chouser: I quite like "typed map" as a concept name, even if deftypemap is too long

9:18 rhickey: I've done a bunch of work on mixins, a fundamental challenge is that in order to fully implement map etc for someone, you need to be able to construct instances, communicating everything needed to the mixin in order to do that is a huge complexity

9:18 cemerick: deftmap is no good?

9:19 rhickey: whereas most abstrct impls never need to do that, basing everthing instead on one or two methods left to derivee

9:20 but that would make the defstruct-like case one of mixing in *and* providing some core fns, begging for a detmap macro anyway

9:20 defmap

9:20 cemerick: I don't see that implication

9:21 lpetit: "defmap" : map in the "type" sense, or in the "instance" sense. The name is confusing, I guess

9:21 rhickey: cemerick: huh, deftmap is surprisingly more readable than deftstruct

9:21 lpetit: defmaptype

9:21 defn: i like deftmap

9:21 lpetit: -1 for deftmap

9:22 defn: hey you can't do that!

9:22 chouser: lpetit: hm, good point. It is defining a type not an instance.

9:22 lpetit: how often will one use "defmap" / "deftypedmap" etc. ? No that often, so let's the name maybe be a bit self-explanatory, he ?

9:22 defn: lpetit: you could stil think of it as "define a type of map"

9:22 AWizzArd: defmaptype could also be an alternative

9:23 chouser: nearly every mature codebase will use this thing

9:23 lpetit: defn: that is a lot of implicit meaning on the letter t :-)

9:23 cemerick: chouser: but how many times? lpetit's got a point. def-typed-struct then. :-P

9:23 AWizzArd: I use it often.

9:24 djpowell: So what will the difference between reify, and slimmed down deftype be?

9:24 lpetit: Let's think a little bit about others willing to create "type builders". The name we're trying to invent may well show the path to how name such "type builders"

9:24 AWizzArd: that is, deftype + IPersistentMap (without providing an implementation)

9:24 chouser: djpowell: deftype will still not create closures

9:24 lpetit: AWizzArd: which percentage of your codebase ? :)

9:25 * cemerick would vote for breaking defstruct. :-D

9:25 AWizzArd: yeah sure, only a fraction, but I use it in lots of files

9:25 chouser: cemerick: yeah, I wouldn't fight that proposal at all.

9:25 cemerick: They've been semi-deprecated from the start, really.

9:25 rhickey: cemerick: I thought about magically interpreting the second arg to defstruct if a vector

9:25 so compatible move

9:26 but...

9:26 djpowell: so how will you access fields in the new deftype without ILookup?

9:26 rhickey: ,(defstruct foo [] () {})

9:26 clojurebot: DENIED

9:26 AWizzArd: cemerick: what are "they"?

9:26 rhickey: ,(foo)

9:26 clojurebot: java.lang.Exception: Unable to resolve symbol: foo in this context

9:26 chouser: never used defstruct anyway, and I'm all about breaking other people's code.

9:26 cemerick: AWizzArd: structs

9:26 AWizzArd: I used defstruct very often, but no replaced virtually every occurrence with deftype.

9:27 rhickey: so (defstruct foo [a b c] ...) gets newness

9:27 bsteuber: so is there anything defstruct can do that can't be done with deftstruct?

9:27 cemerick: rhickey: I think that piece of naming real estate is too valuable for something like defstruct to occupy forever.

9:27 rhickey: bsteuber: yes, see above, defstruct can have arbitrary keys, runtime creation

9:27 cgrand: djpowell: (:foo x) but no (x :foo)

9:28 stuarthalloway: let defstruct be the comprehensive thing

9:28 defn: stuarthalloway: thanks for making labrepl free

9:28 stuarthalloway: r/defstruct/deftype

9:28 cemerick: stuarthalloway: structs really shouldn't provide implementations tho

9:29 conceptually, I mean

9:29 stuarthalloway: and then name the primitive thing something that suggests its primitive/rawness

9:29 cemerick, sorry, meant deftype

9:29 rhickey: cemerick: really?

9:29 cemerick: struct == no impls?

9:29 chouser: deftypedmap won't support arbitrary keys?

9:29 rhickey: but defstructs do implement a lot

9:29 stuarthalloway: please not deftypedmap. ick.

9:30 rhickey: chouser: yes it will, full expando

9:30 cemerick: rhickey: no, I mean user-provided impls. Should conceptually just be a bag of slots.

9:30 chouser: ok, then I misunderstood "defstruct can have arbitrary keys"

9:30 stuarthalloway: defmap w/b better (sorry late to the conversation, know I am retreading ground here)

9:30 AWizzArd: yes, what does that mean? Arbitrary keys?

9:30 rhickey: cemerick: hmm, well that rules out its use here, as this new thing will allow impls

9:31 * cemerick scrolls up frantically

9:31 lpetit: I vote for cgrand's proposal. We're talking about a flavor of deftype. Let's call it defmaptype. Or prune defstruct, long live new defstruct ! :-)

9:31 rhickey: does anyone else agree with cemerick that struct implies no impls?

9:31 stuarthalloway: yes

9:31 (I am now everyone)

9:32 djpowell: i would assume that

9:32 cemerick: rhickey: I'm having trouble reconstituting the context now. Can you restate the objectives, moving pieces?

9:32 chouser: no

9:32 C++ structs can have implementations.

9:32 stuarthalloway: argument by appeal to C++? Isn't that a category of fallacy? :-)

9:32 chouser: what etymology of "struct" rules it out?

9:32 cemerick: chouser: then by all means... *groan* ;-)

9:33 rhickey: this new thing will be a deftype with full map impl - meta, expando keys, etc, while retaining deftype's ability to implement protocols and interfaces

9:33 stuarthalloway: defawesome

9:33 chouser: ha!

9:33 rhickey: Will it come with IFn for lookup?

9:34 cemerick: rhickey: ah, so a simplification avoiding IPersistentMap explicitness.

9:34 raek: I believe struct/record implies map-like-thingy with fixed set of keys, too

9:34 rhickey: chouser: yes, everything that destructs have (except maybe the k/v factory) + a type

9:34 Chousuke: I think there will soon be too many defblahs :P

9:34 AWizzArd: And if one would not add key/value pairs at runtime of keys that were not specified in the definition, would it retain deftypes access speed?

9:34 rhickey: cemerick: yes, that's the prime objective - magic removal

9:34 defn: i dont like pruning defstruct

9:35 rhickey: one use case for defstruct remaining is resultset-seq and its ilk

9:35 lpetit: rhickey: sorry to repeat myself, but "a deftype with full map impl" == "defmaptype" :)

9:35 stuarthalloway: people will learn what it is, so I would rather have a short, pronounceable name

9:35 djpowell: id love a resultset-seq that returned deftype things

9:35 rhickey: lpetit: defmaptype is still a candidate, but it seems no one likes it or anything else much, yet

9:36 djpowell: that would require eval and runtime code gen

9:36 lpetit: grmlml

9:36 djpowell: ah yeah

9:36 raek: I agree with stuarthalloway, pronounceability is a big deal

9:36 defn: rhickey: im not averse to defmaptype, but i agree with stuart that it'd be nice if it were more pronounceable and quick to talk about, defmaptype brings to mind three different concepts

9:36 all of which apply, but dont capture the "essence" IMO

9:37 AWizzArd: I suggested defmaptype and would not find anything bad about typing in these few letters 'type'. No productivity stopper.

9:37 defn: im going back to deftmap

9:37 rhickey: I think that it is important not to disturb defstruct needlessly, and that something with mapo in it is more indicative of what is happening that defstruct was - defstruct only made sense once you read that it produced struct-maps

9:37 Chousuke: please, no :P

9:37 arbitrary abbreviation is just not cool

9:38 AWizzArd: deftmap is not my favourite

9:38 defn: deftmap has my voice -- it's memorable, unique

9:38 lpetit: let's do it piece by piece

9:38 defn: vote*

9:38 lpetit: we all agree on a "def" prefix :-p

9:38 cgrand: going latin: defres

9:38 AWizzArd: I would say it should also include "map"

9:39 or struct or record

9:39 chouser: I think my favorite is to replace defstruct. But if not that, defmaptype -- when you call the ctor you get a "typed map"

9:39 marten: cgrand: defres sounds more like it defines a result or something

9:39 defn: defrec

9:39 cemerick: chouser: +1

9:39 I'm still very wobbly on the notion of structs having user-defined impls tho.

9:40 AWizzArd: Yes, I would also say: 1) defmaptype, 2) defstruct, 3) defmap, 4) deftypedmap

9:40 cemerick: That's a class, or a type, but not a struct.

9:40 chouser: just because C++ does it, doesn't mean its wrong. :-)

9:40 defn: haha ive been thinking that this whole time!

9:40 i thought i might be the only one

9:40 djpowell: does map really capture the key/value pairness of it. something like props or something?

9:40 cemerick: chouser: no, but in my head, class < type < struct

9:41 w.r.t. complexity / "completeness" of implementation

9:41 rhickey: huh

9:41 AWizzArd: or.. defclass

9:41 cemerick: shite. class > type > struct, I mean

9:41 cgrand: I agree with chouser's motion: destruct or else defmaptype

9:41 defn: defmaptype then for me

9:42 chouser: "class" is bad for this. Hosts will already have the name "class" and we'd do best to let them have it.

9:42 defn: but going back to what stuart mentioned, it's just not very, i dont know, something just doesnt fit about it for me

9:42 rhickey: well, if we are saying that types get these dynamic names, and can implement protocols+interfaces, this is plainly more than struct was, and you'll just be explaining destruct as creating a mao-like type

9:42 AWizzArd: chouser: agreed

9:42 rhickey: map-like

9:42 so, keeping type in there is good

9:43 chouser: defstructtype :-/

9:43 AWizzArd: uh ;)

9:43 defn: deftap

9:43 cemerick: chouser: yeah, I wasn't suggesting 'class' for anything.

9:43 AWizzArd: cemerick: i suggested "defclass", but also don't really like it

9:43 * rhickey likes defmaptype better than defstructtype

9:43 djpowell: defmaptype doesn't seem bad. it's got arbitrary slots (map) and is typed (for protocols).

9:44 defn: are there any other def*s which are as long as defmaptype?

9:44 rhickey: what about Stu's idea that this gets the simpler name - deftype, and the primitive one gets another name

9:44 cemerick: defprotomap? :-/

9:44 chouser: Are hash-map and array-map exampels of map types?

9:44 defn: it just seems overly descriptive to me "defmaptype"

9:44 AWizzArd: I just hope that the main thing I need to do will be: rename (nearly) all my deftypes with defmaptype and remove the IPersistentMap and be done :)

9:45 rhickey: chouser: sort of

9:45 chouser: well, they are types of map, but not maptypes. :-/

9:45 AWizzArd: defn: is it bad to have a self documenting name?

9:45 defn: rhickey: im on board with stuart

9:45 cemerick: rhickey: everything we're talking about will respond true to (map? ...)?

9:45 defn: AWizzArd: no i just think it is actually somewhat confusing in that it is overly descriptive

9:45 marten: +1 for defmaptype

9:45 chouser: I'm ok with stuart's idea, we just need the simpler-thing name. defsimpletype ?

9:46 defcoretype

9:46 defminitype

9:46 defn: beating a dead horse... deftmap

9:46 marten: i don't really like deftmap in that i'd like to keep "type" in full in there

9:47 Chousuke: t is just arbitrarily abbreviated

9:47 djpowell: are these going to probably be the core thing that people will mostly use for modelling, and the minimal ones will be mostly used for implementing bits of clojure and stuff? If so, then maybe deftype would be snappier for the expando ones

9:47 lpetit: defrawtyp

9:47 defn: Chousuke: and def isn't?

9:47 lpetit: defrawtype

9:47 Chousuke: defn: no, it's not.

9:47 defn: defn isn't?

9:47 AWizzArd: is defrawtyp really much better that defmaptype?

9:47 Chousuke: defn: nope :)

9:47 chouser: AWizzArd: it's for the other thing.

9:47 cemerick: Might be time to put a page on assembla with descriptions of the different fns. The simpler/primitive/core concepts have gotten twisted.

9:47 stuarthalloway: yes, because it is on the less-often used thing

9:47 cemerick: rhickey: ^^

9:47 Chousuke: defn: those are "fundamental" IMO.

9:47 esj: a struct and a map - > defstrap. Just kidding.

9:47 Chousuke: defn: the t in deftmap is just weird.

9:48 stuarthalloway: +1 to djpowell

9:48 defn: Chousuke: it's two pronounceable english words

9:48 * defn shrugs

9:48 cemerick: Chousuke: you can blame me for that idea :-/

9:49 raek: defrecord, anyone?

9:49 rhickey: cemerick: I don't see how, deftype makes a raw type with hash/=, and you can implement protocols and interfaces with it, the new thing will implement a full persistent map

9:49 defn: raek: would you settle for a defrec?

9:49 lpetit: chouser: me too am not "at home" with the dichotomy between what could be viewed as "technical types" (e.g. hash-map, array-map, linkedhashmap), and "domain types"

9:49 rhickey: raek: I'd rather not add another term

9:50 AWizzArd: defrec / defrecord are possible, but so far Clojure never had "records"

9:50 Is an instance of a defrecord a record?

9:50 rhickey: defbasetype

9:50 Chousuke: rhickey: I assume you want to encourage user-defined types to be map-compatible?

9:50 raek: defn: I generally don't like abbreviations, but maybe, yes

9:50 stuarthalloway: the base thing should have a simple name: defraw? deft?

9:50 rhickey: Chousuke: I want to encourage types used for data to be maps, yes

9:50 stuarthalloway: deft is actually kinda cool

9:50 Chousuke: rhickey: I think in that case deftype and deftype* would be okay.

9:50 defn: deft is more than cool

9:50 it's awesome

9:51 Chousuke: rhickey: deftype would be the default, and deftype* for those who know what they want. :P

9:51 rhickey: types used for things like e.g. data structures and the reference types

9:51 stuarthalloway: deft is my favorite, deftype/deftype* is ok too

9:51 defn: deft is annoying in that it's so obvious IMO

9:51 rhickey: deft + deftype - too cute?

9:51 defn: rhickey: no, i love it

9:52 hoeck: deft is nice, quite short and fundamental, like defn

9:52 AWizzArd: would one of those be like the current deftype?

9:52 defn: hoeck: are you referring to me or the macro? :)

9:52 rhickey: AWizzArd: nothing is like the current deftype

9:52 defn: are you calling me short and fundamental?

9:52 rhickey: base and base+map

9:52 stuarthalloway: deft is base

9:52 Chousuke: deft looks like an abbreviation of deftype though... it might not be immediately obvious that they are variants of the same thing :/

9:52 stuarthalloway: deftype is base+map+etc.

9:53 seths: defn: you're just a macro which expands to def

9:53 defn: Chousuke: i disagree -- it seems pretty obvious to me

9:53 Chousuke: hm, if it's that way around it might make sense

9:53 defn: seths: that hurts, man. take it back.

9:53 hoeck: defn: short, fundamental and nice :)

9:53 raek: which one is the most used? base or base+map?

9:53 rhickey: when people see 'record' do they think more of data than they do with 'type'

9:53 AWizzArd: yes

9:53 underdev: stuarthalloway: been going through labrepl, all day yesterday, should be done today. very cool man!

9:53 stuarthalloway: underdev: thanks

9:53 defn: rhickey: yeah, i immediately think of a database

9:53 rhickey: for me, one crime of OO is when people wall up ordinary data in Employee etc classes

9:54 making things maps makes them amenable to generic handling via the standard lib

9:54 bsteuber: maybe rename defstruct to defrecord and use its name

9:54 if the only normal case for old defstruct is databases

9:55 rhickey: OTOH, there's no reason for a Ref/Atom/PersistentVector implemented with deftype to have a map-like impl

9:55 lpetit: stuarthalloway: yeah, labprel is an amazing piece of work, both from the technical and the pedagocial sides

9:55 AWizzArd: rhickey: do you mean that in general data objects should be stored in maps instead of classes?

9:55 rhickey: how would you all categorize the difference between them and Employee?

9:55 stuarthalloway: lpetit: amazing is a bit strong, I'll settle for "useful" :-)

9:55 defn: rhickey: (inc labrepl)

9:55 err sorry, not directed at you

9:55 lpetit: stuarthalloway: don't be so modest :-)

9:56 defn: stuarthalloway: is it possible to have tests run over and over again? or do you need to call script/test every time?

9:56 AWizzArd: I don’t understand that part of walling up ordinary data in classes such as “Employee”.

9:56 etate: how do you guys know which versions of libraries to use with others?

9:56 lpetit: stuarthalloway: the last piece of work is to have mini-repls right in the webapp, I guess :)

9:57 seths: lpetit: he can steal the code from http://lotrepls.appspot.com

9:57 stuarthalloway: domain entities should rarely be classes

9:57 rhickey: defentity

9:57 lpetit: stuarthalloway: with possibility to "reset" them so that you can work on a subject without having succesfully worked on the previous ones on which they are built

9:58 rhickey: definformationholderthingy

9:58 etate: as in even with leiningen you still need to specify the right versions of all libs you'll use in the dproject.clj

9:58 Chousuke: defdata :P

9:58 AWizzArd: I would slightly prefer defentity over definformationholderthingy

9:58 etate: so what am i missing?

9:58 :D

9:58 AWizzArd: rhickey: could you say a few more things about this example of Employees storing data?

9:58 Chousuke: or the ultimate: "dwim"

9:59 defn: stuarthalloway: i realize you're very busy, but if you get a chance in the next couple weeks I would love to see a video + blog post about getting started on circumspec. I've been really interested in finding an autotest-like tool for clojure, and circumspec is as close as it gets

9:59 lpetit: did we switch subject, or is defentity ... related to deftype/deftype*/deft ?

10:00 stuarthalloway: deft is for the deft

10:01 defn: you can run the tests within the repl at any time. Just (use 'circumspec) (watch)

10:01 rhickey: lpetit: I'm trying to tease out the difference between types used as program entities (data structures, reference types etc) and types used as information holders. The latter should always use the map-like type. So, if that distinction works, then maybe there are names that imply the difference

10:01 stuarthalloway: defn: (1) I am hoping that Sierra will take circumpec's skin and put it over lazttest's guts, so I wouldn't do the tutorial yet

10:02 (2) let's talk Sean Devlin into doing the tutorial

10:02 seths: stuarthalloway: way to delegate :-)

10:02 rhickey: does anyone understand what I am talking about above?

10:02 stuarthalloway: rhickey: warming to the distinction

10:03 cemerick: rhickey: when you separate reference types from "information holders", not really.

10:03 rhickey: one reason Clojure wen out without objects is bacuase I wanted everyone to put their information in maps

10:03 underdev: rhickey: as the leader of our cult, we'll accept it by faith

10:03 lpetit: rhickey: I think I do

10:03 * hoeck understands

10:03 rhickey: your app has some structures associated with the implementation, and some with the information

10:03 stuarthalloway: use defentity to build concretions, and deftype to build abstractions

10:03 rhickey: a vector is the former, an Employee is the latter

10:04 stuarthalloway: and now, with my preferred names:

10:04 deft is used to build abstractions, like vectors

10:04 lpetit: rhickey: defentity seems too "oriented" to me. To specific. deftype would see more "evident" business app usage

10:04 stuarthalloway: deftype is used to build concretions, like Employees

10:04 rhickey: forget defentity

10:04 fogus: defknowledge

10:05 defn: stuarthalloway: im on board with you 100%

10:05 i dont think ive disagreed with a single thing you've said thus far actually, heh

10:05 rhickey: fogus: it's more raw than knowledge

10:05 cemerick: My conceptualization is that I have structs (simple, expandable maps), types (maps that have some callable impls attached), and references (such as atoms, which can hold structs and types). Mix fns that operate over all of them.

10:06 stuarthalloway: separate but related issue: we need to tell the concretion/abstraction story, which this may help us do

10:06 rhickey: cemerick: what would you use to implement PersistentVector?

10:06 cemerick: ah, now I see where you're coming from

10:07 rhickey: what I'm calling types, minus the map impl, plus fields.

10:07 rhickey: cemerick: that's not distinct enough in my mind

10:08 stu is making the point here that the base thing is for library devs, and thus confusing for app devs who normally just find that already there, but library devs need lang support too

10:08 the latter my point

10:09 defn: im not sure i follow rhickey

10:09 Chousuke: I think I would like defrecord for plain data + map interface, deftype for the "lower" level. but then defstruct becomes obsolete

10:09 defn: specifically the "and thus confusing for app devs who normally just find that already there"

10:09 cemerick: rhickey: It seems like the array of options one might want (map impl or no, fields or no, impls or no) points towards having a single configurable entry point.

10:10 rhickey: vector/map/atom/String etc are programming construct, Employee, Roster, SalesReport etc are domain data entities

10:10 cemerick: you're trapped in implementation details, I think

10:11 bsteuber: how about defdata, then? :)

10:12 rhickey: bsteuber: maybe

10:13 defprogramconstruct

10:13 definformationconstruct

10:13 cgrand: coretypes and types?

10:14 cemerick: domain type

10:14 fogus: Digging back into my dusty CLIPS store... deftemplate

10:14 rhickey: definfotype

10:14 hoeck: deftype (base+map) and defbasetype (base only)

10:15 bsteuber: defmodel

10:15 noidi: cgrand, I like coretype vs type

10:15 rhickey: models are usually bigger things

10:15 bsteuber: okay

10:15 stuarthalloway: coretype isn't bad if you really want to type that many chars :-)

10:15 noidi: I assume that won't be too often?

10:15 esj: defdataform

10:15 rhickey: core implies central or important, doesn't get at key distinction

10:16 stuarthalloway: but if I keep saying deft/deftype long enough you will all surrender eventually

10:16 cgrand: impltype

10:16 defn: yeah, ive taken to naming the file which contains my -main, "core.clj" -- that is a "core" AFAICT

10:16 sbt: what is conc in clojure?

10:17 cemerick: basetype

10:17 inittype

10:17 raek: is the map vs Employee class thingy what stuarthalloway referred to as something like "data-as-contract" in one of his talks?

10:17 noidi: isn't the main distinction between abstract and concrete types?

10:17 fogus: template

10:17 bsteuber: My votes at this point would be 1. defstruct (old defstruct -> defrecord) 2. defdata 3. defrecord 4. defmap

10:17 noidi: vectors and such are abstract while employees are concrete

10:18 bsteuber: but I'll leave now - so good louck with finding a good conclusion

10:18 raek: ...if so, where can I read more about this philosophy?

10:18 defn: raek: which talk?

10:18 stuarthalloway: noidi: or maybe code domain vs. problem domain

10:18 raek: it was for a ruby audience

10:18 stuarthalloway: raek: data as contract is just about "don't hide data"

10:19 rhickey: code domain/ information domain

10:20 stuarthalloway: raek: once data is immutable, protecting it with accessors is (even more) silly

10:20 and as soon as you serialize or persist you commit to supporting a data format, not a programmatic interface

10:21 rhickey: defcodetype, definfotype

10:21 raek: ah, yes. I see

10:21 noidi: rhickey, and the latter implement the map interface, while the former don't?

10:21 rhickey: right

10:22 raek: defdatadatatype

10:22 noidi: what if I want to add a new map-like type, which one would I use?

10:23 for code

10:23 I think the names should reflect the semantics, not the most common use cases of each function

10:26 raek: (found the talk: http://rubyconf2009.confreaks.com/21-nov-2009-10-25-clojure-for-ruby-programmers-stuart-halloway.html)

10:26 noidi: for that reason I liked the defmaptype/deftype proposal

10:26 although to make the former shorter, to suggest that it's the common case, I think it should be shortened to deft (to match defn)

10:28 rhickey: cgrand: defimpl good, maybe defimpl, definfo

10:29 cgrand: I like deftype for the common case (definfo)

10:29 fogus: My fav at the moment is definfo

10:29 cgrand: ,(meta (let [i 1] #^{:foo i} [i])) ; can this be relied upon?

10:29 clojurebot: {:foo 1}

10:31 * cemerick finds definfo really grating, just phonetically

10:31 rhickey: yeah

10:31 esj: deffacts

10:32 fogus: hrm... I find it fun to say

10:32 * esj apologises for his oneword outburts

10:34 defn: rhickey: way OT but did I hear right that you were a professional musician in one of your introductions?

10:34 i was just curious what instrument

10:35 noidi: cemerick, yeah, it sounds like pig latin :)

10:36 I don't know how a native speaker would pronounce it, but I have trouble placing the emphasis on any syllable without "definfo" sounding weird and foreign

10:37 it sounds too much like a single word

10:41 defn: go down on the def sound

10:42 like a falling tone in chinese

10:42 raek: thanks for the link

10:45 * fogus Clojure as a Faustian model of programming.

10:47 esj: nobody told me about @(future (:Mephistopheles))

10:50 etate: hmm.. i finally got clojure setup adequately and now when i slime-connect and type a form, it blocks indefinitely

10:50 anyone else experience deadlock like this?

10:51 qbg: But slime-connect is successful?

10:51 etate: yes, i get a REPL

10:51 after pressing y to the version incompatibility

10:52 i should probably also point out that the version of slime i'm using is from cvs

10:52 not from ELPA

10:52 qbg: How recent?

10:52 etate: 2010-03-21

10:53 4 days old

10:53 works fine with common lisp

10:54 also it seems to work when i type in numbers, just not when i type in forms

10:54 qbg: I know that at least not too long ago recent versions of slime would not work with Clojure

10:56 rhickey: bbl

10:56 etate: qbg: indeed, i just tried with an earlier version and it works

10:56 qbg: the 2009 (ooold) version in ELPA works but not cvs slime

10:56 qbg: etate: I just tried the 2010-03-21 version, and it seems to work for me.

10:57 etate: qbg: what was your (slime-setup) ?

10:57 qbg: also are you using the maven plugin or are you using lein swank?

10:58 qbg: I'm using (slime-setup '(slime-repl)), and so far I just tested using M-x slime

10:58 etate: qbg: i was using (slime-setup '(slime-fancy slime-repl)), and lein-swank v 1.1.0

10:59 qbg: Seems to work with lein-swank also

10:59 etate: qbg: which version of lein swank?

10:59 qbg: 1.1.0

11:00 etate: qbg: and you tried typing (+ 1 2 3) ?

11:01 qbg: i just tried with the same slime setup as you, same lein-swank, version 2010-03-21 and its deadlocking

11:01 qbg: In my case, (* 4 2)

11:02 etate: the only other thing i can think of is that i have jline included as a dependency

11:02 qbg: Try removing that

11:03 etate: qbg: nope, makes no difference

11:04 qbg: Appeasing the SLIME gods is hard...

11:05 etate: qbg: indeed, oh well i'll just use an old version of slime :)

11:06 Crowb4r: At first I read that as SLUM gods.

11:06 lol

11:17 npoektop: hi! whould you help me with a macro? http://pastebin.com/MyKFdyFp

11:18 it says: "Can't use qualified name as parameter: com.nnn.server.tests.local/tst"

11:19 hiredman: ` qualifies symbols

11:19 ,`a

11:19 clojurebot: sandbox/a

11:19 Chousuke: npoektop: don't quote the macro parameters

11:19 npoektop: and you can use (fn [tst#] ...), an autogensym

11:20 npoektop: but really, that doesn't need to be a macro :P

11:20 or hm, was require a macro or a function? :/

11:20 ,require

11:20 clojurebot: #<core$require__6458 clojure.core$require__6458@1ef63f9>

11:21 Chousuke: right.

11:21 npoektop: a function?

11:22 defn: fogus: Clojure as a Johnsonian (Robert) model of programming.

11:22 npoektop: ok

11:22 Chousuke: npoektop: yes

11:23 just (defn rt [& namespaces] (doseq [n namespaces] (require n) (run-test n))) (rt 'foo 'bar)

11:47 Crowb4r: Is there a google api lib for clojure at all?

11:47 chouser: which google api?

11:49 Crowb4r: chouser: Just any in general. I've seen the charts one, but I was just wondering if there was one for docs or anything else.

11:49 Mec: Is there any simple way to do a reduce that short circuits on nil

11:52 raek: reminds me of -?>

11:52 http://richhickey.github.com/clojure-contrib/core-api.html

11:52 like ->, but short circuits on nil

11:52 Mec: yes

11:53 hiredman: Mec: take-while

11:53 noidi: the beauty of lazy seqs :)

11:53 hiredman: ,(reduce + (take-while identity [1 2 nil 3 4 5]))

11:53 clojurebot: 3

11:53 noidi: maybe swap reduce and take-while there?

11:54 so that it short circuits if the reduction is nil

11:54 Mec: It may be the case that there is no nil in the seq but the function applied by reduce returns nil, in which case it needs to stop as well

11:54 chouser: reduce is eager though, so that wouldn't work

11:54 Mec: and just return nil?

11:54 noidi: chouser, ah, ok

11:55 Mec: chou

11:55 chouser, yes

11:55 chouser: Mec: perhaps you could build something on clojure.contrib.seq/reductions

11:56 Licenser: greeetings

11:56 noidi: any reason why reduce is not lazy?

11:56 chouser: noidi: can't be

11:56 raek: it should be fairly straight forward to do this with exceptions or c.c.error-kit, but I don't know if that's good style

11:56 Mec: reduce only returns 1 value, so theres nothing to be lazy on

11:58 chouser: right. while reductions returns a lazy seq of each iteration of reduce, so you can take the last value, or nil whichever comes first

11:58 noidi: d'oh, of course

11:58 Mec: chouser: ok, i'll look into reductions

12:00 raek: (try (reduce #(if (nil? %2) (throw (Exception.)) (+ %1 %2)) [1 2 3 nil 4]) (catch Exception e nil))

12:00 chouser: :-(

12:00 raek: beware of hairy code...

12:01 man, that's ugly... forget I wrote it... :)

12:02 Chousuke: ,(reduce + (take-while (complement nil?) [1 2 3 nil 4])) :P

12:02 clojurebot: 6

12:02 Chousuke: hmm, I suppose that's not good enough

12:03 Mec: ,(reduce #(if (= %2 5) nil (+% %2)) (range 10))

12:03 clojurebot: java.lang.NullPointerException

12:04 Mec: more like that

12:06 chouser: ,(loop [a 0, s (range 10)] (if (empty? s) a (let [a (+ a (first s))] (when-not (= a 5) (recur a (next s))))))

12:06 clojurebot: 45

12:07 chouser: oh, that's not right

12:07 Mec: The nil test is based off of the cumulitive value from the reduce, so a maping function wont work

12:07 chouser: oh, that is right. but (= a 6) is needed to see the nil result

12:08 it seems strange to me that when the test is true you want to return nil instead of the result so far.

12:09 AWizzArd: An if that returns nil is less idiomatic than using when or when-not.

12:10 Mec: my example was poorly contrived

12:12 chouser: (defn reduce-if-not [pred f init s] (loop [a init, s s] (if (empty? s) a (let [a (f a (first s))] (when-not (pred a) (recur a (next s)))))))

12:17 Mec: is (last (reductions f coll)) = (reduce f coll) ?

12:17 chouser: yes

12:17 noidi: maybe something like this? http://gist.github.com/343741

12:23 Mec: (defn reduce-if-not [pred f init s] (let [r (reductions f init s)] (when-not (some pred r) (last r)))

12:24 hmm does that look right

12:24 chouser: Mec: just so you're aware, that will hold the head of the reductions seq and walk it a second time, so may fail for large seqs where reduce would work fine.

12:25 Mec: I think im back to the same problem with that one

12:35 raek: ,(let [[f & r] [1]] (class r))

12:35 clojurebot: nil

12:35 Mec: (last (take-while pred (reductions f init s))) seems promising but that wont end at nil

12:38 noidi: Mec, did you try chouser's or my suggestions?

12:39 although I understand if you want to solve it yourself, that's why I wrote that snippet without looking at what chouser wrote :)

12:39 Mec: I'm using chouser's idea, just seeing if theres something simple

12:46 noidi: ,(let [r (reductions + (range 5))] (if (some nil? r) nil (last r)))

12:46 clojurebot: java.lang.Exception: Unable to resolve symbol: reductions in this context

12:46 noidi: ,(use '[clojure.contrib.seq-utils :only [reductions]])

12:46 clojurebot: nil

12:46 noidi: ,(let [r (reductions + (range 5))] (if (some nil? r) nil (last r)))

12:46 clojurebot: 10

12:47 noidi: reductions is lazy, and I assume some is too, so I think that should short-circuit

12:47 Mec: It will, but its holding onto the head of a lazy seq

12:48 noidi: argh, of course some is eager as it returns a single value

12:48 again

12:48 note to self: when too tired to think, hacking doesn't help

12:49 kylesmith: Has anyone tried using clojure-install recently? It gets halfway through the install, and says clojure-contrib doesn't have a build.xml file.

12:49 Mec: i needs a take-while or a drop-while that can somehow return nil

12:51 technomancy: kylesmith: clojure-install is deprecated; see the swank-clojure readme.

12:54 noidi: ,(loop [[x & xs] (reductions + (range 5))] (if xs (if (nil? x) nil (recur xs)) x))

12:54 clojurebot: 10

12:54 noidi: I don't know if that's any simpler than what's been proposed, but that's a variation :)

12:56 I've made so many stupid mistakes today that I'm not sure about anything anymore, but that should walk the lazy seq of reductions without retaining head, returning nil if it encounters a nil reduction, or the final reduction otherwise

12:58 you could abstract that out and just do a (nil-or-last (reductions ...))

12:58 kylesmith: technomancy: README.md? I see no mention of clojure-install.

12:59 Raynes: That's the point.

12:59 Mec: noidi: thanks for the effort ;p

13:00 I do like extracting out nil-or-last

13:00 noidi: Mec, here's the function with some nicer formatting http://gist.github.com/343818

13:04 (nil-or-last (cons nil (reductions + (range 999999999999999999)))) returns instantly, so it seems to be lazy as it should

13:05 Raynes: ,(let [result (take-while true? [false true true false true])] (if (empty? result) nil result))

13:05 clojurebot: nil

13:05 Raynes: orly

13:06 noidi: argh, now I'm checking if reductions is lazy like it says in the doc string. now I'm really shutting down the computer and getting some rest :)

13:06 Mec: heh, night

13:06 esj: Raynes: I think it makes sense, results is never gets populated ?

13:07 Chousuke: (if (empty? result) nil result) can be condensed to (seq result) :P

13:07 Raynes: esj: HuH?

13:07 Huh*

13:07 Chousuke: shh.

13:08 ,(seq (take-while true? [true true true false true]))

13:08 clojurebot: (true true true)

13:08 Raynes: ,(seq (take-while true? [false true true true false true]))

13:08 clojurebot: nil

13:09 Raynes: Seq is a multitasker.

13:09 Mec: if you pass seq a sequence or nil its just like identity

13:10 Raynes: Never would have thunk it.

13:11 defn: Does anyone know in incanter, when you have an x axis that has very long names, how you grow the graph to make them fit?

13:11 Mec: clojure.contrib.seq isnt new is it?

13:11 Raynes: defn: Water it.

13:11 Mec: It's the renamed seq-utils

13:11 Mec: ah thats what i've got still

13:12 Raynes: Mec: Likewise, because it doesn't look like anybody is going to fix the contrib master builds on Hudson until clojure 3.0 is out. ;)

13:12 Mec: I just finally got emacs working happily and im not screwing with it

13:13 defn: Raynes: good advice. it worked

13:13 Raynes: defn: ;)

13:13 liebke: defn: there are :width and :height options to view. Or you can just drag the corner of the window :)

13:13 kylesmith: Has swank-clojure been updated to use leiningen? What happened to swank-clojure-autoload?

13:14 defn: liebke: it doesn't seem to be auto resizing, perhaps because i set the :width and :size ?

13:14 liebke: defn: really? which chart are you using?

13:15 defn: bar

13:15 liebke: sorry i should clarify

13:16 it auto-resizes, but honestly it might not be including labels for the x-axis

13:16 i thought those tick marks were just tightly packed text

13:16 liebke: defn: do you have some example code I can see?

13:17 defn: the x-axis labels for bar-charts are the values of the first argument passed to bar-chart

13:17 defn: (defn build-graph [] (incanter.core/view (incanter.charts/bar-chart countries values :x-label "Countries" :y-label "Number of Denials")))

13:18 liebke: defn: so each of the bars should be labeled with the values of the countries sequence. Is that not what you're seeing?

13:18 defn: liebke: one sec please

13:20 liebke: my structure looks like what we discussed earlier -- [{:country "USA", :count 10} {...} {...}]

13:20 liebke: defn: you can also set the :vertical option to bar-chart to false, to create a horizontal chart, which works better for long labels

13:21 defn: is my structure there correct?

13:22 liebke: defn: yeah, to pass that structure to (to-dataset your-map-array)

13:22 defn: then you can call (bar-chart :country :count :data (to-dataset your-map-array))

13:23 defn: ahhhhh

13:25 Raynes: Leiningen gets no love: http://muckandbrass.com/web/display/~cemerick/2010/03/25/Why+using+Maven+for+Clojure+builds+is+a+no-brainer

13:25 * defn sighs

13:26 defn: it's been around for about a day

13:26 besides, you can use maven AND leiningen

13:26 Raynes: defn: If it was more than two days old, it would be OFN.

13:26 defn: OFN?

13:27 * defn arms his M-x wtf-add

13:27 Raynes: defn: Old f***ing news.

13:27 defn: heh

13:28 cemerick: defn: what does such a combination look like?

13:28 defn: Raynes: is it evil to \n the crap out of your clojre code?

13:28 cemerick: like rubygems and ant for jruby

13:28 cemerick: yeouch

13:29 defn: cemerick: i dont think there is a magic bullet, but what i do know is that bits and pieces of doing stuff with maven could be built into a tool like leiningen

13:30 and that would be handy, and nice

13:30 Chousuke: I'm looking forward to some kind of clojureish wrapper for maven appearing

13:30 cemerick: Chousuke: from the makers of maven: http://polyglot.sonatype.org/clojure.html

13:30 defn: it's logic programming

13:30 people who write clojure like that sort of thing

13:30 :)

13:31 cemerick: defn: I guess I'm left wondering what such a tool would look like, other than being maven + sexprs.

13:32 defn: cemerick: headius was in here yesterday talking about how closely ant and rubygems work together -- it's not messy, rubygems runs the show and is almost completely written in ruby IIRC

13:32 i am probably misquoting him, but it didnt sound like a bad place to be

13:32 cemerick: defn: yeah, I was here when he said that.

13:33 headius: it's getting there

13:33 hopefully in the next week we'll have a maven repo live that appears to be just a rubygems repo

13:33 gem install org.clojure.clojure

13:33 cemerick: I'm not saying it's messy, I'm saying that I'm not particularly interested in scripting-oriented approaches to doing builds anymore.

13:33 defn: now that is just awesome.

13:33 headius: that will be a nice step toward rubyifing maven on the project side as well

13:34 defn: cemerick: ah, don't you think most people still operate with scripts first, customization second?

13:34 cemerick: And, again, mining the maven plugin ecosystem is simply too fruitful to ignore IMO.

13:34 defn: i mean there comes a point where you just get in there and do what you need to do i guess

13:34 kylesmith: Can anyone give me a link to *updated* instructions for how to setup emacs/leiningen/swank-clojure?

13:34 defn: kylesmith: mine or sort of up to date :X

13:34 cemerick: defn: scripting is custom from the start. That's the first big win with maven (or other convention-over-configuration approaches).

13:35 headius: cemerick: any rubified maven we do would leverage all existing stuff...we wouldn't reimpl maven

13:35 defn: kylesmith: http://devinwalters.com/posts/24

13:35 headius: just like the rake+ant integration just merges the two spaces

13:35 cemerick: headius: sounds like a winner

13:36 headius: I like what the buildr guys have done, but they don't use any of maven proper

13:36 I'm too lazy for that

13:36 cemerick: I don't really care what gets used, as long as people can stop reimplementing silly stuff like shell exec, javac compilation, building .war files, etc.

13:37 defn: .war files, ugh

13:37 cemerick: defn: ?

13:37 stuartsierra: I wonder what a clojure syntax for ant would look like?

13:38 headius: probably a lot like xml :)

13:38 stuartsierra: yeah

13:38 defn: only less noisy

13:38 headius: (project (target ...

13:38 defn: cemerick: disregard

13:38 headius: rake+ant looks like rake, so it's not a good comparison

13:38 cemerick: defn: that's not a reason to not use XML BTW :-)

13:38 stuartsierra: cemerick: agreed

13:39 defn: cemerick: label me a hopeless aesthete

13:39 stuartsierra: Heck, Ant has macros, doesn't it?

13:39 headius: sort of

13:39 they're really just function defs

13:39 cemerick: stuartsierra: danger, will robinson!

13:39 stuartsierra: ah

13:39 headius: not really contextual

13:39 defn: stuartsierra: i think im supposed to bug you about circumspec?

13:40 stuartsierra: defn: are you? Did halloway put you on it?

13:40 defn: s.halloway said something along those lines to me

13:40 :)

13:40 cemerick: I probably would still be using ant if its scripts were composable and if it had baked-in dep mgmt.

13:40 stuartsierra: defn: Are you at relevance?

13:40 kylesmith: defn: Am I supposed to get massive warnings when installing everything?

13:40 defn: stuartsierra: no sir, just caught him in irc earlier and complimented him on labrepl, asked about circumspec

13:41 Raynes: I <3 Leiningen.

13:41 defn: he pointed me at you and sean devlin :)

13:41 kylesmith: that will happen yes

13:41 kylesmith: it's okay

13:41 stuartsierra: defn: Ok. I talked to Halloway about Circumspec and lazytest last week. Working right now on merging features from both.

13:42 defn: stuartsierra: one big thing ive been really itching for is a demonstration and blog post with the setup process

13:42 stuartsierra: Just trying to settle some syntax wars going on inside my head.

13:42 defn: im not entirely sure how to get the beast moving

13:42 stuartsierra: what, circumspec?

13:42 defn: i generally edit using swank-clojure-project

13:43 open my source and C-c C-j

13:43 C-k*

13:43 how do i get circumspec into the mix

13:43 stuartsierra: no idea :)

13:43 defn: haha

13:43 stuartsierra: that will come, first we have to finish writing it

13:43 defn: oh...right!

13:43 kylesmith: defn: I got several errors while installing. As far as I know, I'm using standard emacs 22 from the ubuntu repos, and I wiped out my .emacs and .emacs.d

13:43 defn: kylesmith: get 23

13:43 it's in your best interest

13:44 i like to compile emacs from source on linux

13:45 but IIRC there are packages for ubuntu 9.10 now

13:45 stuartsierra: thanks for working on it, anyway -- it looks like it will be fantastic

13:46 stuartsierra: here's hoping

13:47 defn: liebke: still no luck with (view (bar-chart :country :count :data (to-dataset (to-incanter-structure))))

13:48 liebke: to-incanter-structure returns [{:country "X" :count 5} {...} {...}]

14:00 liebke: defn: what's it doing?

14:01 defn: I've got it working now, my only remaining question is how to make the bars wider

14:02 liebke: defn: I'm afraid I can't help you there, they are typically as wide as there is room

14:03 defn: liebke: I have about 182 bars

14:06 liebke: defn: yeah, unless you consolidate some of the bars, I don't have a way to make them bigger

14:06 defn: liebke: okay, thanks

14:14 fogus: cemerick: nice screencast. I'm sold

14:18 cemerick: fogus: Thanks :-)

14:20 I thought about doing a more elaborate example, but the OS X bundling bit seemed like it had some visual impact to it.

14:20 kylesmith: defn: I'm still getting an error during install on emacs 23: "swank-clojure.el:47:1:Error: Symbol's function definition is void: slime-control-modified-char"

14:21 fogus: I liked it. It was perfect length, perfect example. I didn't care for the soundtrack though. ;-)

14:23 cemerick: fogus: what, you don't like endless yammering and opining while you're watching projects build?!?!!11!

14:23 that was a ;-) of course

14:23 chouser: there's no audio, right?

14:23 fogus: cemerick: Nothing wrong with the yammering, although I had imagined your voice to be more like Barry White. :p

14:24 chouser: instead of completely silent, as it is?

14:24 cemerick: chouser: no, there's audio

14:24 chouser: hmph

14:24 cemerick: fogus: time for those voice lessons, get me down a few octaves :-D

14:26 chouser: ah, there we go.

14:34 clojure build system hotness as defined by cemerick's use of it

14:34 cemerick: heh

14:34 chouser: dude, that's just the tip of the iceberg.

14:35 chouser: is the rest of the iceberg also XML?

14:35 sorry, couldn't resist.

14:35 Raynes: I'd rather use a crappy build system than stare at XML for any length of time.

14:35 Chousuke: you can write poms in clojure though

14:36 and translate them to xml poms

14:36 cemerick: chouser: that depends on how long it takes the polyglot maven stuff to bake

14:36 chouser: nah, xml rocks

14:36 cemerick: but I'll likely stick with the XML bits for quite a long time given the tooling

14:36 Chousuke: Raynes: you have to admit that what cemerick showed blows lein right out of the water :P

14:37 Raynes: I didn't want what cemerick showed.

14:37 cemerick: Did I show something I didn't mean to? ;-)

14:37 Raynes: And it wouldn't make me stop using Lein in any case. It's all I need at this point.

14:37 cemerick: Sorry, you gotta go the long way around the barn for that one.

14:37 * fogus feels like the only person in the world who isn't bothered by XML

14:37 chouser: seriously, I've got build files here written in cmake's custom language, gnumake's custom language, and I've worked with qmake -- xml is beautiful compared to those.

14:38 cemerick: fogus: there's lots of us, we just don't jump up and down so much

14:39 chouser: I actually expect cemerick's demo and attitude to be meaningful to a lot of people.

14:39 cemerick: chouser: w.r.t. plugins, the maven native plugin will probably make your socks roll up and down.

14:39 i.e. lots of gcj, jni bits

14:39 Raynes: It would be sad to see Leiningen die as a project at this point, but judging why what I've seen here, looks like it might happen. :\

14:39 by*

14:40 Chousuke: fogus: I'm rather pleased that maven is so declarative :)

14:40 mattrepl: why is lein dying?

14:40 fogus: Raynes: Seen here?

14:40 Raynes: Looks like everybody is perfectly happy with maven.

14:40 mattrepl: I use lein, don't like maven

14:40 cemerick: Raynes: I'm the outlier at the moment, FYI. Just trying to get people into tools that work today.

14:40 Chousuke: Raynes: lein just needs to change to utilise maven more :)

14:40 Raynes: mattrepl: Obviously, cemerick will change your mind.

14:41 fogus: Raynes: I doubt you'll find perfect happiness associated with anything, must less Maven

14:41 Raynes: ;)

14:41 * mattrepl dons tinfoil

14:41 Raynes: Just saying. I thought Leiningen was the big awesome around these parts, but today has really given me a new perspective. I never knew this many people were this happy with maven.

14:41 chouser: I doubt that many people would avoid maven purely based on the xml. It's a combination of unfamilier terms (artifact, phase, groupId, pom), complex-looking pom file content, its desire to manage its own user- or system-wide repo, the xml itself, and all that up against a sense of "that's a lot of junk, why should I bother? The tool I have (make, ant, now lein) works fine!"

14:42 Chousuke: Raynes: leiningen is great, but it can't compare with maven

14:42 Raynes: maven has simply had too much development put into it

14:42 cemerick: chouser: that's part of the "everyone's got their own 20%" syndrome.

14:42 Raynes: Chousuke: It's also a very young project that could become a lot more.

14:42 fogus: Honestly, my exposure to Maven and Lein are almost non-existent. But after spending the past 3 years wrestling with a yak-shaved build system at work I'm very very tired of thinking about build tools

14:43 Chousuke: Raynes: but that lots more still doesn't compare to maven :)

14:43 chouser: so a demonstration of what maven will buy you can go a long way to understanding why it's worth adopting maven's set of pain.

14:43 Raynes: But it could do more with maven.

14:43 cemerick: Raynes: who's going to build all those tools? I'm asking, seriously.

14:43 Chousuke: Raynes: indeed. lein could become a thin, clojureish maven frontend

14:44 mattrepl: it kind of is

14:44 technomancy: Chousuke: it already is that, basically

14:44 chouser: I have used lein exactly once to build ring, and maven exactly once to build contrib. ...roughly similar pain.

14:44 technomancy: more for the deps than other things. I've thought a bit about a plugin adapter for maven since we've been using the appassembler stuff for deployment at work, and it does the job pretty well.

14:45 Chousuke: I think maven scares people mostly because it downloads the internet :P

14:45 Raynes: technomancy: Don't be discouraged by these rebels! We shall rule zeh world!

14:45 fogus: I saw a funny tweet the other day that said something like "mvn clean just downloaded 3 jars"

14:46 cemerick: Yup. World domination through maven screencasts, that's me. 9.9

14:47 Raynes: Looks like you're succeeding. :p

14:47 kylesmith: I'm still having trouble using elpa to install stuff in emacs. grep -R slime-control-modified-char .emacs.d returns nothing. Anyone have any ideas?

14:51 Raynes: cemerick: Can I do mvn swank?

14:51 technomancy: Raynes: it works, but it AOTs everything up front

14:52 so you can't use it to fix a problem that causes compilation errors. =(

14:52 Raynes: technomancy: Ew.

14:52 Not sold. :|

14:52 cemerick: Raynes: yes, see here: http://github.com/talios/clojure-maven-plugin

14:52 technomancy: even if you don't bind the compile goal?

14:52 technomancy: it also doesn't work if you have swank-clojure test-scoped

14:53 cemerick: we don't have any explicit config for swank in our pom

14:53 maybe you can unbind it; I haven't looked into it closely.

14:54 cemerick: technomancy: you mean it's set up in a parent somewhere?

14:54 technomancy: I mean we declare it as a dependency and that's it

14:56 hiredman: I think we need to stop worrying about buildsystems and instead build time machines so we can reclaim all the time lost waiting for builds

14:56 stuartsierra: hiredman: But then when would we goof off?

14:57 hiredman: (or hop on irc)

14:57 stuartsierra: we'll multiplex

14:57 Raynes: stuartsierra: During the time it takes cemerick to write our maven poms for us.

14:57 hiredman: live for two or three days each real time day

14:57 this could get complicated

14:59 stuartsierra: We need some concurrency control mechanisms.

14:59 You know, put ourselves in Refs or something.

15:01 cemerick: stuartsierra: atoms, please. It hurts when future states of me have to get rebuilt because of contention.

15:02 stuartsierra: heh ):

15:02 :)

15:03 Although having a completely safe way to try new things might be useful.

15:05 kylesmith: I found someone else who has the same problem as me: http://pastebin.com/xhPHszg4 I also just realized I have slime version 1:20080223-2 installed. Will that cause problems?

15:06 technomancy: kylesmith: if you've got a system-installed version of slime it might interfere

15:07 kylesmith: Hmm, my sysadmin says it can't be uninstalled for some reason. Can I set some sort of precedence?

15:08 technomancy: kylesmith: but elisp-level compilation errors don't necessarily mean the elisp failed to install

15:08 you can still run it in interpreted mode

15:12 cemerick: I think you might have a bit of a misconception about how lein works since you mentioned people "reimplementing javac, shell exec, etc." ... that stuff is all handled through the ant API that lancet exposes.

15:13 kylesmith: interpreted mode is fine, I guess. Do you have a link for that?

15:13 technomancy: it comes out to around 700 LOC if you exclude lancet.

15:14 basically two weeks worth of work plus contributions that have accumulated since then

15:15 kylesmith: I don't know of any link. just ignore the compilation warnings and proceed as per instructions.

15:16 cemerick: technomancy: I wasn't exclusively talking about lein, but I do see stuff like this, which is really troubling. http://github.com/alienscience/leiningen-war/blob/master/src/leiningen/war.clj

15:16 kylesmith: I did. Reload emacs, M-x slime -> "slime-presentation-init-keymaps: Symbol's function definition is void: slime-control-modified-char"

15:16 which is one of the compile errors

15:16 cemerick: technomancy: You're right that I wasn't aware of the lancet part, but the point is a general one, I think.

15:17 technomancy: cemerick: I see... yeah, I'm sure that plugin could be rendered unnecessary with a good plugin adapter.

15:18 since my own needs are simple I haven't looked into it much

15:18 cemerick: FWIW, There was some very lengthy discussion about shell exec w.r.t. lein in here a few weeks ago that wow'ed me in the same way, so I inferred from that. :-(

15:19 kylesmith: technomancy: Well, I have to go for now. Thanks for the help so far.

15:19 technomancy: kylesmith: definitely an old version of slime left around somewhere on your system; check C-h v load-path to debug further

15:20 cemerick: technomancy: BTW, I certainly mean you no ill will (I know people can get personal about projects, etc). Just trying to provide some...perspective? ;-)

15:22 technomancy: cemerick: sure, understood. I think it's good that people be aware of what's out there and leverage existing tools, especially for people with slightly more exotic needs like OS X apps or .war files.

15:23 cemerick: technomancy: it's a favorite saying of mine lately that everyone says "I only need 20% of *that*", but everyone's 20% is different.

15:23 though I'd say just about everyone needs .war files :-)

15:24 * technomancy strives for peace and has been able to avoid them so far.

15:24 technomancy: (sorry)

15:24 stuartsierra: heh

15:24 cemerick: I cling to them for exactly the same reason! :-D

15:24 war, cargo, done.

15:25 technomancy: the sweet spot for leiningen adoption so far has been higher up the stack... for libraries that aren't meant to be deployed but just used for other applications to depend upon.

15:26 where requirements are rather uniform

15:27 I wonder how much plugin support the maven-ant-tasks library provides.

15:28 I tried to interop with maven itself, but the dependency injection framework it was using seemed to be pretty hostile to outside use.

15:28 cemerick: technomancy: just out of curiosity, remind me again why lein and not clj polyglot?

15:28 technomancy: (in the immortal words of alex payne: "Curl up and DI.")

15:28 cemerick: tired of waiting, mostly

15:29 it was literally usable within two weeks of weekends and evening hacks

15:30 stuartsierra: technomancy, cemerick: lein does seem to make the simple case easy. Maybe someday we can unite our efforts.

15:30 technomancy: it's significantly smaller than clojure-maven-plugin still, though of course since that's implemented in Java it's hardly apples-to-apples. =)

15:33 * technomancy wishes there were an easy way to count LOC that excluded docstrings

15:34 technomancy: I guess you could load the file and then subtract the line-count of the docstring of each var; heh

15:34 * technomancy heads off to lunch; will ponder these things.

15:34 * cemerick heads off to handball :-D

15:37 mattrepl: build tools should build, not sure why deployment would be expected. perhaps it's just semantics. or perhaps it's certain expectations of build tools since maven does more than just build.

15:55 gfodor: I'm getting some very weird behavior with converting from byte arrays to strings and back

15:55 here's an example to highlight it

15:55 ,(count (.getBytes (String. (byte-array [(byte -62) (byte -113) (byte 80)]) "UTF8")))

15:55 clojurebot: 3

15:56 gfodor: on my machine, that returns 2!

15:56 (mac osx)

15:58 lancepantz: what do i pass to get a repl with a script loaded?

16:00 programble: <gfodor> (mac osx)

16:01 i read that

16:01 as

16:01 clojure code

16:01 Raynes: ,(mac osx)

16:01 clojurebot: java.lang.Exception: Unable to resolve symbol: mac in this context

16:01 Raynes: :(

16:01 programble: lol

16:01 gfodor: hah -- anyone with a mac get that to return 2?

16:01 fogus: gfodor: does for me too

16:01 gfodor: that seems horribly wrong, right?

16:02 in JRuby on mac osx, it worsk

16:03 headius: mac java has a fux0red default encoding

16:03 we force it to utf-8

16:03 (we jruby)

16:03 it's MacRoman by default but nothing renders MacRoman right

16:04 Chousuke: you shouldn't care about the number of bytes in a string unless you're working with encodings :/

16:04 gfodor: yeah I am doing BER-packing

16:04 (hey Charles :))

16:04 reimplementing JRuby's pack("w")/unpack("w")

16:04 headius: gfodor: hiya

16:04 ahh for perf or a bug?

16:04 or for clojure?

16:04 gfodor: just so I can read packed strings from clojure packed by a jruby script

16:04 headius: ahh

16:05 good old pack

16:07 gfodor: oh, I figured it out

16:08 you need to supply the encoding to getBytes also

16:08 why is that? It's it just, er, bytes?

16:08 headius: it uses default external encoding if you don't

16:08 which would be macroman if you don't specify it on OS X

16:08 hence, OS X java iz dum

16:08 gfodor: right, surely I'm just being dumb here, but why do you need to supply the encoding to *get* the bytes out?

16:09 Chousuke: gfodor: all strings are stored as UCS-2 internally by java

16:09 gfodor: oh

16:09 *sigh*

16:09 ok, the world makes sense, thanks

16:09 fogus: ,(count (.getBytes (String. #^bytes (byte-array [(byte -62) (byte -113) (byte 80)]) "UTF8") "UTF8")) ;; yuck

16:09 clojurebot: 3

16:09 gfodor: yeah

16:10 any desire for BER packing code for clojure.contrib? :)

16:10 Chousuke: UCS-2 was a horrible choice for the internal encoding though :P

16:10 but, hindsight ;P

16:11 I bet many string ops in java would be much faster if strings were UTF-8 internally

16:17 gfodor: hey headius, here's some jruby fun

16:17 [2000].pack("w").to_java_string.to_s.size == [2000].pack("w").to_s.size

16:17 false

16:24 headius: gfodor: what is 'w' again?

16:24 gfodor: BER-compressed

16:24 nice int packing for small ints

16:24 the problem is basically that hopping through java String "corrupts" the byte array

16:25 I believe you guys keep the raw bytes in the RubyString so if you stick to the Ruby side of things everyting is cool

16:25 as such, clojure is not going to have the ability to pack into Strings

16:26 headius: yeah, that's why we don't use Java strings

16:26 you can't easily represent arbitrary byte arrays

16:26 technomancy: mattrepl: not necessarily that build tools should perform the deployment, but that they should build artifacts that are deploy-ready

16:27 mattrepl: technomancy: completely agree

16:27 technomancy: for our use at least, a jar is not enough; you want /etc/init.d/ scripts to go with it and at least some basic shell scripts for interaction

16:27 we have actual deployment happening with chef

16:29 mattrepl: why not have chef handle deploying the scripts and jars, where the scripts are either static files or being generated from a template on the chef side? don't have experience w/ chef, so maybe preprocess steps, such as generating scripts, can't be done

16:31 technomancy: mattrepl: we probably would if we were using leiningen, but maven did offer some plugins that gave us scripts out of the box.

16:32 I'm bad at shell scripting, so I'm predisposed against writing my own. =)

16:35 mattrepl: heh. I'd think no longer, post-lein

16:36 technomancy: all the .sh in leiningen is either copied from a known-good source or written by contributors. =)

16:40 slyphon: i'm trying to use JYaml, and when it parses a file, it returns a java.util.HashMap. is there an easy way of turning that into a clojure hash-map?

16:42 technomancy: slyphon: sure, try (into {} java-hashmap)

16:42 slyphon: oh, duh

16:42 * slyphon tries that

16:42 slyphon: ah, almost, it only went one level, but i can take it from there

16:48 alexyk: liebke: the latest incanter on clojars returned by search is 1.0-master. That brings in the snapshot of 20091226... surely old?

16:53 slyphon: hmm

16:54 (prn-str) because every language should have a "porn star" function

16:54 KirinDave: Are seq's thread safe?

16:54 I mean, like line-seq

16:54 liebke: alexyk: yeah the version on Clojars is obsolete. Go to http://repo.incanter.org

16:54 alexyk: liebke: so you chose not to clojar anymore?

16:55 liebke: alexyk: it wasn't by choice, it was necessary due to Incanter's build structure. Clojars doesn't support modular maven projects

16:55 alexyk: liebke: got it, cool

16:56 technomancy: KirinDave: the same seq shared across multiple threads should cache itself so changes to the underlying source (file, array, etc) should not interfere

16:56 KirinDave: technomancy: Okay, so that's all done magically for me.

16:56 * technomancy waves the pixie-dust wand

16:56 KirinDave: technomancy: So if i write a lexer into a lazy seq, so long as it uses lazy seq and no state between the calls, it will Just Work™

16:56 slyphon: argh

16:56 recursion hurts my brain

16:57 technomancy: KirinDave: I believe so

16:57 KirinDave: technomancy: That's cool.

16:57 alexyk: liebke: you may want to remove the old incanter from clojars then; or setup a cron job to push the new jars there just in case :)

16:58 technomancy: yep =)

16:58 alexyk: slyphon: get a recursive brain, you'll be ok

16:58 * slyphon needs an upgrade

16:58 liebke: alexyk: last time I checked there wasn't a way to remove projects from clojars

16:58 Raynes: Recursion is awesome.

16:58 chouser: slyphon: are you sure you need clojure maps?

16:58 Chousuke: slyphon: recursion is easy, you only need to understand recursion

16:59 alexyk: technomancy: is it OK to just git pull in the leiningen dir once it was hacked as specified, with a symlnk pointing into the git guts?

16:59 slyphon: chouser: it would make life easier, i believe

16:59 technomancy: alexyk: not sure what "hacked as specified" means here

16:59 chouser: slyphon: if you're going to do persistent updates then you need to convert, otherwise you might not.

17:00 slyphon: nah, this is read-only

17:00 it's for configuration

17:00 chouser: java maps still do all the seq stuff properly

17:00 slyphon: hmm

17:00 * slyphon speriments a bit

17:00 alexyk: meaning, bootstrapped with static, then that used to build git checkout

17:01 then bin/lein from that checkout is used; so if I want a newer, I just git pull, nothing else? no magic>

17:01 ?

17:01 slyphon: it's situations like this that the -> macro totally rocks my world

17:01 technomancy: alexyk: oh, I see; the bootstrap directions from the readme. that's right; git pull should be all you need to get up to date.

17:02 the symlink being from src/leiningen/bin/lein to somewhere on your path

17:02 alexyk: liebke: you can sternly implore _ato to nuke the old crap

17:02 technomancy: so basically it pulls whatever jar it needs, no need to rebuild it right?

17:03 technomancy: alexyk: yes, currently there's no AOT necessary

17:03 alexyk: hey people, why would I want to edit my project.clj to update 1.1.0-master-SNAPSHOT to 1.2.0-...that? is there some yummy stuff in 1.2.0 already?

17:04 technomancy: alexyk: well you should at least move to 1.1.0 stable. =)

17:04 alexyk: I mean irresistably yummy, de rigeur for any true #clojure-ian?

17:05 technomancy: but 1.2.0 has lots of goodies like fine-grained locals-clearing even if you aren't interested in the Big Exciting protocols, reify, deftype, etc.

17:05 alexyk: technomancy: I thought SNAPSHOT is ahead of the stable, with bug fixes and such, no?

17:05 say 1.1.0 is released, is 1.1.0-master branch ahead of it?

17:05 technomancy: alexyk: no, SNAPSHOT is always behind stable of the same version number

17:05 Raynes: albino: deftype, reify, NAMED ARGUMENTS, etc.

17:05 technomancy: SNAPSHOT just means stable hasn't been released yet

17:05 alexyk: Raynoceros: thx

17:06 NAMED ARGUMENTS! now we're talking

17:06 Raynes: Named arguments: they're that important.

17:06 technomancy: get it while it's hot; only a couple days old

17:08 alexyk: yay! I *love* named arguments since Ada 83

17:08 a language without named arguments is pfft

17:10 chouser: named arguments without a language is worse

17:10 alexyk: named arguments: what name did you just call my mama?

17:10 by reference?

17:11 chouser: how's that MEAP coming along? Now that I payed for it, I expect speedy updates! :)

17:11 The-Kenny: alexyk: I think I read something on Twitter about this

17:12 But I can't remember what it was :/

17:12 alexyk: The-Kenny: about chouser?

17:12 The-Kenny: about the meap updates, propably it was written by him

17:13 alexyk: ah! at least I want one without typos! :)

17:13 I mean c'mon, we got 2 authors and lots of typos! they can cross-proofread!

17:14 Manning has people to proofread, with all the ripping-off and whatnot!

17:14 the guy who finds strangely clothed men for the covers can do it in between finds

17:15 underdev: lol

17:16 Raynes: chouser: Yeah. Leave this channel immediately and continue writing. I wants updatez.

17:16 * alexyk imagines there should be an aspell binding in clojure at least

17:16 alexyk: chouser: ignore Raynes, I'll take live advice any time over the written word

17:17 Raynes: chouser: Ignore alexyk, you can teach us more in the book than you can teach us here.

17:17 We have hiredman if we need help.

17:17 alexyk: chouser: doubly ignore Raynes, do both!

17:17 Raynes: Run along now.

17:17 alexyk: the hiredman is hired and not for any more hire

17:18 Raynes: alexyk: That was poetic.

17:18 The-Kenny: Yay! Github is using <canvas> for the network graph now :) http://github.com/blog/621-bye-bye-flash-network-graph-is-now-canvas

17:18 alexyk: Raynes: indeed

17:22 chouser: ha, you guys are funny.

17:23 we've submitted several updated and new chapters, and are just waiting for manning to do what they do to them before they go up on the MEAP.

17:23 so "any day now"

17:25 technomancy: probably waiting on those lazy reviewers

17:25 * technomancy glances around nervously

17:25 underdev: chouser: i read some tweets that they were soon coming, but have been checking and they weren't there. Waiting for a little more content to pull the trigger...

17:26 Raynes: underdev: I'll put some grease on the trigger.

17:26 chouser: underdev: that's fine. there will be a mostly-new chapter 1 soon, which may allow you to better evaluate the book.

17:26 alexyk: (lazy-seq reviewers)

17:27 underdev: "pull the trigger"... hanging out on slickdeals too much...

17:29 alexyk: underdev: just pull the damn trigger already, or it will get rusty

17:30 manning had 47% off recently

17:30 the way to do it is to sign for their list, wait for a ridiculous uneven discount like 42% for two books, and get chouser's and say hadoop

17:31 or two chouser's, one for you, one for the kids!

17:31 one for grandma

17:31 chouser: 45% right now http://twitter.com/chrishouser/status/10990587934

17:32 alexyk: wow! divisible by 5! incredible!

17:33 * alexyk always feel bad when rhickey leaves after his utterance. It's all my fault.

17:33 programble: lol

17:34 underdev: chouser: i actually tried it early today, and it wasn't taking my coupon code

17:34 chouser: underdev: hmph.

17:34 underdev: so i guess i did try to pull the trigger

17:34 * chouser double-checks

17:34 underdev: me too

17:35 chouser: I got it from the bottom of this page: http://tinyurl.com/ygo3654

17:36 maybe being mentioned in slot 10 of the bestselling meap list isn't sufficient?

17:36 alexyk: IRC: Collective Intelligence in Inaction

17:37 chouser: that list is just bestsellers! the special deals on top do not grep it

17:38 the top 10 are always there for reference...

17:38 but, they say "mentioned in this mailer"

17:38 chouser: it says "any book mentioned in this mailer" in bright red giant font

17:38 alexyk: yes

17:38 chouser: so .. I thought ... but perhaps I was wrong.

17:38 sorry

17:38 alexyk: someone has to explain them what "mentioned" means -- it's a contract in the US

17:39 I'll testify in small claims court

17:39 underdev: yeah, when i hit apply with code m3145, the price doesn't change

17:39 alexyk: notary-certify grep results of page source | grep clojure certify found

17:39 hence they owe the discolunt

17:40 discount

17:40 btw looks like 3145 are the digits of π

17:40 almost

17:41 slyphon: you guys know if there's a way to recursively search back through the history in the *slime-repl clojure* buffer?

17:41 like C-r in readline?

17:41 danlarkin: recursively? ...what

17:42 slyphon: incrementally

17:42 sorry, brain-fart

17:43 danlarkin: C-r does an isearch-backward

17:43 slyphon: i know you can just do C-r and search up through the buffer, but if you don't have the buffer saved..

17:43 danlarkin: which is probably what you want

17:44 oh, I see what you mean

17:44 slyphon: there's C-<up arrow>, which goes through the history entries one-by-one

17:44 yeah

17:44 just curious, i can live without it

17:44 danlarkin: there's M-p-r

17:45 underdev: yeah, code no good

17:45 slyphon: ooh

17:45 that looks promising

17:45 danlarkin: thanks

17:47 alexyk: underdev: just sign up for the email, it's usually 40+% every other week

17:48 sometimes for 2 books, you can get another as an excuse for getting the discount

17:53 Lucene/Hadoop/Mahout/Intelligence are all good for 2 books

17:55 ihodes: anyone have an easy way to copy something to the clipboard? java.awt.datatransfer isn't working for me too well

18:02 miltondsilva: ,(interleave {:a :b} {1 2})

18:02 clojurebot: ([:a :b] [1 2])

18:03 Licenser: ,(interleave [:a :b] [1 2])

18:03 clojurebot: (:a 1 :b 2)

18:03 miltondsilva: :(

18:03 Licenser: might be better to understand that way :)

18:03 what did you expect it to do?

18:03 miltondsilva: {:a 1 :b 2}

18:03 Licenser: wow but that is a very different thing

18:04 miltondsilva: I always forget coll isn't a map

18:04 Licenser: ,(seq {1 2}

18:04 clojurebot: EOF while reading

18:04 Licenser: ,(seq {1 2})

18:04 clojurebot: ([1 2])

18:04 Licenser: ,(flatten {1 2})

18:04 clojurebot: java.lang.Exception: Unable to resolve symbol: flatten in this context

18:04 kotarak: ,(zipmap (mapcat identity {:a :b}) (mapcat identity {1 2}))

18:04 clojurebot: {:b 2, :a 1}

18:04 kotarak: But what would be the use?

18:04 Licenser: kotarak was faster :)

18:05 kotarak: You can't guarantee key order. (in general)

18:05 Licenser: especially since there is no order in maps

18:05 miltondsilva: I'm processing *.obj files

18:05 need to get vertices and faces

18:06 Licenser: miltondsilva: but why map keys values from two maps?

18:06 miltondsilva: now that you mention it.. I see it's useless

18:07 kotarak: ,0xff

18:07 clojurebot: 255

18:07 miltondsilva: oh

18:07 no

18:07 it's no from to maps

18:07 kotarak: ,0o77

18:07 clojurebot: Invalid number: 0o77

18:07 miltondsilva: two*

18:07 Licenser: bit {} is a map

18:07 kotarak: ,077

18:07 clojurebot: 63

18:07 Licenser: *but

18:07 ,007

18:07 clojurebot: 7

18:07 Licenser: I want that to be fixed to "Bond" :(

18:08 miltondsilva: it's someting like this (vertices faces) -> {:vertices vertices :faces faces}

18:09 Licenser: ah I see

18:09 reduce it?

18:09 I don't know what exactly vertices or faces are but I have somethign that looks a bit like that

18:10 kotarak: ,(zipmap [:a :b :c :d] [1 2 3 4])

18:10 clojurebot: {:d 4, :c 3, :b 2, :a 1}

18:10 cemerick: mabes: ping?

18:10 Licenser: http://github.com/Licenser/clj-sandbox/blob/master/src/net/licenser/sandbox/tester.clj#L51 look at this?

18:11 mabes: cemerick: hey! you don't mind if I ask you some noob java deployment questions do you?

18:11 Raynes: Licenser: If you don't have any use for the 'new' branch, I'm going to go ahead and delete it since it's been merged.

18:11 Licenser: Raynes: please do :) I forgot how to do it :P

18:12 Raynes: Licenser: git branch -d <branchname>

18:12 ;P

18:12 Licenser: I tried that :( didn't worked

18:12 it deleted it locally but on on github

18:12 mabes: cemerick: are you using jetty in production? if so, are you using embedded jetty?

18:13 cemerick: mabes: no, not in production yet -- embedded jetty in dev environments tho

18:13 Licenser: I just read the google groups massage about the build tool and I think there is a entire different question we didn't asked: Do we actually need/want a build tool?

18:13 kotarak: Licenser: (reduce #(update-in %1 [(:type %2)] conj (:tests %2)) {} definitions)

18:13 Licenser: kotarak: :( that is too easy

18:13 miltondsilva: Licenser, kotarak: thanks but I see now that I don't need to do it. but if theres a better way of doing this let me know :) http://clojure.pastebin.com/WRB5GH89

18:14 cemerick: mabes: did you get my /msg?

18:14 Raynes: Licenser: git push origin :new <-- Deletes a remote branch.

18:14 Licenser: I mean (@the build tool thing) the JVM has a great JIT, so what is wrong with just using .clj files and calling them. It saves the entire silly -main stuff to

18:15 jruby comes a long way with that and I don't see much of a drawback, or actually any important need for compiling clojure code (save for libs callable from java)

18:15 Raynes: Licenser: Also, I added a few new functions to the whitelist, so be sure to pull before your next push.

18:15 Licenser: aye

18:16 cemerick: Licenser: I really don't know where to start. Customers don't like running stuff from the command line, and you can't reasonably run a site with a pile of shell scripts to manage jvm instances manually.

18:16 headius: clojure doesn't seem to have a way of referencing files normally

18:16 not like Ruby's "require"

18:16 that might be a problem for running without a precompile

18:16 clojurebot: not a problem, the average bid for it on getacoder is $821.00

18:16 Licenser: then lets add that?

18:17 hiredman: headius: load-file?

18:17 Licenser: I mean it should not be a problem to - eww okay it already exists

18:17 headius: hiredman: does that work once you've precompiled everything

18:17 Licenser: just give it a nicer less scary name :P

18:17 but why precompile?

18:17 hiredman: ,(doc load-file)

18:17 clojurebot: "([name]); Sequentially read and evaluate the set of forms contained in the file."

18:17 hiredman: ,(doc load)

18:17 clojurebot: "([& paths]); Loads Clojure code from resources in classpath. A path is interpreted as classpath-relative if it begins with a slash or relative to the root directory for the current namespace otherwise."

18:17 Licenser: I mean 90% of the stuff can run without it right?

18:18 headius: there's some duality here about being a file versus being a class though, no?

18:18 load-file won't load clojure code compiled into classes I presume

18:18 will load load files?

18:18 cemerick: load loads classes preferentially to .clj files

18:18 hiredman: headius: in RT at least it has some functionality to load a file or class, whichever is newer, dunno how it is exposed

18:18 headius: and is there no conflict between naming of classes versus files?

18:18 hiredman: cemerick: whichever is newer

18:19 headius: that's the issue we have

18:19 cemerick: hiredman: ah, right.

18:19 headius: files can have arbitrary paths and filenames that aren't valid class names

18:19 * cemerick hasn't used load in ~1.5 years

18:19 Licenser: in a ideal world doing something like clj src/my-main-file.clj and java -jar my-jar.jar should do the same

18:19 headius: Licenser: right

18:19 Licenser: that is what we should aim to get

18:19 kotarak: miltondsilva: another approach http://clojure.pastebin.com/6Hym772L

18:20 headius: it's just hard to support that seamlessly because filesystem paths may differ from package+class

18:20 in jruby we try to mangle paths both ways... / becomes _, + becomes _plus_

18:20 but it's hard

18:20 miltondsilva: kotarak: much better :)

18:21 Licenser: but it is kind of important to give the entire thing a 'it just works' feeling, and that is important in my eyes

18:21 headius: like how do you make a .clj be loadable as either a class or a file with one line of code if it's in a dir structure like blah/foo/1.0.5/whatever

18:21 kotarak: miltondsilva: but not tested...

18:21 miltondsilva: yes but the idea ;)

18:21 headius: that's been the challenge for jruby

18:21 I'd love to brainstorm solutions

18:22 Licenser: hmm brute force: take your class path map the files which classes they have

18:22 silly but not impossible solution

18:23 this makes the startup for projects from the commandline (a bit?) slower but it seems jars are preffared anyway

18:23 if you've a FS with meta data you youd even stuff such things in the meta data

18:23 headius: getting pretty wild now

18:23 it needs to be simple and work everywhere

18:24 Licenser: you've a relative path, some how

18:24 I guess

18:24 so scanning the files in that path once and mapping class -> file(s) should not be impossible

18:24 miltondsilva: kotarak: you had a very small typo (fload) apart from that it works very well

18:24 Licenser: for small to medium sized projects I doubt the time for that would be even notable

18:25 kotarak: miltondsilva: ah. 23:23 o'clock here, typos are allowed. ;P

18:25 Licenser: in clojure a class = a namespace right?

18:25 just to get sure, I'm not a clojure expert

18:25 kotarak: Licenser: no

18:25 Licenser: what do we actually want then?

18:25 headius: it's especially weird for jruby since require can do things like require '~foo/bar/../baz/quux'

18:25 what class name do you look for there?

18:26 Licenser: hmm hmm

18:27 I am confused now

18:27 kotarak: ,xff

18:27 clojurebot: java.lang.Exception: Unable to resolve symbol: xff in this context

18:28 cemerick: ,0xff

18:28 clojurebot: 255

18:29 Raynes: <Nilium> I think the one thing we got out of lisp was emacs, and that's akin to a war crime.

18:29 Licenser: headius: off topic question, do you have a highlight on jruby? :P

18:29 kotarak: cemerick: I know. I wondered whether the 0 is necessary (and of course it is, because xff is a symbol, but it's already late here ...)

18:30 cemerick: :-)

18:30 kotarak: cemerick: btw: wau wau grrr woof woof woof - oh, you mentioned it. My mistake. ;)

18:30 headius: Licenser: jruby and duby, yes :)

18:30 Licenser: will ther be jduby?

18:30 cemerick: kotarak: dude, I totally missed that one. :-)

18:31 Licenser: :)

18:31 sneaky headius, sneaky

18:31 headius: probably something like that once I start to look into type hints for jruby

18:31 Licenser: ^^

18:33 kotarak: ,0xffM

18:33 clojurebot: Invalid number: 0xffM

18:33 kotarak: k

18:34 Licenser: 0xdeadbeef

18:34 m,0xdeadbeef

18:34 ,0xdeadbeef

18:34 clojurebot: 3735928559

18:34 Licenser: geez I suck :(

18:42 headius: ,(/ 1 0)

18:42 clojurebot: java.lang.ArithmeticException: Divide by zero

18:42 headius: dang

18:42 programble: um

21:46 defn: i wish there was a way to generate a bit of test data by intelligently parsing a function and determining what it expects for its vars

21:47 _ato: type inference?

21:48 hiredman: clojurebot: deft?

21:48 clojurebot: deft is http://gist.github.com/128259

21:48 defn: awesome! named it deft?

21:49 hiredman: it's old and not very good

21:50 defn: hiredman: i think the consensus today was to use deft and deftype

21:51 hiredman: deft for the struct like map thing ontop of deftype?

21:51 defn: yes

21:51 there was a lot of talk about calling it defmaptype

21:51 or pruning defstruct

21:51 but in the end i got the impression that it would be called deft and deftype

21:52 i dont fully understand how it all works yet so dont quote me too literally on that

21:53 hiredman: i created a basic clojure interface for maxmind's geoip java library. is that a clojure library? I almost feel guilty publishing it because it is just a transcription of java to clojure...

21:55 hiredman: *shrug*

21:57 defn: i suppose it oculdnt hurt anyone

21:57 i just feel sort of like a fraud publishing it

21:57 there's no original work in it

22:02 17:28 < kotarak> cemerick: btw: wau wau grrr woof woof woof - oh, you mentioned it. My mistake. ;)

22:02 gah, sorry

22:04 cp2: hiredman: pardon for rolling through your gists, but... http://gist.github.com/223246

22:04 what is this for, heh

22:04 i mean, its pretty obvious what it _does_

22:04 not so much _why_

22:05 Mec: Anyone know a good tutorial that shows all the different types of swing components?

22:08 sattvik: Mec: I thought there were some Swing demos that shipped with the JDK, you could look for those.

22:08 dsop: is there a function in clojure on contrib which doesnt add the reuslt of a map to the new list of the result is nil

22:10 so to say it ignores the result value if it's nil

22:11 sattvik: dsop: What do you mean by the result of a map? Are you talking about (map fn data)?

22:12 miltondsilva: you could filter the result?

22:12 dsop: sattvik: yes (map fn data)

22:13 Mec: (map fn (filter identity data))

22:14 sattvik: ,(filter (complement nil?) (map identity [1 2 nil 4]))

22:14 clojurebot: (1 2 4)

22:15 miltondsilva: ,(remove nil? (map identity [1 2 nil 4]))

22:15 clojurebot: (1 2 4)

22:16 dsop: hm

22:16 thx

22:17 sattvik: miltondsilva: That's even better. I wondered if there was a way to avoid the complement.

22:17 miltondsilva: :)

22:20 dsop: Mec: hm i'm not sure if i understand why identity doesn't map nil

22:20 miltondsilva: ,(map identity [1 2 nil 4])

22:20 clojurebot: (1 2 nil 4)

22:20 Mec: (filter identity [1 2 nil 4])

22:20 ,(filter identity [1 2 nil 4])

22:20 clojurebot: (1 2 4)

22:20 miltondsilva: it does... but you then remove the nils

22:21 dsop: ah ys

22:22 Mec: its about equivalent but i prefer (remove nil?) it says more what you want to do

22:26 slyphon: uhm

22:30 brian__: Hi, I'm just learning about java interopt, I'm not sure I understand how java objects are used, ie in Java: Tclass t = new Tclass() , what is the equivalent to "t" in clojure? Thanks

22:31 miltondsilva: brian__: http://java.ociweb.com/mark/clojure/article.html#JavaInterop

22:34 brian__: ok

22:56 brandonw: if i am having problems figuring out exactly what something is called in clojure.contrib, is there a way to list all namespaces available in clojure.contrib?

22:59 Mec: brandonw: http://richhickey.github.com/clojure-contrib/index.html

23:01 brandonw: right, but theoretically if there isn't any documentation

23:01 or i don't have access to it at the moment

23:01 is there any way to enumerate symbols in a namespace from within clojure?

23:01 Mec: There is, but i'm not sure how to do it

23:06 The namespace section of the cheatsheet has some that might work

23:07 brandonw: perfect: all-ns does the trick

23:07 that's what i was looking for, thanks :)

23:07 Raynes: brandonw: There is also grep. :>

23:08 brandonw: yes, but i don't like to leave clojure, it is too nice :)

23:08 Raynes from reddit?

23:08 Raynes: brandonw: Aye, sir.

23:08 brandonw: i am the annoying one talking to you about vimclojure ;)

23:09 Raynes: And I'm the annoying one complaining about VimClojure.

23:09 brandonw: :) i only wanted to help because i didn't realize you already had emacs; i thought you were trying out vim from nothing

23:10 definitely no reason to deal with vimclojure's problems if you already have something perfectly workable, not to mention emacs' support is significantly better

23:10 Raynes: Naw. I'm persistent enough that I could figure everything out if I really needed to. I just wanted to try it out a while back.

23:11 brandonw: yeah. it isn't so much that vimclojure rivals emacs' clojure support (it is reasonably close, but still noticeably worse)

23:11 Raynes: I'm fairly certain that once Meikel gets the build stuff and documentation for such worked out, it will be much simpler.

23:11 brandonw: it is more amazing what meikel did with vim (which is much harder to extend for something like swank-clojure)

23:11 yeah

23:11 Raynes: I imagine. VimScript makes my eyes burn.

23:11 @_@

23:12 brandonw: i am still amazed at his vim/clojure prowess. i've tried several plugins for different filetypes in vim

23:12 and they all had the basics, and some attempted stuff like auto-complete

23:12 but nothing has come even close to vimclojure in terms of a fully working repl, completion, viewing source, going to definitions, auto-completion

23:12 with only vim-script to work with, it truly astounds me :)

23:13 Raynes: Agreed.

23:14 Mec: wooo lich king dead finally

23:15 now back to programming

23:15 brandonw: a blizzard fan

23:15 you wouldn't happen to have a starcraft 2 beta key you could accidentally PM me with :D

23:15 Raynes: Probably because Diablo II is so god-awful hackable.

23:15 Mec: no :x havnt gotten one myself

23:16 brandonw: yeah, i'm actually working on a bwapi-proxy port to clojure as an exercise in learning clojure

23:16 not to mention making it easier to interface with :)

23:16 Raynes: brandonw: Hilariously, it was teh blizzhackers that got me into programming. I still hang around #bhdev on SynIRC.

23:17 I assume you probably know of them.

23:17 If you're a blizzard fan.

23:17 brandonw: that's pretty cool :) what were they doing when you first started programming?

23:17 yeah, they are the ones responsible for the sc2 beta crack :)

23:17 which i for some reason haven't tried yet...

23:17 Raynes: It was when the 1.12 patch was released a couple of years ago.

23:17 They were mostly doing map hack and tppk.

23:18 *cough*#clojure-casual*cough*

23:19 phren0logy: Is anyone else using LabREPL?

23:19 Raynes: miltondsilva: Hit-and-run channel joins are frowned upon. ;P

23:19 It's more active during the day. We're growing slowly.

23:20 miltondsilva: :) I was just checking to see if there was much activity

23:23 Raynes: brandonw: You should totally join. If only to check out my bot.

23:23 :p

23:23 brandonw: #clojure-casual?

23:23 Raynes: Indeed.

23:23 brandonw: i thought i checked to see who was in it, and i didn't see anyone

23:23 i guess i typed the wrong channel :)

Logging service provided by n01se.net