Re: [ANN] walmartlabs/datascope 0.1.0

[Daniel Kersten]

This is brilliant! I was looking for something like this to create images
to use in talk slides. Thank you!
On Thu 30 Jun 2016 at 20:11,  wrote:

> Tried this out to visualize a DFA used for dictionary matching. Very cool.
>
>
> On Monday, June 27, 2016 at 1:57:56 PM UTC-4, Howard M. Lewis Ship wrote:
>>
>>
>> A library that can be used to render typical Clojure data structures
>> using Graphviz.
>>
>> https://github.com/walmartlabs/datascope
>>
>> --
>> 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.
>

-- 
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] better-cond 1.0.1

[Mark Engelberg]

Years ago, Christophe Grand wrote a blog post about how to achieve flatter,
clearer, less-nested code by using a special version of Clojure's cond that
supported :let clauses (just like Clojure's for comprehensions), as well as
:when-let.

I've been using that code on a daily basis ever since, copying it from one
project to another.

For example, here's some code I wrote just today:

(defn- row-type [row]
  (if (set? row) ::row-seq
(loop [row (seq row), seen (transient #{})]
  (b/cond
(not row) nil
:let [item (first row)]
(not (number? item)) ::row-seq
(and (not (== item 0)) (not (== item 1))) ::row-seq
(seen item) ::matrix
:let [seen (conj! seen item)]
(recur (next row) seen)

There's been a JIRA issue for this for 7 years (
http://dev.clojure.org/jira/browse/CLJ-200), but this feature hasn't yet
made it into Clojure.  That doesn't affect me too much, since I can just
keep using this improved cond in my own source.  But it *does *affect me
when I want to share my code with others, for example, in my open-source
projects.  To avoid confusing other people, I've tried to avoid using this
improved cond in my open-source projects, but once you're used to using
:let inside of cond, it's downright painful to go without, and that pain
was actually stopping me from releasing some of my programs as open-source.

So, in order to begin releasing projects that use this better cond, I've
put better-cond into Clojars.  My convention is that in open-source code,
I'm qualifying the cond with a namespace alias like b/cond as a flag to
readers of the code that this might not be the cond they expect.  In my own
code, I just exclude Clojure's cond (as well as if-let and when-let, for
which improved versions are also offered in this library), and `use` them
directly at the top of every namespace, no qualifying necessary since they
function as drop-in replacements (no real performance hit since the
additional complexity occurs at macro-expansion time).  That way I don't
have to think about it, I just always have the better features at my
disposal.

Now that the library is in Clojars, that means you all can benefit from
this great improvement as well.  Try it, use it, get hooked!  Enjoy.

https://github.com/Engelberg/better-cond

--Mark

P.S. 1.0.1 *removes* a feature from 1.0.0, namely a quirky syntax for
supporting if-let inside of cond, which I've never used, and just felt like
clutter.  But 1.0.0 works perfectly fine, so if that's the version number
that's easier for you to remember, by all means, use it.

-- 
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] better-cond 1.0.1

[Mark Engelberg]

I should add that Dunaj already has this feature, so if you are a user of
Dunaj you do not need this library.

-- 
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] clojure-future-spec, a backport of clojure.spec for 1.8

[Sam Estep]

Did you read my whole question? It doesn't work to have the implementation 
namespace require the spec namespace either, as I demonstrated in my second 
example, where the spec for the factor function uses the prime? predicate.

On Friday, July 1, 2016 at 1:38:23 AM UTC-4, Sean Corfield wrote:
>
> I can’t help but think you’re making it way more complicated than it needs 
> to be.
>
>  
>
> Define ::config in example.spec, and in example.core use 
> :example.spec/config (and, yes, require the example.spec namespace).
>
>  
>
> You need to avoid circular namespace dependencies.
>
>  
>
> Sean Corfield -- (904) 302-SEAN
> An Architect's View -- http://corfield.org
>
>  
>
> *From: *Sam Estep 
> *Sent: *Thursday, June 30, 2016 9:36 PM
> *To: *Clojure 
> *Subject: *Re: [ANN] clojure-future-spec, a backport of clojure.spec for 
> 1.8
>
>  
>
> I spent quite a while trying to figure out how I can use some features of 
> spec, like destructuring, to work properly when my specs are in a separate 
> namespace. I asked a question 
>  about this on Stack 
> Overflow; do you have any advice on how to solve the issues I detailed 
> there?
>
> On Wednesday, June 29, 2016 at 1:21:02 PM UTC-4, Sean Corfield wrote:
>
> On 6/29/16, 10:03 AM, "Lucas Bradstreet"  behalf of lucasbr...@gmail.com> wrote: 
> > Sean, a lot of library developers still want to support Clojure 1.8, 
> > but this would prevent using spec with their projects. 
>
> clojure.java.jdbc solves that by having the specs in a separate namespace 
> (and by the tests conditionally loading that and clojure.spec.test). 
> clojure.java.jdbc supports back to Clojure 1.4. 
>
> Nikita, it would be interesting to know how far back (in Clojure versions) 
> your library could support. I can see real value in being able to back port 
> spec beyond 1.8… 
>
> Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN 
> An Architect's View -- http://corfield.org/ 
>
> "If you're not annoying somebody, you're not really alive." 
> -- Margaret Atwood 
>
>
> -- 
> 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.

[ANN] walmartlabs/datascope 0.1.0

[Howard Lewis Ship]

Glad you like it!

I'm thinking of changing it so that empty collections render in-cell, like
scalars.


On Thu, Jun 30, 2016 at 12:11 PM, > wrote:

> Tried this out to visualize a DFA used for dictionary matching. Very cool.
>
>
> On Monday, June 27, 2016 at 1:57:56 PM UTC-4, Howard M. Lewis Ship wrote:
>>
>>
>> A library that can be used to render typical Clojure data structures
>> using Graphviz.
>>
>> https://github.com/walmartlabs/datascope
>>
>> --
>> 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.
>



-- 
Howard M. Lewis Ship

Senior Mobile Developer at Walmart Labs

Creator of Apache Tapestry

(971) 678-5210
http://howardlewisship.com
@hlship


-- 
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: [ANN] better-cond 1.0.1

[Jason Felice]

You've got me thinking whether there's a more general thing which could be
done for packthread: (https://github.com/maitria/packthread).

Hrmm...

On Fri, Jul 1, 2016 at 5:25 AM, Mark Engelberg 
wrote:

> I should add that Dunaj already has this feature, so if you are a user of
> Dunaj you do not need this library.
>
> --
> 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] functional-vaadin 0.1.1

[Paul Bennett]

Hi Everyone,

I'd like to announce functional-vaadin, a library for building Clojure 
webapps using the Vaadin UI framework. Since Vaadin is Java-based, this can 
already be done - but it's clunky: lots of doto and setter calls, 
temporaries to hold parts of the UI being constructed, etc. etc. This 
library is aimed at making all that a thing of the past. 

The code is open-source: https://github.com/wizardpb/functional-vaadin

Jars are deployed to Clojars: 
https://clojars.org/com.prajnainc/functional-vaadin

There is still work to be done, mostly on the documentation, as well as 
some final components and event handling

The primary goal is to use the homoiconic nature of clojure to make the 
code that builds a UI as structurally similar as possible to the UI itself. 
The library provides builder functions for each component, these take 
constructor arguments and/or a configuration Map, as well as any children 
components. This effectively eliminates the clutter.

The other main feature is an integration with RxClojure, which makes 
explicit event handling a thing of the past. Instead, sequences of 
Observers can be created, allowing arbitrary processing of events from the 
UI. It is quite possible have these chains receive an event, process it 
with arbitrary code, and return new data to other parts of the UI.

Other features include a component naming scheme that allows access to 
components via their ID (eliminates temporaries), conversion functions that 
interface Clojure immutable data structures to Vaadin data binding objects, 
and a better Form mechanism, integrating FieldGroups, layouts and 
function-based validation and conversion.

I hope you find this useful! Please feel free to contact me with any 
further questions.

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

Picking a code path if a type is known at compile time (e.g. through hint)

[lvh]

Hi,


I have some code that wants to know the appropriate length of a byte buffer. 
These can be byte arrays (as in [B) or java.nio.ByteBuffers. For the former, I 
can call (alength ^bytes buf), for the latter I call (.remaining ^ByteBuffer 
buf). Is there a way to just write a fn or macro that picks the right one at 
compile time? I wrote some simple test fns, but there doesn’t appear to be a 
way to access that type hinting information.


thanks
lvh

-- 
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: Message signed with OpenPGP using GPGMail

Re: Picking a code path if a type is known at compile time (e.g. through hint)

[Erik Assum]

A multimethod which dispatches on type, or maybe extend the counted(?) protocol 
to these two types?

Erik. 
-- 
i farta

> Den 1. jul. 2016 kl. 17.12 skrev lvh <_...@lvh.io>:
> 
> Hi,
> 
> 
> I have some code that wants to know the appropriate length of a byte buffer. 
> These can be byte arrays (as in [B) or java.nio.ByteBuffers. For the former, 
> I can call (alength ^bytes buf), for the latter I call (.remaining 
> ^ByteBuffer buf). Is there a way to just write a fn or macro that picks the 
> right one at compile time? I wrote some simple test fns, but there doesn’t 
> appear to be a way to access that type hinting information.
> 
> 
> thanks
> lvh
> 
> -- 
> 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: Picking a code path if a type is known at compile time (e.g. through hint)

[Timothy Baldridge]

You can write a protocol, then extend it:

(defprotocol IBufferLength
  (buffer-length [this]))

(extend-protocol IBufferLength
  (Class/forName "[B")
  (buffer-length [this] ...)

  ByteBuffer
  (buffer-length [this] ...))

On Fri, Jul 1, 2016 at 9:15 AM, Erik Assum  wrote:

> A multimethod which dispatches on type, or maybe extend the counted(?)
> protocol to these two types?
>
> Erik.
> --
> i farta
>
> > Den 1. jul. 2016 kl. 17.12 skrev lvh <_...@lvh.io>:
> >
> > Hi,
> >
> >
> > I have some code that wants to know the appropriate length of a byte
> buffer. These can be byte arrays (as in [B) or java.nio.ByteBuffers. For
> the former, I can call (alength ^bytes buf), for the latter I call
> (.remaining ^ByteBuffer buf). Is there a way to just write a fn or macro
> that picks the right one at compile time? I wrote some simple test fns, but
> there doesn’t appear to be a way to access that type hinting information.
> >
> >
> > thanks
> > lvh
> >
> > --
> > 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.

Monads and Middleware

[Scott Klarenbach]

I'm looking for some insight into the relationship between Monads and 
Middleware.

It seems to me that middleware (ala Ring, Boot) is really just a subset of 
Monads, where bind and lift are globally agreed upon conventions, rather 
than explicitly defined.  For example, with middleware you need every 
function to accept and return the same signature so as to be composable, 
whereas with monads you explicitly provide the code for binding and lifting 
into and out of the monad world.

My basic questions are:

1.) Is middleware really a monad with a different name?
2.) Is there any compelling reason to use monads in clojure instead of 
middleware?
3.) Are there classes of problems that can be solved with monads that can't 
be solved with middleware?
4.) Is there any benefit (beyond curiosity) to porting/re-implementing 
middleware as monads?

Thanks.

Scott Klarenbach
www.invisiblerobot.io


-- 
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: Picking a code path if a type is known at compile time (e.g. through hint)

[lvh]

> On Jul 1, 2016, at 10:34 AM, Timothy Baldridge  wrote:
> 
> You can write a protocol, then extend it: ...

Ah! I completely blanked on protocol dispatch being resolved at compile time if 
possible. Thanks!

Does this only work if the type hint is exactly the extended type, or does this 
understand Java’s standard type dispatch? Specifically, I’m thinking of 
java.nio.ByteBuffer vs java.nio.DirectByteBuffer. Is there something like 
reflection warnings to tell me automatically when it doesn’t work correctly?


lvh

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

Recursive specs & forward declarations

[Maarten Truyens]

Hi, 

I am struggling with recursive Spec declarations, more in particular how 
two Spec definitions can refer to each other. In the example below, I use a 
"forward" declaration, but that does not seem very elegant. Am I missing 
something? 

The more fundamental question, however, is how to implement recursion 
limits. After several recursive iterations  during generation, I would like 
to force the use of non-recursive elements (leafs in the example below), to 
avoid stackoverflows. However, I am struggling to see how a recursion limit 
can be implemented.

Example code:


; "Forward" declarations of specs

(s/def ::Tree ::s/any)

(s/def ::Leaf ::s/any)


(s/def ::name string?)

(s/def ::children (s/coll-of (s/or :tree ::Tree, :leaf ::Leaf)))


(defrecord Tree [name children])

(defrecord Leaf [name])


(s/def ::Leaf (s/with-gen

   (s/keys :req-un [::name])

   #(gen/let [name (s/gen ::name)]

 (->Leaf name

(s/def ::Tree (s/with-gen

   (s/keys :req-un [::name ::children])

   #(gen/let [name (s/gen ::name)

  children (s/gen ::children)]

 (->Tree name children


When trying to generate a Tree (gen/generate (s/gen ::Tree)), a 
Stackoverflow is produced. 

I am aware of a bug report (http://dev.clojure.org/jira/browse/CLJ-1964), 
but that report was closed by Alex Miller due to the changes in Alpha8. 
(BTW, the sample code in that bug report still produces a stackoverflow in 
Alpha8, despite Alex' suggestion that it should now work). 

Any ideas?

Best regards, 

Maarten

-- 
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: Monads and Middleware

[James Reeves]

Functions are a type of monad, and function composition is a type of
monadic binding. You could certainly say that middleware are a type of
monad, but so many things can be thought of as monads that's not hugely
useful in and of itself.

- James

On 1 July 2016 at 18:14, Scott Klarenbach  wrote:

> I'm looking for some insight into the relationship between Monads and
> Middleware.
>
> It seems to me that middleware (ala Ring, Boot) is really just a subset of
> Monads, where bind and lift are globally agreed upon conventions, rather
> than explicitly defined.  For example, with middleware you need every
> function to accept and return the same signature so as to be composable,
> whereas with monads you explicitly provide the code for binding and lifting
> into and out of the monad world.
>
> My basic questions are:
>
> 1.) Is middleware really a monad with a different name?
> 2.) Is there any compelling reason to use monads in clojure instead of
> middleware?
> 3.) Are there classes of problems that can be solved with monads that
> can't be solved with middleware?
> 4.) Is there any benefit (beyond curiosity) to porting/re-implementing
> middleware as monads?
>
> Thanks.
>
> Scott Klarenbach
> www.invisiblerobot.io
>
>
> --
> 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: Learning Google's Map Reduce with Clojure

[Olek]

In case you care. Here https://github.com/naleksander/scalduce are Scala 
examples, so you can easily compare the overhead.
For me Clojure is more enjoyable, however if I were to share my code (for 
example as an library) with others (for example beginner users or with 
weaker skills) than statically typed language is a win.

On Wednesday, 29 June 2016 22:20:57 UTC+2, Olek wrote:
>
> Hi!
>
> I was refreshing my knowledge from Google's Map Reduce.
> I've decided to code some examples in Clojure since it is my favorite 
> language.
> Here is the code from the learning process 
> https://github.com/naleksander/mapreduce
>
> I guess that it is time now to code it in Scala *wink*
>
> Btw. if I were to implement it from ground in real scalable manner I would 
> choose HDFS, some distributed reliable message queue and would work on 
> serializing and distributing user defined functions between nodes. Also 
> current API had to be changed a bit (for example instead of few arguments I 
> would just pass the map being the map reduce job specification).
>
> Viva Clojure!
>
>

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

[Mark Engelberg]

Thanks for the pointer to your library, Jason.  I hadn't known about it.

In response to the interest and questions I've been getting about
better-cond, I've added a Rationale section to the README, and I've
mentioned your library in that section:

https://github.com/Engelberg/better-cond#rationale


On Fri, Jul 1, 2016 at 7:22 AM, Jason Felice 
wrote:

> You've got me thinking whether there's a more general thing which could be
> done for packthread: (https://github.com/maitria/packthread).
>
> Hrmm...
>
>

-- 
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: diehard 0.1.0, a Clojure wrapper for Failsafe

[Stanislav Yurin]

Thank you.

Also recently made a use of your https://github.com/sunng87/slacker lib - 
really interesting approach.

On Thursday, June 30, 2016 at 6:08:27 PM UTC+3, Sun Ning wrote:
>
> Hi all, 
>
> Just to announce the first release of diehard[1], a clojure wrapper over 
> the Failsafe[2] library, which deals retry stuff for you. 
>
> Diehard allows you to set retry criteria for any block a clojure code, 
> like: 
>
> (diehard/with-retry {:retry-on IOException} 
>   (http/get "https://google.com";)) 
>
> The first release only has retry supported, more to come in next few 
> versions. 
>
> [1]: https://github.com/sunng87/diehard/ 
> [2]: https://github.com/jhalterman/failsafe 
>
>

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