Re: feeding leiningen a local JAR file
That looks very helpful, thanks. I've been bitten by this hard in the past
- I wanted to play with a few different Processing jars in Quil, none of
which had Maven versions; and even using lein-localrepo, it was excessively
complex to add these jars to my local maven repo just so I could play with
them.
- Korny
On 9 June 2013 04:10, Jay Fields j...@jayfields.com wrote:
David Chelimsky recently released:
https://github.com/dchelimsky/lein-expand-resource-paths
On Friday, June 7, 2013 10:37:46 PM UTC-4, David Williams wrote:
Try here
http://nakkaya.com/2010/03/16/**adding-custom-libraries-into-**
local-leiningen-repository/http://nakkaya.com/2010/03/16/adding-custom-libraries-into-local-leiningen-repository/
On Wednesday, November 21, 2012 3:47:40 AM UTC-8, Dick Davies wrote:
I've got a couple of projects that need a newer version of a JAR
than is available in Maven.
Is there any support/syntax in project.clj that will allow me to point
at a local JAR file?
Also, is it possible to 'override' a given dependency to favour a local
JAR
over the 'official' maven one?
[ specifically, I'm trying to use clj-xmpp which uses the SMACK XMPP
libraries under the hood, and the maven shipped version won't
authenticate
against our ejabberd ]
--
--
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.
--
Kornelis Sietsma korny at my surname dot com http://korny.info
.fnord { display: none !important; }
--
--
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: [pre-ANN] test2, the last Clojure testing framework
Hi Steven, A few thoughts: 1. You may want to look at https://github.com/clojure/test.generative/blob/master/data-model.org. 2. I don't think you want a ref for *assertion-results* -- I am not aware of any use cases that would need transactions. In any case the choice of reference type probably belongs in the impl, not the spec. Good luck with this! Stu On Sat, Jun 8, 2013 at 4:14 PM, Steven Degutis sbdegu...@gmail.com wrote: Test2 is a new testing lib for Clojure, where the power is its simplicity, extensibility, and a SPEChttps://github.com/evanescence/test2/blob/master/SPEC.md much like Ring's. Github: https://github.com/evanescence/test2 Some background: It came out of discussionshttps://github.com/evanescence/test2/wiki/Communal-Brainstorming with the smart folks in #clojure, who were frustrated with the inflexibility of existing libs, and intended this to be the spiritual successor to clojure.test. We wanted something that was still simple like clojure.test, but could be extended externally much more easily in case you wanted features found in clojure.test, Midje, Speclj, or Expectations, or whatever else. This is a pre-ANN because it's more of a call for extensions. I've written one last night, test2-autorunnerhttps://github.com/evanescence/test2-autorunner, which took about an hour. This should give some idea of how easy it is and how well-designed the SPEC was by the smart folks of #clojure. There are some ideas at the bottom of the wiki, but of course any extensions are encouraged. -Steven -- -- 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. -- -- 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: Idiomatic way to write dependency resolving algorithms?
Here is a similar algorithm I did for work a while back:
(defn- find-next-node [deps used-nodes]
(some (fn [[k v]] (if (empty? (remove used-nodes v)) k)) deps))
(defn topsort
Takes a map of dependencies between items and performs a topological
sort.
E.g. (topsort {1 [2 3] 3 [] 2 [3]}) = [3 2 1]
[deps]
(loop [deps deps res []]
(if (empty? deps)
res
(if-let [item (find-next-node deps (set res))]
(recur (dissoc deps item) (conj res item))
(throw (Exception. (str A circular dependency was found:
deps)))
I am not sure if it is optimal, but it does it without the atom which is a
bit nicer i think. I'm also open to input for a better way of course.
On Friday, May 31, 2013 6:33:59 PM UTC+2, Alice wrote:
(def graph
{a {:dependencies [b d]}
b {:dependencies [c e]}
c {:dependencies [d e]}
d {:dependencies []}
e {:dependencies []}})
(defn resolve-dep
[graph name]
(let [resolved (atom [])
resolved-set (atom #{})
f (fn f [name]
(doseq [x (:dependencies (graph name))]
(f x))
(when-not (@resolved-set name)
(swap! resolved conj name)
(swap! resolved-set conj name)))]
(f name)
@resolved))
(resolve-dep graph a)
;= [d e c b a]
This code works, but not sure if it's idiomatic clojure code.
The use of atom feels like procedural than functional to me since
there's no concurrency involved at all.
Any suggestions?
--
--
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: Idiomatic way to write dependency resolving algorithms?
Also yours explodes if given a circular dependency. There is no way around
throwing an exception, but it is always nice not to have stack overflows in
your code:
(def graph
{a {:dependencies [b d]}
b {:dependencies [c e]}
c {:dependencies [d e]}
d {:dependencies [c]}
e {:dependencies []}})
(resolve-dep graph c) = java.lang.StackOverflowError
On Sunday, June 9, 2013 10:30:51 AM UTC+2, Casper Clausen wrote:
Here is a similar algorithm I did for work a while back:
(defn- find-next-node [deps used-nodes]
(some (fn [[k v]] (if (empty? (remove used-nodes v)) k)) deps))
(defn topsort
Takes a map of dependencies between items and performs a topological
sort.
E.g. (topsort {1 [2 3] 3 [] 2 [3]}) = [3 2 1]
[deps]
(loop [deps deps res []]
(if (empty? deps)
res
(if-let [item (find-next-node deps (set res))]
(recur (dissoc deps item) (conj res item))
(throw (Exception. (str A circular dependency was found:
deps)))
I am not sure if it is optimal, but it does it without the atom which is a
bit nicer i think. I'm also open to input for a better way of course.
On Friday, May 31, 2013 6:33:59 PM UTC+2, Alice wrote:
(def graph
{a {:dependencies [b d]}
b {:dependencies [c e]}
c {:dependencies [d e]}
d {:dependencies []}
e {:dependencies []}})
(defn resolve-dep
[graph name]
(let [resolved (atom [])
resolved-set (atom #{})
f (fn f [name]
(doseq [x (:dependencies (graph name))]
(f x))
(when-not (@resolved-set name)
(swap! resolved conj name)
(swap! resolved-set conj name)))]
(f name)
@resolved))
(resolve-dep graph a)
;= [d e c b a]
This code works, but not sure if it's idiomatic clojure code.
The use of atom feels like procedural than functional to me since
there's no concurrency involved at all.
Any suggestions?
--
--
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.
Incanter 1.5.0 has been released!
I'm happy to announce, that Incanter 1.5.0 was pushed to Clojars. Full list of changes is in the Changelog: https://github.com/liebke/incanter/blob/master/Changes.md, please check the Known issues section. Incanter (http://incanter.org/) is a Clojure-based, R-like platform for statistical computing and graphics. Incanter can be used as a standalone, interactive data analysis environment or embedded within other analytics systems as a modular suite of libraries. -- With best wishes,Alex Ott http://alexott.net/ Twitter: alexott_en (English), alexott (Russian) Skype: alex.ott -- -- 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: idiot question about macros
Ben, Thanks for the feedback... and I'm sorry it to so long to say thanks (I've been traveling). In terms of the lack of being hygienic, I discuss that in the next paragraph in the blog post the OP took the macro from. But I really appreciate your thoughts on error messages. As I develop macros, I'll work hard to make sure the end users (who may not be me) get better feedback. Rock on. David On Fri, Jun 7, 2013 at 4:43 PM, Ben Wolfson wolf...@gmail.com wrote: On Fri, Jun 7, 2013 at 12:30 PM, David Pollak feeder.of.the.be...@gmail.com wrote: On Fri, Jun 7, 2013 at 11:14 AM, Ben Wolfson wolf...@gmail.com wrote: The macro (which IMO is terrible and shouldn't be emulated) Why do you think the macro is terrible? It's unnecessarily unhygienic: user (require '[clojure.core.match :refer [match]]) nil user (defmacro match-func [ body] `(fn [~'x] (match [~'x] ~@body))) #'user/match-func user ((match-func [s] x) 1) 1 user ((match-func [[q s]] [q s]) [1 2]) [1 2] user ((match-func [[q x]] [q x]) [1 2]) nil user Proper use requires knowing how it's implemented, and its error messages are opaque: user (match-func [a s] s) CompilerException java.lang.AssertionError: Pattern row 1: Pattern row has differing number of patterns. [a s] has 2 pattern/s, expecting 1 for occurrences [x], compiling:(NO_SOURCE_PATH:1) It wouldn't be hard to catch that error and alert the user before passing it on to core.match/match. (Though, to be fair, lots of clojure macros seem to take the view that enforcement of proper syntax is someone else's problem.) (I also favor More Parens for grouping purposes; I think it's ugly and hard to read when you write (match-func pattern1 action1 pattern2 action2) and have them all mixed up together like that. But that also applies to core.match itself, so. I will say that insofar as this is a macro for defining functions, it would be better if the actions to be taken on successful matches were wrapped in implicit dos, which is something that's only possible if the pattern row/action pairs are themselves delimited by parens or something paren-like.) -- 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. -- Telegram, Simply Beautiful CMS https://telegr.am Lift, the simply functional web framework http://liftweb.net Follow me: http://twitter.com/dpp Blog: http://goodstuff.im -- -- 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: Refactoring tools
I recently upgraded clojure-refactoring to Clojure 1.5.0 and nREPL. See if it helps you. https://github.com/luckykevin/clojure-refactoring On Thursday, March 21, 2013 9:05:57 AM UTC+8, Dave Kincaid wrote: I'm wondering if there are any refactoring tools around for working with Clojure projects in Emacs. There seems to be all kinds of other tools except for refactoring. I'm really looking for simple things like ways to easily rename variables, functions, namespaces, etc. That seems to be the most common thing I'm trying to do. Are there any tools out there to make it easier? Thanks, Dave -- -- 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: Refactoring tools
Hi, I recently upgrade old clojure-refactoring repo to Clojure 1.5.0 and nREPL. See if it help you. https://github.com/luckykevin/clojure-refactoring On Thursday, March 21, 2013 9:05:57 AM UTC+8, Dave Kincaid wrote: I'm wondering if there are any refactoring tools around for working with Clojure projects in Emacs. There seems to be all kinds of other tools except for refactoring. I'm really looking for simple things like ways to easily rename variables, functions, namespaces, etc. That seems to be the most common thing I'm trying to do. Are there any tools out there to make it easier? Thanks, Dave -- -- 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: Incanter 1.5.0 has been released!
Thanks for the new release. Will the changes be also available in files which are downloadable on this link (http://incanter.org/downloads/)? I used these files often to create some ad hoc graphics or a method to show others what can be done. Am 09.06.2013 14:16, schrieb Alex Ott: I'm happy to announce, that Incanter 1.5.0 was pushed to Clojars. Full list of changes is in the Changelog: https://github.com/liebke/incanter/blob/master/Changes.md, please check the Known issues section. Incanter (http://incanter.org/) is a Clojure-based, R-like platform for statistical computing and graphics. Incanter can be used as a standalone, interactive data analysis environment or embedded within other analytics systems as a modular suite of libraries. -- With best wishes,Alex Ott http://alexott.net/ Twitter: alexott_en (English), alexott (Russian) Skype: alex.ott -- -- 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. -- -- 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: [pre-ANN] test2, the last Clojure testing framework
I'd like to mention that expectations* has 0 open pull requests, 0 open issues, and is very actively maintained**. Steven, I don't want to discourage you from creating your own testing framework, I think everyone should, it's a very educational experience. I just wanted to be clear that no one has ever asked me for any help extending expectations, and anyone who chooses to use expectations should feel free to contact me with any suggestions. * https://github.com/jaycfields/expectations ** https://github.com/jaycfields/expectations/commits/master On Saturday, June 8, 2013 11:14:42 AM UTC-4, Steven Degutis wrote: Test2 is a new testing lib for Clojure, where the power is its simplicity, extensibility, and a SPEChttps://github.com/evanescence/test2/blob/master/SPEC.md much like Ring's. Github: https://github.com/evanescence/test2 Some background: It came out of discussionshttps://github.com/evanescence/test2/wiki/Communal-Brainstorming with the smart folks in #clojure, who were frustrated with the inflexibility of existing libs, and intended this to be the spiritual successor to clojure.test. We wanted something that was still simple like clojure.test, but could be extended externally much more easily in case you wanted features found in clojure.test, Midje, Speclj, or Expectations, or whatever else. This is a pre-ANN because it's more of a call for extensions. I've written one last night, test2-autorunnerhttps://github.com/evanescence/test2-autorunner, which took about an hour. This should give some idea of how easy it is and how well-designed the SPEC was by the smart folks of #clojure. There are some ideas at the bottom of the wiki, but of course any extensions are encouraged. -Steven -- -- 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: Refactoring tools
nrepl has macroexpansion, so you can already have 1/2 of what you want - better than nothing. On Friday, March 22, 2013 9:42:10 PM UTC-4, Alex Baranosky wrote: I'd really like to see a way to factor to code that uses -/- and back again. On Fri, Mar 22, 2013 at 12:01 PM, Laurent PETIT lauren...@gmail.comjavascript: wrote: 2013/3/22 Daniel Glauser dangl...@gmail.com javascript: I feel your pain, would love to see some Clojure refactorings. I had started working on the 1.3 branch of clojure-refactoring trying to bring it up to speed. I met with Tony (the original author of clojure-refactoring) and Phil H. at Clojure/West. Tony was very adamant that we ditch his code and start over. Currently I'm doing some experimenting with sjacket ( https://github.com/cgrand/sjacket) trying to see if we could make that work for renaming. Once I'm confident that direction will work I'm happy to throw some code up on Github. If someone beats me to it then I'd like to contribute to their project. I just created a #clojure-refactoring channel up on Freenode to make it easier to collaborate. We can rename the node once a name emerges for a new project. Please note that I've also created a project entry for the Google Summer Of Code for this : creating refactoring library + integration of it into Counterclockwise : http://dev.clojure.org/display/community/Project+Ideas#ProjectIdeas-RefactoringfeatureforCCWotherIDEs I think writing a refactoring library with more than one client in mind (e.g. a command line client as well as an IDE client) is interesting because it will help shape its API (for instance, an IDE client will usually want to offer a view of the modifications to be applied, thus refactoring can have a review step). Cheers, -- Laurent On Thursday, March 21, 2013 12:12:42 AM UTC-6, Akhil Wali wrote: A fairly new project for refactoring Clojure is clj-refactor.el. Not too much functionality yet, but supplements clojure-refactoring pretty well. clj-refactor.el will later interop with nRepl, or that's the plan I heard. That aside (and I know I'm being redundant), refactoring any Lisp is a snap with paredit-mode. It doesn't do stuff like renaming a function or exracting a var, but I've had some success in making these operations as interactive functions. On Thu, Mar 21, 2013 at 8:11 AM, Devin Walters dev...@gmail.comwrote: Yeah it sort of bums me out that clojure-refactoring has been in the ditch. There are a number of tasks to get this back into a good state. The plan right now is to take tests (which were mostly failing and using outdated dependencies) from the old-test directory and get them passing under Midje. Then, get it to play nicely with nrepl and update any elisp that needs updating to bring back the clojure-refactoring minor mode. If anyone wants to help resurrect this project: https://github.com/** devn/clojure-refactoring/tree/**clojure-1.5https://github.com/devn/clojure-refactoring/tree/clojure-1.5 your help would be appreciated. I created a new branch and started bringing old failing tests over. Feel free to drop me a pull request. Big, sweeping commits and tiny typo commits are both equally welcome. On Wednesday, March 20, 2013 at 8:22 PM, Dave Kincaid wrote: Thanks. It looks like nothing has happened on that in a year and it appears to require slime/swank. But it's a start I guess if there isn't anything else. On Wednesday, March 20, 2013 6:13:30 PM UTC-7, Devin Walters (devn) wrote: I don't think much has happened with it recently, but I used to use https://github.com/joodie/clojure-refactoringhttps://github.com/joodie/clojure-refactoring . -- '(Devin Walters) Sent from my Motorola RAZR V3 (Matte Black) On Wednesday, March 20, 2013 at 8:05 PM, Dave Kincaid wrote: I'm wondering if there are any refactoring tools around for working with Clojure projects in Emacs. There seems to be all kinds of other tools except for refactoring. I'm really looking for simple things like ways to easily rename variables, functions, namespaces, etc. That seems to be the most common thing I'm trying to do. Are there any tools out there to make it easier? Thanks, Dave -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@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+u...@**googlegroups.com For more options, visit this group at http://groups.google.com/**group**/clojure?hl=enhttp://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. For more options, visit
Re: Refactoring tools
I've written the 2nd one in emacs lisp, the first one would be even easier. If you're using emacs, you should give it a shot, it was a great learning experience for me. On Friday, March 22, 2013 10:54:36 PM UTC-4, Russell Mull wrote: I find myself doing that a lot by hand, a tool to help would be very useful. Some others that I've thought of are: - change between (fn [x] ...) and #(...) - pull sexp up to let, or introduce a new let (like introduce variable in java et. al) On Saturday, March 23, 2013 10:42:10 AM UTC+9, Alex Baranosky wrote: I'd really like to see a way to factor to code that uses -/- and back again. On Fri, Mar 22, 2013 at 12:01 PM, Laurent PETIT lauren...@gmail.comwrote: 2013/3/22 Daniel Glauser dangl...@gmail.com I feel your pain, would love to see some Clojure refactorings. I had started working on the 1.3 branch of clojure-refactoring trying to bring it up to speed. I met with Tony (the original author of clojure-refactoring) and Phil H. at Clojure/West. Tony was very adamant that we ditch his code and start over. Currently I'm doing some experimenting with sjacket ( https://github.com/cgrand/sjacket) trying to see if we could make that work for renaming. Once I'm confident that direction will work I'm happy to throw some code up on Github. If someone beats me to it then I'd like to contribute to their project. I just created a #clojure-refactoring channel up on Freenode to make it easier to collaborate. We can rename the node once a name emerges for a new project. Please note that I've also created a project entry for the Google Summer Of Code for this : creating refactoring library + integration of it into Counterclockwise : http://dev.clojure.org/display/community/Project+Ideas#ProjectIdeas-RefactoringfeatureforCCWotherIDEs I think writing a refactoring library with more than one client in mind (e.g. a command line client as well as an IDE client) is interesting because it will help shape its API (for instance, an IDE client will usually want to offer a view of the modifications to be applied, thus refactoring can have a review step). Cheers, -- Laurent On Thursday, March 21, 2013 12:12:42 AM UTC-6, Akhil Wali wrote: A fairly new project for refactoring Clojure is clj-refactor.el. Not too much functionality yet, but supplements clojure-refactoring pretty well. clj-refactor.el will later interop with nRepl, or that's the plan I heard. That aside (and I know I'm being redundant), refactoring any Lisp is a snap with paredit-mode. It doesn't do stuff like renaming a function or exracting a var, but I've had some success in making these operations as interactive functions. On Thu, Mar 21, 2013 at 8:11 AM, Devin Walters dev...@gmail.comwrote: Yeah it sort of bums me out that clojure-refactoring has been in the ditch. There are a number of tasks to get this back into a good state. The plan right now is to take tests (which were mostly failing and using outdated dependencies) from the old-test directory and get them passing under Midje. Then, get it to play nicely with nrepl and update any elisp that needs updating to bring back the clojure-refactoring minor mode. If anyone wants to help resurrect this project: https://github.com/** devn/clojure-refactoring/tree/**clojure-1.5https://github.com/devn/clojure-refactoring/tree/clojure-1.5 your help would be appreciated. I created a new branch and started bringing old failing tests over. Feel free to drop me a pull request. Big, sweeping commits and tiny typo commits are both equally welcome. On Wednesday, March 20, 2013 at 8:22 PM, Dave Kincaid wrote: Thanks. It looks like nothing has happened on that in a year and it appears to require slime/swank. But it's a start I guess if there isn't anything else. On Wednesday, March 20, 2013 6:13:30 PM UTC-7, Devin Walters (devn) wrote: I don't think much has happened with it recently, but I used to use https://github.com/joodie/clojure-refactoringhttps://github.com/joodie/clojure-refactoring . -- '(Devin Walters) Sent from my Motorola RAZR V3 (Matte Black) On Wednesday, March 20, 2013 at 8:05 PM, Dave Kincaid wrote: I'm wondering if there are any refactoring tools around for working with Clojure projects in Emacs. There seems to be all kinds of other tools except for refactoring. I'm really looking for simple things like ways to easily rename variables, functions, namespaces, etc. That seems to be the most common thing I'm trying to do. Are there any tools out there to make it easier? Thanks, Dave -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@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
Re: [pre-ANN] test2, the last Clojure testing framework
Thanks for the feedback. I'l look into #1. Regarding #2, we just wanted a side-effecty (mutable) way of adding assertion-results within a test. I suppose I could use (trans []) and let users use conj! although the fact that transient keeps saying alpha, use at your own risk concerns me a bit. On Sunday, June 9, 2013 3:27:30 AM UTC-5, stuart@gmail.com wrote: Hi Steven, A few thoughts: 1. You may want to look at https://github.com/clojure/test.generative/blob/master/data-model.org. 2. I don't think you want a ref for *assertion-results* -- I am not aware of any use cases that would need transactions. In any case the choice of reference type probably belongs in the impl, not the spec. Good luck with this! Stu On Sat, Jun 8, 2013 at 4:14 PM, Steven Degutis sbde...@gmail.comjavascript: wrote: Test2 is a new testing lib for Clojure, where the power is its simplicity, extensibility, and a SPEChttps://github.com/evanescence/test2/blob/master/SPEC.md much like Ring's. Github: https://github.com/evanescence/test2 Some background: It came out of discussionshttps://github.com/evanescence/test2/wiki/Communal-Brainstorming with the smart folks in #clojure, who were frustrated with the inflexibility of existing libs, and intended this to be the spiritual successor to clojure.test. We wanted something that was still simple like clojure.test, but could be extended externally much more easily in case you wanted features found in clojure.test, Midje, Speclj, or Expectations, or whatever else. This is a pre-ANN because it's more of a call for extensions. I've written one last night, test2-autorunnerhttps://github.com/evanescence/test2-autorunner, which took about an hour. This should give some idea of how easy it is and how well-designed the SPEC was by the smart folks of #clojure. There are some ideas at the bottom of the wiki, but of course any extensions are encouraged. -Steven -- -- 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. -- -- 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: [pre-ANN] test2, the last Clojure testing framework
Jay (and others), First of all, you must understand where test2 came from. It started as a bunch of people** in #clojure discussing what we'd change about clojure.test if we could. We realized we can't change clojure.test because (1) this would break backwards compatibility, and (2) clojure.test is really slow-moving since it lives inside Clojure. So the idea was to create a successor to clojure.test with the changes we wanted, and which didn't live inside Clojure. Hence the name test2. These very smart people were brainstorming for a few hours, and came up with some really good ideas. I started organizing their thoughts in a wiki, and was trying to guide the discussion with some provoking questions. Two high-level concepts kept recurring in the discussion. First, it should be really simple, building on Clojure concepts, and not using any special magic. The second one naturally follows from this: if it's just plain old no-magic Clojure, you can easily build on top of it. In other words, you get extensibility for free. This is when we realized that, if done right, test2 could be flexible enough where Midje/Speclj/Expectations could be re-written as extensions to test2. Or you could just use vanilla test2 similarly to clojure.test. Or you can mix and match extensions. Let me briefly say that I don't consider test2 to be my project. All I did was turn their ideas into a SPEChttps://github.com/evanescence/test2/blob/master/SPEC.mdand some code. I knew that everyone involved was too busy to do it, even though they wanted it to exist. So I jumped in and did my small part. You're suggesting we should have started with your lib and proposed changes. Let's generalize this for a second and say with anyone else's lib since there are other test-lib authors who might say the same thing. First of all, whose lib should we start with? Picking any existing one gives an unfair bias toward that lib's feature-set. Second of all, when a feature-set changes this drastically, it's usually clearer to see best solution from a blank slate. Third of all, this is intended to be a community-controlled lib, but each existing lib already has an owner in full control. But you're right. I shouldn't have just assumed the SPEC is ready and started calling for extensions. Sure, the initial conversation in IRC gave us a really solid starting-point, but let's admit that the SPEC isn't ready yet and needs work. I apologize for being so naive. I think we all agree that it's extremely important to discuss the SPEC as a community. In fact, since this is a pre-ANN, let's consider this thread the perfect place for such a discussion. For example, in its current incarnation, having once-fixtures a la clojure.test requires a custom runner, but it should really be part of a Definer's role. And there's some confusion as to whether Runners should give Reporters a lazy sequence of test-results or not, which would mean not actually running each test until the Reporter needs them to be run. Or, maybe the 4 roles defined in the SPEC are inadequate in the first place and need to be changed up somewhat. ** I'm not going to drop names in case they don't want to be part of this discussion, but maybe they'll come in here and affirm that what I'm saying isn't self-serving BS, but that it's all true and an accurate representation of the events. -Steven On Sun, Jun 9, 2013 at 11:45 AM, Jay Fields j...@jayfields.com wrote: I'd like to mention that expectations* has 0 open pull requests, 0 open issues, and is very actively maintained**. Steven, I don't want to discourage you from creating your own testing framework, I think everyone should, it's a very educational experience. I just wanted to be clear that no one has ever asked me for any help extending expectations, and anyone who chooses to use expectations should feel free to contact me with any suggestions. * https://github.com/jaycfields/expectations ** https://github.com/jaycfields/expectations/commits/master On Saturday, June 8, 2013 11:14:42 AM UTC-4, Steven Degutis wrote: Test2 is a new testing lib for Clojure, where the power is its simplicity, extensibility, and a SPEChttps://github.com/evanescence/test2/blob/master/SPEC.md much like Ring's. Github: https://github.com/**evanescence/test2https://github.com/evanescence/test2 Some background: It came out of discussionshttps://github.com/evanescence/test2/wiki/Communal-Brainstorming with the smart folks in #clojure, who were frustrated with the inflexibility of existing libs, and intended this to be the spiritual successor to clojure.test. We wanted something that was still simple like clojure.test, but could be extended externally much more easily in case you wanted features found in clojure.test, Midje, Speclj, or Expectations, or whatever else. This is a pre-ANN because it's more of a call for extensions. I've written one last night, test2-autorunnerhttps://github.com/evanescence/test2-autorunner,
Re: [pre-ANN] test2, the last Clojure testing framework
There's a few things that I know the SPEC needs to address. - Pending tests - Some flexible concept of around-all and around-each that allow separating Definers from Runners (currently, to implement clojure.test's once-fixtures, it requires a custom Definer *and* a custom Runner) - Whether Runners should pass lazy sequences to Reports - Being able to compose runners somehow (i.e. have an auto-runner that also runs them in random order, and runs tests in their own threads, three different runners being used together) Thoughts? -Steven On Sunday, June 9, 2013 1:07:20 PM UTC-5, Steven Degutis wrote: Jay (and others), First of all, you must understand where test2 came from. It started as a bunch of people** in #clojure discussing what we'd change about clojure.test if we could. We realized we can't change clojure.test because (1) this would break backwards compatibility, and (2) clojure.test is really slow-moving since it lives inside Clojure. So the idea was to create a successor to clojure.test with the changes we wanted, and which didn't live inside Clojure. Hence the name test2. These very smart people were brainstorming for a few hours, and came up with some really good ideas. I started organizing their thoughts in a wiki, and was trying to guide the discussion with some provoking questions. Two high-level concepts kept recurring in the discussion. First, it should be really simple, building on Clojure concepts, and not using any special magic. The second one naturally follows from this: if it's just plain old no-magic Clojure, you can easily build on top of it. In other words, you get extensibility for free. This is when we realized that, if done right, test2 could be flexible enough where Midje/Speclj/Expectations could be re-written as extensions to test2. Or you could just use vanilla test2 similarly to clojure.test. Or you can mix and match extensions. Let me briefly say that I don't consider test2 to be my project. All I did was turn their ideas into a SPEChttps://github.com/evanescence/test2/blob/master/SPEC.mdand some code. I knew that everyone involved was too busy to do it, even though they wanted it to exist. So I jumped in and did my small part. You're suggesting we should have started with your lib and proposed changes. Let's generalize this for a second and say with anyone else's lib since there are other test-lib authors who might say the same thing. First of all, whose lib should we start with? Picking any existing one gives an unfair bias toward that lib's feature-set. Second of all, when a feature-set changes this drastically, it's usually clearer to see best solution from a blank slate. Third of all, this is intended to be a community-controlled lib, but each existing lib already has an owner in full control. But you're right. I shouldn't have just assumed the SPEC is ready and started calling for extensions. Sure, the initial conversation in IRC gave us a really solid starting-point, but let's admit that the SPEC isn't ready yet and needs work. I apologize for being so naive. I think we all agree that it's extremely important to discuss the SPEC as a community. In fact, since this is a pre-ANN, let's consider this thread the perfect place for such a discussion. For example, in its current incarnation, having once-fixtures a la clojure.test requires a custom runner, but it should really be part of a Definer's role. And there's some confusion as to whether Runners should give Reporters a lazy sequence of test-results or not, which would mean not actually running each test until the Reporter needs them to be run. Or, maybe the 4 roles defined in the SPEC are inadequate in the first place and need to be changed up somewhat. ** I'm not going to drop names in case they don't want to be part of this discussion, but maybe they'll come in here and affirm that what I'm saying isn't self-serving BS, but that it's all true and an accurate representation of the events. -Steven On Sun, Jun 9, 2013 at 11:45 AM, Jay Fields wrote: I'd like to mention that expectations* has 0 open pull requests, 0 open issues, and is very actively maintained**. Steven, I don't want to discourage you from creating your own testing framework, I think everyone should, it's a very educational experience. I just wanted to be clear that no one has ever asked me for any help extending expectations, and anyone who chooses to use expectations should feel free to contact me with any suggestions. * https://github.com/jaycfields/expectations ** https://github.com/jaycfields/expectations/commits/master On Saturday, June 8, 2013 11:14:42 AM UTC-4, Steven Degutis wrote: Test2 is a new testing lib for Clojure, where the power is its simplicity, extensibility, and a SPEChttps://github.com/evanescence/test2/blob/master/SPEC.md much like Ring's. Github:
Re: Incanter 1.5.0 has been released!
For using Incanter in my onw projects I use Leiningen, but the *.exe and
*.jar files are cool to show Incanter to persons which have no IDE for
clojure right at hand (or any other toll/libarary which can be used with
clojure), and it is a nice tool to make some demos.
Am 09.06.2013 18:18, schrieb Alex Ott:
I'll try to upload new versions there during next days. Right now, the
simplest way to get new version is to create new lein project add
incanter as dependency:
(defproject test-incanter 0.1.0-SNAPSHOT
:description FIXME: write description
:url http://example.com/FIXME;
:license {:name Eclipse Public License
:url http://www.eclipse.org/legal/epl-v10.html}
:dependencies [[org.clojure/clojure 1.5.1]
[incanter 1.5.0]])
On Sun, Jun 9, 2013 at 5:09 PM, Marcus Lindner
marcus.goldritter.lind...@gmail.com
mailto:marcus.goldritter.lind...@gmail.com wrote:
Thanks for the new release.
Will the changes be also available in files which are downloadable
on this link (http://incanter.org/downloads/)?
I used these files often to create some ad hoc graphics or a
method to show others what can be done.
Am 09.06.2013 14 tel:09.06.2013%2014:16, schrieb Alex Ott:
I'm happy to announce, that Incanter 1.5.0 was pushed to
Clojars. Full list of changes is in the Changelog:
https://github.com/liebke/incanter/blob/master/Changes.md,
please check the Known issues section.
Incanter (http://incanter.org/) is a Clojure-based, R-like
platform for statistical computing and graphics. Incanter can
be used as a standalone, interactive data analysis environment
or embedded within other analytics systems as a modular suite
of libraries.
--
With best wishes,Alex Ott
http://alexott.net/
Twitter: alexott_en (English), alexott (Russian)
Skype: alex.ott
--
--
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
mailto: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
mailto:clojure%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 unsubscribe from this group and stop receiving emails from
it, send an email to clojure+unsubscr...@googlegroups.com
mailto:clojure%2bunsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
--
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
mailto: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
mailto:clojure%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 unsubscribe from this group and stop receiving emails from it,
send an email to clojure+unsubscr...@googlegroups.com
mailto:clojure%2bunsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
With best wishes,Alex Ott
http://alexott.net/
Twitter: alexott_en (English), alexott (Russian)
Skype: alex.ott
--
--
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.
--
--
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
Re: [pre-ANN] test2, the last Clojure testing framework
On Jun 9, 2013, at 1:07 PM, Steven Degutis sbdegu...@gmail.com wrote: I think we all agree that it's extremely important to discuss the SPEC as a community. In fact, since this is a pre-ANN, let's consider this thread the perfect place for such a discussion. I suggest that surveying users of the various existing tools for how they use them and what they want is a more important first step than worrying about a data model. For example, it would be good to know what parts of Midje that I personally obsess about are in fact unimportant to the typical user. Although open source projects (Midje, certainly) are about one's own itch, it also helps to see where the users are scratching. Latest book: /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 --- 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: [pre-ANN] test2, the last Clojure testing framework
On Sun, Jun 9, 2013 at 11:07 AM, Steven Degutis sbdegu...@gmail.com wrote: We realized we can't change clojure.test because (1) this would break backwards compatibility, and (2) clojure.test is really slow-moving since it lives inside Clojure. Are there any JIRA tickets open against clojure.test? That would seem to be a good place to start. There seem to be just three against clojure.test: CLJ-840 Add a way to access the current test var in :each fixtures for clojure.test CLJ-866 Provide a clojure.test function to run a single test case with fixtures CLJ-1209 Teach clojure.test reporting about ex-info/ex-data Sounds like CLJ-866 was covered in the discussions around test2 - not sure about the others? If someone (with a signed CA on file) wants to step up and maintain clojure.test, even tho' it's part of core Clojure right now, I expect a way to move forward with that could be found? Perhaps adding test.core as a new contrib library as a copy of clojure.test and deprecating clojure.test? But there is of course the basic question of whether a testing framework should be part of Clojure itself (as it is now) vs a contrib library (as test.generative is now) vs a third party library (as Midje, Expectations, Conjecture and others are right now). This is when we realized that, if done right, test2 could be flexible enough where Midje/Speclj/Expectations could be re-written as extensions to test2. I don't know whether a core testing library would offer enough commonality that those frameworks' authors would consider a rewrite to depend on a separate testing library worthwhile? Perhaps if it was a Clojure contrib library they might? You're suggesting we should have started with your lib and proposed changes. I don't think that's what Jay is saying. I certainly didn't interpret his post that way. I think all he was saying - and I think all Brian is saying about Midje - is that people aren't asking them for the kind of extension points etc that you seem to want for test2. Personally, I think Midje is too complicated for my needs - but it's certainly very slick - so although I've looked at it a couple of times, I've never felt like adopting it. At World Singles, we started out with clojure.test by default and just over a year ago converted our entire test suite to Expectations instead because it's simpler and cleaner and much, much easier to read than clojure.test. We since wrote a whole bunch of tests based on clj-webdriver to replace some Selenium (HTML-based) tests and clojure.test is a better fit there so we've started using it again, just for that. [specifically, our webdriver tests tend to be do a bunch of browser stuff, assert some conditions with `is`, do more browser stuff, assert more stuff, click around some more, assert some more, etc] Is there room for another testing framework? Certainly. Could clojure.test be improved? Definitely. Is there some standalone infrastructure that all testing frameworks could be based on? Maybe. Is that compelling enough that other testing framework authors would rewrite their libraries in terms of some common infrastructure? Given their existing libraries work just fine - and there are Emacs modes and auto runners for them already - I'm very skeptical. On the other hand, there are definitely compelling tools that would benefit from a common data structure for test run reports: displaying results / failures to the console, feeding to JUnit HTML report formatters (where current frameworks are pretty weak), supporting a standard way to display red/green results in editors and IDEs (again, existing frameworks are weak here). My point is that folks either use clojure.test (and may grumble a bit about its shortcomings - but not much based on how few JIRA tickets exist) or they switch to a third party framework they prefer - but across the board tooling is the weak spot (IMO). So I wouldn't spend much time on the test machinery itself and the API that test2 exposes since that's all very subjective - but I think the test result SPEC is potentially very fruitful and could benefit all the frameworks... -- 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 --- 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,
Re: [pre-ANN] test2, the last Clojure testing framework
FWIW, about the only thing about clojure.test that I miss occasionally when using Expectations is 'each' fixtures for a subset of tests but the work involved in wrapping an expression in a try/finally with the resource setup and tear down I need is usually so minimal that's it's not even worth writing a macro to standardize the boilerplate (at least, it hasn't annoyed me sufficiently to make it worth doing yet). Sean On Sun, Jun 9, 2013 at 4:57 PM, Steven Degutis sbdegu...@gmail.com wrote: I agree, we should survey users of existing tools. The thing is, we *are* those users. The aforementioned brainstorming session was just what you're suggesting. That's what I'm suggesting this mailing list thread be. For example, I never use Midje's a = b outside of a macro. I always wrap fact around it like (fact a = b). Firstly because it's clearer to skim for assertions this way. Secondly it works much better with paredit. Now you know how I feel about Midje. If more people chime in with thoughts like this, then we'll have pretty good data to start with. -Steven On Sunday, June 9, 2013 6:11:38 PM UTC-5, Brian Marick wrote: On Jun 9, 2013, at 1:07 PM, Steven Degutis sbde...@gmail.com wrote: I think we all agree that it's extremely important to discuss the SPEC as a community. In fact, since this is a pre-ANN, let's consider this thread the perfect place for such a discussion. I suggest that surveying users of the various existing tools for how they use them and what they want is a more important first step than worrying about a data model. For example, it would be good to know what parts of Midje that I personally obsess about are in fact unimportant to the typical user. Although open source projects (Midje, certainly) are about one's own itch, it also helps to see where the users are scratching. Latest book: /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 --- 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. -- 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 --- 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: [pre-ANN] test2, the last Clojure testing framework
Are there any JIRA tickets open against clojure.test? That would seem to be a good place to start. Good idea, that helps for gathering data about use-cases. If someone (with a signed CA on file) wants to step up and maintain clojure.test, even tho' it's part of core Clojure right now, I expect a way to move forward with that could be found? Perhaps adding test.core as a new contrib library as a copy of clojure.test and deprecating clojure.test? Changing clojure.test seems like the wrong way to go. Being attached to a CA makes it hard to contribute to. Being attached to Clojure makes it too slow-moving. I think everyone involved in the IRC discussion agreed that clojure.test should be deprecated it in favor of a backward-compatible, faster-moving successor. I'm certainly all for it. But there is of course the basic question of whether a testing framework should be part of Clojure itself (as it is now) vs a contrib library (as test.generative is now) vs a third party library (as Midje, Expectations, Conjecture and others are right now). Being a third-party lib seems to me like the easiest way for it to grow and evolve properly. But maybe being a contrib-lib isn't a bad idea. I really don't know much about them and how they work. You're suggesting we should have started with your lib and proposed changes. I don't think that's what Jay is saying. I certainly didn't interpret his post that way. I think all he was saying - and I think all Brian is saying about Midje - is that people aren't asking them for the kind of extension points etc that you seem to want for test2. But that's what I meant, that he's proposing we start with his lib and add extensibility in the places we want it. So my response to that still applies. Personally, I think Midje is too complicated for my needs - but it's certainly very slick - so although I've looked at it a couple of times, I've never felt like adopting it. At World Singles, we started out with clojure.test by default and just over a year ago converted our entire test suite to Expectations instead because it's simpler and cleaner and much, much easier to read than clojure.test. We since wrote a whole bunch of tests based on clj-webdriver to replace some Selenium (HTML-based) tests and clojure.test is a better fit there so we've started using it again, just for that. [specifically, our webdriver tests tend to be do a bunch of browser stuff, assert some conditions with `is`, do more browser stuff, assert more stuff, click around some more, assert some more, etc] Think about it this way: you really just wanted to change how assertions were written. But you had to switch libs entirely. With test2, you'd just have to add a new dependency, and start writing new tests with the new assertion functions, while the old tests kept on working. Then you could rewrite old tests progressively. Until that was done, they could live side by side in your project comfortably. That's part of the goal of test2. Is there room for another testing framework? Certainly. Could clojure.test be improved? Definitely. Is there some standalone infrastructure that all testing frameworks could be based on? Maybe. Is that compelling enough that other testing framework authors would rewrite their libraries in terms of some common infrastructure? Given their existing libraries work just fine - and there are Emacs modes and auto runners for them already - I'm very skeptical. In my experience, when a tool comes out that people think is genuinely better, these things work themselves out. See how nrepl.el replaced swank. How leiningen replaced cake. How ring+compojure placed webjure and others. How Clojure replaced Ruby and CL and Python for a lot of us. When people believe in a tool, extensions for it will get written. Emacs plugins will get written or adapted. They'll do it because they really want to use it. I admit that this point won't come until it's actually got several extensions written to prove it's worth. That task probably falls on me for a little while, until the ball gets rolling. On the other hand, there are definitely compelling tools that would benefit from a common data structure for test run reports: displaying results / failures to the console, feeding to JUnit HTML report formatters (where current frameworks are pretty weak), supporting a standard way to display red/green results in editors and IDEs (again, existing frameworks are weak here). Right! Being able to do these things is one of the main points! My point is that folks either use clojure.test (and may grumble a bit about its shortcomings - but not much based on how few JIRA tickets exist) or they switch to a third party framework they prefer - but across the board tooling is the weak spot (IMO). So I wouldn't spend much time on the test machinery itself and the API that test2 exposes
Re: [pre-ANN] test2, the last Clojure testing framework
On Sun, Jun 9, 2013 at 5:50 PM, Steven Degutis sbdegu...@gmail.com wrote: Changing clojure.test seems like the wrong way to go. Being attached to a CA makes it hard to contribute to. It's a one-off action. Sign it, send it in. Then you can contribute to Clojure or any of its contrib libraries from then on. Not exactly hard. Being attached to Clojure makes it too slow-moving. Not true. Go look at the contrib libraries and see how they have evolved. Nothing holds them back. The number of contributors - and the number of libraries - is growing all the time. I think everyone involved in the IRC discussion agreed that clojure.test should be deprecated it in favor of a backward-compatible, faster-moving successor. I'm certainly all for it. A backward-compatible, faster-moving successor is certainly possible within the contrib system. It is more likely to be used as a dependency by other libraries and it is more discoverable. But maybe being a contrib-lib isn't a bad idea. I really don't know much about them and how they work. Don't dismiss it until you know more about them and the process involved. If clojure.test was replaced within the contrib context, I'd be far more likely to contribute to it than to some random third-party library. But that's what I meant, that he's proposing we start with his lib and add extensibility in the places we want it. So my response to that still applies. Your response was to a point he didn't make. In my experience, when a tool comes out that people think is genuinely better, these things work themselves out. See how nrepl.el replaced swank. How leiningen replaced cake. How ring+compojure placed webjure and others. How Clojure replaced Ruby and CL and Python for a lot of us. True, but none of those were part of Clojure or contrib - and tools.nrepl IS part of contrib now. The low number of JIRA tickets probably says more about JIRA than clojure.test. You said those 3 tickets were the only ones against clojure.test, but in the discussion there were many more complaints. Yes, people tend to complain but don't actually do anything about it - they don't open tickets - so nothing gets done :) -- 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 --- 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: [pre-ANN] test2, the last Clojure testing framework
On Sunday, June 9, 2013 8:50:46 PM UTC-4, Steven Degutis wrote: But that's what I meant, that he's proposing we start with his lib and add extensibility in the places we want it. So my response to that still applies. That's not at all what I said, proposed, alluded to, or anything of the sort. I'll use quotes, perhaps that will make things easier - though I'm skeptical at this point. You said: ..were frustrated with the inflexibility of existing libs.. I pointed out: ..expectations* has 0 open pull requests, 0 open issues, and is very actively maintained.. Further, I wanted to make sure it was clear that ..anyone who chooses to use expectations should feel free to contact me with any suggestions.. That's the only thing I said. I have no desire to integrate with test2. I'll leave it at that. -- -- 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: [pre-ANN] test2, the last Clojure testing framework
Is this still current? http://clojure.github.io/clojure-contrib/ On Sunday, June 9, 2013 8:19:15 PM UTC-5, Sean Corfield wrote: On Sun, Jun 9, 2013 at 5:50 PM, Steven Degutis sbde...@gmail.comjavascript: wrote: Changing clojure.test seems like the wrong way to go. Being attached to a CA makes it hard to contribute to. It's a one-off action. Sign it, send it in. Then you can contribute to Clojure or any of its contrib libraries from then on. Not exactly hard. Being attached to Clojure makes it too slow-moving. Not true. Go look at the contrib libraries and see how they have evolved. Nothing holds them back. The number of contributors - and the number of libraries - is growing all the time. I think everyone involved in the IRC discussion agreed that clojure.test should be deprecated it in favor of a backward-compatible, faster-moving successor. I'm certainly all for it. A backward-compatible, faster-moving successor is certainly possible within the contrib system. It is more likely to be used as a dependency by other libraries and it is more discoverable. But maybe being a contrib-lib isn't a bad idea. I really don't know much about them and how they work. Don't dismiss it until you know more about them and the process involved. If clojure.test was replaced within the contrib context, I'd be far more likely to contribute to it than to some random third-party library. But that's what I meant, that he's proposing we start with his lib and add extensibility in the places we want it. So my response to that still applies. Your response was to a point he didn't make. In my experience, when a tool comes out that people think is genuinely better, these things work themselves out. See how nrepl.el replaced swank. How leiningen replaced cake. How ring+compojure placed webjure and others. How Clojure replaced Ruby and CL and Python for a lot of us. True, but none of those were part of Clojure or contrib - and tools.nrepl IS part of contrib now. The low number of JIRA tickets probably says more about JIRA than clojure.test. You said those 3 tickets were the only ones against clojure.test, but in the discussion there were many more complaints. Yes, people tend to complain but don't actually do anything about it - they don't open tickets - so nothing gets done :) -- 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 --- 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: [pre-ANN] test2, the last Clojure testing framework
No. Read http://dev.clojure.org/display/design/Where+Did+Clojure.Contrib+Go On Sun, Jun 9, 2013 at 6:41 PM, Steven Degutis sbdegu...@gmail.com wrote: Is this still current? http://clojure.github.io/clojure-contrib/ On Sunday, June 9, 2013 8:19:15 PM UTC-5, Sean Corfield wrote: On Sun, Jun 9, 2013 at 5:50 PM, Steven Degutis sbde...@gmail.com wrote: Changing clojure.test seems like the wrong way to go. Being attached to a CA makes it hard to contribute to. It's a one-off action. Sign it, send it in. Then you can contribute to Clojure or any of its contrib libraries from then on. Not exactly hard. Being attached to Clojure makes it too slow-moving. Not true. Go look at the contrib libraries and see how they have evolved. Nothing holds them back. The number of contributors - and the number of libraries - is growing all the time. I think everyone involved in the IRC discussion agreed that clojure.test should be deprecated it in favor of a backward-compatible, faster-moving successor. I'm certainly all for it. A backward-compatible, faster-moving successor is certainly possible within the contrib system. It is more likely to be used as a dependency by other libraries and it is more discoverable. But maybe being a contrib-lib isn't a bad idea. I really don't know much about them and how they work. Don't dismiss it until you know more about them and the process involved. If clojure.test was replaced within the contrib context, I'd be far more likely to contribute to it than to some random third-party library. But that's what I meant, that he's proposing we start with his lib and add extensibility in the places we want it. So my response to that still applies. Your response was to a point he didn't make. In my experience, when a tool comes out that people think is genuinely better, these things work themselves out. See how nrepl.el replaced swank. How leiningen replaced cake. How ring+compojure placed webjure and others. How Clojure replaced Ruby and CL and Python for a lot of us. True, but none of those were part of Clojure or contrib - and tools.nrepl IS part of contrib now. The low number of JIRA tickets probably says more about JIRA than clojure.test. You said those 3 tickets were the only ones against clojure.test, but in the discussion there were many more complaints. Yes, people tend to complain but don't actually do anything about it - they don't open tickets - so nothing gets done :) -- 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 --- 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. -- 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 --- 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: [pre-ANN] test2, the last Clojure testing framework
Then I apologize. I must have conflated what you said with what someone else said. My mistake. On Sunday, June 9, 2013 8:38:22 PM UTC-5, Jay Fields wrote: On Sunday, June 9, 2013 8:50:46 PM UTC-4, Steven Degutis wrote: But that's what I meant, that he's proposing we start with his lib and add extensibility in the places we want it. So my response to that still applies. That's not at all what I said, proposed, alluded to, or anything of the sort. I'll use quotes, perhaps that will make things easier - though I'm skeptical at this point. You said: ..were frustrated with the inflexibility of existing libs.. I pointed out: ..expectations* has 0 open pull requests, 0 open issues, and is very actively maintained.. Further, I wanted to make sure it was clear that ..anyone who chooses to use expectations should feel free to contact me with any suggestions.. That's the only thing I said. I have no desire to integrate with test2. I'll leave it at that. -- -- 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: [pre-ANN] test2, the last Clojure testing framework
This may be a little off topic, but does this, or any other framework, solve some testing inconveniences that exist in Clojure and probably other functional languages: 1) testing recursive functions. I want to test what a recursion STEP does, not the whole function. Can I mock 'recur'? 2) testing sequence, esp. lazy 3) IoC typically makes code more testable. What are Clojure alternatives for IoC? Pass all dependencies as parameters to your function? I wonder if code=data philosophy of Lisp enables some testing techniques that are impossible in languages like Java. Typically you can only test a function programmatically, not arbitrary code block. But you can probably introspect code very easily in Clojure, and test parts, regardless if they are functions or not. A test framework could support that in principle... I found that functional code is harder to separate, which would make it harder to test... Any thoughts? Thanks, Julian -- -- 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: [pre-ANN] test2, the last Clojure testing framework
Ooh, okay a little off topic here, but Expectations looks fantastic. Thanks a lot Jay! -- -- 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.
