Re: No :out in my nREPL responses

2017-03-16 Thread Colin Fleming 
Hi Terje,

When you say the "standard" REPL in Cursive, are you referring to the "Use
nREPL in normal JVM process" option, or the "Use clojure.main in normal JVM
process" option? Obviously the first does use nREPL, but doesn't go through
lein - Cursive just runs a JVM process, starts a bare-bones nREPL server in
it and connects to it. If you haven't tried that option, it might be worth
trying to see if the issue is in nREPL or in lein.

Cheers,
Colin

On 17 March 2017 at 11:05, Terje Dahl  wrote:

> UPDATE:
> I only just discovered:
> It *does* work as expected when I run it from the "standard" REPL in JVM
> (in IntelliJ/Cursive),
> And it *does* work as expected when I run it in my own "home grown" REPL
> stack.
> It does *not* work as expected when running it in any variant of nREPL -
> including:
>  - Through IntelliJ/Cursive
>  - In command-line via `lein repl` (which is simply nREPL)
>
> So I have a potential solution, (and a possible nREPL bug), but it would
> be valuable to understand the cause of the issue.
>
>
>
> On Thursday, March 16, 2017 at 10:24:21 PM UTC+1, Terje Dahl wrote:
>>
>> I am attempting to embed an nREPL server in my application (version
>> 0.2.12).  Everything seems to work nicely, except I am not able to get any
>> out from print statements et al.  Even the basic example on the README
>> "(time (reduce + (range 1e6)))" doesn't work for me: I do not get back the
>> map containing the :out, but I get the two remaining.
>>
>> After two days of studying the source code of tools.nrepl (including the
>> testing code),  leiningen.repl, reply, and a myriad of things online, I am
>> getting rather frustrated.
>>
>> It seems to maybe have something to do with *out*, but I can't figure it
>> out. Any hints at debugging it will be much appreciated.
>>
>> Also, any resources for "tool makers" would be of interest.
>>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: No :out in my nREPL responses

2017-03-16 Thread Terje Dahl 
UPDATE:
I only just discovered: 
It *does* work as expected when I run it from the "standard" REPL in JVM 
(in IntelliJ/Cursive),
And it *does* work as expected when I run it in my own "home grown" REPL 
stack.
It does *not* work as expected when running it in any variant of nREPL - 
including:
 - Through IntelliJ/Cursive
 - In command-line via `lein repl` (which is simply nREPL)

So I have a potential solution, (and a possible nREPL bug), but it would be 
valuable to understand the cause of the issue.



On Thursday, March 16, 2017 at 10:24:21 PM UTC+1, Terje Dahl wrote:
>
> I am attempting to embed an nREPL server in my application (version 
> 0.2.12).  Everything seems to work nicely, except I am not able to get any 
> out from print statements et al.  Even the basic example on the README 
> "(time (reduce + (range 1e6)))" doesn't work for me: I do not get back the 
> map containing the :out, but I get the two remaining.
>
> After two days of studying the source code of tools.nrepl (including the 
> testing code),  leiningen.repl, reply, and a myriad of things online, I am 
> getting rather frustrated.
>
> It seems to maybe have something to do with *out*, but I can't figure it 
> out. Any hints at debugging it will be much appreciated.
>
> Also, any resources for "tool makers" would be of interest.
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

No :out in my nREPL responses

2017-03-16 Thread Terje Dahl 
I am attempting to embed an nREPL server in my application (version 
0.2.12).  Everything seems to work nicely, except I am not able to get any 
out from print statements et al.  Even the basic example on the README 
"(time (reduce + (range 1e6)))" doesn't work for me: I do not get back the 
map containing the :out, but I get the two remaining.

After two days of studying the source code of tools.nrepl (including the 
testing code),  leiningen.repl, reply, and a myriad of things online, I am 
getting rather frustrated.

It seems to maybe have something to do with *out*, but I can't figure it 
out. Any hints at debugging it will be much appreciated.

Also, any resources for "tool makers" would be of interest.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ANN] Virgil 0.1.6

2017-03-16 Thread Ralf Schmitt 
Zach Tellman  writes:

