Re: How to implement a distributed and concurrent system in Clojure?

[Derek Troy-West]

I still have Storm topologies in prod, but I'm investigating Kafka Streams 
and Onyx right now.

On Saturday, July 1, 2017 at 9:38:08 AM UTC+10, Bobby Calderwood wrote:
>
> Onyx is super cool, has matured substantially, and has a great team behind 
> it.
>
> I've also had success building with Kafka (and its ecosystem libraries 
> Kafka Connect and Kafka Streams) and Datomic.
>
> Cheers,
> Bobby
>
>

-- 
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] clojure.java.jdbc 0.7.0 Beta 2

[Sean Corfield]

What?
   Clojure’s contrib wrapper for JDBC.

Where?
   https://github.com/clojure/java.jdbc
   [org.clojure/java.jdbc “0.7.0-beta2”]

Summary?
   Improves reducible queries; 
Completes (optional) specs for public API; 
Drops support for Clojure 1.5 and 1.6 (so, requires Clojure 1.7 or later).

Details?

The contract for ‘reduce’ in its docstring is very specific about the 
situations where ‘f’ is called and what it’s arguments are. java.jdbc 
0.7.0-beta1 did not respect that contract; java.jdbc 0.7.0-beta2 does.

The optional clojure.java.jdbc.spec namespace now has fdef specs for all the 
public API functions in clojure.java.jdbc. It assumes clojure.spec.alpha so it 
requires a recent Clojure 1.9 Alpha build to use it. Please try the specs out 
and open JIRA issues if I got anything wrong!

Based on responses to the survey – over 50 so far – there is clear support for 
only supporting Clojure 1.7 going forward (only one respondent is still on 1.7, 
34 are on 1.8, and 17 are on 1.9 already). This allows me to drop the 
conditional logic that used CollReduce in order to still support 1.5/1.6.

There’s probably a side discussion to be had about IReduce vs IReduceInit but 
I’ll take that to clojure-dev (

The survey is still open if you use java.jdbc and have not yet completed it:
   https://www.surveymonkey.com/r/MR2HRFD

Thanks to?
Kevin Downey and Ghadi Shayban again, as well as Nicola Mometto, for 
continued discussion on Slack around CollReduce, IReduce, IReduceInit, and the 
contract of reduce.
And also everyone who completed the survey!

Sean Corfield -- (904) 302-SEAN -- (970) FOR-SEAN
An Architect's View -- http://corfield.org/

"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/d/optout.

Re: How to implement a distributed and concurrent system in Clojure?

[Bobby Calderwood]

Onyx is super cool, has matured substantially, and has a great team behind it.

I've also had success building with Kafka (and its ecosystem libraries Kafka 
Connect and Kafka Streams) and Datomic.

Cheers,
Bobby

-- 
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] antizer 0.2.0

[James Reeves]

This looks like just what I need. Thanks for writing it!

On 30 June 2017 at 04:31, Michael Lim  wrote:

> https://github.com/priornix/antizer
>
>
> Antizer  has just been released. It
> is a ClojureScript library implementing Ant Design 
> React components for Reagent and Rum.
>
> Ant Design is an enterprise-class UI design language and React-based
> implementation with the following features:
>
>- An enterprise-class UI design language for web applications.
>- A set of high-quality React components out of the box.
>- Extensive API documentation and examples.
>
> Examples and Documentation
>
>-
>
>Reagent Demo
>
>-
>
>Rum Demo 
>-
>
>Antizer Documentation https://priornix.github.io/antizer/latest/
>-
>
>API Documentation https://priornix.github.io/antizer/latest/api/
>
> Github project: https://github.com/priornix/antizer
>
> --
> 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.
>



-- 
James Reeves
booleanknot.com

-- 
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: def partially done when used in if

[Sean Corfield]

You can see it at work in this:

user=> foo
(unable to resolve foo)
user=> (when nil (def foo 42))
nil
user=> foo
(unbound var foo)

When a ‘def’ form is _compiled_ -- which happens in the above case because the 
whole form must be compiled – then it interns the var.

The ‘def’ form is parsed in DefExpr$Parser.parse() and it calls lookupVar(sym, 
true) – which interns the symbol if it is new (i.e., not yet seen). See various 
parts of:


https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/Compiler.java


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

On 6/30/17, 11:28 AM, "Didier"  wrote:

