Cosla: Clojure tool for SLA metrics via JIRA Rest API
Greetings, I've open sourced a command-line tool I wrote, in Clojure, for pulling SLA (service-level agreement) stats from JIRA using the JIRA Rest API. https://github.com/noahlz/cosla Given a JIRA instance, it can generate some CSV files reporting on the issues matching a JQL you provide, such as issues open-per-day and per-issue time-to-close. Hopefully useful to somebody as-is, or an interesting project to hack on / extend that could have practical business use. Issues / pull-requests welcome! @noahlz -- 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.
Understanding unmatched parenthesis in read-string
(Disclaimer: I post this aware that read-string is considered dangerous for untrusted code and having starred tools.reader) I was writing some code using read-string and encountered the following (somewhat odd?) behavior: Clojure 1.5.1 user= (read-string 1000N() 1000N user= (read-string 1000N)) 1000N user= (read-string (1000N) RuntimeException EOF while reading clojure.lang.Util.runtimeException (Util.java:219) user= (read-string )1000N) RuntimeException Unmatched delimiter: ) clojure.lang.Util.runtimeException (Util.java:219) So if the string ends with an unmatched ) or (, the preceding value gets returned and the unmatched character discarded. But if the string starts with an unmatched parens - EOF (as expected). I was a little surprised as I expected the first to cases to throw some kind of RuntimeException. What is the explanation for this behavior if any, and where can I go / read more about the underlying theory of correctly handling this case? I'm aware that lexical parsing is a big topic - just wondering what the ruling was here (if any) and looking for a jumping off point into further readings. Also if this was discussed elsewhere (searching read-string unmatched paren yielded nothing). Thanks! -- -- 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/groups/opt_out.
Re: Understanding unmatched parenthesis in read-string
Understood, but what I was wondering is why the trailing parenthesis is discarded / not considered part of the object expression? On Monday, April 29, 2013 4:32:49 PM UTC-4, Weber, Martin S wrote: user= (doc read-string) - clojure.core/read-string ([s]) Reads *one* object from the string s nil (emphasis on *one* by me) one object from :a( = :a; :a) = :a; ( … = fail; )… = fail. (remember whitespace in front of a paren doesn't matter) Have fun. -- -- 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/groups/opt_out.
Re: Understanding unmatched parenthesis in read-string
Ok. The parser reads a single complete expression and discards the rest. It understands that once it has hit a new character that represents the beginning of a new expression, it doesn't care. I suppose I thought the parser would raise an error on detecting an unmatched parenthesis, but that's wrong. Interestingly, when I try this at the repl (1.5.1) it errors as I expected (probably why I expected it in the first place): user= 1000N) 1000N RuntimeException Unmatched delimiter: ) clojure.lang.Util.runtimeException (Util.java:219) Of course, the repl doesn't use read-string. So, the next step in my journey is to investigate the source of clojure.main. But - someone wants to take the opportunity to ruin the surprise for me - with a more detailed explanation / theory discussion - I'm open to it :) On Monday, April 29, 2013 4:44:13 PM UTC-4, Ben wrote: Because 1000N is a complete expression, as you can verify with your REPL. On Mon, Apr 29, 2013 at 1:43 PM, noahlz nzu...@gmail.com javascript:wrote: Understood, but what I was wondering is why the trailing parenthesis is discarded / not considered part of the object expression? On Monday, April 29, 2013 4:32:49 PM UTC-4, Weber, Martin S wrote: user= (doc read-string) - clojure.core/read-string ([s]) Reads *one* object from the string s nil (emphasis on *one* by me) one object from :a( = :a; :a) = :a; ( … = fail; )… = fail. (remember whitespace in front of a paren doesn't matter) Have fun. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.comjavascript: Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@googlegroups.com javascript: For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com javascript:. For more options, visit https://groups.google.com/groups/opt_out. -- Ben Wolfson Human kind has used its intelligence to vary the flavour of drinks, which may be sweet, aromatic, fermented or spirit-based. ... Family and social life also offer numerous other occasions to consume drinks for pleasure. [Larousse, Drink entry] -- -- 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/groups/opt_out.
Re: Understanding unmatched parenthesis in read-string
On Monday, April 29, 2013 6:07:01 PM UTC-4, Cedric Greevey wrote: If you want to exhaust read-string's input argument, getting back a vector of all of the objects in the input and an error if any of them are syntactically invalid, just call (read-string (str [ in-string ])). This also deals with empty inputs in a non-blowing-up manner, returning an empty vector, which might allow uniform handling of the cases (empty? in-string) and (not (empty? in-string)) in some instances. Interestingly, my code already contains something like the following: (let [expr (- (str ( input )) read-string)] ...) It felt wrong when I wrote this, but it seems like I was in the right track? I'm guessing vectors are safer than lists for passing to eval? -- -- 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/groups/opt_out.
Re: a tutorial for working at the repl?
On Monday, April 29, 2013 6:07:34 PM UTC-4, larry google groups wrote: I am no longer a total beginner at Clojure, but I find I still get badly confused by some issues at the repl (namesspaces, classpath, dependencies, etc). Can anyone point me to a good tutorial about working at the repl? Leiningen is terrific for streamlining this process. http://jrheard.tumblr.com/post/40024238467/getting-started-with-clojure Perhaps the biggest gotcha for me namespaces in the REPL was understanding (in-ns) vs (ns) and (require) vs (use). -- -- 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/groups/opt_out.
Re: More Concise or Idiomatic Max Sub-Array?
Great use of reductions. Thanks! On Saturday, September 29, 2012 11:10:27 AM UTC-4, Jean Niklas L'orange wrote: Is there a more concise implementation, perhaps using `filter` or merely by making the `reduce` version more idiomatic somehow? Another version I believe is more evident utilizes reductions to build a list over all the *max-ending-here*s. You can then just pick the maximal value in that list, giving you the maximal subarray: (defn max-subarray [A] (let [pos+ (fn [sum x] (if (neg? sum) x (+ sum x))) ending-heres (reductions pos+ 0 A)] (reduce max ending-heres))) -- 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
More Concise or Idiomatic Max Sub-Array?
I've implemented the following two versions of the Max Sub-Array problem (http://en.wikipedia.org/wiki/Maximum_subarray_problem) in Clojure, using the Kadane algorithm. First with `loop` / `recur` (defn max-sub-array [A] (loop [x (first A) a (rest A) max-ending-here 0 max-so-far 0] (if (seq a) (recur (first a) (rest a) (max x, (+ max-ending-here x)) (max max-so-far, max-ending-here)) max-so-far))) Then with `reduce` (defn max-sub-array-reduction [A] (letfn [(find-max-sub-array [[max-ending-here max-so-far] x] [(max x (+ max-ending-here x)) (max max-so-far max-ending-here)])] (second (reduce find-max-sub-array [0 0] A Is there a more concise implementation, perhaps using `filter` or merely by making the `reduce` version more idiomatic somehow? Also posted here: http://codereview.stackexchange.com/questions/15992/more-concise-and-or-idiomatic-max-subarray-in-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