> I figured it was worth reminding everyone that this library 
> exists: https://github.com/ztellman/virgil.

Hi Zach,

thanks for the reminder. I've read about Virgil some weeks ago, and
today I thought I could use this project, but couldn't remember the
name.

I'm using it with around 8k lines of java code and so far everything
seems to work.

Thanks for your work on this project!

-- 
Cheers
Ralf

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Handling dependency conflicts

2017-03-16 Thread Daniel Compton 
One option to help with this is OSGi which does have support in Clojure.
https://github.com/talios/clojure.osgi

As Stuart alluded to in his message, the cure to dependency conflicts
(OSGi) may be worse than the disease. I’d guess that the venn diagram of
people using both Clojure and OSGi is pretty thin. There is also
Jigsaw/JPMS in the upcoming Java 9 which is another take on modularity:
https://www.infoq.com/articles/java9-osgi-future-modularity.

On Fri, Mar 17, 2017 at 5:20 AM  wrote:

> Howard, thanks for posting that library. I've passed on the info to some
> of the other developers at work. That kind of tool is highly valuable, I'll
> likely start using it soon.
>
> Gary, the MrAnderson approach sounds similar to shading; I'll take a look
> today.
>
> Stuart, the most common approach boils down to trust and hope, and I don't
> think it's good enough. As projects grow larger the likelihood of running
> into incompatibilities also grows, regardless of community etiquette. Thank
> you for suggesting :pendantic.
>
>
> On Tuesday, March 14, 2017 at 4:49:50 PM UTC-4, Howard M. Lewis Ship wrote:
>
> We have some very, very complex projects that bring in boat-loads of
> dependencies, some of which will have version conflicts, if left
> unchecked.  I've created a Leiningen plugin, vizdeps, to make it easier to
> see the artifact tree, identify and repair conflicts, and determine why any
> particular artifacts are in the build.
>
> https://github.com/walmartlabs/vizdeps
>
> On Mon, Mar 13, 2017 at 1:45 PM, Stuart Sierra 
> wrote:
>
> This is a well-known problem in the JVM world, not just Clojure.
>
> The most common approach is: Always use the latest versions, and don't
> break backwards-compatibility.
>
> Most open-source Java and Clojure libraries are careful about not breaking
> backwards-compatibility. So in general, you're safe choosing the latest
> version of any library.
>
> Leiningen has the `:pedantic` option which can be set to warn or fail when
> there are possible dependency conflicts.
>
> Neither Clojure nor the JVM has explicit support for linking to specific
> versions of a library. Work-arounds exist, but they often increase overall
> complexity and lead to conflicts which are harder to debug.
>
> –S
>
>
> On Monday, March 13, 2017 at 4:13:19 PM UTC-4, arthur wrote:
>
> Hello All,
>
>
>  I have a general inquiry regarding conflicting dependencies in
> Clojure projects and how they affect applications at runtime. I believe
> this is a common problem faced by many languages in this day and age where
> we try not to reinvent the wheel by depending on the work of others.
> Basically: my application depends on libraries *A*, *B*, *C*, and *D*.
> Libraries *B*, *C*, *D* *also* depend on library *A*, but all of us
> depend on *different versions* of library *A.* Leiningen thankfully warns
> us in many of these situations by suggesting exclusions. However, how can I
> possibly know that something hasn't broken? Stringent testing can give a
> certain degree of confidence that things are still working, but it would
> seem to me that to ensure correctness, we should include *all* versions
> of the dependencies and have the functions link to their respective
> *versioned* identites. Does anyone have advice on how they solve these
> kinds of problems on their codebases in the wild? Thankfully nothing has
> broken yet (to my knowledge), but it seems we have very few assurances here
> and the best we can do is *hope* nothing is broken. Any advice is much
> appreciated.
>
> Thanks,
>
> Arthur
>
> --
> 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/d/optout.
>
>
>
>
> --
> Howard M. Lewis Ship
>
> Senior Mobile Developer at Walmart Labs
>
> Creator of Apache Tapestry
>
> (971) 678-5210
> http://howardlewisship.com
> @hlship
>
> --
> 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 unsubs

Re: [ANN] Virgil 0.1.6

