ANN superv.async 0.2.1 - Erlang-inspired error handling for core.async

[Christian Weilbach]

After more than a year of exploration of different approaches to get
error handling right in the Erlang sense with core.async, I am finally
confident enough to release it as superv.async. I have tested it a lot
with replikativ in a distributed system, but I wouldn't consider it
production ready yet.

I have written a blog post about the experiences and different
approaches here:

https://whilo.github.io/org/2016/03/10/error-handling1.html

>From the README:

Let it crash. The Erlang approach to build reliable systems.

Errors happen, and proper error handling cannot be bolted on top of
subsystems. This library draws on the Erlang philosophy of error
handling to help building robust distributed systems that deal with
errors by default.

This is a Clojure(Script) library that extends core.async with error
handling and includes a number of convenience functions and macros. This
library is a fork of full.async. The original attempt to merge this work
with it failed due to the limitations of a dynamic binding approach. The
fork became reasonable, because full.async mostly deals with convenience
functions, but it is not as radically focused on proper error handling.
Since the error handling cannot happen through a transparent dynamic
binding, some convenience is lost in superv.async as you need to carry
around the supervisor lexically. If binding support comes to
ClojureScript for asynchronous contexts the projects might merge again.
The binding approach also has a performance penalty though. Since the
boundary of both error handling libraries is the exception mechanism and
core.async channels, they still compose, but supervision will not
compose with full.async contexts.

https://github.com/replikativ/superv.async

I hope you find it useful and feedback is very much appreciated.

Christian

-- 
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: Bug in clojure.core/take lazy seq?

[Zalan Kemenczy]

Certainly the problem is the realizing the tail sequence of the split-with
before the head sequence, and take shouldn't be trying to solve that. But I
guess I would have thought that (doall (take (count t) t)) would have
realized all of t so the head could be released.

Indeed, the take* formulation is effectively a look-ahead, realizing one
element more than necessary, and I can see how this might be undesirable. I
suppose the two have to be weighed against each other and (doall (take
(count t) t)) is enough of a special case that it's not worth the
lookahead. But take* is the same formulation as drop, no? Is the lookahead
problem not a problem there?

Thanks for the response!


On Mon, Oct 24, 2016 at 7:22 AM, Meikel Brandmeyer (kotarak) 
wrote:

> I think this is not a bug in take, but an unfortunate constellation of
> laziness.
>
> The solution you propose is basically making take looking one step ahead,
> which is not take's business. It could be actually quite dangerous to do
> so in case take's n was carefully calculated based on some external
> stopping condition.
>
> It just fixes your one-step look ahead special case. However the real
> problem is realising the tail sequence of the split-with before the head
> sequence. This is not a problem of take either.
>
> That notwithstanding one could optimise take a little bit by actually
> preventing holding onto the tail in the last step, since n is known
> upfront.
>
> (defn take
>   [n coll]
>   (when (pos? n)
> (lazy-seq
>   (when-let [s (seq coll)]
> (cons (first s) (take+ (dec n) coll))
>
> This would “fix” (split-at 50 (range 1e8)) in your example. However, it
> wouldn't help with split-with. Here the stopping condition is unknown,
> because it is based on a predicate of the input data. There we have to hold
> onto the head of the input.
>
> Takeaway: Always realise t before d. And full t, not some derivative, if
> you hold onto its head.
>
> --
> 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 a topic in the
> Google Groups "Clojure" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/clojure/AvL4nurdB1E/unsubscribe.
> To unsubscribe from this group and all its topics, 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: Bug in clojure.core/take lazy seq?

[Meikel Brandmeyer (kotarak)]

I think this is not a bug in take, but an unfortunate constellation of 
laziness.

The solution you propose is basically making take looking one step ahead, 
which is not take's business. It could be actually quite dangerous to do so 
in case take's n was carefully calculated based on some external stopping 
condition.

It just fixes your one-step look ahead special case. However the real 
problem is realising the tail sequence of the split-with before the head 
sequence. This is not a problem of take either.

That notwithstanding one could optimise take a little bit by actually 
preventing holding onto the tail in the last step, since n is known upfront.

(defn take
  [n coll]
  (when (pos? n)
(lazy-seq
  (when-let [s (seq coll)]
(cons (first s) (take+ (dec n) coll))

This would “fix” (split-at 50 (range 1e8)) in your example. However, it 
wouldn't help with split-with. Here the stopping condition is unknown, 
because it is based on a predicate of the input data. There we have to hold 
onto the head of the input.

Takeaway: Always realise t before d. And full t, not some derivative, if 
you hold onto its head.

-- 
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: need help on `pprint/write` code with better readability

[jiyinyiyong]

Cool library! But i just changed to fipp this morning. I think I will try
it much later. fipp is really fast that it succeeded clojure.pprint/write.

On Mon, Oct 24, 2016 at 4:36 PM Thomas Heller  wrote:

> Try https://github.com/weavejester/cljfmt
>
> It is specifically written for clj code and not general pprinter.
>
> /thomas
>
> On Sunday, October 23, 2016 at 1:28:23 PM UTC+2, Jiyin Yiyong wrote:
>
> I'm using `write` function to generate code very heavily. But small part
> of the code are hard to read.
> So I digged into the options and increased `right-margin` to make it a
> little better. Here's the changes:
>
>
> https://github.com/Cirru/sepal.clj/commit/e65e2d3cac8a5c5537716acd12cc475712ab6f66
>
>
> https://github.com/Quamolit/quamolit/commit/1d2e2a579a3b6741109223faa88c84157035577f
>
> But it turned out the algorithm is doing layout like always appending code
> in a line, until it reaches right margin.
> So if `right-margin` is too big, all the code are in a single line, which
> is hard to read.
> if `right-margin` is too small, then all the code in a column, which is
> also hard to read.
> I think it's not smart enough to make all of my code readable enough, but
> majority of that is fine.
>
> Is there any solution to improvement the readability at this moment?
> Especially for such scenarios:
>
>
> https://github.com/Quamolit/quamolit/blob/master/src/quamolit/render/expand.cljs#L102
>
>
> Thanks.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "Clojure" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/clojure/ZB-nSiFH3uw/unsubscribe.
> To unsubscribe from this group and all its topics, 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: need help on `pprint/write` code with better readability

[Thomas Heller]

Try https://github.com/weavejester/cljfmt 

It is specifically written for clj code and not general pprinter.

/thomas

On Sunday, October 23, 2016 at 1:28:23 PM UTC+2, Jiyin Yiyong wrote:
>
> I'm using `write` function to generate code very heavily. But small part 
> of the code are hard to read.
> So I digged into the options and increased `right-margin` to make it a 
> little better. Here's the changes:
>
>
> https://github.com/Cirru/sepal.clj/commit/e65e2d3cac8a5c5537716acd12cc475712ab6f66
>
>
> https://github.com/Quamolit/quamolit/commit/1d2e2a579a3b6741109223faa88c84157035577f
>
> But it turned out the algorithm is doing layout like always appending code 
> in a line, until it reaches right margin.
> So if `right-margin` is too big, all the code are in a single line, which 
> is hard to read.
> if `right-margin` is too small, then all the code in a column, which is 
> also hard to read.
> I think it's not smart enough to make all of my code readable enough, but 
> majority of that is fine.
>
> Is there any solution to improvement the readability at this moment?
> Especially for such scenarios:
>
>
> https://github.com/Quamolit/quamolit/blob/master/src/quamolit/render/expand.cljs#L102
>
>
> Thanks.
>

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