Re: [ANN] Immutant 0.3.0 released
No offense, but could you next time provide a one line description of what your project is? On Tue, Sep 11, 2012 at 9:30 PM, Jim Crossley jcrossl...@gmail.com wrote: We released our third official version of Immutant today! With this release we now publish the Immutant namespaces to Clojars. They are of limited use when run outside of Immutant, of course, but they'll at least compile so you can mock/stub/redefine them in your unit tests. You can render some of them mostly functional by adding the relevant jars to your project.clj, e.g. Infinispan, HornetQ, etc, and we expect to add more container-less functionality in future releases. Obviously, they're completely functional *inside* an Immutant container, so we've published a library to facilitate integration testing, and continued to improve our nrepl/swank support so you can now add dependencies to your project on the fly without having to redeploy it. Here's the announcement: http://bit.ly/immutant030 Enjoy and thanks, 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 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 -- http://about.me/rogier -- 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: [ANN] Immutant 0.3.0 released
On Fri, Sep 14, 2012 at 1:09 PM, Rogier Peters rogier.pet...@gmail.comwrote: No offense, but could you next time provide a one line description of what your project is? +1 For others here it is, What is Immutant? Immutant is an application server for Clojure. It's an integrated platform built on JBoss AS7 that aims to reduce the incidental complexity that comes along with real world applications. On Tue, Sep 11, 2012 at 9:30 PM, Jim Crossley jcrossl...@gmail.com wrote: We released our third official version of Immutant today! With this release we now publish the Immutant namespaces to Clojars. They are of limited use when run outside of Immutant, of course, but they'll at least compile so you can mock/stub/redefine them in your unit tests. You can render some of them mostly functional by adding the relevant jars to your project.clj, e.g. Infinispan, HornetQ, etc, and we expect to add more container-less functionality in future releases. Obviously, they're completely functional *inside* an Immutant container, so we've published a library to facilitate integration testing, and continued to improve our nrepl/swank support so you can now add dependencies to your project on the fly without having to redeploy it. Here's the announcement: http://bit.ly/immutant030 Enjoy and thanks, 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 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 -- http://about.me/rogier -- 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
Reducers reduce my performance
Hi all, I have some code which uses a lot of map/mapcat/filter stuff and is totally eager (result is always an ordered set). That looked to me like a good candidate for reducers. Basically, my code enables me to write something like this: --8---cut here---start-8--- (reachables p [p-seq [-- 'ContainsType] [p-+ [p-seq [-- 'Defines] [-- 'Imports] [p-opt [-- 'ContainsType]) --8---cut here---end---8--- which calculates the set of reachable vertices in a graph starting at a vertex p (or a set of vertices p) which can be reached by traversing a path matching the structure given as vector. So from p, we navigate a sequence (p-seq) of one forward ContainsType-edge, then one-or-many times (p-+) traversing the sequence of an incoming Defines-edge followed by an outgoing Imports-edge followed by optionally (p-opt) an incoming ContainsType-edge. p-seq, p-+, p-opt, --, -- are all functions receiving a set of vertices and the nested rest of the vector or edge type symbol. The current implementation simply recurses over the vector and applies the functions, combining their results. Ok, that works very good and performs well, but I've though reducers might give me some extra-performance. So now I rewrote all those functions to use reducers and return reducibles instead of ordered sets. The shape has changed to this, so instead of recursively applying the functions in a vector we create one big reducer function that does the job, and reachables simply applies that to p. --8---cut here---start-8--- (reachables p (p-seq (-- 'ContainsType) (p-+ (p-seq (-- 'Defines) (-- 'Imports) (p-opt (-- 'ContainsType)) --8---cut here---end---8--- The good thing is that it calculates exactly the same set. The bad thing is that it's about a factor of 2 or 3 slower. I tried to track down the cause, and the main bottleneck is the p-+ function which got much slower than before. This is the new version using reducers (:as r). The problem here is that to stop the iteration, one has to reduce the intermediate result in every step and check if new reachable vertices (n) could be found. If so, we need to do another iteration. --8---cut here---start-8--- (defn ^:private p-*-or-+ [p include-coll] (fn [coll] ;; coll is a reducible (loop [ret (if include-coll (into (ordered.set/ordered-set) coll) (ordered.set/ordered-set)) n (into (ordered.set/ordered-set) (if include-coll (r/remove ret (p coll)) (p coll)))] (if (seq n) (recur (into ret n) (into (ordered.set/ordered-set) (r/remove ret (p n ret (defn p-+ [p] (p-*-or-+ p false)) --8---cut here---end---8--- This is the original version, where the ordered set of vertices to start with is already given as first parameter, and the fn does the job itself rather than returning a fn that can do it. (As you can see, the old version uses reducers internally, too, but the functions themselves all receive and return sets). --8---cut here---start-8--- (defn ^:private p-*-or-+ [v p ret] (let [n (into (ordered.set/ordered-set) ;; oset is like set for ordered-sets (r/remove ret (oset (*p-apply* v p] (if (seq n) (recur n p (into-oset ret n)) ret))) (defn p-* [v p] (p-*-or-+ v p (oset v))) --8---cut here---end---8--- So is that simply a use-case where reducers don't fit in very well, or am I doing something wrong? Thanks for any hints, Tassilo -- 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
Clojure lazy-seq over Java iterative code
I also posted this to StackOverflow, so sorry if you saw it there too. If you want some rep points over there you can answer there too ( http://stackoverflow.com/questions/12427518/clojure-lazy-seq-over-java-iterative-code ). I'm trying to use create a Clojure seq from some iterative Java library code that I inherited. Basically what the Java code does is read records from a file using a parser, sends those records to a processor and returns an ArrayList of result. In Java this is done by calling parser.readData(), then parser.getRecord() to get a record then passing that record into processor.processRecord(). Each call to parser.readData() returns a single record or null if there are no more records. Pretty common pattern in Java. So I created this next-record function in Clojure that will get the next record from a parser. (defn next-record Get the next record from the parser and process it. [parser processor] (let [datamap (.readData parser) row (.getRecord parser datamap)] (if (nil? row) nil (.processRecord processor row 100 The idea then is to call this function and accumulate the records into a Clojure seq (preferably a lazy seq). So here is my first attempt which works great as long as there aren't too many records: (defn datamap-seq Returns a lazy seq of the records using the given parser and processor [parser processor] (lazy-seq (when-let [records (next-record parser processor)] (cons records (datamap-seq parser processor) I can create a parser and processor, and do something like (take 5 (datamap-seq parser processor)) which gives me a lazy seq. And as expected getting the (first) of that seq only realizes one element, doing count realizes all of them, etc. Just the behavior I would expect from a lazy seq. Of course when there are a lot of records I end up with a StackOverflowException. So my next attempt was to use loop-recur to do the same thing. (defn datamap-seq Returns a lazy seq of the records using the given parser and processor [parser processor] (lazy-seq (loop [records (seq '())] (if-let [record (next-record parser processor)] (recur (cons record records)) records Now using this the same way and defing it using (def results (datamap-seq parser processor)) gives me a lazy seq and doesn't realize any elements. However, as soon as I do anything else like (first results) it forces the realization of the entire seq. Can anyone help me understand where I'm going wrong in the second function using loop-recur that causes it to realize the entire thing? -- 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
Multiple matching dispatch values (multimethods)
Here's a simplification of an exercise I was trying to write. We have a two-level hierarchy of objects: (derive ::starship ::thing) (derive ::gaussjammer ::starship) We have a generic function that uses both arguments: (defmulti collide (fn [one two] [(type one) (type two)])) We have these two specializations: (defmethod collide [::starship ::starship] ...) (defmethod collide [::gaussjammer ::thing] Those are considered ambiguous in the face of: (collide some-gaussjammer some-starship) A `prefer-method` is required: (prefer-method collide [::gaussjammer ::thing] [::starship ::starship]) Why? In what cases would a programmer prefer something like the second match? - Brian Marick, Artisanal Labrador Contract programming in Ruby and Clojure Occasional consulting on Agile Writing /Functional Programming for the Object-Oriented Programmer/: https://leanpub.com/fp-oo -- 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 lazy-seq over Java iterative code
On Fri, Sep 14, 2012 at 8:37 AM, Dave Kincaid kincaid.d...@gmail.com wrote: I also posted this to StackOverflow, so sorry if you saw it there too. If you want some rep points over there you can answer there too (http://stackoverflow.com/questions/12427518/clojure-lazy-seq-over-java-iterative-code). Looks like there's already a good answer over there. Of course when there are a lot of records I end up with a StackOverflowException. Did you dig into where the StackOverflowException originated from? As noted in a comment on SO, the lazy-seq can handle millions of items without a problem so the problem isn't inherently with that part of your code. Perhaps it's the parser or the processor? -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ Perfection is the enemy of the good. -- Gustave Flaubert, French realist novelist (1821-1880) -- 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 lazy-seq over Java iterative code
Thanks, Sean. It turns out the exception is being thrown from one of the Java classes (I should have looked closer). I just assumed that doing the recursion without loop/recur would always blow the stack eventually. I'll have to do some research to understand when it does and when it doesn't. I also pasted in the wrong original function that I was using when I was getting the exception. The code I pasted does work. The version that's making the Java code throw the exception has an extra (remove) in it to remove empty lists. It looks like this: (defn datamap-seq Returns a lazy seq of the records using the given parser and processor [parser processor] (lazy-seq (when-let [records (next-record parser processor)] (cons records (remove empty? (datamap-seq parser processor)) If I take out that remove and do it elsewhere it works fine. Still puzzling over that one. On Friday, September 14, 2012 11:48:23 AM UTC-5, Sean Corfield wrote: On Fri, Sep 14, 2012 at 8:37 AM, Dave Kincaid kincai...@gmail.comjavascript: wrote: I also posted this to StackOverflow, so sorry if you saw it there too. If you want some rep points over there you can answer there too ( http://stackoverflow.com/questions/12427518/clojure-lazy-seq-over-java-iterative-code). Looks like there's already a good answer over there. Of course when there are a lot of records I end up with a StackOverflowException. Did you dig into where the StackOverflowException originated from? As noted in a comment on SO, the lazy-seq can handle millions of items without a problem so the problem isn't inherently with that part of your code. Perhaps it's the parser or the processor? -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ Perfection is the enemy of the good. -- Gustave Flaubert, French realist novelist (1821-1880) -- 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: Multiple matching dispatch values (multimethods)
My first thought on seeing: (collide some-gaussjammer some-starship) was He's colliding two starships, he'll want (defmethod collide [::starship ::starship] ...) In (what's left of) my OO brain, I think That only requires one upcast on gaussjammer to starship in order to get an exact match whereas the alternative match requires an upcast on both arguments. That may not actually be correct in any language but it's what seemed obvious to me ... Sean On Fri, Sep 14, 2012 at 9:30 AM, Brian Marick mar...@exampler.com wrote: Here's a simplification of an exercise I was trying to write. We have a two-level hierarchy of objects: (derive ::starship ::thing) (derive ::gaussjammer ::starship) We have a generic function that uses both arguments: (defmulti collide (fn [one two] [(type one) (type two)])) We have these two specializations: (defmethod collide [::starship ::starship] ...) (defmethod collide [::gaussjammer ::thing] Those are considered ambiguous in the face of: (collide some-gaussjammer some-starship) A `prefer-method` is required: (prefer-method collide [::gaussjammer ::thing] [::starship ::starship]) Why? In what cases would a programmer prefer something like the second match? -- 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
[ANN] clj-ns-browser 1.3.0 - the cool button-row widget release
We're happy to announce the new clj-ns-browser 1.3.0 - the cool button-row
widget - release.
The Clojure Namespace Browser is a GUI-based, Smalltalk-like development tool
that makes it easy to see, inspect, search, and browse the different
namespaces, classes/types, and vars of your live Clojure environment. It allows
you to see the online docs, the source code, the associated clojuredocs
comments/examples/see-alsos, as well as the var's meta-data and values.
Installation is achieved by adding a single line to your project.clj:
;; Leiningen version 1
:dev-dependencies [[clj-ns-browser 1.3.0]]
;; Leiningen version 2
:profiles {:dev {:dependencies [[clj-ns-browser 1.3.0]]}}
After (use 'clj-ns-browser.sdoc), the browser can be invoked at the REPL with
for example: (sdoc map)
where sdoc is a macro equivalent to and compatible with the venerable
clojure.repl/doc one, but give you just a little more info. After the
browser's GUI is invoked, you can pointclick to your heart's content.
A few of the highlights of the new release are:
• upgraded dependencies to latestgreatest (clojure 1.4, seesaw 1.4.2, etc.)
• Andy concocted a cool, new, button-row widget that allows for a more flexible
display of var/class/namespace information.
• syntax highlighting of source code thru use of rsyntaxtextarea
• improved invocation of external web-browser
• many invisible improvements...
There are too many other great features to mention here - please take a look at:
https://github.com/franks42/clj-ns-browser;
Enjoy,
Frank Siebenlist
Andy Fingerhut
--
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: Reducers reduce my performance
On Fri, Sep 14, 2012 at 4:22 AM, Tassilo Horn t...@gnu.org wrote: Hi all, I have some code which uses a lot of map/mapcat/filter stuff and is totally eager (result is always an ordered set). That looked to me like a good candidate for reducers. Basically, my code enables me to write something like this: --8---cut here---start-8--- (reachables p [p-seq [-- 'ContainsType] [p-+ [p-seq [-- 'Defines] [-- 'Imports] [p-opt [-- 'ContainsType]) --8---cut here---end---8--- which calculates the set of reachable vertices in a graph starting at a vertex p (or a set of vertices p) which can be reached by traversing a path matching the structure given as vector. So from p, we navigate a sequence (p-seq) of one forward ContainsType-edge, then one-or-many times (p-+) traversing the sequence of an incoming Defines-edge followed by an outgoing Imports-edge followed by optionally (p-opt) an incoming ContainsType-edge. p-seq, p-+, p-opt, --, -- are all functions receiving a set of vertices and the nested rest of the vector or edge type symbol. The current implementation simply recurses over the vector and applies the functions, combining their results. Ok, that works very good and performs well, but I've though reducers might give me some extra-performance. So now I rewrote all those functions to use reducers and return reducibles instead of ordered sets. The shape has changed to this, so instead of recursively applying the functions in a vector we create one big reducer function that does the job, and reachables simply applies that to p. --8---cut here---start-8--- (reachables p (p-seq (-- 'ContainsType) (p-+ (p-seq (-- 'Defines) (-- 'Imports) (p-opt (-- 'ContainsType)) --8---cut here---end---8--- The good thing is that it calculates exactly the same set. The bad thing is that it's about a factor of 2 or 3 slower. I tried to track down the cause, and the main bottleneck is the p-+ function which got much slower than before. This is the new version using reducers (:as r). The problem here is that to stop the iteration, one has to reduce the intermediate result in every step and check if new reachable vertices (n) could be found. If so, we need to do another iteration. this is almost certainly the problem, if you are using reducers you should not make intermediate results concrete. given the structure of your computation it may not be a good fit for reducers. you might be able to restructure in such a way as return something with a custom impl of CollReduce that performs this computation when reduced, which would get you out of returning concrete results. --8---cut here---start-8--- (defn ^:private p-*-or-+ [p include-coll] (fn [coll] ;; coll is a reducible (loop [ret (if include-coll (into (ordered.set/ordered-set) coll) (ordered.set/ordered-set)) n (into (ordered.set/ordered-set) (if include-coll (r/remove ret (p coll)) (p coll)))] (if (seq n) (recur (into ret n) (into (ordered.set/ordered-set) (r/remove ret (p n ret (defn p-+ [p] (p-*-or-+ p false)) --8---cut here---end---8--- This is the original version, where the ordered set of vertices to start with is already given as first parameter, and the fn does the job itself rather than returning a fn that can do it. (As you can see, the old version uses reducers internally, too, but the functions themselves all receive and return sets). --8---cut here---start-8--- (defn ^:private p-*-or-+ [v p ret] (let [n (into (ordered.set/ordered-set) ;; oset is like set for ordered-sets (r/remove ret (oset (*p-apply* v p] (if (seq n) (recur n p (into-oset ret n)) ret))) (defn p-* [v p] (p-*-or-+ v p (oset v))) --8---cut here---end---8--- So is that simply a use-case where reducers don't fit in very well, or am I doing something wrong? Thanks for any hints, Tassilo -- 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
Fizz-Buzz and Church Numerals
Hi, I've translated the code in http://experthuman.com/programming-with-nothing to Clojure and here's the result: - https://www.refheap.com/paste/5073/fullscreen (code) - https://www.refheap.com/paste/5074/fullscreen (tests) Cheers, Ulises -- 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: Reducers reduce my performance
Kevin Downey redc...@gmail.com writes: Hi Kevin, This is the new version using reducers (:as r). The problem here is that to stop the iteration, one has to reduce the intermediate result in every step and check if new reachable vertices (n) could be found. If so, we need to do another iteration. this is almost certainly the problem, if you are using reducers you should not make intermediate results concrete. given the structure of your computation it may not be a good fit for reducers. I guessed that, but wanted to be extra-sure. you might be able to restructure in such a way as return something with a custom impl of CollReduce that performs this computation when reduced, which would get you out of returning concrete results. Hm, yes, sounds good. I think, I need to have another look at the reducers implementation... Thanks for the hint, Tassilo -- 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: Fizz-Buzz and Church Numerals
This is awesome! On Fri, Sep 14, 2012 at 12:00 PM, Ulises ulises.cerv...@gmail.com wrote: Hi, I've translated the code in http://experthuman.com/programming-with-nothing to Clojure and here's the result: - https://www.refheap.com/paste/5073/fullscreen (code) - https://www.refheap.com/paste/5074/fullscreen (tests) Cheers, Ulises -- 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 -- Baishampayan Ghose b.ghose at gmail.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: Literate Programming in org-babel (ob-clojure.el) is broken under nrepl.el
Yep. Thanks for the patch, Ben. I had set org-babel-default-header-args:clojure to '((:noweb . tangle)) in my .emacs, so I was getting the benefit of automatic noweb expansion when tangling (but not weaving). It's all fun and games until you break someone else's setup! ;) ~Gary On Wednesday, September 12, 2012 11:46:14 PM UTC-4, Ben Mabey wrote: On 9/12/12 9:29 PM, Ben Mabey wrote: Thanks for the great example Gary! I've been meaning to try org-babel out for a while but never got around to it. I just tried your example and when I run org-babel-tangle the code blocks are not expanded into the source file, but rather the code block names are just inserted into the source destination (e.g. find-discounted-subsets instead of the actual function). Any ideas on what may be wrong? Do you have global settings that are perhaps making the tangle work differently on your setup? I was able to export the document to HTML just fine and execute the clojure code, so the only issue appears to be tangling. I found the problem was a missing :noweb argument: https://github.com/lambdatronic/org-babel-example/pull/1 -- 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
distributed fork/join
Who wants to run reducers in a distributed, hdfs-backed environment? Some cool stuff coming down the pike: http://medianetwork.oracle.com/video/player/1785432463001 https://thestrangeloop.com/sessions/h2o-open-source-bigdatabase-for-interactive-analytics I don't know this guy, but if anyone does it might be worth reaching out and pointing him to the clojure's reducers stuff. AFAICT they are planning to open-source at some point. -- 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
[ANN] drakerlabs/lein-deploy-app 0.2.0
A very simple plugin that I wrote today that we're using in our approach to
continuous integration and deployment at Draker. Enjoy! Comments, feedback,
issues, or pull requests are welcome... --Rob lein-deploy-app
A Leiningen plugin to push application uberjars to an AWS s3 bucket,
organized by application and branch.
This plugin is similar to s3-wagon in that you configure your project to
deploy to s3, but whereas lein deploy is for deploying libs,
lein-deploy-app is for deploying app uberjars and does not store the
uberjars in a Maven repo (as lein-deploy-uberjar does).
A workflow involving lein-deploy-app might involve a ci server or an
engineer calling lein deploy-app. Then an operations automation framework
like Chef can easily pull down the appropriate application, version, and
branch in a staging or production environment.
https://github.com/drakerlabs/lein-deploy-app#usageUsage
1.
Put [lein-deploy-app 0.1.0] into the :plugins vector of your
project.clj.
2.
Add a project.clj configuration mapping for deploy-app:
:deploy-app {:s3-bucket s3p://mybucket/releases/
:creds :env}
:s3-bucket is the bucket/path where you want to deploy your uberjars.
:creds is the credentials type. Presently only :env is supported. If using
:env, specify your s3 credentials using the environment variables
LEIN_USERNAME and LEIN_PASSWORD.
To deploy your application's uberjar to s3 for the current git branch:
$ lein deploy-app
To specify some other label instead of current git branch as branch:
$ lein deploy-app --branch NAME
https://github.com/drakerlabs/lein-deploy-app#to-doTo
Dohttps://github.com/drakerlabs/lein-deploy-app#gpg-credentials-option:gpg
credentials option
If using :gpg, create a gpg encrypted ~/.lein/credentials.clj.gpg file out
of a credentials.clj file of the following form:
{s3p://mybucket/releases/ {:username usernamegoeshere
:passphrase passphrasegoeshere}}
https://github.com/drakerlabs/lein-deploy-app#licenseLicense
Author: Robert Levy / @rplevy-draker
Copyright © 2012 Draker, Inc.
Distributed under the Eclipse Public License, the same as Clojure.
--
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