2017-03-16 Thread Zach Tellman 
The code is split into a library and a minimal Leiningen plugin which runs 
it at startup.  If someone wants to contribute a Boot equivalent, I'm happy 
to accept that PR.

On Thursday, March 16, 2017 at 11:18:16 AM UTC-7, Gregg Reynolds wrote:
>
>
>
> On Mar 16, 2017 1:13 PM, "Zach Tellman" > 
> wrote:
>
> I figured it was worth reminding everyone that this library exists: 
> https://github.com/ztellman/virgil.  It now seems to work on Java 
> projects of arbitrary size and structure (the in-process compiler is very 
> fussy about compile order, you need to topologically sort the classes), and 
> I've been using it extensively this last month while writing a bunch of 
> Java [1].  I can tweak some Java, wait a second, and then test that code at 
> the REPL.  It's been pretty game-changing for my workflow.
>
> If anyone has questions, I'm happy to answer them.
>
>
> wow!  looks great, when's the boot version due out? 😊
>
>
> Zach
>
> [1] https://github.com/lacuna/bifurcan
>
> -- 
> 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/d/optout.
>
>
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ANN] Virgil 0.1.6

2017-03-16 Thread Gregg Reynolds 
On Mar 16, 2017 1:13 PM, "Zach Tellman"  wrote:

I figured it was worth reminding everyone that this library exists:
https://github.com/ztellman/virgil.  It now seems to work on Java projects
of arbitrary size and structure (the in-process compiler is very fussy
about compile order, you need to topologically sort the classes), and I've
been using it extensively this last month while writing a bunch of Java
[1].  I can tweak some Java, wait a second, and then test that code at the
REPL.  It's been pretty game-changing for my workflow.

If anyone has questions, I'm happy to answer them.


wow!  looks great, when's the boot version due out? 😊


Zach

[1] https://github.com/lacuna/bifurcan

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with
your first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[ANN] Virgil 0.1.6

2017-03-16 Thread Zach Tellman 
I figured it was worth reminding everyone that this library 
exists: https://github.com/ztellman/virgil.  It now seems to work on Java 
projects of arbitrary size and structure (the in-process compiler is very 
fussy about compile order, you need to topologically sort the classes), and 
I've been using it extensively this last month while writing a bunch of 
Java [1].  I can tweak some Java, wait a second, and then test that code at 
the REPL.  It's been pretty game-changing for my workflow.

If anyone has questions, I'm happy to answer them.

Zach

[1] https://github.com/lacuna/bifurcan

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: go local variable binding

2017-03-16 Thread Timothy Baldridge 
Yes, dynamic vars do not exist in CLJS, so naturally binding doesn't work
as you would expect.

On Thu, Mar 16, 2017 at 11:36 AM, Christian Weilbach <
whitesp...@polyc0l0r.net> wrote:

> You cannot do so in cljs though:
> http://dev.clojure.org/jira/browse/CLJS-1634
>
> Just in case you expect to write cross-platform code with dynamic bindings.
>
>
> Am 16.03.2017 um 01:01 schrieb Timothy Baldridge:
> > Yes, that should work fine, do your tests confirm otherwise? Also if
> > you're not doing a recur there's no reason to use `go-loop` you can just
> > use `go`.
> >
> > On Wed, Mar 15, 2017 at 4:44 PM, Eran Levi  > > wrote:
> >
> > Hi,
> > can I bind variables, same as I do for threads, for go routines, to
> > be local only for a particular go routine, and if I can't, how would
> > you mimic this behavior ?
> >
> > |
> > (defn print-stuff [s]
> >   (println s))
> >
> > (go-loop []
> >(binding [*out*(clojure.java.io/writer "foo.txt")]
> >   (print-stuff)))
> >
> > (go-loop []
> >(binding [*out*(clojure.java.io/writer "bar.txt")]
> >   (print-stuff)))
> > |
> >
> >
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Clojure" group.
> > To post to this group, send email to clojure@googlegroups.com
> > 
> > Note that posts from new members are moderated - please be patient
> > with your first post.
> > To unsubscribe from this group, send email to
> > clojure+unsubscr...@googlegroups.com
> > 
> > For more options, visit this group at
> > http://groups.google.com/group/clojure?hl=en
> > 
> > ---
> > You received this message because you are subscribed to the Google
> > Groups "Clojure" group.
> > To unsubscribe from this group and stop receiving emails from it,
> > send an email to clojure+unsubscr...@googlegroups.com
> > .
> > For more options, visit https://groups.google.com/d/optout
> > .
> >
> >
> >
> >
> > --
> > “One of the main causes of the fall of the Roman Empire was that–lacking
> > zero–they had no way to indicate successful termination of their C
> > programs.”
> > (Robert Firth)
> >
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Clojure" group.
> > To post to this group, send email to clojure@googlegroups.com
> > Note that posts from new members are moderated - please be patient with
> > your first post.
> > To unsubscribe from this group, send email to
> > clojure+unsubscr...@googlegroups.com
> > For more options, visit this group at
> > http://groups.google.com/group/clojure?hl=en
> > ---
> > You received this message because you are subscribed to the Google
> > Groups "Clojure" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> > an email to clojure+unsubscr...@googlegroups.com
> > .
> > For more options, visit https://groups.google.com/d/optout.
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
“One of the main causes of the fall of the Roman Empire was that–lacking
zero–they had no way to indicate successful termination of their C
programs.”
(Robert Firth)

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: go local variable binding

