1:15 abrooks: Hrm. xml/emit-element does not properly escape XML entities.
1:53 Has anyone use xml-stream-reader.clj?
1:53 I'm properly steeped in Java to grok the context, I think.
1:53 I'm looking for examples if anyone has them.
11:25 rapido: how hard would it be to allow meta-data for *all* types, not only for collections or symbols?
11:31 rhickey: impossible, as many types, like String are final
11:31 and I don't want to require wrappers
11:32 rapido: can't you just keep a separate global map that maps any object to its meta data?
11:32 (i know global is evil)
11:32 rhickey: there is that
11:33 plus, the original concept of metadata coincides with data as values - with-meta produces a new object
11:33 any global cache would be identity-basec
11:33 metadata on Vars is an anomaly
11:34 rapido: still, i feel the concept can be pushed a lot further
11:35 rhickey: well, java.util.concurrent is there
11:36 rapido: does java.util.concurrent have something similar to meta-data?
11:37 rhickey: no, just the tools to build the global map you want
11:39 actually, maybe not, as no concurrent identity map
11:41 rapido: i have been looking at PersistentHashMap which is nice, performance wise
11:41 rhickey: thanks
11:41 rapido: but i feel PersistentVector could be implemented similarly fast.
11:41 do you know about ropes?
11:42 rhickey: how is persistent vector not similarly fast?
11:42 same data structure
11:42 rapido: is it possible to concatenate two vectors?
11:43 in O(log(n))?
11:44 rhickey: no, nothing that virtualizes concat for vector
11:45 rapido: i think you should do an implementation that's optimized for vectors
11:45 rhickey: of concat?
11:46 rapido: concat, head, tail, subvector etc. all the important operations
11:47 rhickey: I don't think vector concat is important
11:48 head/tail/conj/subvector are all smoking, as is initialization with an existing array
11:48 rapido: let's say you have a sequence of chars
11:48 Chouser: rapido: wouldn't it be pretty easy to write an object that holds two (or more) vectors, and translates the operations you need to the underlying vectors?
11:49 rapido: fast concatenation of string would be nice not?
11:49 rhickey: There is fast concat, it just doesn't yield a vector
11:49 rapido: is it lazy?
11:49 rhickey: lazy-cat is
11:50 rapido: where can i find fast concat and what algorithm is used?
11:50 rhickey: um, the source for concat?
11:51 gotta run
11:53 rapido: but if you repeatedly concat *n* times you end up with a linear structure that resembles a linked list
11:54 but if the (lazy) structure would be balanced with using a tree balance algorithm you would still have good performance for all operations
11:54 chouser: does that answer your question?
11:56 replace strings(=sequence of chars) with any sequence of objects
11:58 Chouser: Yeah, I see your point.
11:58 The Clojure data structures (vector, etc.) are written in Java. There's no reason you can't write your own if you have an application that needs a certain performance profile.
12:01 rapido: sure. it's the old 'library' versus 'build-in' debate :)
12:02 nevertheless, there are many more interesting immutable data structures
12:02 Chouser: yup.
12:03 It'll be interesting to see how that debate plays out over time.
12:03 rapido: avl trees, alpha-beta trees, etc. etc.
12:03 Chouser: I think Rich wants to keep the core language pretty small, which seems like a good idea.
12:03 We've got clojure-contrib as a semi-official place to offer general-purpose code.
12:04 rapido: i saw (one of) his presentations which are very good.
12:04 Chouser: I always liked how Python gives you such a large library be default. It'll be interesting to see where Clojure ends up.
12:05 rapido: i also very strongly believe that mutability is evil, but for more reasons than concurrency
12:06 still, keeping mutability *out* of all the frameworks will be difficult
12:07 Chouser: I'm not deeply familiar with this stuff, but in order to have complete immutability, don't you need monads? I think Clojure has chosen a more practical approach of carefully controlled mutability.
12:08 rapido: i've implementation my own (research) language that pushed immutability to the extreme
12:08 Chouser: ah
12:08 rapido: data, code, computations, environments are all immutable (without using monads)
12:09 i've done several implementations in java, factor, haskell and (finally) scala
12:10 haskell was nice but when i wanted to add io, the code turned into an ugly mess
12:10 chouser: do you know factor?
12:11 Chouser: nope
12:11 * Chouser reads wikipedia
12:15 rapido: what i don't understand why slava, the factor developer, has moved away from the jvm
12:15 i think that was his biggest mistake
12:16 you can't beat the libraries and the cummulated thousands of man years of (compiler) research that went into the jvm
12:17 Chouser: yeah
12:17 rapido: i think rich made very a good choice there
12:21 chouser: so what's your take/interest on clojure
12:26 got to go... later..
13:59 leafw: I have just sent a feature proposal to the mailing list: embedding java code -like python weaver package. Would be great.
14:00 to have the best of both worlds ... convenience+power, and speed where it matters.
15:55 Chouser: rhickey: I'm poking at the code in the "embedded java" post to the group.
15:56 ImageJ beat me up, so I'm using: (def pix (into-array (for [x (range 512) y (range 512)] (+ x y))))
15:57 on my computer: (time (dotimes i 10 (/ (apply + pix) (count pix)))) ; 863.762673 msecs
15:58 oh, nm -- I don't have anything interesting to say yet. Sorry.
16:05 well, one thing is sort interesting: (reduce + pix) is pretty much the same speed as (reduce long/+ pix)