subject:"Re\: Update"

Why are Clojure features defined in terms of Java classes, instead of as 
bytecode primitives?
For eg: Cons is a class containing two objects: first and rest.
Is this only to achieve Java interoperability, or is there more to it?

-- 
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/d/optout.

Re: Update

2014-04-29 Thread Andrew Chambers

Well, why write it in primitives when there is a perfectly good compiler 
from java to primitives? I dont quite understand why you think there would 
be benefit from manually writing everything with java bytecode. The JVM 
works with classes, thats how its designed, Clojure itself is just a java 
library.

On Tuesday, April 29, 2014 8:25:01 PM UTC+12, Divyansh Prakash wrote:

 Why are Clojure features defined in terms of Java classes, instead of as 
 bytecode primitives?
 For eg: Cons is a class containing two objects: first and rest.
 Is this only to achieve Java interoperability, or is there more to it?


-- 
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/d/optout.

Re: Update

2014-04-29 Thread David Powell

The JVM is very class-oriented.  It is basically designed for Java, and
corresponds pretty much to the things you can do in Java.  Code belongs to
methods which belong to classes, and calls are made using java method
calling conventions.  Data has to be stored in primitives, arrays, or
objects; and arrays aren't particularly to-the-metal in Java anyway.

The Byte Code Verifier keeps what you do fairly simple - eg you can't just
leave things in the stack and jump to another method.

Even if you wanted to do anything a bit different, the performance of the
JVM all comes from the assumptions made while executing the bytecodes at
runtime.  If you did anything very weird, you'd probably find that these
optimizations didn't kick in.



On Tue, Apr 29, 2014 at 9:25 AM, Divyansh Prakash 
divyanshprakas...@gmail.com wrote:

 Why are Clojure features defined in terms of Java classes, instead of as
 bytecode primitives?
 For eg: Cons is a class containing two objects: first and rest.
 Is this only to achieve Java interoperability, or is there more to it?

 --
 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/d/optout.


-- 
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/d/optout.

Re: Update

Thank you for the explanation.
What if I target a non-OO-centric VM (like Parrot or LLVM)?

I've noticed that most Lisp implementations define lambda calculus 
primitives, and then use those as the core.
I wonder what would be if we had bytecode primitives, and defined 
everything else on top of that. 
I don't know to what end, this is just an exercise.

Do you know if this has been done before?

-- 
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/d/optout.

Re: Update

I looked into a port of Clojure to Parrot, and it basically does the same 
thinghttps://github.com/ayardley/ClojurePVM/blob/master/src/c/lisp/microlisp/lisp.c
.

-- 
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/d/optout.

Re: Update

Why not emit bytecode directly from the language?
Couldn't this potentially lead to tons of specialized optimizing macros? 

-- 
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/d/optout.

Re: Update

2014-04-29 Thread Gary Trakhman

The hard part with other runtimes will be details around things like
garbage collection for the implementation of persistent data structures.

Clojurescript is a better example of how this is done since most of the
impls are implemented in the language itself, different from
clojure-proper.

Granted, printed-text compiler output sucks, but it all seems to work.

Here's the javascript emission stage:
https://github.com/clojure/clojurescript/blob/master/src/clj/cljs/compiler.clj#L206

It's been ported to gambit-scheme:
https://github.com/takeoutweight/clojure-scheme/blob/rewrite/src/clj/cljscm/compiler.clj



On Tue, Apr 29, 2014 at 10:45 AM, Divyansh Prakash 
divyanshprakas...@gmail.com wrote:

 I looked into a port of Clojure to Parrot, and it basically does the same
 thinghttps://github.com/ayardley/ClojurePVM/blob/master/src/c/lisp/microlisp/lisp.c
 .

 --
 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/d/optout.


-- 
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/d/optout.

Re: Update

Check out my previous reply. The parrot vm provides gc and everything, But 
still the author defines lambda primitives in c, and then builds over it.

-- 
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/d/optout.

Re: Update

2014-04-29 Thread Andrew Chambers

For the llvm based approach you can look at vmkit.

On Wednesday, April 30, 2014 3:39:21 AM UTC+12, Divyansh Prakash wrote:

 Check out my previous reply. The parrot vm provides gc and everything, But 
 still the author defines lambda primitives in c, and then builds over it.

-- 
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/d/optout.

Re: Update

2014-04-28 Thread Divyansh Prakash

Jasmin would be a much better choice, btw, because it could be used as a 
dependency in Clojure.

-- 
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/d/optout.

Re: Update

2014-04-28 Thread Gary Trakhman

Seen: https://github.com/clojure/tools.emitter.jvm ?
Here's the actual ASM emit:
https://github.com/clojure/tools.emitter.jvm/blob/master/src/main/clojure/clojure/tools/emitter/jvm/transform.clj


On Mon, Apr 28, 2014 at 5:43 PM, Divyansh Prakash 
divyanshprakas...@gmail.com wrote:

 ---IDEA---
 I was wondering if we could have a bytecode DSL that would map directly to
 JVM assembler, using either Jasmin http://jasmin.sourceforge.net/ or
 Krakatau https://github.com/Storyyeller/Krakatau.
 Then we could define primitives using these bytecode instructions.
 For eg:

 (defroutine + [a b]
 (push! a)
 (push! b)
 add!
 pop!)

 that could be used to call:

 (+ 2 3) ;= 5

 --
 We could define the lambda calculus primitives in the same way.
 This would be awesome because bottlenecks could be optimized by embedding
 assembly inside Lisp itself.
 We could do efficient bit-manipulation, write shader routines, and what
 not.

 --
 Thoughts?

 --
 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/d/optout.


-- 
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/d/optout.

Re: Update

2014-04-28 Thread Divyansh Prakash



 Thanks!

 Exactly what I was looking for.

-- 
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/d/optout.

Re: Update to downloads page?

2012-06-21 Thread Timothy Baldridge

Or perhaps something like this:

Although it is possible to download Clojure directly here link, for
a more complete package management system please see Leiningen.

But yes, I agree, we need a big fat notice that says don't download
directly unless you know what you're doing.

Timothy