2017-03-16 Thread Christian Weilbach 
You cannot do so in cljs though:
http://dev.clojure.org/jira/browse/CLJS-1634

Just in case you expect to write cross-platform code with dynamic bindings.


Am 16.03.2017 um 01:01 schrieb Timothy Baldridge:
> Yes, that should work fine, do your tests confirm otherwise? Also if
> you're not doing a recur there's no reason to use `go-loop` you can just
> use `go`.
> 
> On Wed, Mar 15, 2017 at 4:44 PM, Eran Levi  > wrote:
> 
> Hi,
> can I bind variables, same as I do for threads, for go routines, to
> be local only for a particular go routine, and if I can't, how would
> you mimic this behavior ?
> 
> |
> (defn print-stuff [s]
>   (println s))
> 
> (go-loop []
>(binding [*out*(clojure.java.io/writer "foo.txt")]
>   (print-stuff)))
> 
> (go-loop []
>(binding [*out*(clojure.java.io/writer "bar.txt")]
>   (print-stuff)))
> |
> 
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> 
> Note that posts from new members are moderated - please be patient
> with your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> 
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> 
> ---
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to clojure+unsubscr...@googlegroups.com
> .
> For more options, visit https://groups.google.com/d/optout
> .
> 
> 
> 
> 
> -- 
> “One of the main causes of the fall of the Roman Empire was that–lacking
> zero–they had no way to indicate successful termination of their C
> programs.”
> (Robert Firth)
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to clojure+unsubscr...@googlegroups.com
> .
> For more options, visit https://groups.google.com/d/optout.


-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Re: Combinatorics partitions that preserves adjacency?

2017-03-16 Thread Paul Gowder 
For sake of completeness/if this is useful for anyone else, a full 
implementation of the number-the-possible-split-locations method, including the 
original API with :min and :max options. Could probably be tidied up with 
transducers and such for all those filters but does the job. 

