Re: offtopic - where are you come from? (poll)
Hamburg, Germany On Oct 18, 8:22 am, "Alexander Kjeldaas" <[EMAIL PROTECTED]> wrote: > Trondheim, Norway > > 2008/10/18 Brett Morgan <[EMAIL PROTECTED]> > > > > > Sydney, Australia > > > On Sat, Oct 18, 2008 at 3:58 PM, Ande Turner <[EMAIL PROTECTED]> > > wrote: > > > Dunedin, Otago, NEW ZEALAND > > > > 2008/10/18 Craig McDaniel <[EMAIL PROTECTED]> > > > >> also from Atlanta, Georgia > > > -- > > > Brett Morganhttp://brett.morgan.googlepages.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 To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: offtopic - where are you come from? (poll)
I'm from Mexico city but right now in Tokyo Japan. Regards. On Oct 17, 6:27 pm, "Rastislav Kassak" <[EMAIL PROTECTED]> wrote: > Hello Clojurians, > > I think after 1st year of Clojure life it's good to check how far has > Clojure spread all over the world. > > So wherever are you come from, be proud and say it. > > I'm from Slovakia. :) > > RK --~--~-~--~~~---~--~~ 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 To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: offtopic - where are you come from? (poll)
Hubei，China gerry On Oct 17, 5:27 pm, "Rastislav Kassak" <[EMAIL PROTECTED]> wrote: > Hello Clojurians, > > I think after 1st year of Clojure life it's good to check how far has > Clojure spread all over the world. > > So wherever are you come from, be proud and say it. > > I'm from Slovakia. :) > > RK --~--~-~--~~~---~--~~ 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 To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: offtopic - where are you come from? (poll)
Paris, France (but born Montreal, Canada) --~--~-~--~~~---~--~~ 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 To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: offtopic - where are you come from? (poll)
Manila, Phiippines Ray [EMAIL PROTECTED] wrote: > Hubei，China > > gerry > > On Oct 17, 5:27 pm, "Rastislav Kassak" <[EMAIL PROTECTED]> wrote: > > Hello Clojurians, > > > > I think after 1st year of Clojure life it's good to check how far has > > Clojure spread all over the world. > > > > So wherever are you come from, be proud and say it. > > > > I'm from Slovakia. :) > > > > RK --~--~-~--~~~---~--~~ 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 To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Clojure + Terracotta
On Fri, Oct 17, 2008 at 8:01 PM, Luc Prefontaine <[EMAIL PROTECTED]> wrote: > I am not very far from tackling this issue. In our bus messaging system, we > are using Terracotta with some Java components > and it's a matter of weeks before we start to investigate how we can bridge > Clojure and Terracotta. > > A customer asked us about some new functionality today and I see a need to > fill the Terracotta/Clojure gap > somehow. > > I'll comeback toward the end of November with some proposal. > > Any comments Rich about how you would see this integration and what Clojure > semantics you would like to share through Terracotta ? > I might enlarge the scope beyond what we need in our system even if not all > the pieces are delivered in the very short term. > There are lots of potential synergies. I think that one key benefit of using Clojure is that the immutable data structures can be shared, yet read outside of locks. As you know, Terracotta requires shared objects to be accessed under a lock. However, once the object has been propagated, it need not be acceessed under a lock iff it is immutable. This was one of the first things I verified with Terracotta. So, for instance, you can do the normal Terracotta cache thing and put Clojure's persistent data structures in a ConcurrentHashMap shared root. Once you pull one out of the map, you can use it henceforth without locking - a huge benefit IMO. Plus, since the data structures share structure, updates are also efficient. A current hitch, which I am looking to enhance anyway, is that some of the data structures do lazy hash creation with volatile caches. In proc this is no problem, nor out of proc since the hash value is a pure function of the immutable structure value, but I think Terracotta may not be happy with the volatile members. I have already on my todo list moving to incrementally calculated hash values (had to wait for the unification of hash logic with java.util's, now done). Of course, this leaves you with ConcurrentHashMap's last-one-in-wins, no coordinated activity semantics. When that's not good enough, you'll want to try STM refs + transactions. Here too, I think a lot is possible. As I've said, I once had this working, but haven't tracked whether or not all mechanisms I am using are supported by Terracotta. Underneath the STM are all standard Java concurrency things - reentrant locks, wait/notify, java.util.concurrent.atomic stuff etc. To the extent these are supported, it should function correctly right away. That said, there's one aspect of the STM I think could be tweaked for a clustering situation. The only thing that is shared between all transactions is a single CAS for the timestamps. In-proc, that works fine until you get to very heavy micro-transactions, which are a bad idea anyway. On a Terracotta cluster, that CAS will turn into a shared lock, I think, which is much heavier. What you really want is a central getAndIncrement server, since this capability can be done completely with a server-side CAS with no client coordination. Terracotta, being API-free, will want to maintain the illusion that each JVM has its own CAS. If I had time to do Terracotta/Clojure work, I'd probably investigate abstracting out the STM's timestamp generator to allow for a timestamp server for clustered situations. Once you have that, you can make normal locality-of-reference based architectural decisions for the refs, and get concurrency that is scalable strictly on the transactions' degree of ref overlap. Rich --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: offtopic - where are you come from? (poll)
Aarhus, Denmark. -- Karl --~--~-~--~~~---~--~~ 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 To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: offtopic - where are you come from? (poll)
Newcastle UK --~--~-~--~~~---~--~~ 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 To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Clojure's first year
I saw clojure mentioned on LtU and put it in my "to read soon" bookmarks (which I never get around). Then at JAOO 2008, I heard Guy Steele and I think also Kirk Pepperdine mention the language (just as a side remark), and I decided it was time to look again ;-) After seeing Rich's presentation videos I was more excited than I'd ever been about a language. Now, I just want to learn more. Excellent work, Rich, truly innovative! /karl --~--~-~--~~~---~--~~ 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 To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Beginners (and idiomatic Clojure)
This post is intended to start a discussion about how to help beginners (like myself) going in the right direction learning *to actually use* Clojure in real-world programs. The presentation videos on the net are excellent -- they are what convinced my that Clojure is really worth learning, and learning well, too. The homepage is great, it really explains many concepts and important ideas in a concise yet readable manner. Excellent work: The 'theory' part of the documentation is great. (As opposed to so many other languages). However, to be really accessible to newcomers, it would be great with more information on the 'practice'. E.g., a number medium-scale 'real' open-source example programs. Even better if the design rationale and architecture of such application were available as well... Also a wiki on idiomatic Clojure would be really valuable. I am very willing to contribute to all of these to the best of my ability; even if my contribution would be trying, failing and sharing ;-) Rich, any chance you could help out with the 'idiomatic clojure' part? Obviously, your experiences would be most valuable. Apart from Clojure itself, do you have some programs you would be willing to share? Cheers, /krukow --~--~-~--~~~---~--~~ 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 To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: offtopic - where are you come from? (poll)
2008/10/17 Rastislav Kassak <[EMAIL PROTECTED]>: > So wherever are you come from, be proud and say it. Helsinki, Finland! br, S -- () Today is the car of the cdr of your life. /\ http://arc.pasp.de/ --~--~-~--~~~---~--~~ 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 To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
load-string string length limitation
The following fails for me: (load-string (format "(quote (%s))" (nth (iterate #(format "%s%s" % %) "(1 2 3 4)") 13))) java.lang.ClassFormatError: Unknown constant tag 32 in class file user/ eval__2485 (NO_SOURCE_FILE:0) With 12 as the argument to nth, it works. Alexander --~--~-~--~~~---~--~~ 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 To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: load-string string length limitation
On Oct 18, 11:42 am, Alexander Kjeldaas <[EMAIL PROTECTED]> wrote: > The following fails for me: > > (load-string >(format "(quote (%s))" >(nth (iterate #(format "%s%s" % %) "(1 2 3 4)") 13))) > java.lang.ClassFormatError: Unknown constant tag 32 in class file user/ > eval__2485 (NO_SOURCE_FILE:0) > > With 12 as the argument to nth, it works. In moving to ahead-of-time compilation there are now limits to the size of data structures that can be embedded in code, since they have to be included in the class files. In most cases, large data structures can be saved separately and then read, with read. For the case above, which is just the representation of a data literal as a string, I've also added read-string: (read-string (format "(%s)" (nth (iterate #(format "%s%s" % %) "(1 2 3 4)") 13))) The reader is a fine and sufficient tool for reading data structures - there's no need to involve the compiler. load should be reserved for for code from now on. Rich --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Callstack from load-file
Hey all, I had a situation where a source file wouldn't load and the error message was unhelpful: java.lang.IllegalArgumentException: Too many arguments to struct constructor (source-file.clj:0) So, I threw together a quick hack to print the call stack: (defn callstack-str [thrown] (let [stk (new java.io.StringWriter) pw (new java.io.PrintWriter stk)] (. thrown (printStackTrace pw)) (str (. stk (toString) (defn lf [filename] (try (load-file filename) (catch java.lang.Throwable e (print (callstack-str e) As usual, I'm sure there's a better way, so I'd appreciate hearing about it. Jim --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Callstack from load-file
On Oct 18, 9:40 pm, jim <[EMAIL PROTECTED]> wrote: > Hey all, > > I had a situation where a source file wouldn't load and the error > message was unhelpful: > > java.lang.IllegalArgumentException: Too many arguments to struct > constructor (source-file.clj:0) > > So, I threw together a quick hack to print the call stack: > > (defn callstack-str [thrown] > (let [stk (new java.io.StringWriter) > pw (new java.io.PrintWriter stk)] > (. thrown (printStackTrace pw)) > (str (. stk (toString) > > (defn lf [filename] > (try > (load-file filename) > (catch java.lang.Throwable e > (print (callstack-str e) > > As usual, I'm sure there's a better way, so I'd appreciate hearing > about it. > > Jim Hi Jim, The default behavior of the REPL is to show only the exception to avoid too much clutter on the screen. The special variable *e stores the last exception which can be used to see the stack trace. So one way to do this would be: user=> (defn foo [] (/ 1 0)) #=(var user/foo) user=> (foo) java.lang.ArithmeticException: Divide by zero (NO_SOURCE_FILE:0) user=> *e #=(clojure.lang.Compiler$CompilerException. "java.lang.ArithmeticException: Divide by zero (NO_SOURCE_FILE:0)") user=> (.printStackTrace *e) java.lang.ArithmeticException: Divide by zero (NO_SOURCE_FILE:0) at clojure.lang.Compiler.eval(Compiler.java:4117) at clojure.lang.Repl.main(Repl.java:87) Caused by: java.lang.ArithmeticException: Divide by zero at clojure.lang.Numbers.divide(Numbers.java:142) at user.foo__2478.invoke(Unknown Source) at user.eval__2481.invoke(Unknown Source) at clojure.lang.Compiler.eval(Compiler.java:4106) ... 1 more nil user=> Parth --~--~-~--~~~---~--~~ 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 To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: clojure.zip/goto proposal
Hi, Am 16.10.2008 um 23:07 schrieb Meikel Brandmeyer: I'll will mull a bit more about this. But something along the lines of (goto loc some-predicate path) seems like it could do what it want. Ok. The attached patch is what I came up with. It is actually split up in two functions walk-along-and-do and walk-along. (Naming suggestions welcome). So the idea is: I give it a location in the zipper, a predicate to identify the nodes and path, which is basically a sequence of things. (pred node thing) should identify the desired node however. Using this I successfully implemented a two-tree widget in Swing, where selected nodes are moved between the two widgets inserting dependent structure as necessary. Here I also saw the need of a try-walk-along, which returns the last node of the path, which is contained in the tree and the rest of the path, which is missing. So I extracted the walker code and added two callbacks, a found-action and a not-found-action. In the current implementation it only finds the left-most path in a tree, in case the nodes are not unique. The difference to your XML code is, that xml-> allows a different filter for each step. This is not the case here. Sincerely Meikel walk-along.clj Description: Binary data smime.p7s Description: S/MIME cryptographic signature
Re: packaging App (cross-platform) without scripts, only jar
When I try this, I get the following if I try to run the jar: Exception in thread "main" java.lang.NoSuchMethodError: clojure.lang.RT.loadResourceScript(Ljava/lang/Class;Ljava/lang/ String;Z)V This is using the latest stable Clojure and a single source file. --~--~-~--~~~---~--~~ 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 To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
ANN: Clojure Chimp v1.2.0
Dear vimming Clojurians, a new version of Chimp is available. Changes are: - fixed obsolete argument bug for EvalFile - added dw to lookup docstring for word under cursor - added ld to lookup arbitrary docstring - added fd to search for docstrings via find-doc - added pe to print the Exception stored in *e The new version is available via: http://www.vim.org/scripts/script.php?script_id=2348 Sincerely Meikel smime.p7s Description: S/MIME cryptographic signature
Re: offtopic - where are you come from? (poll)
Mumbai, India On Oct 17, 2:27 pm, "Rastislav Kassak" <[EMAIL PROTECTED]> wrote: > Hello Clojurians, > > I think after 1st year of Clojure life it's good to check how far has > Clojure spread all over the world. > > So wherever are you come from, be proud and say it. > > I'm from Slovakia. :) > > RK --~--~-~--~~~---~--~~ 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 To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: offtopic - where are you come from? (poll)
Palm Coast, Florida, USA - Original Message - From: mritun <[EMAIL PROTECTED]> Sent: Saturday 18 October 2008 17:05 To: Clojure Cc: Subject: Re: offtopic - where are you come from? (poll) Mumbai, India On Oct 17, 2:27 pm, "Rastislav Kassak" <[EMAIL PROTECTED]> wrote: > Hello Clojurians, > > I think after 1st year of Clojure life it's good to check how far has > Clojure spread all over the world. > > So wherever are you come from, be proud and say it. > > I'm from Slovakia. :) > > RK --~--~-~--~~~---~--~~ 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 To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Functional graphs
Thanks, Rich, for sticking your head into comp.lang.lisp and pointing me at hash array mapped tries. It just occurred to me that they have another advantage, besides performance, over the binary trees I am currently using for FSet: they make it much easier to implement weak functional maps. And weak functional maps are the critical piece needed for functional graphs. Persistent functional graphs, to my mind, are the Holy Grail of functional data structures. Without them, there's no completely satisfactory functional way to construct arbitrarily interconnected structures, potentially including cycles. For example, a truly general implementation of functional graphs could be used to simulate the heap: you could put all the state in your program into a functional graph; instead of updating a slot of an object, you would build a new graph in which the graph node representing that object had a different edge. It would be slow, certainly, but not combinatorially slow; each update would take time logarithmic in the size of the heap. And it would give you the unique ability to retain past states of the heap for review. Even if it ran 1000 times slower than normal execution, it could still be very useful for debugging. But there are likelier uses than simulating the entire heap. Persistent functional graphs would be useful for things like program transformation, for instance. Any interactive program can benefit from having data structures that make undoing easy. The usual way to construct arbitrary graph structures is with side- effects, of course. An alternative (used in Haskell, for instance) is to represent the graph as a map from node to (map from edge-label to target node). This works, but loses the benefit of garbage collection: even if some node is not reachable from anywhere in the heap other than the map that implements the graph, nor is reachable within the graph from any node that is reachable from elsewhere in the heap, it won't be GCed because it's still in the _domain_ of the map. One workaround for this problem is to GC the graph itself at the user level. This could be done, for instance, by walking it from a known rootset, copying the nodes reached to a new graph, and finally discarding the old graph and keeping the copy. This can work in some situations, but is not satisfactory in general because it requires knowing the correct rootset. Another approach, apparently common in Haskell, is simply to ignore the problem, letting the garbage nodes be collected when the entire graph becomes garbage. This is not a general solution either, obviously. A third approach in Haskell is to simulate the imperative implementation using monads, but let's not go there :) I see only one fully general solution: weak functional maps. Implementing weak functional maps using binary trees is difficult for an obvious reason: because the values in the map are used to navigate the map. If the value at a tree node were to disappear, because the tree node held it weakly and it became garbage, then when we came to that node while walking the tree, we wouldn't know whether to go left or right. It's conceivable that the tree could be fixed up somehow, but I haven't yet worked out how to do it and it's clear that it's going to be a royal PITA, if indeed it's possible at all. HAMTs do not have this problem: navigation of the trie is controlled entirely by the hash code for the value being looked up. Implementing weak functional maps using HAMTs seems quite doable. You might want to think about doing this for Clojure. It seems possible that functional graphs would enable Clojure programs to read and update fewer refs, which could be desirable in some cases. (I don't think I'll convert FSet to using HAMTs anytime soon, though I'm definitely more motivated now; there are things I would already like to use functional graphs for.) -- Scott --~--~-~--~~~---~--~~ 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 To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Multiple indexing for vectors/maps
Sorry if this has been asked before, but I couldn't find anything on it. If I have: (def A [ [ 1 2 3 ] [ 4 5 6 ] ] ) then if I want to access a specific element, I have to do: ((A 1) 1) -or- (get (get A 1) 1) I could make a macro for this of course, but I'd kind of like to change the call semantics for vectors/maps to allow (A 1 1), perhaps something like: (myvec index &more) -> (if more (apply (myvec index) more), (get myvec index)) I don't think adding this should conflict with any existing code, though I did notice that "get" currently accepts and apparently ignores one extra parameter. This seem like a reasonable feature request? --~--~-~--~~~---~--~~ 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 To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Clojure + Terracotta
Ok, I'll digest this in the next couple of weeks and have a look more closely at Clojure code and Terracotta's capabilities. I have a non-linear thinking process so it helps to have some early goals. I'll create some prototype setup here to help identify issues and run some basic tests. Thank you, Luc On Sat, 2008-10-18 at 08:50 -0400, Rich Hickey wrote: > On Fri, Oct 17, 2008 at 8:01 PM, Luc Prefontaine > <[EMAIL PROTECTED]> wrote: > > I am not very far from tackling this issue. In our bus messaging system, we > > are using Terracotta with some Java components > > and it's a matter of weeks before we start to investigate how we can bridge > > Clojure and Terracotta. > > > > A customer asked us about some new functionality today and I see a need to > > fill the Terracotta/Clojure gap > > somehow. > > > > I'll comeback toward the end of November with some proposal. > > > > Any comments Rich about how you would see this integration and what Clojure > > semantics you would like to share through Terracotta ? > > I might enlarge the scope beyond what we need in our system even if not all > > the pieces are delivered in the very short term. > > > > There are lots of potential synergies. I think that one key benefit of > using Clojure is that the immutable data structures can be shared, yet > read outside of locks. As you know, Terracotta requires shared objects > to be accessed under a lock. However, once the object has been > propagated, it need not be acceessed under a lock iff it is immutable. > This was one of the first things I verified with Terracotta. > > So, for instance, you can do the normal Terracotta cache thing and put > Clojure's persistent data structures in a ConcurrentHashMap shared > root. Once you pull one out of the map, you can use it henceforth > without locking - a huge benefit IMO. Plus, since the data structures > share structure, updates are also efficient. A current hitch, which I > am looking to enhance anyway, is that some of the data structures do > lazy hash creation with volatile caches. In proc this is no problem, > nor out of proc since the hash value is a pure function of the > immutable structure value, but I think Terracotta may not be happy > with the volatile members. I have already on my todo list moving to > incrementally calculated hash values (had to wait for the unification > of hash logic with java.util's, now done). > > Of course, this leaves you with ConcurrentHashMap's last-one-in-wins, > no coordinated activity semantics. When that's not good enough, you'll > want to try STM refs + transactions. Here too, I think a lot is > possible. As I've said, I once had this working, but haven't tracked > whether or not all mechanisms I am using are supported by Terracotta. > Underneath the STM are all standard Java concurrency things - > reentrant locks, wait/notify, java.util.concurrent.atomic stuff etc. > To the extent these are supported, it should function correctly right > away. > > That said, there's one aspect of the STM I think could be tweaked for > a clustering situation. The only thing that is shared between all > transactions is a single CAS for the timestamps. In-proc, that works > fine until you get to very heavy micro-transactions, which are a bad > idea anyway. On a Terracotta cluster, that CAS will turn into a shared > lock, I think, which is much heavier. What you really want is a > central getAndIncrement server, since this capability can be done > completely with a server-side CAS with no client coordination. > Terracotta, being API-free, will want to maintain the illusion that > each JVM has its own CAS. If I had time to do Terracotta/Clojure work, > I'd probably investigate abstracting out the STM's timestamp generator > to allow for a timestamp server for clustered situations. > > Once you have that, you can make normal locality-of-reference based > architectural decisions for the refs, and get concurrency that is > scalable strictly on the transactions' degree of ref overlap. > > Rich > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Multiple indexing for vectors/maps
On Oct 19, 3:12 am, kwatford <[EMAIL PROTECTED]> wrote: > Sorry if this has been asked before, but I couldn't find anything on > it. > If I have: (def A [ [ 1 2 3 ] [ 4 5 6 ] ] ) > then if I want to access a specific element, I have to do: > ((A 1) 1) -or- (get (get A 1) 1) get-in is probably what you are looking for. user=> (get-in A [1 1]) 5 There is also, update-in and assoc-in. Parth > I could make a macro for this of course, but I'd kind of like to > change the call semantics for vectors/maps to allow (A 1 1), perhaps > something like: > (myvec index &more) -> (if more (apply (myvec index) more), (get myvec > index)) > > I don't think adding this should conflict with any existing code, > though I did notice that "get" currently accepts and apparently > ignores one extra parameter. > > This seem like a reasonable feature request? --~--~-~--~~~---~--~~ 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 To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