On Thu, Jun 21, 2012 at 1:11 PM, John Gabriele jmg3...@gmail.com wrote:
 Hi,

 It appears to me that, at the top of http://clojure.org/downloads , it
 should say,

 Though, for typical use, install
 [Leiningen](http://leiningen.org/index.html) and have it take care of
 getting Clojure for you.

 Would it be possible to change this? I've sent in my CA, but don't
 know if Rich got it yet.

 Thanks,
 ---John

 --
 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



-- 
“One of the main causes of the fall of the Roman Empire was
that–lacking zero–they had no way to indicate successful termination
of their C programs.”
(Robert Firth)

-- 
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

Re: (update-in) and getting the new value at the leaf efficiently

2012-04-26 Thread Andy Fingerhut

Here is one way to do it called update-in+.  It returns a vector consisting
of the new udpated value, like update-in does, followed by the original
value (in case you might want to see that for some reason), followed by the
updated value.

(defn update-in+
  ([m [k  ks] f  args]
 (if ks
   (let [[new-map old-val new-val] (apply update-in+ (get m k) ks f
args)]
 [(assoc m k new-map) old-val new-val])
   (let [old-val (get m k)
 new-val (apply f old-val args)]
 [(assoc m k new-val) old-val new-val]

Andy

On Thu, Apr 26, 2012 at 9:19 AM, Ambrose Bonnaire-Sergeant 
abonnaireserge...@gmail.com wrote:

 Hi,

 You shouldn't need mutation for such a function.

 If you look at the source of update-in, it's fairly straightforward.

 (defn update-in
   ([m [k  ks] f  args]
(if ks
  (assoc m k (apply update-in (get m k) ks f args))
  (assoc m k (apply f (get m k) args)

 Just create another function that returns a vector of the result of
 applying f, and the update-in result. It should be easy starting from
 update-in's source.

 (I'm not aware of an existing solution)

 Thanks,
 Ambrose

 On Fri, Apr 27, 2012 at 12:00 AM, blais goo...@furius.ca wrote:

 Hi,
 I have this use-case for (update-in) which keeps showing up in my code
 which I don't have a solution for and I'm wondering if there isn't a
 solution.
 How do I _efficiently_ obtain the new value created by an invocation of
 (update-in), that is, without having to get the modified value by lookups
 in the new map?

 Simplified example:

 (def m {:planet {:country {:state {:city {:borough 4})

 (let [mm (update-in m
 [:planet :country :state :city :borough]
 (fn [old] (if (nil? old) 0 (inc old]
   (get-in mm [:planet :country :state :city :borough]))

 (update-in) returns the new/modified map, but what I want is to obtain
 the new count returned by the anonymous function.
 Having to call (get-in) right after is inefficient.

 This is obviously a contrived example for this question, but I have a lot
 of real use cases for this (where at the top level of my app I have a ref
 for a deep structure which changes as a response to network events).

 Is there an idiomatic way to do this without having to resort to
 mutability?
 (The only solution that comes to my mind is to wrap up update-in and the
 modifier function with a special version that updates a local mutable and
 return both the new map and the new object.)
 Nasty?

 Thank you,



  --
 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 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 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

Re: (update-in) and getting the new value at the leaf efficiently

2012-04-26 Thread Jay Fields

I would have written the fn like this, if I was following what you've been
doing:

(def m {:planet {:country {:state {:city {:borough 4})

(let [mm (update-in m [:planet :country :state :city :borough ] (fnil inc
-1))]
  (get-in mm [:planet :country :state :city :borough ]))

However, when I run into this pattern I usually

(let [v ((fnil inc -1) (get-in m [:planet :country :state :city :borough
]))]
  (assoc-in m [:planet :country :state :city :borough ] v))

The update in does a get, and I do a get-in, so I'm guessing the
performance is pretty similar, though I haven't tested it.

Cheers, Jay

On Thu, Apr 26, 2012 at 12:00 PM, blais goo...@furius.ca wrote:

 Hi,
 I have this use-case for (update-in) which keeps showing up in my code
 which I don't have a solution for and I'm wondering if there isn't a
 solution.
 How do I _efficiently_ obtain the new value created by an invocation of
 (update-in), that is, without having to get the modified value by lookups
 in the new map?

 Simplified example:

 (def m {:planet {:country {:state {:city {:borough 4})

 (let [mm (update-in m
 [:planet :country :state :city :borough]
 (fn [old] (if (nil? old) 0 (inc old]
   (get-in mm [:planet :country :state :city :borough]))

 (update-in) returns the new/modified map, but what I want is to obtain the
 new count returned by the anonymous function.
 Having to call (get-in) right after is inefficient.

 This is obviously a contrived example for this question, but I have a lot
 of real use cases for this (where at the top level of my app I have a ref
 for a deep structure which changes as a response to network events).

 Is there an idiomatic way to do this without having to resort to
 mutability?
 (The only solution that comes to my mind is to wrap up update-in and the
 modifier function with a special version that updates a local mutable and
 return both the new map and the new object.)
 Nasty?

 Thank you,



  --
 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 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

Re: (update-in) and getting the new value at the leaf efficiently

2012-04-26 Thread blais

Thanks Andy,
Two comments:

1. Your version does not use a transient/mutable, which is great, but it 
does create one vector for each level. I thought that since this would be 
wrapped and hidden from external view, a mutable would have been more 
appropriate.  More generally, I still don't know yet where to position 
myself when I code in Clojure, in terms of performance: I'm used to coding 
in C where I care a lot about every little detail, like cache coherency, or 
in Python for glue code where I really don't worry about such minute 
optimizations. Perhaps I tend to eagerly overoptimize in Clojure? Don't 
know.  I like your version in any case, thank you.

2. More importantly: I don't understand why I'm often having to add some 
functionality which I think of as something that everyone would need 
everywhere, and that makes me think I'm thinking about it the wrong way. 
For example, when I'm being careful about not using any mutable objects 
anywehre I end up with code that essentially recreates a new path to the 
root application every time I need to modify/store something in memory 
(i.e., I get a new version of the world on every update). So I wonder... 
isn't anybody else in dire need for something like update-in+?  How come 
not?  Isn't it a really common case that you need to modify some object 
far from the root object of your application, and if so, that you may need 
to do multiple things with that new object, beyond storing it by 
recreating all the intervening objects?  (e.g. (dosync (alter update-in 
...))) )

(Generally I find I get too little cultural osmosis when it comes to 
practical application of Clojure, so questions like this one come up all 
the time while I'm coding. Meetups and books touch on topics I understand 
well but rarely do people talk about the kinds of issues I'm encountering, 
like the one above. Libraries and other people's code often doesn't help 
all that much because it's fairly easy to do away with mutability in a 
library context.  I'll just read more OPC for now I guess.)


-- 
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

Re: (update-in) and getting the new value at the leaf efficiently

2012-04-26 Thread David Nolen

On Thu, Apr 26, 2012 at 4:30 PM, blais goo...@furius.ca wrote:

 (Generally I find I get too little cultural osmosis when it comes to
 practical application of Clojure, so questions like this one come up all
 the time while I'm coding. Meetups and books touch on topics I understand
 well but rarely do people talk about the kinds of issues I'm encountering,
 like the one above. Libraries and other people's code often doesn't help
 all that much because it's fairly easy to do away with mutability in a
 library context.  I'll just read more OPC for now I guess.)


Do you need to represent your data with that much nesting?

(def m {:planet ...
   :country ...
   :state ...
   :city ...
   :borough 4})

What's wrong with this representation?

David

-- 
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

Re: (update-in) and getting the new value at the leaf efficiently

2012-04-26 Thread blais

On Thursday, April 26, 2012 4:36:52 PM UTC-4, David Nolen wrote:

 On Thu, Apr 26, 2012 at 4:30 PM, blais goo...@furius.ca wrote:

 (Generally I find I get too little cultural osmosis when it comes to 
 practical application of Clojure, so questions like this one come up all 
 the time while I'm coding. Meetups and books touch on topics I understand 
 well but rarely do people talk about the kinds of issues I'm encountering, 
 like the one above. Libraries and other people's code often doesn't help 
 all that much because it's fairly easy to do away with mutability in a 
 library context.  I'll just read more OPC for now I guess.)


 Do you need to represent your data with that much nesting?

 (def m {:planet ...
:country ...
:state ...
:city ...
:borough 4})

 What's wrong with this representation?

 
Well this was just to simplify my original question; the real application 
has a root instance that is a networked application class, which contains 
some list of clients, each of which has a mapping of orders (per exchange / 
market, this is a trading application) which themselves map to events 
related to those orders.  So it's more like application - client-handler 
- feed - market - order-id - event.  These aren't necessarily pure 
data classes--some of these may be records with implementations of 
protocols. 

I suppose I could elect to move refs for modifiable things towards the 
leaves, but that seems to me like going against the grain and may have 
implications for concurrency (there are few but some threads running in 
parallel in this application).  In this specific example of an application 
tree, where would you recommend the mutable objects be placed?

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

Re: (update-in) and getting the new value at the leaf efficiently

2012-04-26 Thread David Nolen

On Thu, Apr 26, 2012 at 4:52 PM, blais goo...@furius.ca wrote:

 I suppose I could elect to move refs for modifiable things towards the
 leaves, but that seems to me like going against the grain and may have
 implications for concurrency (there are few but some threads running in
 parallel in this application).  In this specific example of an application
 tree, where would you recommend the mutable objects be placed?


Why do you need refs at leaves?

David

-- 
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

Re: (update-in) and getting the new value at the leaf efficiently

2012-04-26 Thread blais

On Thursday, April 26, 2012 4:59:31 PM UTC-4, David Nolen wrote:

 On Thu, Apr 26, 2012 at 4:52 PM, blais goo...@furius.ca wrote:

 I suppose I could elect to move refs for modifiable things towards the 
 leaves, but that seems to me like going against the grain and may have 
 implications for concurrency (there are few but some threads running in 
 parallel in this application).  In this specific example of an application 
 tree, where would you recommend the mutable objects be placed?


 Why do you need refs at leaves?


I receive events from a network. My application calls for storing these 
events and doing different things based on the changing status of orders 
attached to these events. I need to store them somewhere, I need to track 
this state in my app. At one extreme, I could store the changing state near 
the leaves (i.e. a list of events by order-id by ...). At another extreme, 
I could recreate the entire path of immutable objects all the way to the 
root application on every update (using update-in, and with a single ref 
for the root application).  And then there's all the other options in 
between, I could have refs are every level if I chose to (but that seems 
very, very wrong, somehow).

Java would call for mutability at the leaves.  
Clojure makes it easy to build it one way or another, but the language is 
calling for refs at the root. 

Isn't this a really common case of every type of application out there 
which has to store some changing state somewhere?

-- 
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

Re: (update-in) and getting the new value at the leaf efficiently

2012-04-26 Thread David Nolen

On Thu, Apr 26, 2012 at 5:08 PM, blais goo...@furius.ca wrote:

 I receive events from a network. My application calls for storing these
 events and doing different things based on the changing status of orders
 attached to these events. I need to store them somewhere, I need to track
 this state in my app. At one extreme, I could store the changing state near
 the leaves (i.e. a list of events by order-id by ...). At another extreme,
 I could recreate the entire path of immutable objects all the way to the
 root application on every update (using update-in, and with a single ref
 for the root application).  And then there's all the other options in
 between, I could have refs are every level if I chose to (but that seems
 very, very wrong, somehow).

 Java would call for mutability at the leaves.
 Clojure makes it easy to build it one way or another, but the language is
 calling for refs at the root.

 Isn't this a really common case of every type of application out there
 which has to store some changing state somewhere?


You've already stated that your multithreaded needs are modest. Why not one
atom wrapping all your data, each piece indexed by the most relevant key,
and each actual piece of data is flat.

David

-- 
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

Re: (update-in) and getting the new value at the leaf efficiently

2012-04-26 Thread kurtharriger

I think you are too concerned with micro optimizations.  get-in is probably 
just as efficient as attempting to bubble the state change back up and 
certainly simpler to work with.  In practice, optimizations like this do not 
have a significant impact on the overall performace.  
Measure before you optimize.  I might also add, parrelize before you optimize. 
Immutable data structures often makes it much easier to parrelize the 
algorithm, so even if you do have slow spots if the applications critical path 
is not affected you still may not need to optimize. 

There probably are several methods in clojure that can be significantly 
optimized and eventually someone will, but the best optimizations will come 
from real world performance problems not theoretical ones.  Do some research on 
clojures vector implementation and you'll see the fastest implementation in 
theory is comparitively slow in practice due to the way the caching works. 

-- 
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

Re: Update an item from a list of maps in STM transaction

2012-04-02 Thread Stephen Compall

On Sat, 2012-03-31 at 11:00 -0700, Marcelo Macedo de Melo Silva wrote:
 I'm running multiple threads using this same list and need to update
 the value of an item inside a STM transaction.

If you mean by value of an item the value in the database: I suggest
you create an updater agent instead, shared by all the threads.  While
each thread is in a transaction, it can `send' an action to update the
database to this agent.  Agent sends are queued by the STM, so you can
be sure only one update happens, and only if a transaction succeeds.

If you mean to mutate the list of maps, you can't do that.

 I tried using one FUTURE for a REF but is not working.

Not sure what this means.  Futures are IDerefs...

-- 
Stephen Compall
^aCollection allSatisfy: [:each|aCondition]: less is better

-- 
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

Re: Update swank classpath on the fly?

2011-11-04 Thread Jack Moffitt

 I've noticed that swank (which I run in emacs using M-x clojure-jack-
 in) doesn't pickup changes to the classpath on-the-fly. For example,
 if I update my leiningen project.clj with a new dependency and run
 lein deps, I need to restart swank to have it use the library. Is
 there a way to load something into a running swank without restarting
 it (which causes loss of state in the slime-repl).

I have the same project, which I suspect is a limitation of the JVM.
I'd settle for a fast way to restart the session.

jack.

-- 
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

Re: Update swank classpath on the fly?

2011-11-04 Thread Chas Emerick


On Nov 4, 2011, at 11:53 AM, AndyK wrote:

 I've noticed that swank (which I run in emacs using M-x clojure-jack-
 in) doesn't pickup changes to the classpath on-the-fly. For example,
 if I update my leiningen project.clj with a new dependency and run
 lein deps, I need to restart swank to have it use the library. Is
 there a way to load something into a running swank without restarting
 it (which causes loss of state in the slime-repl).
 
 thx

This is part of what pomegranate provides:

https://github.com/cemerick/pomegranate

It won't pick up changes from your project.clj, but it does provide an 
`add-dependencies` function that works with leiningen-style dependency notation 
(and an improved `add-classpath` if you just have jars available on disk you 
want to dynamically add to your classpath).

However, I have at least one report that pomegranate fails under swank:

https://github.com/cemerick/pomegranate/issues/1

It'd be great to get confirmation or not of that issue (or, even better, a 
patch to make it work under swank!).  FWIW, it works fine in a command-line 
REPL and with nREPL (jark, counterclockwise).  I've yet to test it with 
swank/slime myself.

Cheers,

- Chas

-- 
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

Re: update to clojure.tools.cli

2011-11-01 Thread Aaron Bedra

It's strange that it hasn't made it to central yet. This is normally a few
hours on the high end and it's been over 12 now.  I double checked that the
release hit sonatype

https://oss.sonatype.org/content/repositories/public/org/clojure/tools.cli/0.2.0/

We might need to summon the all mighty Stuart Sierra to see if he knows
what could have happened.

Cheers,

Aaron Bedra
--
Clojure/core
http://clojure.com

On Tue, Nov 1, 2011 at 1:59 PM, gaz jones gareth.e.jo...@gmail.com wrote:

 Hi,

 I have made some changes to tools.cli to fix an annoying bug arround
 boolean flags and the inability to collect 'trailing arguments'.
 Whilst gathering opinions on these changes, a few other suggestions
 were made such as removing all magic functions and System/exit calls.
 The update is therefore going to break the existing API which you
 obviously need to be aware of if you are currently using 0.1.0 and
 intend to upgrade to 0.2.0.

 The release has been cut, but the last time I checked it still hadn't
 hit maven central, so this is slightly advanced notice. To see details
 of the new api please see: https://github.com/clojure/tools.cli.

 There are a few things worth mentioning... support for grouped options
 has been removed, and the result of the call to cli is now a vector of
 [options, trailing arguments, usage banner] (originally it was just a
 hash of options). Automatic help is also no longer provided, an
 example of how to roll your own is at the bottom of the aforementioned
 page.

 a brief example of the differences (see the site for full details though):

 0.1.0:

 (cli [-p 8080 -v --foo bar some-filename]
 (optional [-p --port The port] #(Integer. %))
 (optional [-f --foo Some foos])
 (optional [-v --[no-]verbose Be chatty])

 = {:port 8080, :foo bar, :verbose true}

 0.2.0:

 (cli [-p 8080 --foo bar -v some-filename]
 [-p --port The port :parse-fn  #(Integer. %)]
 [-f --foo Some foos]
 [-v --[no-]verbose Be chatty :default false])

 = [{:port 8080, :foo bar, :verbose true}, [some-filename], *the
 usage banner*]

 Apologies for anyone upset by the timing / notification of the changes
 -- I will give greater advanced notice in future if there are any more
 breaking changes (hopefully there wont be :D)

 --
 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 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

Re: update to clojure.tools.cli

2011-11-01 Thread Sean Corfield

It's on Maven Central now...

On Tue, Nov 1, 2011 at 11:59 AM, Aaron Bedra aaron.be...@gmail.com wrote:
 It's strange that it hasn't made it to central yet.
...
 On Tue, Nov 1, 2011 at 1:59 PM, gaz jones gareth.e.jo...@gmail.com wrote:
 The release has been cut, but the last time I checked it still hadn't
 hit maven central, so this is slightly advanced notice. To see details
 of the new api please see: https://github.com/clojure/tools.cli.

-- 
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

Re: update to clojure.tools.cli

2011-11-01 Thread Sean Corfield

On Tue, Nov 1, 2011 at 10:59 AM, gaz jones gareth.e.jo...@gmail.com wrote:
 The update is therefore going to break the existing API which you
 obviously need to be aware of if you are currently using 0.1.0 and
 intend to upgrade to 0.2.0.
...
 Apologies for anyone upset by the timing / notification of the changes
 -- I will give greater advanced notice in future if there are any more
 breaking changes (hopefully there wont be :D)

FWIW, I really like the changes and will be upgrading a number of
utilities to 0.2.0 shortly at World Singles (even tho' every one of
them needs changes!).
-- 
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

Re: update xml attribute value

2011-06-02 Thread Allen Johnson

 Does anyone know how to update xml element attribute value on the zipper
 data structure?
 I have something like
 root
     element1 name=x1 description=d1/
     element2 name=x2 description=d2/
 /root
 (:require (clojure [xml :as xml] [zip :as zip])
      [clojure.contrib.zip-filter.xml :as zf])
 (let
   [src (- c:/my.xml io/file xml/parse zip/xml-zip)
    edf (zf/xml1- src :root :element1)
    n    (- (zf/attr :description) (zip/replace ))])
 and this is giving me java.lang.ClassCastException: java.lang.Character
 cannot be cast to clojure.lang.Associative (test-xml-zip.clj:0)

Given that 'loc is the proper location in your zipper:

(zip/edit loc assoc-in [:attrs :description] new value)

Allen

-- 
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

Re: update xml attribute value

2011-06-02 Thread siyu798

Thanks Allen, it works, I did not know the loc can be treated like a hash.

siyu

-- 
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

Re: update xml attribute value

2011-06-02 Thread Allen Johnson

 Thanks Allen, it works, I did not know the loc can be treated like a hash.

'loc itself isn't a map even though zip/edit makes it seem that way.
Behind the scenes zip/edit calls (zip/node loc) which will return a
map, at least in the case of this xml example. zip/edit then applies
the function you provided (assoc-in) to this map plus any supplied
args. The result of this replaces the node at loc.

https://github.com/clojure/clojure/blob/59b65669860a1f33825775494809e5d500c19c63/src/clj/clojure/zip.clj#L210

Allen

-- 
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

Re: update-in oddness

2010-06-04 Thread Joost

On Jun 4, 7:37 am, Heinz N. Gies he...@licenser.net wrote:
 Update-in behaves oddly when getting an empty path. (update-in [] {1 2} 
 (constantly {2 3})) returns {nil {2 3} 1 2} not {2 3} as I'd expect. get-in 
 works well with empty pathes so I think this isn't a good behavior.

I don't know why you expect that to do anything - first of all, the
second argument to update-in should be a seq of keys. In any case, it
throws

nth not supported on this type: PersistentArrayMap
  [Thrown class java.lang.UnsupportedOperationException]

-- 
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

Re: update-in oddness


On Jun 4, 2010, at 11:15 , Joost wrote:

 On Jun 4, 7:37 am, Heinz N. Gies he...@licenser.net wrote:
 Update-in behaves oddly when getting an empty path. (update-in [] {1 2} 
 (constantly {2 3})) returns {nil {2 3} 1 2} not {2 3} as I'd expect. get-in 
 works well with empty pathes so I think this isn't a good behavior.
 
 I don't know why you expect that to do anything - first of all, the
 second argument to update-in should be a seq of keys. In any case, it
 throws
 
 nth not supported on this type: PersistentArrayMap
  [Thrown class java.lang.UnsupportedOperationException]

Sorry I mixed arguments, it should be (update-in {1 2} [] (constantly {2 3})) 

-- 
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

Re: update-in oddness

2010-06-04 Thread Joost

On Jun 4, 1:42 pm, Heinz N. Gies he...@licenser.net wrote:
 Sorry I mixed arguments, it should be (update-in {1 2} [] (constantly {2 3}))

Yes, that gives {nil {2 3}, 1 2}

You're not giving any key in the key list, so that is the reason
there's a nil key now, and {2 3} is just the value that you give it,
since that's what ((constantly {2 3}) nil) returns.

Seems correct as far as the documentation of update-in is concerned.

Joost.

-- 
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

Re: update-in oddness

2010-06-04 Thread Joost



On Jun 4, 2:03 pm, Joost jo...@zeekat.nl wrote:
 Seems correct as far as the documentation of update-in is concerned.

Addendum: though I think you've got a point in that inserting a nil
key is unexpected.
Personally, I don't really know what to expect from that expression.

Joost.

-- 
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

Re: update-in oddness


On Jun 4, 2010, at 14:03 , Joost wrote:

 On Jun 4, 1:42 pm, Heinz N. Gies he...@licenser.net wrote:
 Sorry I mixed arguments, it should be (update-in {1 2} [] (constantly {2 3}))
 
 Yes, that gives {nil {2 3}, 1 2}
 
 You're not giving any key in the key list, so that is the reason
 there's a nil key now, and {2 3} is just the value that you give it,
 since that's what ((constantly {2 3}) nil) returns.
 
 Seems correct as far as the documentation of update-in is concerned.
 
I'd expect that a empty key works on the entire  map, just as get-in with en 
empty key returns the entire map, this is kind of very important if you work 
with automatically with keys since otherwise you always have to handle the 
special case []. This is very annoying :(

here an example:

(if-let [r (butlast @path)]
  (do
(alter m update-in r dissoc (last @path))
(alter m update-in r assoc {:name @sr} c))
  (do
(alter m dissoc (last @path))
(alter m assoc {:name @sr} c)))

-- 
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

Re: update-in oddness


On Jun 4, 2010, at 14:11 , Heinz N. Gies wrote:

 
 On Jun 4, 2010, at 14:03 , Joost wrote:
 
 On Jun 4, 1:42 pm, Heinz N. Gies he...@licenser.net wrote:
 Sorry I mixed arguments, it should be (update-in {1 2} [] (constantly {2 
 3}))
 
 Yes, that gives {nil {2 3}, 1 2}
 
 You're not giving any key in the key list, so that is the reason
 there's a nil key now, and {2 3} is just the value that you give it,
 since that's what ((constantly {2 3}) nil) returns.
 
 Seems correct as far as the documentation of update-in is concerned.


So for how I'd expect it to work:

(defn update-in*
  ([m [k  ks] f  args]
   (if ks
 (assoc m k (apply update-in* (get m k) ks f args))
 (if k
   (assoc m k (apply f (get m k) args))
   (apply f  m args)

user (get-in {1 2} [])
{1 2}
user (update-in* {1 2} [] assoc  1 3)
{1 3}

In opposite of how it works:

user (update-in {1 2} [] assoc  1 3)
{nil {1 3}, 1 2}



-- 
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

Re: update-in oddness

2010-06-04 Thread Chouser

On Fri, Jun 4, 2010 at 10:04 AM, Heinz N. Gies he...@licenser.net wrote:

 On Jun 4, 2010, at 14:11 , Heinz N. Gies wrote:


 On Jun 4, 2010, at 14:03 , Joost wrote:

 On Jun 4, 1:42 pm, Heinz N. Gies he...@licenser.net wrote:
 Sorry I mixed arguments, it should be (update-in {1 2} [] (constantly {2 
 3}))

 Yes, that gives {nil {2 3}, 1 2}

 You're not giving any key in the key list, so that is the reason
 there's a nil key now, and {2 3} is just the value that you give it,
 since that's what ((constantly {2 3}) nil) returns.

 Seems correct as far as the documentation of update-in is concerned.


 So for how I'd expect it to work:

 (defn update-in*
  ([m [k  ks] f  args]
   (if ks
     (assoc m k (apply update-in* (get m k) ks f args))
     (if k
       (assoc m k (apply f (get m k) args))
       (apply f  m args)

 user (get-in {1 2} [])
 {1 2}
 user (update-in* {1 2} [] assoc  1 3)
 {1 3}

I agree with the spirit of your argument, but not your
implementation:

  (update-in* {nil 2} [nil] (constantly 3))
  ;= 3

Perhaps:

  (defn update-in*
[m ks f  args]
(if-let [[k  mk] ks]
(if mk
(assoc m k (apply update-in* (get m k) mk f args))
(assoc m k (apply f (get m k) args)))
  (apply f m args)))

  (update-in* {nil 2} [nil] (constantly 3))
  ;= {nil 3}

--Chouser
http://joyofclojure.com/

-- 
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

Re: update-in oddness

On Jun 4, 2010, at 16:23 , Chouser wrote:

 
 I agree with the spirit of your argument, but not your
 implementation:
 
  (update-in* {nil 2} [nil] (constantly 3))
  ;= 3
As so often Chouser, you are of cause totally right :). I just realized the 
flaw when I was about to open a ticket but you were faster ;) well this are 
good news so since I don't have a CA signed yet (actually I do just not send it 
:P) so one could use your code as a fix.


Regards,
Heinz

-- 
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

Re: update-in and get-in why no default?

2010-02-02 Thread Timothy Pratley

On 2 February 2010 17:55, Richard Newman holyg...@gmail.com wrote:
 If you view 'get-in' as an unwrapping operation, unwrapping by zero steps
 should return the existing collection, no?

Thanks for that description I completely agree.


 Can you explain why you think the result should be nil?

I was not thinking very clearly :) Loosely 'oh there is nothing to
look up'. Thanks for setting me straight.


 As above: I equate nil with the empty sequence.

Yup.


Ok patch updated - salient part is:
+  ([m ks not-found]
+   (if (seq ks)
+ (if-let [l (reduce get m (butlast ks))]
+   (get l (last ks) not-found)
+   not-found)
+ m)))

Which preserves all the desired behavior so far :)

http://www.assembla.com/spaces/clojure/tickets/256-get-in-optional-default-value


Regards,
Tim.

-- 
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

Re: update-in and get-in why no default?

2010-02-02 Thread Meikel Brandmeyer

Hi,

On Feb 2, 1:48 pm, Timothy Pratley timothyprat...@gmail.com wrote:

  If you view 'get-in' as an unwrapping operation, unwrapping by zero steps
  should return the existing collection, no?

 Thanks for that description I completely agree.

Hmm.. I thought of get-in as a recursive application of get. get-in
now diverges from get. Maybe this version should be called unwrap
instead?

Sincerely
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

Re: update-in and get-in why no default?

2010-02-02 Thread Meikel Brandmeyer

Hi,

On Feb 2, 2:31 pm, Timothy Pratley timothyprat...@gmail.com wrote:

  Hmm.. I thought of get-in as a recursive application of get. get-in
  now diverges from get. Maybe this version should be called unwrap
  instead?

 Zero applications of get to a map might be thought of as the map itself.
 Are you thinking of a particular scenario where throwing an exception
 would be better?

Ok. One could see this like that:

(get-in m [:a :b]) = (get (get m :a) :b)
(get-in m [:a])= (get m :a)
(get-in m [])  = m

In so far I understand the picture of what happens. But does it make
sense?

get-in does a lookup of a key sequence in a nested structure of
associative things. I think nil/[] are simply not in the domain of get-
in. However it can be extended to nil/[] as the identity.

So in the end it will probably boil down to some suitable definition
argument of the domain of get-in. And I see some applications, where
just returning the original thing might be handy.

I'm persuaded. :)

Sincerely
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

Re: update-in and get-in why no default?

2010-02-01 Thread Timothy Pratley

 Am 31.01.2010 um 18:29 schrieb Daniel Werner:
 If I understand this arity version of get-in correctly, won't the
 default also be used if the value stored in the nested data structure
 evaluates to something false-y?

Thanks for spotting that early!


On 1 February 2010 05:46, Meikel Brandmeyer m...@kotka.de wrote:
 (if-let [l (reduce get m (pop ks))]
  (get l (peek ks) not-found)
  not-found))

Good idea, but peek and pop work differently on vectors and sequences,
seeing get-in is not constrained to use vectors this could lead to an
unexpected behavior:
user= (def m  {:a 1, :b 2, :c {:d 3, :e 4}, :f nil})
#'user/m
user= (get-in3 m '(:c :e) 2)   ;peek-pop keys applied in unexpected order
2
user= (get-in2 m '(:c :e) 2)   ;expected result
4

I've replaced the patch on assembla with this:
   (reduce #(get %1 %2 not-found) m ks)))
And added test cases for the falsey returns and seq args



Regards,
Tim.

-- 
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

Re: update-in and get-in why no default?

2010-02-01 Thread Meikel Brandmeyer

Hi,

On Feb 1, 1:57 pm, Timothy Pratley timothyprat...@gmail.com wrote:

 Good idea, but peek and pop work differently on vectors and sequences,
 seeing get-in is not constrained to use vectors this could lead to an
 unexpected behavior:
 user= (def m  {:a 1, :b 2, :c {:d 3, :e 4}, :f nil})
 #'user/m
 user= (get-in3 m '(:c :e) 2)   ;peek-pop keys applied in unexpected order
 2
 user= (get-in2 m '(:c :e) 2)   ;expected result
 4

o.O Ok... 100% of my use-cases for get-in were with vectors up to now.
Didn't think about the allowing lists also.

 I've replaced the patch on assembla with this:
    (reduce #(get %1 %2 not-found) m ks)))
 And added test cases for the falsey returns and seq args

Consider this (admittedly constructed) case:

(get-in {:a {:b 1}} [:x :c] {:c :uhoh})

I would not mind only allowing vectors in the interface. I would
expect the length of such a chain sufficiently short for easy
conversion if necessary. Or to use butlast/last instead of peek/pop.
Again the damage would be limited by the short keychain length.
(Of course it would have to be considered: is the usual keychain
really short?)

Sincerely
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

Re: update-in and get-in why no default?

2010-02-01 Thread Timothy Pratley

On 2 February 2010 00:18, Meikel Brandmeyer m...@kotka.de wrote:
 Consider this (admittedly constructed) case:
 (get-in {:a {:b 1}} [:x :c] {:c :uhoh})

Excellent point!


 Or to use butlast/last instead of peek/pop.

I think this is the best approach. butlast/last have linear time so
the overhead is small.

There are still some sharp edges I'm not sure about:
(A) user= (get-in {:a 1} [])
{:a 1}
;; this is existing behavior, but I feel the result should be nil

(B) user= (get-in {:a 1} nil)
{:a 1}
;; this is existing behavior, but I feel the result should be nil (nil
is a seq so not an exception)

(C) user= (get-in {:a 1} 5)
java.lang.IllegalArgumentException: Don't know how to create ISeq
from: java.lang.Integer (NO_SOURCE_FILE:0)
;; existing behavior, seems sensible to throw an exception here rather
than return nil

(D) user= (get-in {nil {:a 1}} [] 2)
{:a 1}
;; new behavior
;; using last/butlast only - this is wrong... need to check the seq size
;; the solution depends upon what is correct for the preceding cases
so need to establish those first

Alternatively one could take the view that [] and nil are illegal key
sequences, in which case should get-in enforce that (via preconditions
or just a check) or should it just be added to the doc-string that
using those values is undefined, or both?

I've marked the ticket back to new in the meantime... will update once resolved.


For reference here is a version that behaves most like existing get-in:

(defn get-in
  Returns the value in a nested associative structure,
  where ks is a sequence of keys. Returns nil if the key is not present,
  or the not-found value if supplied.
  ([m ks]
   (reduce get m ks))
  ([m ks not-found]
   (if (empty? ks)
 m
 (if-let [l (reduce get m (butlast ks))]
   (get l (last ks) not-found)
   not-found

I'm not convinced returning the map when given an empty key sequence
is the right thing to do, I'd prefer it to return nil or throw an
exception in both arity cases.


Regards,
Tim.

-- 
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

Re: update-in and get-in why no default?

2010-02-01 Thread Meikel Brandmeyer

Hi Timothy,

On Feb 2, 1:19 am, Timothy Pratley timothyprat...@gmail.com wrote:

 There are still some sharp edges I'm not sure about:
 (A) user= (get-in {:a 1} [])
 {:a 1}
 ;; this is existing behavior, but I feel the result should be nil

+1 for nil

 (B) user= (get-in {:a 1} nil)
 {:a 1}
 ;; this is existing behavior, but I feel the result should be nil (nil
 is a seq so not an exception)

+1 for nil

 (C) user= (get-in {:a 1} 5)
 java.lang.IllegalArgumentException: Don't know how to create ISeq
 from: java.lang.Integer (NO_SOURCE_FILE:0)
 ;; existing behavior, seems sensible to throw an exception here rather
 than return nil

+1 for exception

 (D) user= (get-in {nil {:a 1}} [] 2)
 {:a 1}
 ;; new behavior
 ;; using last/butlast only - this is wrong... need to check the seq size
 ;; the solution depends upon what is correct for the preceding cases
 so need to establish those first

 Alternatively one could take the view that [] and nil are illegal key
 sequences, in which case should get-in enforce that (via preconditions
 or just a check) or should it just be added to the doc-string that
 using those values is undefined, or both?

I'm not sure about this too. I tend to an exception. (get m) will also
throw an exception...

 For reference here is a version that behaves most like existing get-in:

 (defn get-in
   Returns the value in a nested associative structure,
   where ks is a sequence of keys. Returns nil if the key is not present,
   or the not-found value if supplied.
   ([m ks]
    (reduce get m ks))
   ([m ks not-found]
    (if (empty? ks)
      m
      (if-let [l (reduce get m (butlast ks))]
        (get l (last ks) not-found)
        not-found

I would get rid of the if-let. Together with throwing an exception in
case of an empty key sequence we get:

(defn get-in
  Returns the value in a nested associative structure,
  where ks is a sequence of keys. Returns nil if the key is not
present,
  or the not-found value if supplied.
  ([m ks] (get-in m ks nil))
  ([m ks not-found]
   (if-let [ks (seq ks)]
 (get (reduce get m (butlast ks)) (last ks) not-found)
 (throw (Exception. key sequence must not be empty)

Sincerely
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

Re: update-in and get-in why no default?

2010-02-01 Thread Richard Newman


There are still some sharp edges I'm not sure about:
(A) user= (get-in {:a 1} [])
{:a 1}
;; this is existing behavior, but I feel the result should be nil


+1 for nil


I think I disagree.

If you view 'get-in' as an unwrapping operation, unwrapping by zero  
steps should return the existing collection, no?


{:foo {:bar {:baz 1}}}

[] = {:foo ...
[:foo] = {:bar ...
[:foo :bar]= {:baz ...

This maps trivially to a sophisticated user's recursive mental model  
of get-in:


(defn get-in [m ks]
  (loop [looking-at m
 first-key  (first ks)
 remaining-keys (rest ks)]
(if-not first-key
  looking-at
  (recur (get looking-at first-key)
 (first remaining-keys)
 (rest  remaining-keys)

... if there are no keys, it returns m. That's intuitive to me, at  
least.


Can you explain why you think the result should be nil?


(B) user= (get-in {:a 1} nil)
{:a 1}
;; this is existing behavior, but I feel the result should be nil  
(nil

is a seq so not an exception)


+1 for nil


As above: I equate nil with the empty sequence.

--
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

Re: update-in and get-in why no default?

2010-02-01 Thread Meikel Brandmeyer

Hi,

On Feb 2, 7:55 am, Richard Newman holyg...@gmail.com wrote:

 I think I disagree. Can you explain why you think the result should be nil?

Woops. I got confused. I didn't mean nil for empty key sequences. I
meant throwing an exception as does get.

Sincerely
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

Re: update-in and get-in why no default?

2010-01-31 Thread Daniel Werner

  ([m ks not-found]
   (if-let [v (reduce get m ks)]
 v
 not-found)))

If I understand this arity version of get-in correctly, won't the
default also be used if the value stored in the nested data structure
evaluates to something false-y?

Anyway, thanks for creating the patches!

-- 
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

Re: update-in and get-in why no default?

2010-01-31 Thread Meikel Brandmeyer

Hi,

Am 31.01.2010 um 18:29 schrieb Daniel Werner:

 ([m ks not-found]
  (if-let [v (reduce get m ks)]
v
not-found)))
 
 If I understand this arity version of get-in correctly, won't the
 default also be used if the value stored in the nested data structure
 evaluates to something false-y?

Yes. It should probably read:

(if-let [l (reduce get m (pop ks))]
  (get l (peek ks) not-found)
  not-found))

Sincerely
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

Re: update-in and get-in why no default?

2010-01-29 Thread Rich Hickey



On Dec 30 2009, 6:18 am, Timothy Pratley timothyprat...@gmail.com
wrote:
 On Dec 13, 1:24 am, Rich Hickey richhic...@gmail.com wrote:

  fnil seems to me to have greater utility than patching all functions
  that apply functions with default-supplying arguments.

 Neat :) I like it.

  The get-in function could be enhanced, and would mirror get.

 Should I interpret 'could' as 'patch welcome' or 'let me think about
 it'?


Patches welcome for get-in, and my fnil.

Thanks,


Rich

-- 
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

Re: update-in and get-in why no default?

2010-01-29 Thread Sean Devlin

Rich,
Your example didn't support a variadic signature.  Is that the long
term plan?

Sean

On Jan 29, 8:48 am, Rich Hickey richhic...@gmail.com wrote:
 On Dec 30 2009, 6:18 am, Timothy Pratley timothyprat...@gmail.com
 wrote:

  On Dec 13, 1:24 am, Rich Hickey richhic...@gmail.com wrote:

   fnil seems to me to have greater utility than patching all functions
   that apply functions with default-supplying arguments.

  Neat :) I like it.

   The get-in function could be enhanced, and would mirror get.

  Should I interpret 'could' as 'patch welcome' or 'let me think about
  it'?

 Patches welcome for get-in, and my fnil.

 Thanks,

 Rich

-- 
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

Re: update-in and get-in why no default?

2010-01-29 Thread Rich Hickey



On Jan 29, 9:04 am, Sean Devlin francoisdev...@gmail.com wrote:
 Rich,
 Your example didn't support a variadic signature.  Is that the long
 term plan?


It's the short term plan. Let's see if there's any real need for more
than three. I've never needed more than one.

Rich

-- 
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

Re: update-in and get-in why no default?

2010-01-29 Thread Timothy Pratley

2010/1/30 Rich Hickey richhic...@gmail.com:
 Patches welcome for get-in, and my fnil.

Groovy! uploaded to:
https://www.assembla.com/spaces/clojure/tickets/256-get-in-optional-default-value
https://www.assembla.com/spaces/clojure/tickets/257-add-fnil-for-wrapping-functions-to-handle-nil


Regards,
Tim.

-- 
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

Re: update-in! (?)

2010-01-21 Thread Gabi

I don't think zipper would help in this case

On Jan 21, 12:40 am, brianh brian.h.w...@gmail.com wrote:
 Any chance you could rethink your approach  use a zipper?

 On Jan 20, 9:32 am, Gabi bugspy...@gmail.com wrote:

  I posted a question on SO about it. Interesting 
  discussion:http://stackoverflow.com/questions/2102606/algorithm-to-implement-non...

  On Jan 20, 5:39 pm, Christophe Grand christo...@cgrand.net wrote:

   I concur: a map (or a sorted map if you need to emulate access to a
   subtree) can be an option.

   [[1 2] [3 4]] is represented by {[0 0] 1, [0 1] 2, [1 0] 3, [1 1] 4}

   On Wed, Jan 20, 2010 at 4:24 PM, Sean Devlin francoisdev...@gmail.com 
   wrote:
How about a sorted set w/ a custom comparator?  Of course, this rules
out transients, but maybe the flatness will make up for it?

On Jan 20, 10:15 am, Gabi bugspy...@gmail.com wrote:
I need to add/delete much more frequently than just updating
actually.

On Jan 20, 4:59 pm, Sean Devlin francoisdev...@gmail.com wrote:

 Gabi,
 A similar technique is used with sparse matrices.  You usually have
 severals arrays, one for the non-zero elements, and another one for
 indexing the column and a third for indexing the rows.

http://pasadena.wr.usgs.gov/office/baagaard/research/papers/thesis/fi...

 This should be fast as long as you're only updating.  If you're
 inserting/deleting, you might be able to get away with using a
 collection of 1D trees.

 Sean

 On Jan 20, 9:18 am, Gabi bugspy...@gmail.com wrote:

  These vectors represent trees which need to updated very 
  frequently.
  So If there was an efficient way to use transients to represent
  transient trees the whole process would be much more efficient (so
  each update to a tree would be done in place instead of creating 
  new
  one.) As discussed above, naive usage of transients won't help.
  Another approach would be implement in Java, but I wish there would
  some way to achieve this directly from Clojure.
  Now that I think about it, maybe the solution is to represent the 
  tree
  as one dimensional vector instead of nested one (any good clojure
  algorithm for this ? Representing and traversing non binary trees 
  as
  one dimensional vector?)

  Jan 20, 12:53 pm, Christophe Grand christo...@cgrand.net wrote:

   Hi Gabi!

   Can you tell us more about your problem, what do those deeply 
   nested
   vectors represent and how are you going to update them? (are all
   updates batched in one part of your program?)

   With transients current implementation you can't write an 
   efficient update-in!

   Christophe

   On Wed, Jan 20, 2010 at 9:15 AM, Gabi bugspy...@gmail.com 
   wrote:
Guys, I really need your expertise here.
I have lots of deeply nested vectors, which i need to 
manipulate
frequently (thousands of times)
What is the most effective way to do this ?

On Jan 17, 4:27 pm, Gabi bugspy...@gmail.com wrote:
Right. I thought that transient performing deep 
'transientivity'.
Here is a fixed version. It takes a regular coll converts 
whatever it
can to transient and update the stuff.
The problem is that doing persistent!(assoc!(transient m)) on 
each
level probably misses the whole point of performance.
So while it work, it probably slower than the regular 
update-in.
I need a better solution.

(defn update-in!!
  modified version of core/update-in that works on, and 
return
transiants
  ([m [k  ks] f  args]
   (if ks
     (persistent!(assoc! (transient m) k (apply update-in!! 
(get m k)
ks f args)))
     (persistent!(assoc! (transient m) k (apply f (get m k) 
args))

On Jan 17, 3:57 pm, Chouser chou...@gmail.com wrote:

 On Sun, Jan 17, 2010 at 8:25 AM, Gabi bugspy...@gmail.com 
 wrote:

  user= (persistent!(update-in!(transient v) [0] reverse))

  Forgot to mention that v in the example is defined to  
  [[1 2] [3 4]]

 So you've got a transient vector of persistent vectors of
 numbers.  The problem is your update-in! then calls assoc! 
 on
 each level, but of course assoc! on the inner persistent 
 vector
 fails.

 You either need to make the inner vectors transient (and 
 then
 call persist! on them when you're done) or use assoc! only 
 at the
 outer level.

 --Chouserhttp://joyofclojure.com/

--
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

Re: update-in! (?)

Guys, I really need your expertise here.
I have lots of deeply nested vectors, which i need to manipulate
frequently (thousands of times)
What is the most effective way to do this ?

On Jan 17, 4:27 pm, Gabi bugspy...@gmail.com wrote:
 Right. I thought that transient performing deep 'transientivity'.
 Here is a fixed version. It takes a regular coll converts whatever it
 can to transient and update the stuff.
 The problem is that doing persistent!(assoc!(transient m)) on each
 level probably misses the whole point of performance.
 So while it work, it probably slower than the regular update-in.
 I need a better solution.

 (defn update-in!!
   modified version of core/update-in that works on, and return
 transiants
   ([m [k  ks] f  args]
    (if ks
      (persistent!(assoc! (transient m) k (apply update-in!! (get m k)
 ks f args)))
      (persistent!(assoc! (transient m) k (apply f (get m k) args))

 On Jan 17, 3:57 pm, Chouser chou...@gmail.com wrote:

  On Sun, Jan 17, 2010 at 8:25 AM, Gabi bugspy...@gmail.com wrote:

   user= (persistent!(update-in!(transient v) [0] reverse))

   Forgot to mention that v in the example is defined to  [[1 2] [3 4]]

  So you've got a transient vector of persistent vectors of
  numbers.  The problem is your update-in! then calls assoc! on
  each level, but of course assoc! on the inner persistent vector
  fails.

  You either need to make the inner vectors transient (and then
  call persist! on them when you're done) or use assoc! only at the
  outer level.

  --Chouserhttp://joyofclojure.com/
-- 
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

Re: update-in! (?)

2010-01-20 Thread Christophe Grand

Hi Gabi!

Can you tell us more about your problem, what do those deeply nested
vectors represent and how are you going to update them? (are all
updates batched in one part of your program?)

With transients current implementation you can't write an efficient update-in!

Christophe

On Wed, Jan 20, 2010 at 9:15 AM, Gabi bugspy...@gmail.com wrote:
 Guys, I really need your expertise here.
 I have lots of deeply nested vectors, which i need to manipulate
 frequently (thousands of times)
 What is the most effective way to do this ?

 On Jan 17, 4:27 pm, Gabi bugspy...@gmail.com wrote:
 Right. I thought that transient performing deep 'transientivity'.
 Here is a fixed version. It takes a regular coll converts whatever it
 can to transient and update the stuff.
 The problem is that doing persistent!(assoc!(transient m)) on each
 level probably misses the whole point of performance.
 So while it work, it probably slower than the regular update-in.
 I need a better solution.

 (defn update-in!!
   modified version of core/update-in that works on, and return
 transiants
   ([m [k  ks] f  args]
    (if ks
      (persistent!(assoc! (transient m) k (apply update-in!! (get m k)
 ks f args)))
      (persistent!(assoc! (transient m) k (apply f (get m k) args))

 On Jan 17, 3:57 pm, Chouser chou...@gmail.com wrote:

  On Sun, Jan 17, 2010 at 8:25 AM, Gabi bugspy...@gmail.com wrote:

   user= (persistent!(update-in!(transient v) [0] reverse))

   Forgot to mention that v in the example is defined to  [[1 2] [3 4]]

  So you've got a transient vector of persistent vectors of
  numbers.  The problem is your update-in! then calls assoc! on
  each level, but of course assoc! on the inner persistent vector
  fails.

  You either need to make the inner vectors transient (and then
  call persist! on them when you're done) or use assoc! only at the
  outer level.

  --Chouserhttp://joyofclojure.com/

 --
 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




-- 
Professional: http://cgrand.net/ (fr)
On Clojure: http://clj-me.cgrand.net/ (en)
-- 
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

Re: update-in! (?)

These vectors represent trees which need to updated very frequently.
So If there was an efficient way to use transients to represent
transient trees the whole process would be much more efficient (so
each update to a tree would be done in place instead of creating new
one.) As discussed above, naive usage of transients won't help.
Another approach would be implement in Java, but I wish there would
some way to achieve this directly from Clojure.
Now that I think about it, maybe the solution is to represent the tree
as one dimensional vector instead of nested one (any good clojure
algorithm for this ? Representing and traversing non binary trees as
one dimensional vector?)


Jan 20, 12:53 pm, Christophe Grand christo...@cgrand.net wrote:
 Hi Gabi!

 Can you tell us more about your problem, what do those deeply nested
 vectors represent and how are you going to update them? (are all
 updates batched in one part of your program?)

 With transients current implementation you can't write an efficient update-in!

 Christophe



 On Wed, Jan 20, 2010 at 9:15 AM, Gabi bugspy...@gmail.com wrote:
  Guys, I really need your expertise here.
  I have lots of deeply nested vectors, which i need to manipulate
  frequently (thousands of times)
  What is the most effective way to do this ?

  On Jan 17, 4:27 pm, Gabi bugspy...@gmail.com wrote:
  Right. I thought that transient performing deep 'transientivity'.
  Here is a fixed version. It takes a regular coll converts whatever it
  can to transient and update the stuff.
  The problem is that doing persistent!(assoc!(transient m)) on each
  level probably misses the whole point of performance.
  So while it work, it probably slower than the regular update-in.
  I need a better solution.

  (defn update-in!!
    modified version of core/update-in that works on, and return
  transiants
    ([m [k  ks] f  args]
     (if ks
       (persistent!(assoc! (transient m) k (apply update-in!! (get m k)
  ks f args)))
       (persistent!(assoc! (transient m) k (apply f (get m k) args))

  On Jan 17, 3:57 pm, Chouser chou...@gmail.com wrote:

   On Sun, Jan 17, 2010 at 8:25 AM, Gabi bugspy...@gmail.com wrote:

user= (persistent!(update-in!(transient v) [0] reverse))

Forgot to mention that v in the example is defined to  [[1 2] [3 4]]

   So you've got a transient vector of persistent vectors of
   numbers.  The problem is your update-in! then calls assoc! on
   each level, but of course assoc! on the inner persistent vector
   fails.

   You either need to make the inner vectors transient (and then
   call persist! on them when you're done) or use assoc! only at the
   outer level.

   --Chouserhttp://joyofclojure.com/

  --
  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

 --
 Professional:http://cgrand.net/(fr)
 On Clojure:http://clj-me.cgrand.net/(en)
-- 
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

Re: update-in! (?)

2010-01-20 Thread Sean Devlin

Gabi,
A similar technique is used with sparse matrices. You usually have
severals arrays, one for the non-zero elements, and another one for
indexing the column and a third for indexing the rows.

http://pasadena.wr.usgs.gov/office/baagaard/research/papers/thesis/figs/methods/sparseMatrix.gif

This should be fast as long as you're only updating. If you're
inserting/deleting, you might be able to get away with using a
collection of 1D trees.

Sean

On Jan 20, 9:18 am, Gabi bugspy...@gmail.com wrote:
These vectors represent trees which need to updated very frequently.
So If there was an efficient way to use transients to represent
transient trees the whole process would be much more efficient (so
each update to a tree would be done in place instead of creating new
one.) As discussed above, naive usage of transients won't help.
Another approach would be implement in Java, but I wish there would
some way to achieve this directly from Clojure.
Now that I think about it, maybe the solution is to represent the tree
as one dimensional vector instead of nested one (any good clojure
algorithm for this ? Representing and traversing non binary trees as
one dimensional vector?)

Jan 20, 12:53 pm, Christophe Grand christo...@cgrand.net wrote:

Hi Gabi!

Can you tell us more about your problem, what do those deeply nested
vectors represent and how are you going to update them? (are all
updates batched in one part of your program?)

With transients current implementation you can't write an efficient
update-in!

Christophe

On Wed, Jan 20, 2010 at 9:15 AM, Gabi bugspy...@gmail.com wrote:
Guys, I really need your expertise here.
I have lots of deeply nested vectors, which i need to manipulate
frequently (thousands of times)
What is the most effective way to do this ?

On Jan 17, 4:27 pm, Gabi bugspy...@gmail.com wrote:
Right. I thought that transient performing deep 'transientivity'.
Here is a fixed version. It takes a regular coll converts whatever it
can to transient and update the stuff.
The problem is that doing persistent!(assoc!(transient m)) on each
level probably misses the whole point of performance.
So while it work, it probably slower than the regular update-in.
I need a better solution.

(defn update-in!!
modified version of core/update-in that works on, and return
transiants
([m [k ks] f args]
(if ks
(persistent!(assoc! (transient m) k (apply update-in!! (get m k)
ks f args)))
(persistent!(assoc! (transient m) k (apply f (get m k) args))

On Jan 17, 3:57 pm, Chouser chou...@gmail.com wrote:

On Sun, Jan 17, 2010 at 8:25 AM, Gabi bugspy...@gmail.com wrote:

user= (persistent!(update-in!(transient v) [0] reverse))

Forgot to mention that v in the example is defined to [[1 2] [3 4]]

So you've got a transient vector of persistent vectors of
numbers. The problem is your update-in! then calls assoc! on
each level, but of course assoc! on the inner persistent vector
fails.

You either need to make the inner vectors transient (and then
call persist! on them when you're done) or use assoc! only at the
outer level.

--Chouserhttp://joyofclojure.com/

--
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

--
Professional:http://cgrand.net/(fr)
On Clojure:http://clj-me.cgrand.net/(en)
--
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

Re: update-in! (?)

I need to add/delete much more frequently than just updating
actually.


On Jan 20, 4:59 pm, Sean Devlin francoisdev...@gmail.com wrote:
 Gabi,
 A similar technique is used with sparse matrices.  You usually have
 severals arrays, one for the non-zero elements, and another one for
 indexing the column and a third for indexing the rows.

 http://pasadena.wr.usgs.gov/office/baagaard/research/papers/thesis/fi...

 This should be fast as long as you're only updating.  If you're
 inserting/deleting, you might be able to get away with using a
 collection of 1D trees.

 Sean

 On Jan 20, 9:18 am, Gabi bugspy...@gmail.com wrote:

  These vectors represent trees which need to updated very frequently.
  So If there was an efficient way to use transients to represent
  transient trees the whole process would be much more efficient (so
  each update to a tree would be done in place instead of creating new
  one.) As discussed above, naive usage of transients won't help.
  Another approach would be implement in Java, but I wish there would
  some way to achieve this directly from Clojure.
  Now that I think about it, maybe the solution is to represent the tree
  as one dimensional vector instead of nested one (any good clojure
  algorithm for this ? Representing and traversing non binary trees as
  one dimensional vector?)

  Jan 20, 12:53 pm, Christophe Grand christo...@cgrand.net wrote:

   Hi Gabi!

   Can you tell us more about your problem, what do those deeply nested
   vectors represent and how are you going to update them? (are all
   updates batched in one part of your program?)

   With transients current implementation you can't write an efficient 
   update-in!

   Christophe

   On Wed, Jan 20, 2010 at 9:15 AM, Gabi bugspy...@gmail.com wrote:
Guys, I really need your expertise here.
I have lots of deeply nested vectors, which i need to manipulate
frequently (thousands of times)
What is the most effective way to do this ?

On Jan 17, 4:27 pm, Gabi bugspy...@gmail.com wrote:
Right. I thought that transient performing deep 'transientivity'.
Here is a fixed version. It takes a regular coll converts whatever it
can to transient and update the stuff.
The problem is that doing persistent!(assoc!(transient m)) on each
level probably misses the whole point of performance.
So while it work, it probably slower than the regular update-in.
I need a better solution.

(defn update-in!!
  modified version of core/update-in that works on, and return
transiants
  ([m [k  ks] f  args]
   (if ks
     (persistent!(assoc! (transient m) k (apply update-in!! (get m k)
ks f args)))
     (persistent!(assoc! (transient m) k (apply f (get m k) args))

On Jan 17, 3:57 pm, Chouser chou...@gmail.com wrote:

 On Sun, Jan 17, 2010 at 8:25 AM, Gabi bugspy...@gmail.com wrote:

  user= (persistent!(update-in!(transient v) [0] reverse))

  Forgot to mention that v in the example is defined to  [[1 2] [3 
  4]]

 So you've got a transient vector of persistent vectors of
 numbers.  The problem is your update-in! then calls assoc! on
 each level, but of course assoc! on the inner persistent vector
 fails.

 You either need to make the inner vectors transient (and then
 call persist! on them when you're done) or use assoc! only at the
 outer level.

 --Chouserhttp://joyofclojure.com/

--
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

   --
   Professional:http://cgrand.net/(fr)
   On Clojure:http://clj-me.cgrand.net/(en)
-- 
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

Re: update-in! (?)

2010-01-20 Thread Sean Devlin

How about a sorted set w/ a custom comparator?  Of course, this rules
out transients, but maybe the flatness will make up for it?

On Jan 20, 10:15 am, Gabi bugspy...@gmail.com wrote:
 I need to add/delete much more frequently than just updating
 actually.

 On Jan 20, 4:59 pm, Sean Devlin francoisdev...@gmail.com wrote:

  Gabi,
  A similar technique is used with sparse matrices.  You usually have
  severals arrays, one for the non-zero elements, and another one for
  indexing the column and a third for indexing the rows.

 http://pasadena.wr.usgs.gov/office/baagaard/research/papers/thesis/fi...

  This should be fast as long as you're only updating.  If you're
  inserting/deleting, you might be able to get away with using a
  collection of 1D trees.

  Sean

  On Jan 20, 9:18 am, Gabi bugspy...@gmail.com wrote:

   These vectors represent trees which need to updated very frequently.
   So If there was an efficient way to use transients to represent
   transient trees the whole process would be much more efficient (so
   each update to a tree would be done in place instead of creating new
   one.) As discussed above, naive usage of transients won't help.
   Another approach would be implement in Java, but I wish there would
   some way to achieve this directly from Clojure.
   Now that I think about it, maybe the solution is to represent the tree
   as one dimensional vector instead of nested one (any good clojure
   algorithm for this ? Representing and traversing non binary trees as
   one dimensional vector?)

   Jan 20, 12:53 pm, Christophe Grand christo...@cgrand.net wrote:

Hi Gabi!

Can you tell us more about your problem, what do those deeply nested
vectors represent and how are you going to update them? (are all
updates batched in one part of your program?)

With transients current implementation you can't write an efficient 
update-in!

Christophe

On Wed, Jan 20, 2010 at 9:15 AM, Gabi bugspy...@gmail.com wrote:
 Guys, I really need your expertise here.
 I have lots of deeply nested vectors, which i need to manipulate
 frequently (thousands of times)
 What is the most effective way to do this ?

 On Jan 17, 4:27 pm, Gabi bugspy...@gmail.com wrote:
 Right. I thought that transient performing deep 'transientivity'.
 Here is a fixed version. It takes a regular coll converts whatever it
 can to transient and update the stuff.
 The problem is that doing persistent!(assoc!(transient m)) on each
 level probably misses the whole point of performance.
 So while it work, it probably slower than the regular update-in.
 I need a better solution.

 (defn update-in!!
   modified version of core/update-in that works on, and return
 transiants
   ([m [k  ks] f  args]
    (if ks
      (persistent!(assoc! (transient m) k (apply update-in!! (get m k)
 ks f args)))
      (persistent!(assoc! (transient m) k (apply f (get m k) 
 args))

 On Jan 17, 3:57 pm, Chouser chou...@gmail.com wrote:

  On Sun, Jan 17, 2010 at 8:25 AM, Gabi bugspy...@gmail.com wrote:

   user= (persistent!(update-in!(transient v) [0] reverse))

   Forgot to mention that v in the example is defined to  [[1 2] [3 
   4]]

  So you've got a transient vector of persistent vectors of
  numbers.  The problem is your update-in! then calls assoc! on
  each level, but of course assoc! on the inner persistent vector
  fails.

  You either need to make the inner vectors transient (and then
  call persist! on them when you're done) or use assoc! only at the
  outer level.

  --Chouserhttp://joyofclojure.com/

 --
 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

--
Professional:http://cgrand.net/(fr)
On Clojure:http://clj-me.cgrand.net/(en)
-- 
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

Re: update-in! (?)

Can you elaborate more ? How can trees be represented in sorted sets?

On Jan 20, 5:24 pm, Sean Devlin francoisdev...@gmail.com wrote:
 How about a sorted set w/ a custom comparator?  Of course, this rules
 out transients, but maybe the flatness will make up for it?

 On Jan 20, 10:15 am, Gabi bugspy...@gmail.com wrote:

  I need to add/delete much more frequently than just updating
  actually.

  On Jan 20, 4:59 pm, Sean Devlin francoisdev...@gmail.com wrote:

   Gabi,
   A similar technique is used with sparse matrices.  You usually have
   severals arrays, one for the non-zero elements, and another one for
   indexing the column and a third for indexing the rows.

  http://pasadena.wr.usgs.gov/office/baagaard/research/papers/thesis/fi...

   This should be fast as long as you're only updating.  If you're
   inserting/deleting, you might be able to get away with using a
   collection of 1D trees.

   Sean

   On Jan 20, 9:18 am, Gabi bugspy...@gmail.com wrote:

These vectors represent trees which need to updated very frequently.
So If there was an efficient way to use transients to represent
transient trees the whole process would be much more efficient (so
each update to a tree would be done in place instead of creating new
one.) As discussed above, naive usage of transients won't help.
Another approach would be implement in Java, but I wish there would
some way to achieve this directly from Clojure.
Now that I think about it, maybe the solution is to represent the tree
as one dimensional vector instead of nested one (any good clojure
algorithm for this ? Representing and traversing non binary trees as
one dimensional vector?)

Jan 20, 12:53 pm, Christophe Grand christo...@cgrand.net wrote:

 Hi Gabi!

 Can you tell us more about your problem, what do those deeply nested
 vectors represent and how are you going to update them? (are all
 updates batched in one part of your program?)

 With transients current implementation you can't write an efficient 
 update-in!

 Christophe

 On Wed, Jan 20, 2010 at 9:15 AM, Gabi bugspy...@gmail.com wrote:
  Guys, I really need your expertise here.
  I have lots of deeply nested vectors, which i need to manipulate
  frequently (thousands of times)
  What is the most effective way to do this ?

  On Jan 17, 4:27 pm, Gabi bugspy...@gmail.com wrote:
  Right. I thought that transient performing deep 'transientivity'.
  Here is a fixed version. It takes a regular coll converts whatever 
  it
  can to transient and update the stuff.
  The problem is that doing persistent!(assoc!(transient m)) on each
  level probably misses the whole point of performance.
  So while it work, it probably slower than the regular update-in.
  I need a better solution.

  (defn update-in!!
    modified version of core/update-in that works on, and return
  transiants
    ([m [k  ks] f  args]
     (if ks
       (persistent!(assoc! (transient m) k (apply update-in!! (get m 
  k)
  ks f args)))
       (persistent!(assoc! (transient m) k (apply f (get m k) 
  args))

  On Jan 17, 3:57 pm, Chouser chou...@gmail.com wrote:

   On Sun, Jan 17, 2010 at 8:25 AM, Gabi bugspy...@gmail.com 
   wrote:

user= (persistent!(update-in!(transient v) [0] reverse))

Forgot to mention that v in the example is defined to  [[1 2] 
[3 4]]

   So you've got a transient vector of persistent vectors of
   numbers.  The problem is your update-in! then calls assoc! on
   each level, but of course assoc! on the inner persistent vector
   fails.

   You either need to make the inner vectors transient (and then
   call persist! on them when you're done) or use assoc! only at the
   outer level.

   --Chouserhttp://joyofclojure.com/

  --
  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

 --
 Professional:http://cgrand.net/(fr)
 On Clojure:http://clj-me.cgrand.net/(en)
-- 
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

Re: update-in! (?)

2010-01-20 Thread Christophe Grand

I concur: a map (or a sorted map if you need to emulate access to a
subtree) can be an option.

[[1 2] [3 4]] is represented by {[0 0] 1, [0 1] 2, [1 0] 3, [1 1] 4}

On Wed, Jan 20, 2010 at 4:24 PM, Sean Devlin francoisdev...@gmail.com wrote:
 How about a sorted set w/ a custom comparator?  Of course, this rules
 out transients, but maybe the flatness will make up for it?

 On Jan 20, 10:15 am, Gabi bugspy...@gmail.com wrote:
 I need to add/delete much more frequently than just updating
 actually.

 On Jan 20, 4:59 pm, Sean Devlin francoisdev...@gmail.com wrote:

  Gabi,
  A similar technique is used with sparse matrices.  You usually have
  severals arrays, one for the non-zero elements, and another one for
  indexing the column and a third for indexing the rows.

 http://pasadena.wr.usgs.gov/office/baagaard/research/papers/thesis/fi...

  This should be fast as long as you're only updating.  If you're
  inserting/deleting, you might be able to get away with using a
  collection of 1D trees.

  Sean

  On Jan 20, 9:18 am, Gabi bugspy...@gmail.com wrote:

   These vectors represent trees which need to updated very frequently.
   So If there was an efficient way to use transients to represent
   transient trees the whole process would be much more efficient (so
   each update to a tree would be done in place instead of creating new
   one.) As discussed above, naive usage of transients won't help.
   Another approach would be implement in Java, but I wish there would
   some way to achieve this directly from Clojure.
   Now that I think about it, maybe the solution is to represent the tree
   as one dimensional vector instead of nested one (any good clojure
   algorithm for this ? Representing and traversing non binary trees as
   one dimensional vector?)

   Jan 20, 12:53 pm, Christophe Grand christo...@cgrand.net wrote:

Hi Gabi!

Can you tell us more about your problem, what do those deeply nested
vectors represent and how are you going to update them? (are all
updates batched in one part of your program?)

With transients current implementation you can't write an efficient 
update-in!

Christophe

On Wed, Jan 20, 2010 at 9:15 AM, Gabi bugspy...@gmail.com wrote:
 Guys, I really need your expertise here.
 I have lots of deeply nested vectors, which i need to manipulate
 frequently (thousands of times)
 What is the most effective way to do this ?

 On Jan 17, 4:27 pm, Gabi bugspy...@gmail.com wrote:
 Right. I thought that transient performing deep 'transientivity'.
 Here is a fixed version. It takes a regular coll converts whatever 
 it
 can to transient and update the stuff.
 The problem is that doing persistent!(assoc!(transient m)) on each
 level probably misses the whole point of performance.
 So while it work, it probably slower than the regular update-in.
 I need a better solution.

 (defn update-in!!
   modified version of core/update-in that works on, and return
 transiants
   ([m [k  ks] f  args]
    (if ks
      (persistent!(assoc! (transient m) k (apply update-in!! (get m 
 k)
 ks f args)))
      (persistent!(assoc! (transient m) k (apply f (get m k) 
 args))

 On Jan 17, 3:57 pm, Chouser chou...@gmail.com wrote:

  On Sun, Jan 17, 2010 at 8:25 AM, Gabi bugspy...@gmail.com wrote:

   user= (persistent!(update-in!(transient v) [0] reverse))

   Forgot to mention that v in the example is defined to  [[1 2] 
   [3 4]]

  So you've got a transient vector of persistent vectors of
  numbers.  The problem is your update-in! then calls assoc! on
  each level, but of course assoc! on the inner persistent vector
  fails.

  You either need to make the inner vectors transient (and then
  call persist! on them when you're done) or use assoc! only at the
  outer level.

  --Chouserhttp://joyofclojure.com/

 --
 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

--
Professional:http://cgrand.net/(fr)
On Clojure:http://clj-me.cgrand.net/(en)

 --
 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




-- 
Professional: http://cgrand.net/ (fr)
On Clojure:

Re: update-in! (?)