(require '[clojure.math.combinatorics :as c])
(defn breaks->partition 
  ([v brks]
   (breaks->partition 0 [] v brks))
  ([start pars v brks]
   (if (empty? brks)
 (conj pars (subvec v start (count v)))
 (let [this-part (subvec v start (first brks))]
   (recur (first brks) (conj pars this-part) v (rest brks))

(defn min-parts [min splits]
  (>= (count splits) (- min 1)))

(defn max-parts [max splits]
  (<= (count splits) (- max 1)))

(defn ordered-partitions [v & {:keys [max min]}]
  (let 
[s (c/subsets (range 1 (count v)))
 fs (cond
  (and max min) 
  (filter 
(partial max-parts max) 
(filter (partial min-parts min) s))
  max (filter (partial max-parts max) s)
  min (filter (partial min-parts min) s)
  :else s)]
(map (partial breaks->partition v) fs)))

It does, alas, take more than 10 times as long as Mike's version.  Which proves 
that one should never try to do anything faster than the core.matrix guy.  :-) 

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Handling dependency conflicts

2017-03-16 Thread arthur 
Howard, thanks for posting that library. I've passed on the info to some of 
the other developers at work. That kind of tool is highly valuable, I'll 
likely start using it soon.

Gary, the MrAnderson approach sounds similar to shading; I'll take a look 
today.

Stuart, the most common approach boils down to trust and hope, and I don't 
think it's good enough. As projects grow larger the likelihood of running 
into incompatibilities also grows, regardless of community etiquette. Thank 
you for suggesting :pendantic.


On Tuesday, March 14, 2017 at 4:49:50 PM UTC-4, Howard M. Lewis Ship wrote:
>
> We have some very, very complex projects that bring in boat-loads of 
> dependencies, some of which will have version conflicts, if left 
> unchecked.  I've created a Leiningen plugin, vizdeps, to make it easier to 
> see the artifact tree, identify and repair conflicts, and determine why any 
> particular artifacts are in the build.
>
> https://github.com/walmartlabs/vizdeps
>
> On Mon, Mar 13, 2017 at 1:45 PM, Stuart Sierra  > wrote:
>
>> This is a well-known problem in the JVM world, not just Clojure.
>>
>> The most common approach is: Always use the latest versions, and don't 
>> break backwards-compatibility.
>>
>> Most open-source Java and Clojure libraries are careful about not 
>> breaking backwards-compatibility. So in general, you're safe choosing the 
>> latest version of any library.
>>
>> Leiningen has the `:pedantic` option which can be set to warn or fail 
>> when there are possible dependency conflicts.
>>
>> Neither Clojure nor the JVM has explicit support for linking to specific 
>> versions of a library. Work-arounds exist, but they often increase overall 
>> complexity and lead to conflicts which are harder to debug.
>>
>> –S
>>
>>
>> On Monday, March 13, 2017 at 4:13:19 PM UTC-4, arthur wrote:
>>>
>>> Hello All,
>>>
>>>
>>>  I have a general inquiry regarding conflicting dependencies in 
>>> Clojure projects and how they affect applications at runtime. I believe 
>>> this is a common problem faced by many languages in this day and age where 
>>> we try not to reinvent the wheel by depending on the work of others. 
>>> Basically: my application depends on libraries *A*, *B*, *C*, and *D*. 
>>> Libraries *B*, *C*, *D* *also* depend on library *A*, but all of us 
>>> depend on *different versions* of library *A.* Leiningen thankfully 
>>> warns us in many of these situations by suggesting exclusions. However, how 
>>> can I possibly know that something hasn't broken? Stringent testing can 
>>> give a certain degree of confidence that things are still working, but it 
>>> would seem to me that to ensure correctness, we should include *all* 
>>> versions 
>>> of the dependencies and have the functions link to their respective 
>>> *versioned* identites. Does anyone have advice on how they solve these 
>>> kinds of problems on their codebases in the wild? Thankfully nothing has 
>>> broken yet (to my knowledge), but it seems we have very few assurances here 
>>> and the best we can do is *hope* nothing is broken. Any advice is much 
>>> appreciated.
>>>
>>> Thanks,
>>>
>>> Arthur
>>>
>> -- 
>> 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/d/optout.
>>
>
>
>
> -- 
> Howard M. Lewis Ship
>
> Senior Mobile Developer at Walmart Labs
>
> Creator of Apache Tapestry
>
> (971) 678-5210
> http://howardlewisship.com
> @hlship
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Combinatorics partitions that preserves adjacency?

2017-03-16 Thread Paul Gowder 
Ooh, thank you---those are both lovely solutions! 

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ANN] Ansible roles for deploying Clojure + book on using them

2017-03-16 Thread Janko Muzykant 
Daniel Higginbotham  writes:

[cut]
> The deployment tools rely on scripts that I developed for my own sites, 
> including Community Picks, a site for community-powered product 
> recommendations.

I didn't know about Community Picks before. Awesome idea, thanks :)

-- 
"This is so f*cking simple that I can't go wrong"

  - most popular testing strategy

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.