Re: [ANN] core.rrb-vector -- RRB-Tree-based confluently persistent vectors

2013-06-01 Thread Peter Taoussanis 
That looks great Michał, thanks for your work!

Have use cases for something like this popping up quite regularly - 
definitely looking forward to a production-ready implementation. Cheers! 

- Peter

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [ANN] core.rrb-vector -- RRB-Tree-based confluently persistent vectors

2013-06-01 Thread Philip Potter 
Check out Phil bagwell and Daniel spiewak's talks from clojure/conj 2011.
The former describes RRB trees, while the latter describes some of the
failings of finger trees on the JVM.

Phil
On Jun 1, 2013 1:09 AM, "Daniel"  wrote:

> Apologies for my lack of knowledge. My understanding was that a finger
> tree implementation has been in development for some time and was to
> provide the same benefits. Can you explain the differences between RRB
> trees and finger trees? Any hope of getting this project into core?
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Simple socket programming problem

2013-06-01 Thread Michael Wood 
Hi

On 1 June 2013 02:44, Andrew Spano  wrote:

> Hello,
>
> I'm trying to create a very simple interaction between a client and server
> program using the server-socket library which used to be part of
> clojure-contrib and is now maintained by technomancy
> https://github.com/technomancy/server-socket/blob/master/src/server/socket.clj
>
>
> I created a simple echo server, which works fine when accessed by telnet
> but can't seem to accept messages from the python client.
>
[...]


> The only output the client displays is a single empty vector after which
> it waits to receive more data.  Since this works correctly when I access
> the port over telnet I can't figure out what the problem is.  As a novice
> to both clojure and socket programming my best guess is that it has
> something to do with multiple threading--I know that both python and
> clojure create a new thread for each distinct socket.
>

No, there is no threading involved here.  Neither Python, nor Clojure
create new threads for new sockets.

Some servers create new threads when accepting connections, but that has to
be explicitly programmed like that.  Other servers (although generally not
ones implemented in Java) instead spawn new processes to handle new
connections.  Others use a combination of both.  There are even others that
can handle multiple connections with only a single process and a single
thread by using select() or poll() etc.


> It's probably an incorrect guess. That's why I've decided to consult the
> community :D.  Any help is appreciated in advance!
>
>
-- 
Michael Wood 

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: keys maps ... gak

2013-06-01 Thread mond 
Dang it, I could have sworn that I had tried that combination but actually 
was missing the set wrapping the map!

So thanks TJ - great work and I really appreciate the support.

Ray

