Re: terracotta?
I don't think it every is going to scale. MVCC/TL2 based STM designs rely on a central clock, so if you can update the clock in 0.1 ms on all machines, the maximum throughput is 1/0.0001 = 10.000 transactions/second... no matter how many machines you throw at it. Even on a single machine the central clock can cause scalability problems (10/20M transactions/second and this will degrade when you throw more cores at it). This is one of the reasons I dropped the TL2 approach for Multiverse and switched over to the SkySTM model (with some magic of my own) that doesn't relied as much on a central mechanism. On Jul 11, 6:50 pm, scx mark_addle...@bigfoot.com wrote: hi -- i've seen paul standig's work with clojure + terracotta. wondering if anyone has continued his work? -- 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
Identity and equality for protocols
Dear all,
After playing a bit with protocols I found this (which seems odd to me):
(All of this on clojure-1.2.0-master-SNAPSHOT, downloaded with lein - i
don't know how recent it is)
user (defprotocol Foo (foo [x] )) ; We define a protocol Foo
user (def bar {:foo Foo}) ; We hide it in a record
#'user/bar
user (= (:foo bar) Foo) ; It's still equal to itselffrom
true
user (extend Object (:foo bar) {:foo (fn [x] :bar)}) ; We extend it
nil
user (foo 5) ; It works
:bar
user (= (:foo bar) Foo) ; it's not equal to itself anymore
false
By the way, if you look at the extenders of each:
user (extenders (:foo bar))
nil
user (extenders Foo)
(java.lang.Object)
Foo is extended but not its copy.
Is it what it is supposed to do?
Best regards,
Nicolas.
--
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: Identity and equality for protocols
Hi,
On Jul 12, 10:44 am, Nicolas Oury nicolas.o...@gmail.com wrote:
After playing a bit with protocols I found this (which seems odd to me):
(All of this on clojure-1.2.0-master-SNAPSHOT, downloaded with lein - i
don't know how recent it is)
user (defprotocol Foo (foo [x] )) ; We define a protocol Foo
user (def bar {:foo Foo}) ; We hide it in a record
#'user/bar
user (= (:foo bar) Foo) ; It's still equal to itselffrom
true
user (extend Object (:foo bar) {:foo (fn [x] :bar)}) ; We extend it
nil
user (foo 5) ; It works
:bar
user (= (:foo bar) Foo) ; it's not equal to itself anymore
false
By the way, if you look at the extenders of each:
user (extenders (:foo bar))
nil
user (extenders Foo)
(java.lang.Object)
Foo is extended but not its copy.
Is it what it is supposed to do?
I think this is the expected way. Since clojure emphasises
immutability you don't modify a Protocol by extending it to some type,
instead you get back a new version of it extending to the type.
Multimethods work similarly, IIRC.
Your previously stored version of the protocol is the old one, which
is not extended. Hence the nil on the extenders call. (foo 5) however
sees the new protocol and hence does the right thing.
This is backed solely by a gut feeling of mine, but I would not be
surprised if it were close to the truth.
Sincerely
Meikel
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Identity and equality for protocols
On 12 July 2010 10:44, Nicolas Oury nicolas.o...@gmail.com wrote: Is it what it is supposed to do? I think so. The reason why this happens is that the Var backing the protocol holds an immutable map, which extend modifies with alter-var-root; the copy has the old version. You're able to add an implementation of the protocol through the copy, because a protocol descriptor map holds a reference to the protocol-backing Var; that is always the same Var object, even if the value behind it changes, so this part of the copy never becomes invalidated. I also think that this is an implementation detail which shouldn't be relied upon... A protocol defined in a namespace is, to me, a sort of a permanent fixture in said namespace, so this doesn't bother me at all. Sincerely, Michał -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure on BEAM
On Jul 11, 11:55 am, stewart setor...@gmail.com wrote: Hi All, Has anybody considered implementing Clojure on BEAM. Are there any works or current attempts currently available? In your view where are the real trip ups for this to happen. Instead you should take a look at Erjang /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 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: Identity and equality for protocols
Ok. I understand.
So, if you want to do some programming that generates insances, it should be
done with symbols, at the macro-level?
On Mon, Jul 12, 2010 at 10:01 AM, Meikel Brandmeyer m...@kotka.de wrote:
Hi,
On Jul 12, 10:44 am, Nicolas Oury nicolas.o...@gmail.com wrote:
After playing a bit with protocols I found this (which seems odd to me):
(All of this on clojure-1.2.0-master-SNAPSHOT, downloaded with lein - i
don't know how recent it is)
user (defprotocol Foo (foo [x] )) ; We define a protocol Foo
user (def bar {:foo Foo}) ; We hide it in a record
#'user/bar
user (= (:foo bar) Foo) ; It's still equal to itselffrom
true
user (extend Object (:foo bar) {:foo (fn [x] :bar)}) ; We extend it
nil
user (foo 5) ; It works
:bar
user (= (:foo bar) Foo) ; it's not equal to itself anymore
false
By the way, if you look at the extenders of each:
user (extenders (:foo bar))
nil
user (extenders Foo)
(java.lang.Object)
Foo is extended but not its copy.
Is it what it is supposed to do?
I think this is the expected way. Since clojure emphasises
immutability you don't modify a Protocol by extending it to some type,
instead you get back a new version of it extending to the type.
Multimethods work similarly, IIRC.
Your previously stored version of the protocol is the old one, which
is not extended. Hence the nil on the extenders call. (foo 5) however
sees the new protocol and hence does the right thing.
This is backed solely by a gut feeling of mine, but I would not be
surprised if it were close to the truth.
Sincerely
Meikel
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with
your first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.comclojure%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 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 on BEAM
This is not Clojure: http://github.com/rvirding/lfe Are there any works or current attempts currently available? -- 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: CCW zombie error markers
Hi Lee, Please note that ccw also has a user ml (for an historical reason, it has a name which does not reflect the current name of the project): clojuredev-us...@googlegroups.com Anyway: 2010/7/11 Lee Spector lspec...@hampshire.edu I'm using Eclipse/Counterclockwise and on a couple of occasions have had errors (e.g. once with a java.lang.IllegalArgumentException) that produce an error marker (a red circle with a white x in the left margin) that won't go away when the error is fixed, or even when closing/reopening the document or quitting/restarting Eclipse. Is there some simple way to clear these that I'm missing? I'm new to Eclipse but have tried to find this in the documentation or via web searches... but to no avail, and I have the feeling that I must be missing something obvious. The quick answer: Project clean The long answer: The problem/error markers can only appear when there is an active REPL for the project. When there is an active REPL for the project, every time you'll save a file, the whole project will be recompiled in the background (using the active REPL for running the (compile ..) commands). If there are compilation errors, they will be reported as error markers in the right place (file/line). If you fix the error, you must still have a running REPL, and when you save the file, the markers are first deleted, then the project is compiled, etc. HTH, -- Laurent Actually I did find one way to remove these things, but it's a weird pain: quit delete workspace/.metadata/.plugins/org.eclipse.core.resources/.projects/projectname/.markers relaunch clean run (see http://wiki.objectstyle.org/confluence/display/WOL/Sticky+WOD+error+markers+will+not+go+away ) This seems like a workaround for a rare, pathological situation, but I've gotten into this situation twice in two days with CCW, so I'm guessing that I'm either missing the simpler, normal way to clear these things or maybe the CCW/Clojure is creating a pathological situation more than other Eclipse configurations (but more likely the former). Any pointers would be appreciated. -- Lee Spector, Professor of Computer Science School of Cognitive Science, Hampshire College 893 West Street, Amherst, MA 01002-3359 lspec...@hampshire.edu, http://hampshire.edu/lspector/ Phone: 413-559-5352, Fax: 413-559-5438 Check out Genetic Programming and Evolvable Machines: http://www.springer.com/10710 - http://gpemjournal.blogspot.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.comclojure%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 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
Maps with functions for default values
Is there a way to set up a map so that there is a default function which depending on the key returns a value if one is not present in the map. I can obviously write this with a deftype and have it implement Associative, Seqable, etc. so it behaves like a built-in map, but just wondering if there was a way to get this out-of-the-box. Thanks, Aria -- 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: CCW zombie error markers
Thanks Laurent. FWIW I had looked for the ccw-specific mailing list but not found it... perhaps that should be advertised a bit more (e.g. I don't see it mentioned on http://code.google.com/p/counterclockwise/). Thanks for pointing it out to me. On the specific issue: I had turned off build automatically because I preferred to be able to save without triggering anything else. Maybe that contributed to the problem. However, Project Clean did NOT resolve the problem by itself. The most recent instance of the problem DID clear up, however, after clicking the Remove Launch and/or Remove All Terminated Launches buttons above the REPL. I have no idea what those things really mean (what's a launch anyway, and what's it being removed from?), but in my desperate clicking I tried them and the zombie markers went away. Thanks, -Lee On Jul 12, 2010, at 9:51 AM, Laurent PETIT wrote: Hi Lee, Please note that ccw also has a user ml (for an historical reason, it has a name which does not reflect the current name of the project): clojuredev-us...@googlegroups.com Anyway: The quick answer: Project clean The long answer: The problem/error markers can only appear when there is an active REPL for the project. When there is an active REPL for the project, every time you'll save a file, the whole project will be recompiled in the background (using the active REPL for running the (compile ..) commands). If there are compilation errors, they will be reported as error markers in the right place (file/line). If you fix the error, you must still have a running REPL, and when you save the file, the markers are first deleted, then the project is compiled, etc. -- Lee Spector, Professor of Computer Science School of Cognitive Science, Hampshire College 893 West Street, Amherst, MA 01002-3359 lspec...@hampshire.edu, http://hampshire.edu/lspector/ Phone: 413-559-5352, Fax: 413-559-5438 Check out Genetic Programming and Evolvable Machines: http://www.springer.com/10710 - http://gpemjournal.blogspot.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: SAFETY CRITICAL SOFTWARE
I think the first, most important, step is to identify a JVM which is designed for safety critical systems. The only JVM I know of that has even bothered to consider SC Java is Atego's (formerly Aonix) UltraPERC, and I don't think they've qualified it to the level you seek. To get qualified for Safety Critical, you need to strip a lot of what Java is to remove the uncertainty in execution (namely multi-threading and garbage collection). For Clojure to achieve that would require top- to-bottom redesign and rewrite, and likely would have to directly compile to machine code. It would have to lose many of the dynamic typing features that make it what it is. Basically, there's no way for Clojure to be Safety Critical. Sorry! -Travis On Jul 11, 8:59 pm, lprefonta...@softaddicts.ca wrote: Hmm.. I would give it a try for a critical app. We have sever apps in Clojure running for months non-stop now without unscheduled down time. Clojure has not been a source of problems, we had more problems with the customer networks and other site specific conditions. We run redundant components by up to now it's been mostly used to safely upgrade the system while it's running or cope with the bad network conditions mentioned above. However meeting a paper certification is a significant process and has nothing to do with the readiness of the language itself. Clojure runs on the JVM (or CLR) it certainly has an impact on the certification. If I remember Sun had some disclaimers about what Java and the JVM should be used for. I would certainly board on a plane with computers running Clojure on properly tuned environments. Of course the wings may still fall apart : Luc P. Neil Mock neilm...@gmail.com wrote .. call me crazy but I think any organization planning to use clojure as such should be able to independently evaluate it's readiness for the proposed task(s). On Jul 10, 2010, at 10:55 PM, David Blubaugh davidblubaugh2...@gmail.com wrote: To All, I was wondering if it was possible to utilize Clojure for safety critical software development. This would include development for guidelines within both DO-178B level A and DO-254 certification. I am also wondering if it was possible to utilize Clojure for space-borne applications?? Also is it possible to utilize Clojure for programming microcontrollers?? Thanks, David Blubaugh -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Maps with functions for default values
On 12 Jul 2010, at 16:13, aria42 wrote: Is there a way to set up a map so that there is a default function which depending on the key returns a value if one is not present in the map. I can obviously write this with a deftype and have it implement Associative, Seqable, etc. so it behaves like a built-in map, but just wondering if there was a way to get this out-of-the-box. I imagine fnmap would make this easy to do: http://richhickey.github.com/clojure-contrib/fnmap-api.html -Steve -- 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
(very simple) Type classes in Clojure
Dear all, I have written a small experimentation about type-classes in Clojure 1.2, build above protocols. It's not a proposal, not even a good idea, just an idea that was easy enough to try. It allows to give some rules to Clojure in order to extend Protocols when some protocol/interfaces are satisfied/implemented. For example, this (totally pointless) example works (at least on my computer): (defprotocol Incr (increment [x])) (defprotocol Decr (decrement [x])) (defprotocol Neg (negate [x])) Then, you can create a rule (type-classes/= (Incr Neg) () ; ( protocols needed) (intefraces needed) for the rule to apply Decr (decrement [x] (negate (increment (negate x) After that, calling decrement on any instance of both Incr and Neg, would create an extension of Decr for that type (only at the first call) and call it. (Doing that AOT is more or less planned) I have a bigger (and as much pointless) example in the repository. So the code and a bigger example can be found at: http://nicolasoury.repositoryhosting.com/trac/nicolasoury_type-classes/wiki Comments, suggestions and idea for better examples are very much welcome. Best regards, Nicolas. -- 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: ClojureDocs.org
On Sun, Jul 11, 2010 at 4:10 PM, zkim zachary@gmail.com wrote: If you're willing to continue the discussion, I'd like to keep this going (maybe another thread?). As I'm writing this I'm getting the feeling that I'm not quite articulating my thoughts well, and I think further discussion will help me to flesh them out. Actually I was hoping it would spark a discussion with the maintainers and contributors of those projects. I haven't done any web development myself in years, I just know it always bothers me to hear It doesn't work or It's not ready about my own projects without more details. -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
Structure of complex ex-OOP programs
Okay, I have a fairly complex app I'm thinking of converting to clojure as a way to learn how clojure works. Here's how the basic structure of the app works: 1) Load a SVG (XML) file and parse it into a format usable by the program (convert strings to numbers, etc) 2) Persist the in-memory version of the file to the disk in a binary format that can be quickly loaded again 3) Perform some processing on the file (rotations, scaling, pasting between SVG documents) 4) Render the document using Java Graphics2D The current version of this code is written in Python, and is organized in the standard OOP form. Each element (e.g. Polygons, paths, images) are given a separate object that must implement a render() method. Loading, unloading, and persistence is all co-ordinated by the base object that calls child elements implementations of each function. So here's my question. In converting this to a clojure program, I see two methods: 1) OOP method where I have a separate protocol for each element 2) I divide the code into parts: a renderer, a persistance layer, a xml parser, then have multi-methods to override the behavior of each part. For instance: (defmethod render :image [context] (...)) (defmethod render :polygon [context] (...)) (defmethod render :path [context] (...)) (defmethod render :group [context] (...)) It's basically a question of grouping functions by the data or by the function they perform. Do I group all the render functions together or group all the polygon functions together? Timothy -- “One of the main causes of the fall of the Roman Empire was that–lacking zero–they had no way to indicate successful termination of their C programs.” (Robert Firth) -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Structure of complex ex-OOP programs
1) would be more:
- define a protocol for each kind of function (render, serialize...)
- define a deftype/defrecord for each type of element, and make them extend
the protocol
It's not that different from 2. (protocol, as far as I understand, are
multimethod whose dispatch function is the type of first arg)
More choice:
3)
(defn render rendering
[obj context]
(case (:shape obj)
:line (render-line obj context)
.
)
with obj being a PersistentHashMap {:shape :line :begin {:x :y} ...}
The right choice depends somehow of taste.
I would do for 1, but other would do differently I think.
Good thing with a multi-paradigm language.
--
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: Structure of complex ex-OOP programs
1. would be my favorite too. Multimethods are fine too, but may be a bit slow. 3. is the same as 2. while avoiding multimethods. On Mon, Jul 12, 2010 at 10:26 PM, Nicolas Oury nicolas.o...@gmail.com wrote: I would do for 1, but other would do differently I think. Good thing with a multi-paradigm language. -- Moritz Ulrich Programmer, Student, Almost normal Guy http://www.google.com/profiles/ulrich.moritz -- 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: Structure of complex ex-OOP programs
On Jul 12, 1:26 pm, Nicolas Oury nicolas.o...@gmail.com wrote: The right choice depends somehow of taste. chipping in two cents: try to predict what kinds of change your system needs to support, and use that to help choose a style. (a) fp style: easy to add new operations on a fixed set of data types. (cf. pattern matching styles in ocaml, haskell, etc.) (b) oo style: easy to add new data types implementing a fixed set of operations. (c) in between style: something that purports to cut the gordian knot in the expression problem? typeclasses? multimethods? whatever crazy stuff scala does? or something else besides? 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: ClojureDocs.org
The site looks very nice, I especially like the find real world examples functionality and the fact that it collects documentation for common non-core libraries as well. I made my own cheat sheet for private use over the past month or so, core functions only. It's at the 80% stage, I don't expect it will ever be 100%, but I have found it useful: http://faustus.webatu.com/clj-quick-ref.html It is loosely inspired by the Ruby QuickRef http://www.zenspider.com/Languages/Ruby/QuickRef.html which I found tremendously useful. The experience has told me that good documentation is a lot of work, and I can see why people writing books want to get paid for their efforts :) So I appreciate the community aspect of your site. I expect that managing a community is just as much (or more) of a challenge than the technical aspects, but if you can get it working it can scale in a way that no private effort can. On Jul 11, 11:23 am, zkim zachary@gmail.com wrote: (3) +1 on making it very easy to see which version of an API you are looking at. This should be both at the top level (some way to say show me 1.1) and on a per-var basis, reading the :added metadata. This is something I'd like to discuss in-depth on the new google group (http://groups.google.com/group/clojuredocsorg). It is something that I'd really like to see, but I haven't worked through the implementation details in my head (multiple versions stored per var vs. diffs stored, UI around this, etc). I would like to see this as well. In the short term I think the way the official doc does it, just listing the Since Clojure x.y metadata tag, works well enough. I can't really see the benefit of listing the source code for the function so prominently - in most cases I look up documentation to find out how to use a function, not how to implement it. I would suggest leaving it in a collapsed state initially. I am missing some form of logical grouping, like operations on vectors. Much of the benefit I get from using my own cheat sheet rather than the official documentation is that I can zoom in on for example the dozen or so operations that apply to agents (under Concurrency in my cheat sheet) rather than wading through hundreds of names that may or may not be relevant to what I am looking for. All in all a great initiative, and I hope there will be room for some level of grouping beyond alphabetically and by namespace. Regards jf -- 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: ClojureDocs.org
On Jul 13, 12:25 am, j-g-faustus johannes.fries...@gmail.com wrote: I made my own cheat sheet for private use over the past month or so, core functions only. It's at the 80% stage, I don't expect it will ever be 100%, but I have found it useful: http://faustus.webatu.com/clj-quick-ref.html Looks like the hosting provider put my Clojure cheat sheet under review, I guess they found it suspicious... :) According to their website under review page, it should be available in a few hours. If not, and if anyone is interested in seeing it, I can probably find somewhere else to put it. jf -- 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
A DSL for writing scripts which have restricted memory and cpu usage
I want to provide a scripting api into my program which runs server side, but don't want my users to completely use up the resources on my server. Are there any ways to restrict how many resources a user has access to? Perhaps create a sandboxed environment per user which they can execute their scripts in which is limited? Thank you for any help you can give. -- 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: A DSL for writing scripts which have restricted memory and cpu usage
Are there any ways to restrict how many resources a user has access to? If you use Linux, you see /etc/security/limits.conf. -- 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: A DSL for writing scripts which have restricted memory and cpu usage
On Jul 13, 1:36 am, ngocdaothanh ngocdaoth...@gmail.com wrote: Are there any ways to restrict how many resources a user has access to? If you use Linux, you see /etc/security/limits.conf. That is useful and I will keep that in mind, however I was thinking of application users, so they would login to the clojure application and run scripts on it. Can they somehow be restricted? I will definitely consider running the app under a seperate user and putting limits on that user as a whole. -- 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: Proposal: Digest
Hi David, David Soria Parra d...@php.net writes: any feeback on this so far? A typical example would be: (digest-to-str (digest hello world :algorithm SHA-1)) digest-to-str is a bit misleading as hexadecimal digits are not the only way you can represent a digest as a string: base 64 and base 32 are also quite common. Additionally, named arguments are typically useful when the arguments are optional or there's a lot of them. I'd probably just drop the :algorithm keyword, since you're always going to need to specify it. Something important that you don't seem to be covering is incremental digests (using the .update method). I'm not sure what the best way to expose this is (push or pull: update-digest vs passing in a lazy seq), but most non-trivial uses of digests are going to want to be able to do things incrementally. In my experience it's very bad to encourage people to load full datasets into memory where it's unnecessary (even just the simple cases of sha1summing a file) -- that road leads to brittle applications and OutOfMemoryErrors. One might argue that this is just a convenience for trivial string and byte array usage and that anybody doing it incrementally should use the raw MessageDigest API, but at the end of the day, if somebody provides some sort of Clojure API many people are going to try and shoehorn all their uses into it. Alex -- 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
DataLog
Has anyone used clojure.contrib.Datalog for anything serious? What kind of problem did you run into if any? What is the performance like? Is there a sweet spot beyond that it's completely in memory only? Thanks, -- Omnem crede diem tibi diluxisse supremum. -- 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
faster flatten?
Another flatten thread! Sorry..
Hello all, before I realized there was a flatten in the master branch
(and before I looked at contrib) I wrote this pretty standard code:
(defn my-flatten [coll]
(lazy-seq
(when-let [coll (seq coll)]
(let [x (first coll)]
(if (sequential? x)
(concat (my-flatten x) (my-flatten (next coll)))
(cons x (my-flatten (next coll
(There's very similar versions on the boards. I'm not claiming this is
anything amazing or unique.)
It's not as elegant as what's in core, but in my micro benchmarks (ran
on my laptop; 2.26 core 2 and 4gb ram) it seems to perform a bit
better, _especially_ in the already flattened case. It behaves just
like core/flatten except that it doesn't return an empty list when
passed a map or set, it just returns whatever you gave it but with the
top level converted to a seq. I'm pretty much a clojure noob, so are
there any hidden detractors of this implementation as opposed to the
version introduced in 1.2?
Also, quick note, if you swap the call to sequential? with seqable?
from contrib/core, it flattens maps and sets like you'd expect as
well.
Here is how it looks
user= (my-flatten #{1 {2 3} 4 [5 6 7 #{8 {9 10}}]})
(1 2 3 4 5 6 7 9 10 8)
And for the micro-benchmarks (using sequential?):
user= (time (dotimes [_ 1e7] (flatten [1 2 3 4])))
Elapsed time: 14,661.592 msecs
nil
user= (time (dotimes [_ 1e7] (my-flatten [1 2 3 4])))
Elapsed time: 922.268 msecs
nil
user= (time (dotimes [_ 1e7] (flatten [1 [2 [3 [4 [5 [6 [7 [8]
[[[9]]] 10 [11] 12 [13 14 [15])))
Elapsed time: 18,147.959 msecs
nil
user= (time (dotimes [_ 1e7] (my-flatten [1 [2 [3 [4 [5 [6 [7 [8]
[[[9]]] 10 [11] 12 [13 14 [15])))
Elapsed time: 6,088.914 msecs
nil
user= (time (dotimes [_ 1e7] (flatten [[1 2 3 4 5 6 7 8 9 10]])))
Elapsed time: 11,696.693 msecs
nil
user= (time (dotimes [_ 1e7] (my-flatten [[1 2 3 4 5 6 7 8 9 10]])))
Elapsed time: 1,533.983 msecs
nil
Thoughts?
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Atomic execution of a SELECT and UPDATE
To learn Clojure, I'm writing a system that could be compared to fold...@home. I have a database table of jobs that need to be done, where each row has an id, some data, and a status. The server that issues these jobs to clients is multi-threaded, and I want to ensure that it never issues the same job to two clients. I do a SELECT on the table to get the id and the data, and then an UPDATE to mark the row with that id as being checked out (the SELECT only grabs a row that has a not-checked-out status). The obvious problem with this, is that another thread might select the same row between the SELECT and UPDATE. I've thought of a few possibilities, but as I'm new to clojure, I was hoping for some advice on which would be best practice, and if I'm making bad assumptions. 1) I add a constraint to my UPDATE, so that it only updates rows that aren't checked out. If the execution of this statement returns a 0, I know there was a collision, and I SELECT a different row until the UPDATE returns 1. I fear that if this cycled once, it would cycle constantly until the server quieted down. 2) I perform all this SQL inside a dosync transaction. The call to JDBC's excuteUpdate would be the very last action, and the only side- effect. As I know very little about the inner workings of dosync, I fear I may be missing something obvious. 3) Perhaps some combination of #2, with autoCommit turned off, and/or rolling the database back to a saved state in the event of failure? Can't quite wrap my head around the best way to do this. Any thoughts or pointers? Help would be very much appreciated. Thanks! Sean -- 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: faster flatten?
Unless you wrap a doall around the calls to flatten and my-flatten, you're not really timing anything relevant. -- 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: DataLog
Hi, On Jul 13, 4:02 am, Wilson MacGyver wmacgy...@gmail.com wrote: Has anyone used clojure.contrib.Datalog for anything serious? What kind of problem did you run into if any? I considered using it, but I could never figure out, how to use it correctly. eg. what predicates are available? Can I define my own? I remember finally hitting a wall, but can't remember what the exact problem was. What is the performance like? Is there a sweet spot beyond that it's completely in memory only? The sweet spot for me are the recursive predicates. I encounter a lot of situations in my day work where I need to define my own predicates. These can be quite ad-hoc. eg. a part number is be part of a certain family of devices. But two part numbers from the same device family might use different microcontrollers, etc. So datalog sounded very interesting to me. Sincerely Meikel -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