I admit, this is very surprising. It looks like evaluation happens in two 
pass, like first it finds all defs and declares them, interning the symbol and 
creating an unbound var. And on a second pass it evaluates the full form.

Can someone more informed confirm or explain in more details what's 
responsible for this behavior?

-- 
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: def partially done when used in if

[Didier]

I admit, this is very surprising. It looks like evaluation happens in two pass, 
like first it finds all defs and declares them, interning the symbol and 
creating an unbound var. And on a second pass it evaluates the full form.

Can someone more informed confirm or explain in more details what's responsible 
for this behavior?

-- 
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: Stubbing with instrument and generators

[Michael Glaesemann]

Thanks for taking a look. Here's a ticket: 
https://dev.clojure.org/jira/browse/CLJ-2197

> On 2017-06-30, at 11:52, Alex Miller  wrote:
> 
> I don't think this is the same case as CLJ-2095 as the instrumented var 
> should have the opportunity to use the gen overrides you've included. In 
> particular, it seems like stest/instrument-choose-fn is currently passing the 
> :gen overrides map when getting the gen for the stubbed var. I'm wondering if 
> there is a bug there where the spec has already been resolved and thus the 
> gen key (::y) is not getting matched. Feel free to file a ticket for this.
> 
> On Friday, June 30, 2017 at 9:37:42 AM UTC-5, Michael Glaesemann wrote:
> Using spec instrument to stub functions is really helpful. I'm using stubbing 
> to test Stuart Sierra-style components with some success. However, I've been 
> surprised that generator override doesn't work as I would expect it to. 
> Here's an example: 
> 
> ;; [org.clojure/spec.alpha "0.1.123"] 
> 
> (require '[clojure.spec.alpha :as s]) 
> (require '[clojure.spec.gen.alpha :as gen]) 
> (require '[clojure.spec.test.alpha :as stest]) 
> 
> (defprotocol Y 
>   (-do-y [r])) 
> 
> (def y? (partial satisfies? Y)) 
> (s/def ::y y?) 
> 
> ;; Protocol methods can't be spec'd, so wrap it in a function. 
> 
> (defn do-y [r] 
>   (-do-y r)) 
> 
> (s/fdef do-y :args (s/cat :y-er ::y)) 
> 
> ;; Example of the protocol implementation that we're going to stub. 
> 
> (defrecord BadYer [] 
>   Y 
>   (-do-y [_] (throw (Exception. "can't make me!" 
> 
> 
> ;; Confirm BadYer instances are valid with respect to the protol spec. 
> 
> (s/valid? ::y (->BadYer)) 
> ;; => true 
> 
> ;; And confirm BadYer instances will throw when called. 
> 
> (try 
>   (do-y (->BadYer)) 
>   (catch Exception e 
> (.getMessage e))) 
> ;; => "can't make me!" 
> 
> 
> (def y-gen (gen/return (->BadYer))) 
> 
> ;; Confirm generator works as expected: 
> 
> (gen/sample y-gen 1) 
> ;; => (#spec_ex.core.BadYer{}) 
> 
> ;; We want to stub `do-y`, providing y-gen as a generator for `::y` 
> 
> (try 
>   (stest/instrument `do-y {:stub #{`do-y} 
>:gen {::y (fn [] y-gen)}}) 
>   (catch Exception e 
> (ex-data e))) 
> ;; => #:clojure.spec.alpha{:path [:y-er], :form :spec-ex.core/y, :failure 
> :no-gen} 
> 
> ;; However, we *can* stub `do-y` if we replace its spec. 
> 
> (stest/instrument `do-y 
>   {:stub #{`do-y} 
>:spec {`do-y (s/fspec 
>   :args (s/cat :y-er (s/with-gen ::y 
>(fn [] y-gen}}) 
> ;; => [spec-ex.core/do-y] 
> 
> There is a ticket open[ (CLJ-2095[1]) regarding using overrides s/gen with 
> custom generators. Is this a case where this applies? I can imagine that it 
> could be. Not overriding something that isn't there would result in the thing 
> still not being there, thus the :no-gen failure. And it is something that can 
> be worked around.  It would be decidedly more succinct if the gen override 
> worked rather than the spec override. 
> 
> Best, 
> 
> Michael Glaesemann 
> grzm seespotcode net 
> 
> 
> [1]: https://dev.clojure.org/jira/browse/CLJ-2095 
> 
> 
> -- 
> 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.

Michael Glaesemann
grzm seespotcode net



-- 
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: Stubbing with instrument and generators

[Alex Miller]

I don't think this is the same case as CLJ-2095 as the instrumented var 
should have the opportunity to use the gen overrides you've included. In 
particular, it seems like stest/instrument-choose-fn is currently passing 
the :gen overrides map when getting the gen for the stubbed var. I'm 
wondering if there is a bug there where the spec has already been resolved 
and thus the gen key (::y) is not getting matched. Feel free to file a 
ticket for this.

On Friday, June 30, 2017 at 9:37:42 AM UTC-5, Michael Glaesemann wrote:
>
> Using spec instrument to stub functions is really helpful. I'm using 
> stubbing to test Stuart Sierra-style components with some success. However, 
> I've been surprised that generator override doesn't work as I would expect 
> it to. Here's an example: 
>
> ;; [org.clojure/spec.alpha "0.1.123"] 
>
> (require '[clojure.spec.alpha :as s]) 
> (require '[clojure.spec.gen.alpha :as gen]) 
> (require '[clojure.spec.test.alpha :as stest]) 
>
> (defprotocol Y 
>   (-do-y [r])) 
>
> (def y? (partial satisfies? Y)) 
> (s/def ::y y?) 
>
> ;; Protocol methods can't be spec'd, so wrap it in a function. 
>
> (defn do-y [r] 
>   (-do-y r)) 
>
> (s/fdef do-y :args (s/cat :y-er ::y)) 
>
> ;; Example of the protocol implementation that we're going to stub. 
>
> (defrecord BadYer [] 
>   Y 
>   (-do-y [_] (throw (Exception. "can't make me!" 
>
>
> ;; Confirm BadYer instances are valid with respect to the protol spec. 
>
> (s/valid? ::y (->BadYer)) 
> ;; => true 
>
> ;; And confirm BadYer instances will throw when called. 
>
> (try 
>   (do-y (->BadYer)) 
>   (catch Exception e 
> (.getMessage e))) 
> ;; => "can't make me!" 
>
>
> (def y-gen (gen/return (->BadYer))) 
>
> ;; Confirm generator works as expected: 
>
> (gen/sample y-gen 1) 
> ;; => (#spec_ex.core.BadYer{}) 
>
> ;; We want to stub `do-y`, providing y-gen as a generator for `::y` 
>
> (try 
>   (stest/instrument `do-y {:stub #{`do-y} 
>:gen {::y (fn [] y-gen)}}) 
>   (catch Exception e 
> (ex-data e))) 
> ;; => #:clojure.spec.alpha{:path [:y-er], :form :spec-ex.core/y, :failure 
> :no-gen} 
>
> ;; However, we *can* stub `do-y` if we replace its spec. 
>
> (stest/instrument `do-y 
>   {:stub #{`do-y} 
>:spec {`do-y (s/fspec 
>   :args (s/cat :y-er (s/with-gen ::y 
>(fn [] y-gen}}) 
> ;; => [spec-ex.core/do-y] 
>
> There is a ticket open[ (CLJ-2095[1]) regarding using overrides s/gen with 
> custom generators. Is this a case where this applies? I can imagine that it 
> could be. Not overriding something that isn't there would result in the 
> thing still not being there, thus the :no-gen failure. And it is something 
> that can be worked around.  It would be decidedly more succinct if the gen 
> override worked rather than the spec override. 
>
> Best, 
>
> Michael Glaesemann 
> grzm seespotcode net 
>
>
> [1]: https://dev.clojure.org/jira/browse/CLJ-2095 
>
>

-- 
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: Clojure android activity?

[Alex Miller]

It's not really lack of interest from the core team, just a matter of not 
being able to do everything. I personally am not aware of any list of 
patches necessary to make Clojure work on Android (other than CLJ-1472, 
which has been the subject of some debate across Android and Clojure).

I would love to have all problems filed as tickets in jira and marked with 
a common label. I just created an Android report based on the label 
"android" at 
https://dev.clojure.org/jira/secure/IssueNavigator.jspa?mode=hide=11701.
 
Feel free to tag any issues with that label so they show up there. 

Would be happy to try to move any issues forward towards release. CLJ-1472 
btw would possibly be sidestepped by CLJ-1891 which would pull the use of 
the locking macro out of the default initialization path (which is why it 
became an issue when it did). Doesn't really fix the issue but probably 
makes it ignorable for now. I'm hoping to get CLJ-1891 into Clojure 1.9.

Alex

On Friday, June 30, 2017 at 9:56:43 AM UTC-5, Adam Clements wrote:
>
> Hey Mike, 
>
> It's a case of life getting in the way - both Alex and myself got jobs not 
> in the Android space. That being said, looking at the issues that have come 
> up on the mailing list recently most would be fairly simple fixes, and I 
> don't think there would be much of a problem bringing it up to date with 
> the latest Clojure version.
>
> Michael - I agree about using react native if you're writing a 
> conventional app with activities etc, with the added benefit of iOS cross 
> compatibility. If you want to do anything more involved with the input 
> apis, wear apis etc, you'll probably need access to all the raw 
> functionality as clojure-android provides.
>
> It's a pity there was never any interest from core to acknowledge android 
> as a supported platform - the set of patches was (and still is) pretty tiny 
> to get it running - most of the custom work happened in lein-droid to 
> package it up appropriately.
>
> How many people want this? Is it worth spending some time bringing things 
> back up to date? I'm going fully freelance in a week or so, so might find 
> some time between projects (or if any companies want to use this and would 
> be willing to sponsor development, get in touch and we'll see what we can 
> do)
>
> Adam
>
> On Wed, Jun 28, 2017 at 5:12 PM Michael Blume  
> wrote:
>
>> My impression is that if you want to write Clojure on Android in 2017 you 
>> use React Native and write ClojureScript. Re-natal is a good starting point
>>
>> On Fri, Jun 23, 2017, 3:57 PM Mike Meyer  wrote:
>>
>>> Is there still any activity in the clojure-android space? The 
>>> clojure-android mail list is largely inactive, seems like the developers of 
>>> lein-droid haven't done anything in months (1.7.0-r4 is still used in the 
>>> templates), and the numerous references If ind for an android-clojure web 
>>> site are all dead.
>>>
>>> That said, things do seem to mostly work for stock android. But 
>>> accessing API's for android wear seems problematical (see 
>>> https://github.com/clojure-android/lein-droid/issues/162 for my bug 
>>> report).
>>>
>>> -- 
>>> 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.
>>
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to

Re: How to implement a distributed and concurrent system in Clojure?

[Christopher Small]

I'd have to know a little bit more about the specifics of your message
driven architecture to say for sure, but in general I'd still highly
recommend Onyx over Storm. In the last two years the Distributed Masonry
crew have done a TON of fabulous work with Onyx, including closing the
performance gap (maybe someone can chime in here about the current sate of
that gap) by switching to Aeron for message passing (the old version used
HornetMQ I believe). It's also significantly more battle tested now, and
the team just recently got $500k for building out tooling and services
around Onyx. There are also quite a few new features, like improved
agregation support, and so on. They also implemented a runtime for onyx
jobs in cljc, meaning you can test out jobs locally without all the
overhead of firing up zookeeper! EVEN IN THE BROWSER! Imagine that;
dynamically building and testing (with small data) a distributed system in
the browser via some domain-specific UI, and then pushing it to the cluster
when you're ready to let her rip... Nothing like this exists for Storm or
any of the other competitors in this space. I've even heard some dashing
and enterprizing group of fellows are considering building a re-frame-esque
event-driven UI system using Onyx. Who knows? The future is bright.

Chris

PS; Conflict of Interest Disclaimer: I have recieved no moneys or favors
from Distributed Masonry for frequent and prefuse recommendation of their
products. They're just that cool.


On Fri, Jun 30, 2017 at 12:53 AM, Matan  wrote:

> This thread is a bit old, but it's seen two year awakenings before... and
> still shows up high in google searches.
> I wonder how you folks see it now. Onyx is a bit older by now, and not
> much seems new out there. What would you choose for reliable and resilient
> distributed computing with clojure, if you had to start over at this time?
> in particular, for a message driven architecture not a streaming one.
>
>
> On Monday, July 20, 2015 at 3:52:44 AM UTC+3, Derek Troy-West wrote:
>>
>> We use Storm/Trident fairly extensively for distributed computation, it
>> has not been painless and the documentation is poor, however it does
>> perform well once you understand its peculiarities. I'm keeping an
>> interested eye on Onyx but my bandwidth is fairly limited at the moment.
>>
>> The only things I would add to your post are:
>>
>> * It's possible to write Storm and Trident topologies purely in Clojure,
>> in fact parts of Storm were originally written in Clojure. I'm not sure the
>> DSL were an afterthought, but I agree they are fairly impenetrable at
>> first. Storm has a large learning curve and lots of quirks, and the
>> documentation is pretty bad (in-fact, completely wrong in parts).
>>
>> * Storm is currently limited to Clojure 1.5.1, thought the latest beta
>> release has been updated to 1.6.0
>>
>> * Recently the momentum of the project appears to have picked up, but
>> certainly for a while there (just after apache incubation) it appeared a
>> bit stagnant. I presume they were busy settling the project in.
>>
>>
>> On Monday, July 20, 2015 at 3:11:24 AM UTC+10, Christopher Small wrote:
>>>
>>>
>>> I'll also add that if you're interested in the Storm model (distributed
>>> stream processing), you may want to check out Onyx (
>>> https://github.com/onyx-platform/onyx). It's newer, but I have a
>>> feeling that moving forward we're going to see it take a dominant position
>>> as far as that flavor of distributed computing goes. The reasons for this
>>> (briefly):
>>>
>>> * Data all the topologies: Because computational topologies are data
>>> structures, it's far simpler to have more dynamic computational workflows
>>> than with storms opaque macros.
>>> * It's more Clojure centric: Parts of Storm are Clojure, but the Clojure
>>> API seems almost an afterthought, reading the documentation. (However,
>>> support is on the way for other JVM languages).
>>> * Pace of development: Storm is now an Apache Incubator project, and
>>> development is slower than molasses. I was working on a project for over a
>>> year and many times encountered issues with stale dependencies that didn't
>>> play nicely with newer things.
>>> * Designed with batch processing in mind: Even though both are designed
>>> around streaming first, Onyx has a little more explicit support for batched
>>> computations.
>>>
>>> For a while, the biggest advantage of Storm was that it was a lot
>>> faster, but the gap there has closed considerably recently (perhaps
>>> entirely?). Storm is still more battle tested, but there are folks starting
>>> to use it in production.
>>>
>>> The biggest reason I see Onyx taking sway over Storm is the data centric
>>> approach. I see this resonating with the community's "data all the things"
>>> philosophy as a way of maximizing composability and productivity.
>>> Anecdotally, folks using Onyx are already saying this about it.
>>>
>>> My 2 c
>>>
>>> Chris
>>>
>>>
>>>
>>> On 

Re: Clojure android activity?

[Adam Clements]

Hey Mike,

It's a case of life getting in the way - both Alex and myself got jobs not
in the Android space. That being said, looking at the issues that have come
up on the mailing list recently most would be fairly simple fixes, and I
don't think there would be much of a problem bringing it up to date with
the latest Clojure version.

Michael - I agree about using react native if you're writing a conventional
app with activities etc, with the added benefit of iOS cross compatibility.
If you want to do anything more involved with the input apis, wear apis
etc, you'll probably need access to all the raw functionality as
clojure-android provides.

It's a pity there was never any interest from core to acknowledge android
as a supported platform - the set of patches was (and still is) pretty tiny
to get it running - most of the custom work happened in lein-droid to
package it up appropriately.

How many people want this? Is it worth spending some time bringing things
back up to date? I'm going fully freelance in a week or so, so might find
some time between projects (or if any companies want to use this and would
be willing to sponsor development, get in touch and we'll see what we can
do)

Adam

On Wed, Jun 28, 2017 at 5:12 PM Michael Blume  wrote:

> My impression is that if you want to write Clojure on Android in 2017 you
> use React Native and write ClojureScript. Re-natal is a good starting point
>
> On Fri, Jun 23, 2017, 3:57 PM Mike Meyer  wrote:
>
>> Is there still any activity in the clojure-android space? The
>> clojure-android mail list is largely inactive, seems like the developers of
>> lein-droid haven't done anything in months (1.7.0-r4 is still used in the
>> templates), and the numerous references If ind for an android-clojure web
>> site are all dead.
>>
>> That said, things do seem to mostly work for stock android. But accessing
>> API's for android wear seems problematical (see
>> https://github.com/clojure-android/lein-droid/issues/162 for my bug
>> report).
>>
>> --
>> 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.
>

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

Stubbing with instrument and generators

[Michael Glaesemann]

Using spec instrument to stub functions is really helpful. I'm using stubbing 
to test Stuart Sierra-style components with some success. However, I've been 
surprised that generator override doesn't work as I would expect it to. Here's 
an example:

;; [org.clojure/spec.alpha "0.1.123"]

(require '[clojure.spec.alpha :as s])
(require '[clojure.spec.gen.alpha :as gen])
(require '[clojure.spec.test.alpha :as stest])

(defprotocol Y
  (-do-y [r]))

(def y? (partial satisfies? Y))
(s/def ::y y?)

;; Protocol methods can't be spec'd, so wrap it in a function.

(defn do-y [r]
  (-do-y r))

(s/fdef do-y :args (s/cat :y-er ::y))

;; Example of the protocol implementation that we're going to stub.

(defrecord BadYer []
  Y
  (-do-y [_] (throw (Exception. "can't make me!"


;; Confirm BadYer instances are valid with respect to the protol spec.

(s/valid? ::y (->BadYer))
;; => true

;; And confirm BadYer instances will throw when called.

(try
  (do-y (->BadYer))
  (catch Exception e
(.getMessage e)))
;; => "can't make me!"


(def y-gen (gen/return (->BadYer)))

;; Confirm generator works as expected:

(gen/sample y-gen 1)
;; => (#spec_ex.core.BadYer{})

;; We want to stub `do-y`, providing y-gen as a generator for `::y`

(try
  (stest/instrument `do-y {:stub #{`do-y}
   :gen {::y (fn [] y-gen)}})
  (catch Exception e
(ex-data e)))
;; => #:clojure.spec.alpha{:path [:y-er], :form :spec-ex.core/y, :failure 
:no-gen}

;; However, we *can* stub `do-y` if we replace its spec.

(stest/instrument `do-y
  {:stub #{`do-y}
   :spec {`do-y (s/fspec
  :args (s/cat :y-er (s/with-gen ::y
   (fn [] y-gen}})
;; => [spec-ex.core/do-y]

There is a ticket open[ (CLJ-2095[1]) regarding using overrides s/gen with 
custom generators. Is this a case where this applies? I can imagine that it 
could be. Not overriding something that isn't there would result in the thing 
still not being there, thus the :no-gen failure. And it is something that can 
be worked around.  It would be decidedly more succinct if the gen override 
worked rather than the spec override.

Best,

Michael Glaesemann
grzm seespotcode net


[1]: https://dev.clojure.org/jira/browse/CLJ-2095

-- 
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: ClojureScript 1.9.671, bugfix release

[David Nolen]

ClojureScript, the Clojure compiler that emits JavaScript source code.

README and source code: https://github.com/clojure/clojurescript

Leiningen dependency information:

[org.clojure/clojurescript "1.9.671"]

This is a follow up bugfix release to 1.9.660.

As always, feedback welcome!

## 1.9.671

### Fixes
* CLJS-2139: Undeclared var regression in fn bodies
* CLJS-2137: Missing INext on some sequences
* CLJS-2136: Clarify IFind contract to avoid double-lookups
* need to elide :c.a/analyzed in c.a/analyze-wrap-meta to avoid dumping
unintended
  with-meta expressions
* resolve returns improperly constructed Var
* fix :fn-invoke-direct edgecase around keywords

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

Scripting with a pre-prepared environment

[Phillip Lord]

I am trying to build a clojure environment which can run pre-prepared
scripts, using functions from my own library. I've been trying out boot
and it's nice. I can do things like so:


#!/usr/bin/env boot

(set-env! :dependencies '[[uk.org.russet/tawny-owl "2.0.0-SNAPSHOT"]])

(use 'tawny.owl)

(defontology o)
(defclass C)

(save-ontology "ontology-and-class.omn")


For simple uses, this is fine, but it has quite a lot of boilerplate at
the beginning. So, I'd like to replace this.

I thought about having a script like so:

boot --file init.clj --file $*

where "init.clj" would contain my additinal material, but unfortunately,
boot doesn't accept multiple "--file" options.

What I really want to do is to produce an executable like boot but with
my additional functionality added in. Am I missing something obvious
here?

Phil

-- 
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: How to implement a distributed and concurrent system in Clojure?

[Matan]

This thread is a bit old, but it's seen two year awakenings before... and 
still shows up high in google searches.
I wonder how you folks see it now. Onyx is a bit older by now, and not much 
seems new out there. What would you choose for reliable and resilient 
distributed computing with clojure, if you had to start over at this time? 
in particular, for a message driven architecture not a streaming one.


On Monday, July 20, 2015 at 3:52:44 AM UTC+3, Derek Troy-West wrote:
>
> We use Storm/Trident fairly extensively for distributed computation, it 
> has not been painless and the documentation is poor, however it does 
> perform well once you understand its peculiarities. I'm keeping an 
> interested eye on Onyx but my bandwidth is fairly limited at the moment.
>
> The only things I would add to your post are:
>
> * It's possible to write Storm and Trident topologies purely in Clojure, 
> in fact parts of Storm were originally written in Clojure. I'm not sure the 
> DSL were an afterthought, but I agree they are fairly impenetrable at 
> first. Storm has a large learning curve and lots of quirks, and the 
> documentation is pretty bad (in-fact, completely wrong in parts).
>
> * Storm is currently limited to Clojure 1.5.1, thought the latest beta 
> release has been updated to 1.6.0
>
> * Recently the momentum of the project appears to have picked up, but 
> certainly for a while there (just after apache incubation) it appeared a 
> bit stagnant. I presume they were busy settling the project in.
>
>
> On Monday, July 20, 2015 at 3:11:24 AM UTC+10, Christopher Small wrote:
>>
>>
>> I'll also add that if you're interested in the Storm model (distributed 
>> stream processing), you may want to check out Onyx (
>> https://github.com/onyx-platform/onyx). It's newer, but I have a feeling 
>> that moving forward we're going to see it take a dominant position as far 
>> as that flavor of distributed computing goes. The reasons for this 
>> (briefly):
>>
>> * Data all the topologies: Because computational topologies are data 
>> structures, it's far simpler to have more dynamic computational workflows 
>> than with storms opaque macros.
>> * It's more Clojure centric: Parts of Storm are Clojure, but the Clojure 
>> API seems almost an afterthought, reading the documentation. (However, 
>> support is on the way for other JVM languages).
>> * Pace of development: Storm is now an Apache Incubator project, and 
>> development is slower than molasses. I was working on a project for over a 
>> year and many times encountered issues with stale dependencies that didn't 
>> play nicely with newer things.
>> * Designed with batch processing in mind: Even though both are designed 
>> around streaming first, Onyx has a little more explicit support for batched 
>> computations.
>>
>> For a while, the biggest advantage of Storm was that it was a lot faster, 
>> but the gap there has closed considerably recently (perhaps entirely?). 
>> Storm is still more battle tested, but there are folks starting to use it 
>> in production.
>>
>> The biggest reason I see Onyx taking sway over Storm is the data centric 
>> approach. I see this resonating with the community's "data all the things" 
>> philosophy as a way of maximizing composability and productivity. 
>> Anecdotally, folks using Onyx are already saying this about it.
>>
>> My 2 c
>>
>> Chris
>>
>>
>>
>> On Sunday, July 19, 2015 at 9:38:09 AM UTC-7, Devin Walters (devn) wrote:
>>>
>>> http://docs.paralleluniverse.co/pulsar/ is out there. I can't say I've 
>>> used it in anger, but I did enjoy experimenting with it.
>>> On Sun, Jul 19, 2015 at 11:24 AM Colin Yates  wrote:
>>>
 I don’t have anything to add at that scale, but I wanted to echo 
 Stuart’s comment about the serialisability of EDN. Moving EDN between the 
 front and back tiers  on our app has cut down a bunch of boilerplate. That 
 principle can scale across machines as well.

 On 19 Jul 2015, at 16:54, Stuart Sierra  wrote:

 Absolutely would use again. But I'm biased towards Clojure already. :)
 –S

 On Sunday, July 19, 2015 09goral wrote:
>
> Thanks Stuart for your answer, it is very helpfull. Would you choose 
> Clojure again ?
>
> 2015-07-19 17:13 GMT+02:00 Stuart Sierra:
>
>>
>> This is an old thread, but it showed up in my Google Groups so I 
>> figured I would give an answer.
>>
>> I have worked on fairly large (10-50 machines) distributed systems 
>> written entirely in Clojure
>>
>
 -- 
 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