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 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 wrote: > > > On Sun, Jan 17, 2010 at 8:25 AM, Gabi 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: Empty defstruct
> Just another option to consider:
> {:type :person, :name "Bill", :age 20}
Why then use defstruct at all? I think defstruct is useful, but it
would be even
more useful if I had nothing to fear if it "runs empty" sometime
because of
little design changes. It might be only experimental and later I may
choose
other obligatory keys, but breaking the consistency of defstruct at
this
point is in my opinion a singularity that is just unnecessary.
--
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: Empty defstruct
> I think your use of "workaround" is pejorative. And can it even be > called a work around if it is a best practice even when there is > nothing to work around? I just can't understand why throwing an exception should be more useful than returning some object you can actually work with. I wouldn't throw an exception for empty vectors or list either. Why artificially introducing this constraint where it is not necessary at all? Please help me to understand why I am wrong. Why are empty structs in C, empty classes in Java, empty hashmaps in Clojure, why are all of these objects allowed (of course, because it makes sense), but empty defstructs are forbidden by a if-empty-then-exception where it is not necessary or helpful at all? -- 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: compojure/defservlet
Unfortunately, that Wikibook is out of date. The `defservlet On Jan 20, 1:19 am, Jeff Schwab wrote: > Hi: > > The compojure wikibook claims that compojure provides a defservlet > function, along with other syntactic conveniences that I seem to be > missing. Grepping the git log didn't turn up anything relevant, so I'm > wondering: Is compojure supposed to provide defservlet, or should I fix > the wikibook? > > http://en.wikibooks.org/wiki/Compojure/Core_Libraries -- 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: compojure/defservlet
Unfortunately, that wikibook is rather out of date by now. Compojure's
documentation is generally not in the best of states; however, I'm
holding off fixing it until I finish work on the next version in a
couple of months. There doesn't seem much point in writing docs for a
version that will soon be supplanted.
Originally, back in version 0.1, Compojure constructing Java servlets
directly using defservlet. Now it uses defroutes to construct a Ring
handler, which can then be turned into a servlet proxy with the
"servlet" function. For example:
(defroutes foobar
(GET "/" "Hello World")
(ANY "*" [404 "Page not found"]))
(run-server {:port 8080}
"/" (servlet foobar))
This code defines a Ring handler function, which is then converted
into a servlet and passed to an embedded Jetty server.
- James
On Jan 20, 1:19 am, Jeff Schwab wrote:
> Hi:
>
> The compojure wikibook claims that compojure provides a defservlet
> function, along with other syntactic conveniences that I seem to be
> missing. Grepping the git log didn't turn up anything relevant, so I'm
> wondering: Is compojure supposed to provide defservlet, or should I fix
> the wikibook?
>
> http://en.wikibooks.org/wiki/Compojure/Core_Libraries
--
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! (?)
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 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 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 wrote: >> >> > On Sun, Jan 17, 2010 at 8:25 AM, Gabi 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 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 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 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 wrote: > > >> > On Sun, Jan 17, 2010 at 8:25 AM, Gabi 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! (?)
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 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 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 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 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 wrote: > > > >> > On Sun, Jan 17, 2010 at 8:25 AM, Gabi 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 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 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 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 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 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 wrote: > > > > >> > On Sun, Jan 17, 2010 at 8:25 AM, Gabi 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! (?)
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 wrote: > I need to add/delete much more frequently than just updating > actually. > > On Jan 20, 4:59 pm, Sean Devlin 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 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 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 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 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 wrote: > > > > > >> > On Sun, Jan 17, 2010 at 8:25 AM, Gabi 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 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 wrote: > > > I need to add/delete much more frequently than just updating > > actually. > > > On Jan 20, 4:59 pm, Sean Devlin 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 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 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 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 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 wrote: > > > > > > >> > On Sun, Jan 17, 2010 at 8:25 AM, Gabi > > > > > >> > 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 mem
Re: update-in! (?)
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 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 wrote:
>> I need to add/delete much more frequently than just updating
>> actually.
>>
>> On Jan 20, 4:59 pm, Sean Devlin 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 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 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 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 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 wrote:
>>
>> > > > >> > On Sun, Jan 17, 2010 at 8:25 AM, Gabi 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@goog
Re: update-in! (?)
I posted a question on SO about it. Interesting discussion:
http://stackoverflow.com/questions/2102606/algorithm-to-implement-non-binary-trees-using-1-dimensional-vector
On Jan 20, 5:39 pm, Christophe Grand 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 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 wrote:
> >> I need to add/delete much more frequently than just updating
> >> actually.
>
> >> On Jan 20, 4:59 pm, Sean Devlin 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 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 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 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 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 wrote:
>
> >> > > > >> > On Sun, Jan 17, 2010 at 8:25 AM, Gabi
> >> > > > >> > 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
> >> > > > > clo
Re: Empty defstruct
"empty classes in Java" what does that mean? as I said, structs are an optimization on maps, that optimization doesn't work for empty structs, so empty structs "of course" don't make sense On Wed, Jan 20, 2010 at 12:39 AM, Andreas Wenger wrote: >> I think your use of "workaround" is pejorative. And can it even be >> called a work around if it is a best practice even when there is >> nothing to work around? > > I just can't understand why throwing an exception should be more > useful than returning some object you can actually work with. > I wouldn't throw an exception for empty vectors or list either. Why > artificially introducing this constraint where it is not necessary at > all? > > Please help me to understand why I am wrong. Why are empty structs in > C, empty classes in Java, empty hashmaps in Clojure, why are all of > these objects allowed (of course, because it makes sense), but empty > defstructs are forbidden by a if-empty-then-exception where it is not > necessary or helpful at all? > > -- > 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 > -- And what is good, Phaedrus, And what is not good— Need we ask anyone to tell us these things? -- 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
Autodoc for the masses
Now your project can have the same documentation as Clojure, clojure- contrib, and Incanter! The standalone autodoc tool is now available. It can be run from the command line and it integrates with Leiningen and ant. (Maven still to come - let me know if you want to help.) Autodoc builds full, styled HTML documentation from your doc-strings and other metadata you supply. It includes a project overview page, separate pages for each namespace, and an overall index page. It builds pages suitable for use with github pages so you can easily publish documentation and can include links to source code if you publish source. Documentation on how to get and use Autodoc is here: http://tomfaulhaber.github.com/autodoc/ (apologies for the fact that the doc is not yet pretty!). I hope that Autodoc helps you increase the quality of documentation for your projects. Enjoy, Tom Faulhaber -- 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: deftype implementing methods with multiple argument lists
On 19 Jan 2010, at 22:32, Stuart Sierra wrote: You can include multiple definitions of the same method, with different arguments, in a deftype. (deftype Foo [f] (bar [x] ...) (bar [x y] ...)) Don't know if that's intended, but it works. Indeed, thanks! Assuming that this is an intentional feature, I would expect the deftype macro to do the translation from the standard Clojure notation to a list of multiple methods. Rich, is that something you'd want? I volunteer to provide a patch in that case. Konrad. -- 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: Good "refs" on concurrency?
> These two are sufficient to convince many of the complexity of Concurrent > programming. The way I try to convince people of the benefits of Clojure is > by first explaining these 2 articles and then showing how easy life is with > Clojure. please also see CTM. http://www.info.ucl.ac.be/~pvr/VanRoyChapter.pdf sincerely. -- 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: clojure unicode on Windows
Hi using directly (not jline or others) although pure REPL would be still fine, I have found how to make it work in emacs WIN32 not sure if all of this is needed though .emacs (setq locale-coding-system 'utf-8) (set-terminal-coding-system 'utf-8) (set-keyboard-coding-system 'utf-8) (set-selection-coding-system 'utf-8) (prefer-coding-system 'utf-8) (setq x-select-request-type '(UTF8_STRING COMPOUND_TEXT TEXT STRING)) (set-clipboard-coding-system 'utf-16le-dos) (set-language-environment "UTF-8") (setq slime-net-coding-system 'utf-8-unix) then in slime repl user> éő ; Evaluation aborted. user> (def éő 0) #'user/éő user> éő 0 user> looks ok Lukas On 1/15/2010 11:21 PM, Kevin Downey wrote: are you using the repl directly? or wrapped in jline or rlwrap? On Wed, Jan 13, 2010 at 3:02 PM, Lukas Lehner wrote: Ok, tried to put this at the top of the file, but same bad result on Win (System/setProperty "file.encoding" "UTF8") and actually here http://stackoverflow.com/questions/361975/setting-the-default-java-character-encoding it looks like JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF8 has the same effect, and should be used (and I am using it) Is everybody here running macs and linuxes? :( And, more important now is actually REPL user=> (System/setProperty "file.encoding" "UTF8") "UTF8" user=> "éőó" "∩┐╜o∩┐╜" user=> L On 1/13/2010 11:34 PM, Kevin Downey wrote: java uses local settings, on windows the default encoding is some godawful thing (same on Mac, still godawful, but different) set file.encoding to pick something sane On Wed, Jan 13, 2010 at 1:52 PM, Lukas Lehner wrote: Hi all The clojure unicode reading, evaluating and printing was discussed already with various results. Let me add one more, and kindly ask for advice if anyone has. OS: Windows 7 clojure 1.1 C:\>java -version Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF8 java version "1.6.0_17" Java(TM) SE Runtime Environment (build 1.6.0_17-b04) Java HotSpot(TM) Client VM (build 14.3-b01, mixed mode, sharing) chcp: 437 java clojure.main user=>éáú java.lang.Exception: Unable to resolve symbol: ∩┐╜∩┐╜∩┐╜ in this context (NO_SOURCE_FILE:0) You see the problem. chcp: 65001 java clojure.main user=>éáú C:\> In this case REPL is killed without any message File unicode-test.clj in unicode: (println (seq (.split "őúáé öüü? sdf" "\\W+"))) c:\>java clojure.main unicode-test.clj Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF8 Exception in thread "main" java.lang.Exception: Unable to resolve symbol: in this context (unicode-test.clj:0)0) rest of the error at http://clojure.pastebin.com/m2235d7fb OS: FreeBSD 7.2 clojure 1.1 java -version java version "1.6.0_07" Diablo Java(TM) SE Runtime Environment (build 1.6.0_07-b02) Diablo Java HotSpot(TM) Server VM (build 10.0-b23, mixed mode) locale LANG=en_US.UTF-8 LC_CTYPE="en_US.UTF-8" LC_COLLATE="en_US.UTF-8" LC_TIME="en_US.UTF-8" LC_NUMERIC="en_US.UTF-8" LC_MONETARY="en_US.UTF-8" LC_MESSAGES="en_US.UTF-8" LC_ALL=en_US.UTF-8 java clojure.main user=>éőó java.lang.Exception: Unable to resolve symbol: ó�éőó in this context (NO_SOURCE_FILE:0) user=>"éőó" "éőó" user=>(println "éőó") éőó nil user=>(def éőó 0) java.lang.Exception: Unable to resolve symbol: �0 in this context (NO_SOURCE_FILE:6) user=> better but still not bulletproof testing also the same script like on windows java clojure.main unicode-test.clj ( sfd) No errors :) but of course it did not split the way I wanted... Anyone having better results with unicode and encoding? Preferably on windows. Thank you in advance Lukas -- 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
Multimethod attribute maps
In Clojure 1.1.0, the documentation states: clojure.core/defmulti ([name docstring? attr-map? dispatch-fn & options]) Macro Creates a new multimethod with the associated dispatch function. The docstring and attribute-map are optional. Options are key-value pairs and may be one of: :defaultthe default dispatch value, defaults to :default :hierarchy the isa? hierarchy to use for dispatching defaults to the global hierarchy What is the purpose of the attribute map (and, perhaps more importantly, where could I have found an explanation in the documentation) ? 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
Re: update-in! (?)
Any chance you could rethink your approach & use a zipper?
On Jan 20, 9:32 am, Gabi 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 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
> > 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 wrote:
> > >> I need to add/delete much more frequently than just updating
> > >> actually.
>
> > >> On Jan 20, 4:59 pm, Sean Devlin 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 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 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 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 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 wrote:
>
> > >> > > > >> > On Sun, Jan 17, 2010 at 8:25 AM, Gabi
> > >> > > > >> > 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
Question about Responsiveness of Garbage Collection
Hi, Java was my first language, and my favorite platform to work in, but I do notice (especially after buying a mac and experiencing Mac OS X) that gui programs written on the JVM are noticeably less responsive than their native counterparts. Some articles I read point to Java's use of garbage collection as the culprit, and I'm wondering whether that is true. I know Scheme and Common Lisp also use garbage collection, so do gui programs written those languages also feel sluggish? Thanks for your opinions -Patrick -- 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: Question about Responsiveness of Garbage Collection
> Thanks for your opinions for the most part, it is theoretically (and research implementations have shown) that GC can be just as responsive from an end-user perspective as manual memory management. i believe the price to pay is usually a significantly larger memory footprint. and, there is nothing about this which says the JVM/CLR/*VM you use (or the one your client uses to run your program) has a GC that is that "good". sincerely. -- 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: Autodoc for the masses
That's fantastic news! I wholeheartedly recommend Autodoc, it has been great for the Incanter project. Here are examples of its output: Clojure: http://richhickey.github.com/clojure/ Clojure-contrib: http://richhickey.github.com/clojure-contrib/ Incanter: http://liebke.github.com/incanter/ David On Jan 20, 12:51 pm, Tom Faulhaber wrote: > Now your project can have the same documentation as Clojure, clojure- > contrib, and Incanter! > > The standalone autodoc tool is now available. It can be run from the > command line and it integrates with Leiningen and ant. (Maven still to > come - let me know if you want to help.) > > Autodoc builds full, styled HTML documentation from your doc-strings > and other metadata you supply. It includes a project overview page, > separate pages for each namespace, and an overall index page. > > It builds pages suitable for use with github pages so you can easily > publish documentation and can include links to source code if you > publish source. > > Documentation on how to get and use Autodoc is > here:http://tomfaulhaber.github.com/autodoc/(apologies for the fact that > the doc is not yet pretty!). > > I hope that Autodoc helps you increase the quality of documentation > for your projects. > > Enjoy, > > Tom Faulhaber -- 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: Autodoc for the masses
Tom Faulhaber writes: > Now your project can have the same documentation as Clojure, clojure- > contrib, and Incanter! > > The standalone autodoc tool is now available. It can be run from the > command line and it integrates with Leiningen and ant. (Maven still to > come - let me know if you want to help.) > > Autodoc builds full, styled HTML documentation from your doc-strings > and other metadata you supply. It includes a project overview page, > separate pages for each namespace, and an overall index page. > > It builds pages suitable for use with github pages so you can easily > publish documentation and can include links to source code if you > publish source. > > Documentation on how to get and use Autodoc is here: > http://tomfaulhaber.github.com/autodoc/ (apologies for the fact that > the doc is not yet pretty!). > > I hope that Autodoc helps you increase the quality of documentation > for your projects. Looks great! A couple comments. * Adding "by unknown author" to namespaces that have no author metadata seems a bit superfluous. * Have you thought about a task to automatically upload the HTML files to github? I haven't used Github Pages; is this something that could be done using jcsh, or would it require shelling out to scp? * It would be great to be able to provide a logo image that would be included as in Incanter's docs. Thanks for getting this all packaged up. -Phil -- 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: Autodoc for the masses
Fantastic! Love 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
Re: compojure/defservlet
James Reeves wrote: Compojure's documentation is generally not in the best of states; however, I'm holding off fixing it until I finish work on the next version in a couple of months. Fair enough, 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: Autodoc for the masses
> Looks great! A couple comments. Thanks! > * Adding "by unknown author" to namespaces that have no author metadata > seems a bit superfluous. Yeah, that's on my list to clean up. I did that in the old days to shame the contrib authors into adding the metadata (and remind me to bug them), but clearly for lots of projects it makes no sense. In the meantime, it's not too hard to do by hand. Once you've got it set up, all you have to do is do a "git commit" in the autodoc directory after running autodoc. See the documentation for full info on getting it set up. > * Have you thought about a task to automatically upload the HTML files > to github? I haven't used Github Pages; is this something that could > be done using jcsh, or would it require shelling out to scp? Yup, and it's on its way. I was thinking I'd use ant. It's just executing some git stuff and I already have the ant code for it. I was thinking I'd lancet-ify it and enable a call out. The service version of autodoc is a mix of ant calling autodoc calling ant - real set your hair on fire kind of stuff. I'm slowly trying to rationalize it down to "pure" clojure. > * It would be great to be able to provide a logo image that would be > included as in Incanter's docs. It's possible. I need to add doc for how to do 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
Re: Multimethod attribute maps
2010/1/20 Jacek Generowicz :
> What is the purpose of the attribute map?
The attribute map is added to the meta-data of the created. Meta-data
contains info which can be used at runtime or to create documentation
but is not part of the object itself and does not affect equality.
Specifically for defmulti you might use it like this:
(defmulti foo "This is foo" {:author "me", :arglists '([bar])} type)
Notably defmulti does not automatically create an arglists like defn
and defmacro do. So this is a good example where you might want to use
an attribute map to specify that. Speaking of which, it would seem
that a good default arglists would be to copy the dispatch functions
arglists, which would at least provide the correct arity... anyone
agree/disagree?
You can view meta data like so: (meta (var foo))
Note that the file/line is stored in meta-data for debugging,
> where could I have found an explanation in the documentation ?
Hmmm not sure for this one.
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: Question about Responsiveness of Garbage Collection
If you are talking about gui's written in swing you might have more luck with AWT since that is supposed to be using native gui components rather than doing it's rendering in java. I suspect that the sluggishness of swing is due to the fact that it has to copy a lot of data between the java heap and native memory on every repaint. A lot of java desktop applications just use a third party library for doing their gui and that works pretty well (not that eclipse for example is very fast anyway but I think that's because it's a big mess of an application). -- 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
return value of use, requires?
hi, in the repl when i (use 'foo) vs. (use :foo) they both return nil, so it doesn't help me know that the former is right and the latter isn't. i think. would it be sensible for use to return true or something more positive than nil if it successfully brings in a namespace? 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
