Re: What to use for serializing reference types?
Le mardi 12 août 2014, MS 5lvqbw...@sneakemail.com a écrit : Thanks, I figure now in 2014 disk space is not a big deal, and any two sequences of text will compress to something really small, so saving disk space is not a compelling reason for reference data. There was in fact a decent reason I wanted these to reference the same object, but of course I can't think of what that was now. It'll return to me when I'm half asleep. Maybe you want to save memory by not having unnecessary duplicates created? On Monday, August 11, 2014 7:49:51 AM UTC-7, James Reeves wrote: If your purpose is just to save disk space, then I'd suggest just using compression. Two identical data types should produce the same sequence of bytes, which are easily compressed. I believe Nippy has a fast compression via Snappy enabled by default. - James On 10 August 2014 19:36, MS 5lvq...@sneakemail.com wrote: I'm trying to write an EE schematic capture program in clojure. I'd like to be able to define a prototype component, say a resistor with value=10k, then be able to instantiate that many times, with each instance having an additional property such as a name string. It's easy to ensure (identical? (proto instance1) (proto instance2)) returns true while in-memory, however I'm not sure how to write this out to disk. It seems the serialization libraries, print-dup, edn, etc., operate on values, so reading the database back in won't guarantee it's really the same object. I'd like to have the thing defined *once* then instantiated many times, and have this captured in the on-disk version. Am I barking up the wrong tree? ie, given immutable data structures, there's kind of no point in doing this. I'm actually trying to save disk space, so I'd like to be able to refer in a few characters a potentially large structure that was defined earlier. It would also be nice to have this be human readable. Would one of the JSON serializers do this for me? -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@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+u...@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+u...@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 javascript:_e(%7B%7D,'cvml','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 javascript:_e(%7B%7D,'cvml','clojure%2bunsubscr...@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 javascript:_e(%7B%7D,'cvml','clojure%2bunsubscr...@googlegroups.com');. For more options, visit https://groups.google.com/d/optout. -- Laurent Petit -- 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: CIDER vs Org Mode: Symbol's definition is void: nrepl-send-string-sync (workaround)
Bozhidar Batsov bozhidar.bat...@gmail.com writes: This was recently renamed - have a look at CIDER's changelog. Interestingly we have an alias with the old name, so people should be getting warnings, not errors. I’ll have at the problem. I think the attached patch should fix the problem. -- Bastien diff --git a/nrepl-client.el b/nrepl-client.el index dcaa4a7..6e7c69b 100644 --- a/nrepl-client.el +++ b/nrepl-client.el @@ -1060,6 +1060,7 @@ Refreshes EWOC. (define-obsolete-function-alias 'nrepl-send-request-sync 'nrepl-send-sync-request 0.8.0) +(define-obsolete-function-alias 'nrepl-send-string-sync 'nrepl-sync-request:eval 0.8.0) (define-obsolete-function-alias 'nrepl-send-string 'nrepl-request:eval 0.8.0) (define-obsolete-variable-alias 'nrepl-log-events 'nrepl-log-messages 0.7.0) (define-obsolete-function-alias 'nrepl-log-events 'nrepl-log-messages 0.7.0) -- 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: Benchmarking structural sharing
You could likely use System/identityHashCode to count the similarity of
objects all the objects.
I created a small function that only honors the clojure-visible
structure, and exposes every item in a tree structure (apart from the
arrays in PersistentVectors and some PersistentMaps)
(defn steam-roller [l]
gives a representation of all object pointers in a
nested structure by both adding pointers to everything seqable
as well as its contents
it also takes out keys and vals of maps, as well as the whole map
(let [l [l]]
(loop [l1 l l2 '()]
(cond
(sequential? (first l1)) (recur (concat (first l1) (rest l1)) (cons
(first l1) l2))
(map? (first l1)) (recur (concat (keys (first l1)) (vals (first l1))
(rest l1)) (cons (first l1) l2))
(empty? l1) (reverse l2)
:else (recur (rest l1) (cons (first l1) l2))
(inspired by slovic's version of flatten at
http://clojuredocs.org/clojure_core/clojure.core/flatten)
Example output is:
(steam-roller *[:a :b {:c 2 3 4}]*)
- (*[:a :b {:c 2, 3 4}]* :a :b {:c 2, 3 4} :c 3 2 4)
You could then make some trivial statistics collection like
(map #(System/identityHashCode %) (steam-roller {1 2 3 4}))
- (359344022 504432400 1778018115 1172818142 256714182)
where (set) gives the unique HashCodes.
The reasoning behind not taking out mapEntries of maps, but just the keys
and vals is that maps usually is k-v-pairs in an Object-array or a shallow
tree of those Objectarrays.
This does *not* take care about either implementation details in either
PersistentVector or rrb-vector. I guess one could use
https://github.com/arohner/clj-wallhack or https://github.com/zcaudate/iroh
to walk around inside the inners of PersistentVector and rrb-vector.
The conclusion of this is I think the easiest way to make this work is to
just run the algorithm in both versions and watch the object allocation
statistics closely in VisualVM or similar. My intuition is that the there
will be a lot of copied arrays, but that's quite quick (not as quick as
shuffling longs with sun.misc.Unsafe, though).
/Linus
2014-08-11 14:56 GMT+02:00 Paul Butcher p...@paulbutcher.com:
Is there any way to benchmark the degree of structural sharing achieved by
a Clojure algorithm? I'm evaluating two different implementations of an
algorithm, one which uses zippers and one which uses rrb-vector. It would
be great if there were some way to quantify the degree to which they both
achieved (or didn't) structural sharing.
--
paul.butcher-msgCount++
Silverstone, Brands Hatch, Donington Park...
Who says I have a one track mind?
http://www.paulbutcher.com/
LinkedIn: http://www.linkedin.com/in/paulbutcher
Skype: paulrabutcher
Author of Seven Concurrency Models in Seven Weeks: When Threads Unravel
http://pragprog.com/book/pb7con
--
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.
[ANN] Skummet alpha-1 released
So I am finally comfortable for showing Project Skummet to the general public. Skummet is a experimental Clojure branch that features a modified AOT-compiler providing the following features: a) Compiling vars into objects stored as namespace's static fields; b) Skipping emission of macros; c) Skipping emission of metadata without eliding it completely (so it is used during compilation but not emitted in the resulting classes). Since it's still in alpha stage, bugs might occur. I was able to lean-compile Clojure, core.async and a few other small libraries, but for others it might fail for one reason or another. The most usual problem is when a library declares a var that it then references explicitly (by with-redefs or by calling methods on that Var object). How to deal with that is described below as step 3. To try Skummet you need to add two things to your Leiningen's project.clj: 1. Add special Clojure version to the :dependencies [org.bytopia/clojure 1.7.0-skummet-SNAPSHOT] 2. Add lein-skummet to the :plugin section: [lein-skummet 0.1.4-SNAPSHOT] 3. If errors with direct Var usage occur, you can put a vector to :skummet-skip-vars that contains stringified var names that have to be made non-lean: :skummet-skip-vars [#'neko.context/context #'neko.resource/package-name] Then to compile a project with Skummet use lein skummet compile. This will produce AOT-compiled Clojure classes. You can then run it with lein skummet run (the only difference from lein run is that no source dependencies are included to the classpath, so you are sure you are running only the compile code); or you can execute lein skummet jar to create an uberjar that can then be used regularly. There is a sample project that already has all necessary configuration for Skummet: https://github.com/alexander-yakushev/leantest. I'd be really grateful if you tried this project and shared your experiences (specifically disappointing ones:)). It is important now to test Skummet with different libraries and find code where it falls short compiling. A good idea will be to benchmark results. My experiments so far show a reduction in startup time by ~40% for Clojure, core.async and for Clojure on Android (right now lein-skummet cannot be used with lein-droid, but this option will be available soon). -- 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.
[ANN] Gorilla REPL 0.3.2 - Important security fix
Hi All, there's a new version of Gorilla REPL, version 0.3.2, available on clojars that contains an important security fix. I would recommend upgrading immediately, if possible. Many thanks to @silasdavis for initially reporting this issue, and for @foogoof for highlighting that it was more important than I had initially thought. The problem was that Gorilla, by default, listened on all available IPs meaning that if your firewall was open on the Gorilla port then untrusted users could execute commands in the clojure REPL (essentially giving them the level of access of the user that ran Gorilla). I had not given this the highest priority to fix, as a sane firewall configuration would prevent this, and rather saw this as a matter of providing safer defaults. However, I recently learned that both Windows and MacOS don't have a sane firewall configuration :eek:. Specifically, if you've ever given incoming access permission to a java program (say IntelliJ, some Oracle abomination that you have to use to buy things at work, a bit torrent client etc etc) then all java processes, including the Gorilla server, will open a hole in the firewall by default :-( A quick sampling of machines around the lab suggested that this is pretty likely to be the case. The fix, contributed by @foogoof, is to only listen on the loopback address by default. You can still configure Gorilla to listen to other addresses if you want to use it in a server configuration. My sincere apologies to anyone who's been put at risk by this, both for writing the half-assed code in the first place, and then not appreciating the severity of the issue when reported! On a brighter note, this release also has improved bracket-match-highlighting which should make it more accessible to those with colour vision deficiency. Jony -- 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: [ANN] Skummet alpha-1 released
I am so excited to use this, Alex! A hello world uberjar with Skummet is 1 MB slimmer and launches twice as fast on my netbook, though I won't call it a scientific test. And of course you know I'm excited about the prospects for CoA -- have you been testing it with ART yet, or just Dalvik? Great work. Zach On Tuesday, August 12, 2014 10:18:23 AM UTC-4, Alexander Yakushev wrote: So I am finally comfortable for showing Project Skummet to the general public. Skummet is a experimental Clojure branch that features a modified AOT-compiler providing the following features: a) Compiling vars into objects stored as namespace's static fields; b) Skipping emission of macros; c) Skipping emission of metadata without eliding it completely (so it is used during compilation but not emitted in the resulting classes). Since it's still in alpha stage, bugs might occur. I was able to lean-compile Clojure, core.async and a few other small libraries, but for others it might fail for one reason or another. The most usual problem is when a library declares a var that it then references explicitly (by with-redefs or by calling methods on that Var object). How to deal with that is described below as step 3. To try Skummet you need to add two things to your Leiningen's project.clj: 1. Add special Clojure version to the :dependencies [org.bytopia/clojure 1.7.0-skummet-SNAPSHOT] 2. Add lein-skummet to the :plugin section: [lein-skummet 0.1.4-SNAPSHOT] 3. If errors with direct Var usage occur, you can put a vector to :skummet-skip-vars that contains stringified var names that have to be made non-lean: :skummet-skip-vars [#'neko.context/context #'neko.resource/package-name] Then to compile a project with Skummet use lein skummet compile. This will produce AOT-compiled Clojure classes. You can then run it with lein skummet run (the only difference from lein run is that no source dependencies are included to the classpath, so you are sure you are running only the compile code); or you can execute lein skummet jar to create an uberjar that can then be used regularly. There is a sample project that already has all necessary configuration for Skummet: https://github.com/alexander-yakushev/leantest. I'd be really grateful if you tried this project and shared your experiences (specifically disappointing ones:)). It is important now to test Skummet with different libraries and find code where it falls short compiling. A good idea will be to benchmark results. My experiments so far show a reduction in startup time by ~40% for Clojure, core.async and for Clojure on Android (right now lein-skummet cannot be used with lein-droid, but this option will be available soon). -- 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: [ANN] Skummet alpha-1 released
Thank you for the feedback, Zach! I only tested on Dalvik so far, with Clojure and most part of Neko lean-compiled (including neko.ui). I plan to try it on ART soon, since Adam Clements made CoA finally working with ART. Alex Yakushev http://www.bytopia.org On Aug 12, 2014 6:49 PM, Zach Oakes zsoa...@gmail.com wrote: I am so excited to use this, Alex! A hello world uberjar with Skummet is 1 MB slimmer and launches twice as fast on my netbook, though I won't call it a scientific test. And of course you know I'm excited about the prospects for CoA -- have you been testing it with ART yet, or just Dalvik? Great work. Zach On Tuesday, August 12, 2014 10:18:23 AM UTC-4, Alexander Yakushev wrote: So I am finally comfortable for showing Project Skummet to the general public. Skummet is a experimental Clojure branch that features a modified AOT-compiler providing the following features: a) Compiling vars into objects stored as namespace's static fields; b) Skipping emission of macros; c) Skipping emission of metadata without eliding it completely (so it is used during compilation but not emitted in the resulting classes). Since it's still in alpha stage, bugs might occur. I was able to lean-compile Clojure, core.async and a few other small libraries, but for others it might fail for one reason or another. The most usual problem is when a library declares a var that it then references explicitly (by with-redefs or by calling methods on that Var object). How to deal with that is described below as step 3. To try Skummet you need to add two things to your Leiningen's project.clj: 1. Add special Clojure version to the :dependencies [org.bytopia/clojure 1.7.0-skummet-SNAPSHOT] 2. Add lein-skummet to the :plugin section: [lein-skummet 0.1.4-SNAPSHOT] 3. If errors with direct Var usage occur, you can put a vector to :skummet-skip-vars that contains stringified var names that have to be made non-lean: :skummet-skip-vars [#'neko.context/context #'neko.resource/package-name] Then to compile a project with Skummet use lein skummet compile. This will produce AOT-compiled Clojure classes. You can then run it with lein skummet run (the only difference from lein run is that no source dependencies are included to the classpath, so you are sure you are running only the compile code); or you can execute lein skummet jar to create an uberjar that can then be used regularly. There is a sample project that already has all necessary configuration for Skummet: https://github.com/alexander-yakushev/leantest. I'd be really grateful if you tried this project and shared your experiences (specifically disappointing ones:)). It is important now to test Skummet with different libraries and find code where it falls short compiling. A good idea will be to benchmark results. My experiments so far show a reduction in startup time by ~40% for Clojure, core.async and for Clojure on Android (right now lein-skummet cannot be used with lein-droid, but this option will be available soon). -- 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 a topic in the Google Groups Clojure group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/clojure/KsaLNBwj4os/unsubscribe. To unsubscribe from this group and all its topics, 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: Benchmarking structural sharing
On 12 August 2014 at 13:49:42, Linus Ericsson (oscarlinuserics...@gmail.com) wrote: The conclusion of this is I think the easiest way to make this work is to just run the algorithm in both versions and watch the object allocation statistics closely in VisualVM or similar. Yeah, that's exactly what I was hoping I might be able to avoid. Ah well. My intuition is that the there will be a lot of copied arrays Indeed. But intuition often isn't a good guide when it comes to optimisation (hence my wish to measure and make decisions based on data instead of intuition). -- paul.butcher-msgCount++ Silverstone, Brands Hatch, Donington Park... Who says I have a one track mind? http://www.paulbutcher.com/ LinkedIn: http://www.linkedin.com/in/paulbutcher Skype: paulrabutcher Author of Seven Concurrency Models in Seven Weeks: When Threads Unravel http://pragprog.com/book/pb7con -- 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: handling agent errors
On Monday, August 11, 2014 10:08:09 PM UTC-7, Jeremy Heiler wrote: On Mon, Aug 11, 2014 at 3:07 PM, Brian Craft craft...@gmail.com javascript: wrote: Two questions, really. I'm running large batch jobs with an agent. The jobs may fail in any number of unanticipated ways (due to user input), so I do a try/catch in the agent, log any errors, and continue with the next job. First question: how to deal with OOM (the Xmx limit, not the OS out of mem)? The try/catch doesn't appear to help, here. The agent dies, and all subsequent jobs never run. Is there some way to prevent or recover from this? Once it has happened, I don't think there's much you can do to save the process. I'd suggest that you figure out where you're improperly managing memory by throwing a profiler at it. Profiling is not going to change user behavior: users can give us inputs too large for their systems. If we can't recover from it, then we need to predict the event and abort. Perhaps we could monitor heap usage in another thread, and shut down the agent if it goes past some fraction. But there doesn't appear to be any mechanism for shutting down an agent. Maybe the agent action could stash the thread id in an atom, and a watcher thread could shut it down somehow. -- 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: handling agent errors
On Tuesday, August 12, 2014 9:59:54 AM UTC-7, Brian Craft wrote: On Monday, August 11, 2014 10:08:09 PM UTC-7, Jeremy Heiler wrote: On Mon, Aug 11, 2014 at 3:07 PM, Brian Craft craft...@gmail.com wrote: Two questions, really. I'm running large batch jobs with an agent. The jobs may fail in any number of unanticipated ways (due to user input), so I do a try/catch in the agent, log any errors, and continue with the next job. First question: how to deal with OOM (the Xmx limit, not the OS out of mem)? The try/catch doesn't appear to help, here. The agent dies, and all subsequent jobs never run. Is there some way to prevent or recover from this? Once it has happened, I don't think there's much you can do to save the process. I'd suggest that you figure out where you're improperly managing memory by throwing a profiler at it. Profiling is not going to change user behavior: users can give us inputs too large for their systems. If we can't recover from it, then we need to predict the event and abort. Perhaps we could monitor heap usage in another thread, and shut down the agent if it goes past some fraction. But there doesn't appear to be any mechanism for shutting down an agent. Maybe the agent action could stash the thread id in an atom, and a watcher thread could shut it down somehow. http://docs.oracle.com/javase/1.5.0/docs/guide/misc/threadPrimitiveDeprecation.html Hm... from this doc it appears that maybe the thing to do is implement a please stop atom that the agent action would check periodically. -- 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: Benchmarking structural sharing
It seems hard to answer in a completely generic fashion. If there's a certain collection of vectors which you'd like to share structure, it may be possible to put a number on the degree of sharing achieved by examining the internals of those vectors. That wouldn't address the issue of intermediate allocations internal to your algorithms, but that might be fine. As for a possible approach to the above, I've just added a function called count-nodes to clojure.core.rrb-vector.debug (the JVM version only) which counts all vector nodes used by a collection of vectors (PV / gvec / RRB). An example from my REPL: (let [vs (mapv (comp vec range) [2048 2048 2048])] [(apply dv/count-nodes (apply fv/catvec vs) vs) (apply dv/count-nodes (reduce into [] vs) vs)]) ;= [203 396] I might tweak the way it works a little (for example, it could take a collection rather than varargs and count internal arrays rather than nodes; the latter change could be beneficial, as tails are just arrays without a node wrapper). Hope this helps. Cheers, Michał On 11 August 2014 14:56, Paul Butcher p...@paulbutcher.com wrote: Is there any way to benchmark the degree of structural sharing achieved by a Clojure algorithm? I'm evaluating two different implementations of an algorithm, one which uses zippers and one which uses rrb-vector. It would be great if there were some way to quantify the degree to which they both achieved (or didn't) structural sharing. -- paul.butcher-msgCount++ Silverstone, Brands Hatch, Donington Park... Who says I have a one track mind? http://www.paulbutcher.com/ LinkedIn: http://www.linkedin.com/in/paulbutcher Skype: paulrabutcher Author of Seven Concurrency Models in Seven Weeks: When Threads Unravel http://pragprog.com/book/pb7con -- 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: RICON CFP open - anyone submitting?
I wanted to submit a talk to share my experience with implementing CRDTs in Clojure and building riak_core-like cluster. But put it aside cause there are still too many unresolved problems and question without proper answers. I talked at local meetup a month ago about deterministic parallel and distributed programming with Clojure. Determinism is quite hot topic now, but not in Clojure community, as I can see. The keynote of that speech was there are many cools things that you can do with Clojure and there are many useful ideas that we can borrow/port from other languages (like Erlang, Haskell, Scala). Nothing to be really proud about in this field (except one notable project - tool for testing network partitions Jepsen, and maybe Avout). In general, it's very interesting to know, who works with sophisticated distributed system? What problems did you face and what solutions do you use to deal with them? CRDTs? Or modern consensus protocols (like Raft)? Work distribution platforms cluster management (like riak_core)? Gossip protocols? Maybe distributed core.async? 2014-08-11 22:03 GMT+03:00 Alex Miller a...@puredanger.com: RICON CFP is open - anyone planning on submitting anything Clojure-related? CFP ends in one week: http://ricon.io/event-details/index.html Event is in Las Vegas, Oct 28-29. -- 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. -- Kind regards, Alexey S. Kachayev, CTO at Attendify.com -- http://github.com/kachayev http://twitter.com/kachayev Skype: kachayev Tel: +380-996692092 -- 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.
