Programmatic reification
Hi all, Is there a good way to reify protocols programmatically, i.e., by passing data structures rather than dropping down into a macro? reify bottoms out in reify*, which doesn't help much. Thanks, Brian -- 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: Programmatic reification
Okay, Brian. I'll bite. :) I don't have the answer for you, but I'm definitely curious what your use case is. Whatcha upto? Steven Deobald -- ⌀ -- nilenso.com On Fri, Apr 24, 2015 at 7:18 PM, Brian Guthrie btguth...@gmail.com wrote: Hi all, Is there a good way to reify protocols programmatically, i.e., by passing data structures rather than dropping down into a macro? reify bottoms out in reify*, which doesn't help much. Thanks, Brian -- 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: Meaning of part of the doc string for `ns-resolve`
Nicola Mometto wrote: It's talking about fully qualified symbols that map to an actual var. E.g user= (ns-resolve *ns* 'clojure.string/join) #'clojure.string/join Ah. Thank you. Ambrose Bonnaire-Sergeant wrote: Could you clarify why you expect that? Thanks, Ambrose Because the namespace is ambiguous in the sentence. It could mean either the namespace that qualifies the symbol or the namespace that is the first argument to `ns-resolve`. Having been confused by this in the past, I've started trying to be explicit when mentioning variables, always using the explicit variable name, and surrounding the name with `markdown quotes`. -- 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] Clojure 1.7.0-beta2
Clojure 1.7.0-beta2 is now available. Try it via - Download: https://repo1.maven.org/maven2/org/clojure/clojure/1.7.0-beta2/ - Leiningen: [org.clojure/clojure 1.7.0-beta2] Regression fixes since 1.7.0-beta1: 1) CLJ-1711 - structmap iterator broken 2) CLJ-1709 - range wrong for step != 1 3) CLJ-1713 - range chunks are not serializable 4) CLJ-1698 - fix reader conditional bugs Additional enhancements to new features since 1.7.0-beta1: 1) CLJ-1703 - Pretty print #error and new public function Throwable-map 2) CLJ-1700 - Reader conditionals now allowed in the REPL 3) CLJ-1699 - Allow data_readers.cljc as well as data_readers.clj For a full list of changes since 1.6.0, see: https://github.com/clojure/clojure/blob/master/changes.md Please give it a try and let us know if things are working (or not)! - 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 --- 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: Strange behaviour of a callable record
It would be great if the ticket has more of the original use case as motivation. On Thursday, April 23, 2015 at 7:00:51 AM UTC-5, Nicola Mometto wrote: I've opened an enhancement ticket with a patch that changes this behaviour btw: http://dev.clojure.org/jira/browse/CLJ-1715 http://www.google.com/url?q=http%3A%2F%2Fdev.clojure.org%2Fjira%2Fbrowse%2FCLJ-1715sa=Dsntz=1usg=AFQjCNF8bkUYdHtcFlrlNYUWyTHsbg5tRQ Alexey Cherkaev writes: Hi, I have encountered the problem with Clojure 1.6.0, when I create the record that implements IFn. For example, (defrecord Foo [x] clojure.lang.IFn (invoke [_ f] (f x))) Than create an instance of this record: (def f (-Foo 10)) And we can call it without a problem: user= (f inc) 11 Yet, if you try to define a value to keep the result, compiler throws an error: user= (def z (f inc)) CompilerException java.lang.AbstractMethodError, compiling:(form-init4774307052978984831.clj:1:8) There is workaround: create local binding first and then assign the value to a global variable: user= (def z (let [temp (f inc)] temp)) #'user/z user= z 11 Is this a bug or I don't fully understand why you can't do that? Cheers, Alexey -- -- 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: What are favored Redis-backed queues?
Also, I should mention that Ruby doesn't have very good built in parallelism support (no true threads when I was using, though this might have changed). As such, I've seen a fair bit of usage of Resque running on a single machine. This would be an insane overcomplication in Clojure given all it's concurrency/parallelism support. So unless you're actually planning to distribute tasks across a cluster, keep it simple and stick to things like the built in Clojure reference types and core.async. Chris -- 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: [ClojureScript] Re: [ANN] Silk, an isomorphic routing library for Clojure and ClojureScript
On Saturday, April 11, 2015 at 8:40:07 AM UTC-7, kovas boguta wrote: On Sat, Apr 11, 2015 at 10:46 AM, Malcolm Sparks mal...@juxt.pro So, in summary, I think it would be useful to have a single 'default' routing library in Clojure that supported isomorphism and was built on protocols, as a minimum. Now that Clojure is attracting so many new users, it would be great to discuss the outstanding differences between all the routing libraries and try to drive some consensus as to what a combined library would include. I'm on board with most of this post (and the Bidi approach in particular), I'm not sure consensus is necessary but I'll throw in my 2 cents. - Please, no more defroute etc macros - Routing should be composable. I want to take some routes and just plug them in at some level of my existing hierarchy. - Middleware should be decoupled from the routes as much as possible. The process for associating middleware to the request should be parallel/complementary to resolving the resource. Maybe middleware is not the best concept to begin with. I'm definitely in agreement that the approach Bidi and Silk have taken is much better than what exists on master in Secretary. Most of the undesirable aspects pointed out about Secretary have largely been resolved on the 2.0.0 branch for Secretary. The other desirable qualities found in Silk (unsure about Bidi) have been in existence in Secretary for sometime but the library was not oriented properly to make those features idiomatic. I do not agree that defroute etc macros should be eliminated from the picture. There is nothing inherently wrong with authoring and/or encouraging their use. It is only an issue when those macros are the only way to use a library effectively. People enjoy using DSL's (until they hit a wall with them) and for small to medium scale projects they are completely appropriate and just as effective as the it's just data style of routing for getting shit done. I will also say the same about middleware. Although I do not like the middleware pattern I do not believe it is worth throwing out the window just because it is not the best concept. It is a familiar pattern and sometimes that familiarity is worth avoiding the friction of learning a something else for some individuals and teams. tl;dr retaining features that people enjoy using and are familiar with is fine so long as there is a composable API underneath it that can be used alternatively. -- 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: What are favored Redis-backed queues?
I think you mean to be asking specifically about *job* queuing using Redis. You don't need anything other than Redis + Carmine to create queues. But obviously, the value of Resque (note spelling) is that it *uses* Redis in a number of non-trivial ways, such that all of the features above are available. There does appear to have been a Clojure port of Resqueue (https://github.com/jxa/resque-clojure) which garnered a bit of attention, but it hasn't been updated in a while, so I don't know what the state of it is. It's worth considering that if you don't *need* something very robust (and depending on your situation), you could just use Redis + Carmine directly to pass messages around (possibly representing jobs), and have workers pull from the message queue. There is nothing else you really need for this; it's quite straight forward. The rub is that you don't get any of the higher level features; if a job dies for instance, there's no way to know about that without building it yourself. It's also worth considering whether a job queue is really the right mode of distributed computing. This area is a real strength of Clojure's, and there are a lot of offerings here. I say this because the offerings are a lot slimmer in Ruby land (at least when I was working with it), and so if you're thinking queues based on prior experience with Ruby, I'd definitely dig a little more to make sure it's the right model for you. It might seem like already having Redis in your system makes it a good goto, but if you're bending the model it'll end up being more work. Some other things to consider: * storm * onyx * quasar (https://github.com/puniverse/quasar) * pulsar (http://docs.paralleluniverse.co/pulsar) Chris -- 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: Programmatic reification
This is a situation where I reach for eval. Construct your reify call as if
you were inside a macro, but instead of returning data from the macro, call
(eval form). The call to reify will be slow (and could cause permgen
problems), but if you wrap the form in a function you can cache the
function and avoid that problem. Something like:
(let [cache (atom {})]
(defn implement-at-runtime [interface-name method-name body]
(if-let [result (@cache [interface-name method-name body])]
(result)
(let [f (eval `(fn []
(reify
~interface-name
(~method-name ~@body]
(swap! cache assoc [interface-name method-name body] f)
(f)
@(implement-at-runtime 'clojure.lang.IDeref 'deref '[this] 42)
;; returns 42
Timothy
On Fri, Apr 24, 2015 at 8:14 AM, Steven Deobald ste...@nilenso.com wrote:
Okay, Brian. I'll bite. :)
I don't have the answer for you, but I'm definitely curious what your use
case is. Whatcha upto?
Steven Deobald -- ⌀ -- nilenso.com
On Fri, Apr 24, 2015 at 7:18 PM, Brian Guthrie btguth...@gmail.com
wrote:
Hi all,
Is there a good way to reify protocols programmatically, i.e., by passing
data structures rather than dropping down into a macro? reify bottoms out
in reify*, which doesn't help much.
Thanks,
Brian
--
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.
--
“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
---
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: Meaning of part of the doc string for `ns-resolve`
I agree about wanting to use the explicit argument name surrounded by markdown quotes in docs. I've definitely started adopting this practice and wish there were conventions around this sort of thing. Without it, doc strings can easily get ambiguous and confusing in how they relate the the actual arguments of the function (in function docs that is). I also try to make it a point to mention each argument of he function in the doc string... -- 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.
Could type function (type X) print nothing?
Hello, Clojure users. I'm a beginner of Clojure, so it could be a dumb question. I'm playing with Apache Storm, and I leave below line to see tuple value when something is wrong. (log-warn Can't transfer tuple - task value is null. tuple type: (type tuple) and information: tuple) log-warn is defined... (ns backtype.storm.log (:require [clojure.tools [logging :as log]])) (defmacro log-warn [ args] `(log/warn (str ~@args))) But it prints like... 2015-04-23T14:46:59.517+0200 b.s.d.worker [WARN] Can't transfer tuple - task value is null. tuple type: and information: Evaluated value of (type tuple) and tuple value (maybe toString()?) doesn't printed. Is this possible? If possible, please let me know what type the tuple can be. Thanks! Regards. Jungtaek Lim (HeartSaVioR) -- 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: Could type function (type X) print nothing?
(str nil) = (type nil) = nil (str (type nil)) = Rather than use `str`, try using `pr-str` to get a more accurate representation of the data: (pr-str nil) = nil - James On 25 April 2015 at 03:23, 임정택 kabh...@gmail.com wrote: Hello, Clojure users. I'm a beginner of Clojure, so it could be a dumb question. I'm playing with Apache Storm, and I leave below line to see tuple value when something is wrong. (log-warn Can't transfer tuple - task value is null. tuple type: (type tuple) and information: tuple) log-warn is defined... (ns backtype.storm.log (:require [clojure.tools [logging :as log]])) (defmacro log-warn [ args] `(log/warn (str ~@args))) But it prints like... 2015-04-23T14:46:59.517+0200 b.s.d.worker [WARN] Can't transfer tuple - task value is null. tuple type: and information: Evaluated value of (type tuple) and tuple value (maybe toString()?) doesn't printed. Is this possible? If possible, please let me know what type the tuple can be. Thanks! Regards. Jungtaek Lim (HeartSaVioR) -- 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: [ANN] Clojure 1.7.0-beta2
Awesome. Just tested it on our API and working well. Looking forward to a more in depth testing session! - Matt On Friday, April 24, 2015 at 2:27:40 PM UTC-4, Alex Miller wrote: Clojure 1.7.0-beta2 is now available. Try it via - Download: https://repo1.maven.org/maven2/org/clojure/clojure/1.7.0-beta2/ - Leiningen: [org.clojure/clojure 1.7.0-beta2] Regression fixes since 1.7.0-beta1: 1) CLJ-1711 - structmap iterator broken 2) CLJ-1709 - range wrong for step != 1 3) CLJ-1713 - range chunks are not serializable 4) CLJ-1698 - fix reader conditional bugs Additional enhancements to new features since 1.7.0-beta1: 1) CLJ-1703 - Pretty print #error and new public function Throwable-map 2) CLJ-1700 - Reader conditionals now allowed in the REPL 3) CLJ-1699 - Allow data_readers.cljc as well as data_readers.clj For a full list of changes since 1.6.0, see: https://github.com/clojure/clojure/blob/master/changes.md Please give it a try and let us know if things are working (or not)! - 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 --- 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] Clojure 1.7.0-beta2
Thanks David! Instaparse was using some internals of the reader, which changed for reader conditionals, but has subsequently been patched. On Friday, April 24, 2015 at 2:06:01 PM UTC-5, David McNeil wrote: I did a real quick test on one of our projects. I had to upgrade to the latest compojure (seems the old version used a version of instaparse that wouldn't compile) but after that it seemed to work and was noticably faster. -David -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- 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] Clojure 1.7.0-beta2
I did a real quick test on one of our projects. I had to upgrade to the latest compojure (seems the old version used a version of instaparse that wouldn't compile) but after that it seemed to work and was noticably faster. -David -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- 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: Programmatic reification
On Fri, Apr 24, 2015 at 10:14 AM, Steven Deobald ste...@nilenso.com wrote: I don't have the answer for you, but I'm definitely curious what your use case is. Whatcha upto? I've become a firm believer in using protocols to encapsulate operations with side effects, but I don't know of any good test-framework-agnostic mocking or stubbing frameworks that work with them. I don't care much for interaction-based (mocking) tests anyway, really, and reification is simple enough that I don't think sugar for stubs buys you much. But it seemed like an open niche and a fun project. If I'm wrong and such a library does exist, please let me know. The library I'm working on doesn't attempt to perform any var replacements, and it doesn't introduce any new syntax; it's simply a mechanism for building fake versions of protocols, with full or partial implementations, that can be passed into functions that require them, and whose state (e.g., the set of calls they've received) can be subsequently inspected. I'd prefer to avoid macros entirely, except that I don't know of any other way to reify on demand. Release coming shortly. Cheers, Brian -- 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.
What are favored Redis-backed queues?
I'm looking at this old post from Github, that lists the features they were looking for in a message queue: - Persistence - See what's pending - Modify pending jobs in-place - Tags - Priorities - Fast pushing and popping - See what workers are doing - See what workers have done - See failed jobs - Kill fat workers - Kill stale workers - Kill workers that are running too long - Keep Rails loaded / persistent workers - Distributed workers (run them on multiple machines) - Workers can watch multiple (or all) tags - Don't retry failed jobs - Don't release failed jobs https://github.com/blog/542-introducing-resque They ended up creating Rescue, and using Redis in the background. Lately I've been looking at Carmine, but I'm wondering, what are some of the queues that people are using with Clojure, in particular, those using Redis? (Since the subject is potentially immense, I figure I should limit conversation to Redis. I am already using Redis in production, so for me anything using Redis is easy to add in.) -- 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] closp 0.1.11 and closp-crud 0.1.0
Yesterday I release a new version of closp which includes closp-crud. You can find the change list of closp at the bottom of the readme: https://github.com/sveri/closp I also released closp-crud, which is a leiningen CRUD plugin generating SQL files, HTML templates and clojure database and routes code for the operations. I provided some documentation on how to get running here: https://github.com/sveri/closp-crud I also made a 12 minute introduction video on how to use that plugin and setting up closp before: http://www.twitch.tv/sveri80/v/4298695 Disclaimer: The audio is not the best and I have some hiccups with an already running figwheel process that must have crashed somewhere. So, live debugging is included Best Regards, Sven. PS: Is there a way to crosspost to the clojurescript group? -- 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: Programmatic reification
This is why I like component (https://github.com/stuartsierra/component). The nice thing about using this library is that it encourages you to break your application into self-contained components. Those components must then communicate via protocols, and the result is a modular system that's much simpler to test. Timothy On Fri, Apr 24, 2015 at 1:37 PM, Brian Guthrie btguth...@gmail.com wrote: On Fri, Apr 24, 2015 at 10:14 AM, Steven Deobald ste...@nilenso.com wrote: I don't have the answer for you, but I'm definitely curious what your use case is. Whatcha upto? I've become a firm believer in using protocols to encapsulate operations with side effects, but I don't know of any good test-framework-agnostic mocking or stubbing frameworks that work with them. I don't care much for interaction-based (mocking) tests anyway, really, and reification is simple enough that I don't think sugar for stubs buys you much. But it seemed like an open niche and a fun project. If I'm wrong and such a library does exist, please let me know. The library I'm working on doesn't attempt to perform any var replacements, and it doesn't introduce any new syntax; it's simply a mechanism for building fake versions of protocols, with full or partial implementations, that can be passed into functions that require them, and whose state (e.g., the set of calls they've received) can be subsequently inspected. I'd prefer to avoid macros entirely, except that I don't know of any other way to reify on demand. Release coming shortly. Cheers, Brian -- 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. -- “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 --- 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: Programmatic reification
Correction on my original response: The call to eval will be slow...
Reify doesn't take up permgen space with each invocation, but eval will (at
least on JVM 8).
Timothy
On Fri, Apr 24, 2015 at 2:14 PM, Brian Guthrie btguth...@gmail.com wrote:
Thanks for the advice, Timothy. I think this is probably much cleaner than
where I ended up, and good advice. I'll let you know how it goes.
On Fri, Apr 24, 2015 at 10:45 AM, Timothy Baldridge tbaldri...@gmail.com
wrote:
This is a situation where I reach for eval. Construct your reify call as
if you were inside a macro, but instead of returning data from the macro,
call (eval form). The call to reify will be slow (and could cause permgen
problems), but if you wrap the form in a function you can cache the
function and avoid that problem. Something like:
(let [cache (atom {})]
(defn implement-at-runtime [interface-name method-name body]
(if-let [result (@cache [interface-name method-name body])]
(result)
(let [f (eval `(fn []
(reify
~interface-name
(~method-name ~@body]
(swap! cache assoc [interface-name method-name body] f)
(f)
@(implement-at-runtime 'clojure.lang.IDeref 'deref '[this] 42)
;; returns 42
Timothy
On Fri, Apr 24, 2015 at 8:14 AM, Steven Deobald ste...@nilenso.com
wrote:
Okay, Brian. I'll bite. :)
I don't have the answer for you, but I'm definitely curious what your
use case is. Whatcha upto?
Steven Deobald -- ⌀ -- nilenso.com
On Fri, Apr 24, 2015 at 7:18 PM, Brian Guthrie btguth...@gmail.com
wrote:
Hi all,
Is there a good way to reify protocols programmatically, i.e., by
passing data structures rather than dropping down into a macro? reify
bottoms out in reify*, which doesn't help much.
Thanks,
Brian
--
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.
--
“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
---
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.
--
“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.”
Re: Programmatic reification
On Fri, Apr 24, 2015 at 3:51 PM, Timothy Baldridge tbaldri...@gmail.com wrote: This is why I like component (https://github.com/stuartsierra/component). The nice thing about using this library is that it encourages you to break your application into self-contained components. Those components must then communicate via protocols, and the result is a modular system that's much simpler to test. Strongly agree. I've been making much greater use of protocols since adopting Component on a wider scale, and that's sort of the motivation here. Brian -- 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: Programmatic reification
Thanks for the advice, Timothy. I think this is probably much cleaner than
where I ended up, and good advice. I'll let you know how it goes.
On Fri, Apr 24, 2015 at 10:45 AM, Timothy Baldridge tbaldri...@gmail.com
wrote:
This is a situation where I reach for eval. Construct your reify call as
if you were inside a macro, but instead of returning data from the macro,
call (eval form). The call to reify will be slow (and could cause permgen
problems), but if you wrap the form in a function you can cache the
function and avoid that problem. Something like:
(let [cache (atom {})]
(defn implement-at-runtime [interface-name method-name body]
(if-let [result (@cache [interface-name method-name body])]
(result)
(let [f (eval `(fn []
(reify
~interface-name
(~method-name ~@body]
(swap! cache assoc [interface-name method-name body] f)
(f)
@(implement-at-runtime 'clojure.lang.IDeref 'deref '[this] 42)
;; returns 42
Timothy
On Fri, Apr 24, 2015 at 8:14 AM, Steven Deobald ste...@nilenso.com
wrote:
Okay, Brian. I'll bite. :)
I don't have the answer for you, but I'm definitely curious what your use
case is. Whatcha upto?
Steven Deobald -- ⌀ -- nilenso.com
On Fri, Apr 24, 2015 at 7:18 PM, Brian Guthrie btguth...@gmail.com
wrote:
Hi all,
Is there a good way to reify protocols programmatically, i.e., by
passing data structures rather than dropping down into a macro? reify
bottoms out in reify*, which doesn't help much.
Thanks,
Brian
--
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.
--
“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
---
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: Strange behaviour of a callable record
Thanks, Nicola! It solved it. When I looked at docs, I couldn't figure out the role of `applyTo`. Well, now I know. On Thursday, April 23, 2015 at 1:47:11 PM UTC+2, Nicola Mometto wrote: You're not implementing IFn.applyTo, you should. Why applyTo is used in the second example while invoke is used in the other cases has to do with implementation details of how def expressions are compiled/evaluated. Alexey Cherkaev writes: Hi, I have encountered the problem with Clojure 1.6.0, when I create the record that implements IFn. For example, (defrecord Foo [x] clojure.lang.IFn (invoke [_ f] (f x))) Than create an instance of this record: (def f (-Foo 10)) And we can call it without a problem: user= (f inc) 11 Yet, if you try to define a value to keep the result, compiler throws an error: user= (def z (f inc)) CompilerException java.lang.AbstractMethodError, compiling:(form-init4774307052978984831.clj:1:8) There is workaround: create local binding first and then assign the value to a global variable: user= (def z (let [temp (f inc)] temp)) #'user/z user= z 11 Is this a bug or I don't fully understand why you can't do that? Cheers, Alexey -- -- 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.
