Re: Best IDE

[Catonano]

Jay,


2013/6/8 Jay Fields 

> My favorite recent addition - I can run my app from within emacs, allowing
> me to change my app with a simple C-x C-e and see my changes immediately in
> the running app (no restart, refresh or reload necessary).


Would you mind to extend on that ?

How is this done, exactly ?

>

-- 
-- 
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

[Meikel Brandmeyer (kotarak)]

I sense a misunderstanding of transients in this message.

Am Sonntag, 9. Juni 2013 18:51:00 UTC+2 schrieb Steven Degutis:
>
> 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.
>
>
Transients are supposed to be used like their normal counterparts: in a 
functional way. So you won't get around a reference type. Transients are a 
pure optimisation when constructing a data structure. They are not intended 
as faster drop-in replacement.

Kind regards
Meikel
 

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
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

[Peter Taoussanis]

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.

Re: [pre-ANN] test2, the last Clojure testing framework

[julianrz]

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

[Steven Degutis]

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

[Sean Corfield]

No. Read http://dev.clojure.org/display/design/Where+Did+Clojure.Contrib+Go

On Sun, Jun 9, 2013 at 6:41 PM, Steven Degutis  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  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

[Steven Degutis]

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 
> > 
> 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

[Jay Fields]

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

[Sean Corfield]

On Sun, Jun 9, 2013 at 5:50 PM, Steven Degutis  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

[Steven Degutis]

> 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 
> muc

Re: [pre-ANN] test2, the last Clojure testing framework

[Sean Corfield]

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  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  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

[Steven Degutis]

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 > 
> 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

[Sean Corfield]

On Sun, Jun 9, 2013 at 11:07 AM, Steven Degutis  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

[Brian Marick]

On Jun 9, 2013, at 1:07 PM, Steven Degutis  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: Incanter 1.5.0 has been released!

[Marcus Lindner]

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 
> 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 :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.





--
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.c

Re: [pre-ANN] test2, the last Clojure testing framework

[Steven Degutis]

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 
> SPECand 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 
>>> SPEC

Re: [pre-ANN] test2, the last Clojure testing framework

[Steven Degutis]

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
SPECand 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 
>> SPEC much
>> like Ring's.
>>
>> Github: 
>> https://github.com/**evanescence/test2
>>
>> Some background: It came out of 
>> discussions
>>  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-autorunner

Re: [pre-ANN] test2, the last Clojure testing framework

[Steven Degutis]

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 
> > wrote:
>
>> Test2 is a new testing lib for Clojure, where the power is its 
>> simplicity, extensibility, and a 
>> SPEC much 
>> like Ring's.
>>
>> Github: https://github.com/evanescence/test2
>>
>> Some background: It came out of 
>> discussions
>>  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-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.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=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 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: Refactoring tools

[Jay Fields]

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 wrote:
>>
>>> 2013/3/22 Daniel Glauser 
>>>
 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 wrote:
>
>> 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.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-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 

Re: Refactoring tools

[Jay Fields]

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 
> 
> > wrote:
>
>> 2013/3/22 Daniel Glauser >
>>
>>> 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 wrote:

> 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.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-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...@**googlegro

Re: [pre-ANN] test2, the last Clojure testing framework

[Jay Fields]

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 
> SPEC much 
> like Ring's.
>
> Github: https://github.com/evanescence/test2
>
> Some background: It came out of 
> discussions 
> 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-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: Incanter 1.5.0 has been released!

[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> 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: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+unsubscribe@**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+unsubscribe@**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+unsubscribe@**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+unsubscribe@**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.

Re: Incanter 1.5.0 has been released!

[Marcus Lindner]

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: Refactoring tools

[Ye He]

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: Refactoring tools

[Ye He]

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: idiot question about macros

[David Pollak]

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  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  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.

Incanter 1.5.0 has been released!

[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.

Re: Idiomatic way to write dependency resolving algorithms?

[Casper Clausen]

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.

Re: Idiomatic way to write dependency resolving algorithms?

[Casper Clausen]

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: [pre-ANN] test2, the last Clojure testing framework

[Stuart Halloway]

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  wrote:

> Test2 is a new testing lib for Clojure, where the power is its simplicity,
> extensibility, and a 
> SPEC much
> like Ring's.
>
> Github: https://github.com/evanescence/test2
>
> Some background: It came out of 
> discussions 
> 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-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: feeding leiningen a local JAR file

[Korny Sietsma]

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  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/
>>
>>
>>
>> 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.