On Saturday, June 1, 2013 3:26:32 AM UTC+2, Tj Gabbour wrote:
>
> Hi Ray,
>
> Perhaps this?
>
>
> user> (let [desired-entity-names (set (map entity-names [:model :project]))]
> (select #(desired-entity-names (:entity %))
> query-parts))
> #{{:entity "Model",   :main-query "select * from model where ..."} 
>   {:entity "Project", :main-query "select * from project where ..."}}
>
>
> All the best,
>   Tj
>
> On Friday, May 31, 2013 10:18:09 PM UTC+2, mond wrote:
>>
>> Sometimes its just so frustrating when you know you are close but just 
>> cannot get that last little bit ... so I am appealing again for more newbie 
>> support 
>>
>> I have a map for some names:
>>
>> user=> (def entity-names {:project "Project" :model "Model"})
>>
>> Which I then reference in a set of maps:
>>
>> user=> def query-parts #{{:entity (entity-names :project )
>> :main-query "select * from project where ..." }
>>{:entity (entity-names :model )
>> :main-query "select * from model where ..." }})
>>
>> This query-parts is actually a large set. It will form the basis of 
>> execution and sometimes I want to execute a smaller set of the queries.
>>
>> So I want to be able to filter it based on a subset of the entity names, 
>> for example just :model.
>>
>> user=> (select #(= (:model entity-names) (:entity %)) query-parts)
>> #{{:entity "Model", :main-query "Model Query"}}
>>
>> So that works great.
>>
>> But I would like a list of entities (:model :project :foo :bar) that 
>> represents a subset of the complete set of query parts.
>>
>> So I just (sic!) need some advice on how to run this select over a list 
>> of entity names rather than just the one shown above.
>>
>> I'm ashamed to say that I have spent an hour on this already so this is 
>> my white flag. I hope you can help.
>>
>> Thanks
>>
>> Ray
>>
>>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

how would you improve this map-reduce style fn?

2013-06-01 Thread Jim - FooBar(); 

Hi all,

I've been using the following fn quite extensively lately and I'm just 
wondering if you can see any flaws with it...or perhaps something that 
can be done better? I generally find that this performs better than a 
bare pmap and in fact it often performs better than my 'pool-map' (which 
I'm not showing here) which is backed by executors.


(defn mapr
"A basic map-reduce style mapping-function. Will partition the data 
according to p-size and assign a future to each partition (per pmap)."

([f coll p-size]
 (->> coll
(partition-all p-size)
(pmap (fn [p] (reduce #(conj %1 (f %2)) [] p)) )
(apply concat)) ) ;;concat the inner vectors that represent the 
partitions

([f coll]
  (mapr f coll (+ 2 cpu-no

thanks,

Jim

--
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups "Clojure" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: how would you improve this map-reduce style fn?

2013-06-01 Thread James Reeves 
Why do you use:

  (reduce #(conj %1 (f %2)) [] p)

Instead of:

  (mapv f p)

?

Also, this looks a lot like what you can achieve with the reducers library:

(r/fold p-size r/cat r/append! (r/map f (vec coll)))

- James


On 1 June 2013 12:49, Jim - FooBar();  wrote:

> Hi all,
>
> I've been using the following fn quite extensively lately and I'm just
> wondering if you can see any flaws with it...or perhaps something that can
> be done better? I generally find that this performs better than a bare pmap
> and in fact it often performs better than my 'pool-map' (which I'm not
> showing here) which is backed by executors.
>
> (defn mapr
> "A basic map-reduce style mapping-function. Will partition the data
> according to p-size and assign a future to each partition (per pmap)."
> ([f coll p-size]
>  (->> coll
> (partition-all p-size)
> (pmap (fn [p] (reduce #(conj %1 (f %2)) [] p)) )
> (apply concat)) ) ;;concat the inner vectors that represent the
> partitions
> ([f coll]
>   (mapr f coll (+ 2 cpu-no
>
> thanks,
>
> Jim
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscribe@**googlegroups.com
> For more options, visit this group at
> http://groups.google.com/**group/clojure?hl=en
> --- You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to 
> clojure+unsubscribe@**googlegroups.com
> .
> For more options, visit 
> https://groups.google.com/**groups/opt_out
> .
>
>
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: how would you improve this map-reduce style fn?

2013-06-01 Thread Jim - FooBar(); 

On 01/06/13 13:06, James Reeves wrote:

Why do you use:

  (reduce #(conj %1 (f %2)) [] p)

Instead of:

  (mapv f p)

?


oops you're right mapv is simpler and has the same effect :)

Also, this looks a lot like what you can achieve with the reducers 
library:


(r/fold p-size r/cat r/append! (r/map f (vec coll)))


hmmm...I'll have to think about that for a while...

thanks a lot  James :)
I was suspecting it can be simplified...

Jim

--
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups "Clojure" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: how would you improve this map-reduce style fn?

2013-06-01 Thread Jim - FooBar(); 

On 01/06/13 13:06, James Reeves wrote:
Also, this looks a lot like what you can achieve with the reducers 
library:


(r/fold p-size r/cat r/append! (r/map f (vec coll)))


well, for fork-join-based parallelism I was using this:

(defn fold-into-vec [chunk coll]
"Provided a reducer, concatenate into a vector.
 Same as (into [] coll), but parallel."
  (r/fold chunk (r/monoid into vector) conj coll))

(defn rmap
"A fork-join based mapping function that pours the results in a vector."
[f coll fj-chunk-size]
(fold-into-vec fj-chunk-size (r/map f (vec coll

where 'fold-into-vec' is taken from 
http://www.thebusby.com/2012/07/tips-tricks-with-clojure-reducers.html


basically, the only difference is the reducing/combining fns...you 
suggest r/cat & r/append! whereas I'm using (r/monoid into vector) and conj.
from a quick look in reducers.clj it seems that cat uses an ArrayList 
underneath...is this why it's considered high-performance? I also see 
there is 'foldcat' which is (foldcatappend!coll) - exacly what you 're 
sugegsting! interesting stuff...I'll try it now :)


Jim

--
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups "Clojure" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

ExceptionInInitializerError in clojure.main in every clojure lein project.

2013-06-01 Thread Alexandr Kurilin 
Hello folks,

I'm wondering if someone out there might have encountered this problem 
before. I'm not sure when exactly it started, perhaps 2-3 days ago, but 
ever since I have not been able to run neither "lein repl" nor "lein ring 
server[-headless]" on this machine on any of my leiningen-created clojure 
projects. The machine I'm running on is a Ubuntu 12.04 LTS box with 
java-7-openjdk.

As an example, I can create a new lein project with "lein new justatest" 
and run "lein repl" in its folder right away, and I will get the following 
error:

Exception in thread "main" java.lang.ExceptionInInitializerError
at clojure.main.(main.java:20)
Caused by: java.lang.IllegalStateException: Attempting to call unbound fn: 
#'clojure.core/refer
at clojure.lang.Var$Unbound.throwArity(Var.java:43)
at clojure.lang.AFn.invoke(AFn.java:39)
at clojure.lang.Var.invoke(Var.java:415)
at clojure.lang.RT.doInit(RT.java:460)
at clojure.lang.RT.(RT.java:329)
... 1 more
Could not find the main class: clojure.main. Program will exit.
Exception in thread "Thread-1" clojure.lang.ExceptionInfo: Subprocess 
failed {:exit-code 1}
at clojure.core$ex_info.invoke(core.clj:4327)
at leiningen.core.eval$fn__1963.invoke(eval.clj:213)
at clojure.lang.MultiFn.invoke(MultiFn.java:231)
at leiningen.core.eval$eval_in_project.invoke(eval.clj:283)
at leiningen.repl$start_server.invoke(repl.clj:117)
at leiningen.repl$server$fn__4421.invoke(repl.clj:173)
at clojure.lang.AFn.applyToHelper(AFn.java:159)
at clojure.lang.AFn.applyTo(AFn.java:151)
at clojure.core$apply.invoke(core.clj:617)
at clojure.core$with_bindings_STAR_.doInvoke(core.clj:1788)
at clojure.lang.RestFn.invoke(RestFn.java:425)
at clojure.lang.AFn.applyToHelper(AFn.java:163)
at clojure.lang.RestFn.applyTo(RestFn.java:132)
at clojure.core$apply.invoke(core.clj:621)
at clojure.core$bound_fn_STAR_$fn__4102.doInvoke(core.clj:1810)
at clojure.lang.RestFn.invoke(RestFn.java:397)
at clojure.lang.AFn.run(AFn.java:24)
at java.lang.Thread.run(Thread.java:679)


Does this ring a bell at all? I have seen this error pop up a couple of 
times when Googling around, but no conclusive solutions that are applicable 
to my situation.

Thanks!

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: gen-class - ClassNotFoundException

2013-06-01 Thread Meikel Brandmeyer (kotarak) 
You have to compile your namespace. gen-class only works with AOT 
compilation.

see: http://clojure.org/compilation

Kind regards
Meikel

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: ExceptionInInitializerError in clojure.main in every clojure lein project.

2013-06-01 Thread Alexandr Kurilin 
Answering myself on this one, thanks to hiredman from #clojure.

The 1.5.1 clojure jar was somehow broken, nuking the folder and letting 
leiningen re-fetch it fixed it.

On Saturday, June 1, 2013 11:11:41 AM UTC-7, Alexandr Kurilin wrote:
>
> Hello folks,
>
> I'm wondering if someone out there might have encountered this problem 
> before. I'm not sure when exactly it started, perhaps 2-3 days ago, but 
> ever since I have not been able to run neither "lein repl" nor "lein ring 
> server[-headless]" on this machine on any of my leiningen-created clojure 
> projects. The machine I'm running on is a Ubuntu 12.04 LTS box with 
> java-7-openjdk.
>
> As an example, I can create a new lein project with "lein new justatest" 
> and run "lein repl" in its folder right away, and I will get the following 
> error:
>
> Exception in thread "main" java.lang.ExceptionInInitializerError
> at clojure.main.(main.java:20)
> Caused by: java.lang.IllegalStateException: Attempting to call unbound fn: 
> #'clojure.core/refer
> at clojure.lang.Var$Unbound.throwArity(Var.java:43)
> at clojure.lang.AFn.invoke(AFn.java:39)
> at clojure.lang.Var.invoke(Var.java:415)
> at clojure.lang.RT.doInit(RT.java:460)
> at clojure.lang.RT.(RT.java:329)
> ... 1 more
> Could not find the main class: clojure.main. Program will exit.
> Exception in thread "Thread-1" clojure.lang.ExceptionInfo: Subprocess 
> failed {:exit-code 1}
> at clojure.core$ex_info.invoke(core.clj:4327)
> at leiningen.core.eval$fn__1963.invoke(eval.clj:213)
> at clojure.lang.MultiFn.invoke(MultiFn.java:231)
> at leiningen.core.eval$eval_in_project.invoke(eval.clj:283)
> at leiningen.repl$start_server.invoke(repl.clj:117)
> at leiningen.repl$server$fn__4421.invoke(repl.clj:173)
> at clojure.lang.AFn.applyToHelper(AFn.java:159)
> at clojure.lang.AFn.applyTo(AFn.java:151)
> at clojure.core$apply.invoke(core.clj:617)
> at clojure.core$with_bindings_STAR_.doInvoke(core.clj:1788)
> at clojure.lang.RestFn.invoke(RestFn.java:425)
> at clojure.lang.AFn.applyToHelper(AFn.java:163)
> at clojure.lang.RestFn.applyTo(RestFn.java:132)
> at clojure.core$apply.invoke(core.clj:621)
> at clojure.core$bound_fn_STAR_$fn__4102.doInvoke(core.clj:1810)
> at clojure.lang.RestFn.invoke(RestFn.java:397)
> at clojure.lang.AFn.run(AFn.java:24)
> at java.lang.Thread.run(Thread.java:679)
>
>
> Does this ring a bell at all? I have seen this error pop up a couple of 
> times when Googling around, but no conclusive solutions that are applicable 
> to my situation.
>
> Thanks!
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [ANN] core.rrb-vector -- RRB-Tree-based confluently persistent vectors

2013-06-01 Thread Michał Marczyk 
Hi Daniel,

First, about getting this into core: the idea behind core.rrb-vector
is to provide extensions to the core Clojure vector API which could at
any point in time be folded into the core library -- or simply dropped
into any projects which need them with no need for them to pay
attention to which vector types they are using. Hence the core.* name.
That's as close to an answer as I can provide on this point. :-)


About RRB trees vs. finger trees:


RRB trees are a variation on the idea behind Clojure's
PersistentVector, whereby concatenation and slicing in logarithmic
time become possible at the cost of a slight slowdown of operations on
vectors resulting from the application these two additional
operations. There is no slowdown in the base case of a vector which
never participated in concatenation / slicing. (That's in principle;
core.rrb-vector's vector is currently slower than c.l.PersistentVector
and about on a par with gvec. Figuring out how to close the gap is one
of the major goals for further development.)

As we all know from experience, persistent vectors are *extremely*
fast, and RRB trees only sacrifice a little of this speed, so there is
every hope that they will be eminently usable in practice.

Rather importantly, RRB trees can seamlessly interoperate with regular
persistent vectors, and indeed core.rrb-vector allows you to pass in
vectors of arbitrary type to its catvec and subvec functions.
(Strictly speaking, element types of vectors passed into catvec must
match, that is, you can't concatenate a vector of objects with a
vector of longs; but you can certainly concatenate a regular vector of
objects with a clojure.core/subvec-created "view vector" of objects
and a previously created RRB vector. RRB tree variants of vec, vector
and vector-of are available, but there should be no reason to use
them; I'm only using them for tests and benchmarking.)


Finger trees are a slightly different beast in that they are more like
a toolkit for constructing ad hoc special-purpose persistent data
structures. The data.finger-tree contrib [1] is designed to support
such usage.

One could indeed use it to construct a vector workalike (in fact I
believe the provided counted-double-list is pretty much that) with
pretty great big-O complexity on a number of operations. Unfortunately
the real-world performance of finger trees is generally considered to
be less satisfying than the complexity bounds -- which is why we use
persistent vectors in the first place: the finger tree paper [2] was
published in 2006, so the choice was certainly open in Clojure's early
days. Daniel Spiewak's talk mentioned by Phil goes into some details
and attributes the underwhelming performance mostly to poor memory
locality; you can watch it at [3].

Finger trees may still be useful because of this toolkit-like feel to
them; when specialized data structures are available, however, they
will often be superior in performance.

Cheers,
Michał


[1] https://github.com/clojure/data.finger-tree

[2] http://www.soi.city.ac.uk/~ross/papers/FingerTree.html

[3] http://www.youtube.com/watch?v=pNhBQJN44YQ


On 1 June 2013 02:09, Daniel  wrote:
> Apologies for my lack of knowledge. My understanding was that a finger tree 
> implementation has been in development for some time and was to provide the 
> same benefits. Can you explain the differences between RRB trees and finger 
> trees? Any hope of getting this project into core?
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [ANN] core.rrb-vector -- RRB-Tree-based confluently persistent vectors

2013-06-01 Thread Michał Marczyk 
On 1 June 2013 09:22, Peter Taoussanis  wrote:
> That looks great Michał, thanks for your work!
>
> Have use cases for something like this popping up quite regularly -
> definitely looking forward to a production-ready implementation. Cheers!
>
> - Peter

Thanks Peter,

Good to know there is real-world demand for this!

Cheers,
Michał


>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [ANN] core.rrb-vector -- RRB-Tree-based confluently persistent vectors

2013-06-01 Thread Michał Marczyk 
On 1 June 2013 09:41, Philip Potter  wrote:
> Check out Phil bagwell and Daniel spiewak's talks from clojure/conj 2011.
> The former describes RRB trees, while the latter describes some of the
> failings of finger trees on the JVM.
>
> Phil

Thanks for posting the pointers, Phil!


For anybody interested in even more background, here are two additional links:

1. The paper itself:

http://infoscience.epfl.ch/record/169879/files/RMTrees.pdf

2. Tiark Rompf's presentation on RRB trees:

http://skillsmatter.com/podcast/scala/fast-concatenation-immutable-vectors

Cheers,
Michał


>
> On Jun 1, 2013 1:09 AM, "Daniel"  wrote:
>>
>> Apologies for my lack of knowledge. My understanding was that a finger
>> tree implementation has been in development for some time and was to provide
>> the same benefits. Can you explain the differences between RRB trees and
>> finger trees? Any hope of getting this project into core?
>>
>> --
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [ANN] core.rrb-vector -- RRB-Tree-based confluently persistent vectors

2013-06-01 Thread Michael Klishin 
2013/6/2 Michał Marczyk 

> For anybody interested in even more background, here are two additional
> links:
>
> 1. The paper itself:
>
> http://infoscience.epfl.ch/record/169879/files/RMTrees.pdf
>

For people who are not sure where to find the project as opposed to the
paper it implements, here it is:
https://github.com/clojure/core.rrb-vector

Unfortunately, the README currently includes no dependency information.
Beginners
won't be able to use your project, Michal.
-- 
MK

http://github.com/michaelklishin
http://twitter.com/michaelklishin

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [ANN] core.rrb-vector -- RRB-Tree-based confluently persistent vectors

2013-06-01 Thread Sean Corfield 
Guidelines for contrib READMEs can be found here:
http://dev.clojure.org/display/design/Contrib+Library+READMEs

On Sat, Jun 1, 2013 at 10:58 PM, Michael Klishin
 wrote:
>
> 2013/6/2 Michał Marczyk 
>>
>> For anybody interested in even more background, here are two additional
>> links:
>>
>> 1. The paper itself:
>>
>> http://infoscience.epfl.ch/record/169879/files/RMTrees.pdf
>
>
> For people who are not sure where to find the project as opposed to the
> paper it implements, here it is:
> https://github.com/clojure/core.rrb-vector
>
> Unfortunately, the README currently includes no dependency information.
> Beginners
> won't be able to use your project, Michal.
> --
> MK
>
> http://github.com/michaelklishin
> http://twitter.com/michaelklishin
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>



-- 
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.