Re: Java interop: dealing with Java implementation instances vs interfaces

[Erik Assum]

I think the method you're looking for is sendAsync. 

As for binding yourself to the implementation, you should stick to whatever 
interface getProducer says it returns, and you'll be ok. 

Erik. 
-- 
i farta

> Den 16. okt. 2016 kl. 08.42 skrev hiskennyness :
> 
> Not sure if this is a Java question or Clojure question, but I think it is 
> the latter.
> 
> I am trying to use the Yahoo pulsar library 
> https://mvnrepository.com/artifact/com.yahoo.pulsar/pulsar-client/1.14 from 
> Clojure.
> 
> It is going OK in general, but a couple times now trying to replicate Java 
> code such as:
> 
> Producer producer = 
> client.createProducer("persistent://sample/standalone/ns1/my-topic");
> 
> ..with:
> 
>   (let [prod (.createProducer client 
> "persistent://sample/standalone/ns1/ktopic")]
> )
> 
> ...all goes well except I end up with prod bound to an instance of 
> ProducerImpl.
> 
> My Java is zilch but I presume the Java code binding the impl to a var type 
> Producer is why the code can then execute:
> 
> producer.send("my-message".getBytes());
> 
> ...whereas I get an error about send not being defined when I do:
> 
> (.send prod "Hi Mom")
> 
> I looked around for a way to "cast" the impl to a Producer but came up empty.
> 
> I did find a public sendAsync on ProducerImpl and that almost worked but then 
> I ran into the same impl vs interface issue with another class 
> (MessageBuilder) and decided I better figure this issue out once and for all.
> 
> Any ideas?
> 
> -kt
> 
> 
> 
> -- 
> 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: Java interop: dealing with Java implementation instances vs interfaces

[hiskennyness]

On Sunday, October 16, 2016 at 3:35:30 AM UTC-4, Erik Assum wrote:
>
> I think the method you're looking for is sendAsync. 
>

Thx, yeah, I did that then ran into the same issue (I thought) trying to 
deal with the MessageBuilder mechanism so I thought I should come to grips 
with the general case.

Turns out i am a twit: The undefined method error arose because I was 
passing in a string and Producer/send is defined for a byte array.

Sorry for the noise.

-kt
 

>
> As for binding yourself to the implementation, you should stick to 
> whatever interface getProducer says it returns, and you'll be ok. 
>
> Erik. 
> -- 
> i farta
>
> Den 16. okt. 2016 kl. 08.42 skrev hiskennyness  >:
>
> Not sure if this is a Java question or Clojure question, but I think it is 
> the latter.
>
> I am trying to use the Yahoo pulsar library 
> https://mvnrepository.com/artifact/com.yahoo.pulsar/pulsar-client/1.14 
> from Clojure.
>
> It is going OK in general, but a couple times now trying to replicate Java 
> code such as:
>
> Producer producer = client.createProducer(
> "persistent://sample/standalone/ns1/my-topic");
>
> ..with:
>
>   (let [prod (.createProducer client 
> "persistent://sample/standalone/ns1/ktopic")]
> )
>
> ...all goes well except I end up with prod bound to an instance of 
> ProducerImpl.
>
> My Java is zilch but I presume the Java code binding the impl to a var 
> type Producer is why the code can then execute:
>
> producer.send("my-message".getBytes());
>
> ...whereas I get an error about send not being defined when I do:
>
> (.send prod "Hi Mom")
>
> I looked around for a way to "cast" the impl to a Producer but came up 
> empty.
>
> I did find a public sendAsync on ProducerImpl and that almost worked but 
> then I ran into the same impl vs interface issue with another class 
> (MessageBuilder) and decided I better figure this issue out once and for 
> all.
>
> Any ideas?
>
> -kt
>
>
>
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clo...@googlegroups.com 
> Note that posts from new members are moderated - please be patient with 
> your first post.
> To unsubscribe from this group, send email to
> clojure+u...@googlegroups.com 
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+u...@googlegroups.com .
> For more options, visit https://groups.google.com/d/optout.
>
>

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

Re: Possible ClojureScript compiler issue...

[David Nolen]

It's true that there other scenarios where you can encounter this but it
gets reported infrequently enough that I don't think these kinds of
property name collisions are common.

Still it has come up before and I think the simplest solution least likely
to adversely affect performance is to test for a def'onced unique object
instead of `true`.

David

On Sat, Oct 15, 2016 at 8:46 PM, Antonin Hildebrand <
antonin.hildebr...@gmail.com> wrote:

> Unfortunately, this problem is not specific to `js->clj` only.
>
> I believe in general under :advanced optimizations, any object which was
> created or modified by a code which
> was not subject of the same closure compiler optimization pass could
> exhibit similar problems when used with ClojureScript core functions like
> `satisfies?`.
>
> That also includes working with external data (your case), and working
> with objects created/modified by adding properties by string names.
>
> To illustrate, I created a screenshot of cljs type instance with two
> protocols, to see the internals in dev mode:
> https://dl.dropboxusercontent.com/u/559047/cljs-protocol-internals-01.png
> In the selected text I highlighted part of generated code for `satisfies?`
> call.
>
> ClojureScript adds/checks $cljs prefixed properties to objects. These
> internal properties get renamed by closure compiler.
> So any object which happens to have one of those renamed names
> independently added as their property will potentially confuse functions
> like `satisfies?`.
>
> Possible solutions I see:
>
> 1. use string names for clojurescript internal properties, and avoid
> clashes by using "unique-enough" prefix even in advanced mode - still not
> safe solution, but would minimize clash chances
>
> or
>
> 2. start tracking which objects belong to cljs land, have one
> "unique-enough" string name as a marker, clojurescript functions like
> satisfies? would check this marker before proceeding further. Still dirty,
> one could clobber cljs properties by modifying a cljs-land-object from
> unaware Javascript code. And this would probably change behaviour of some
> existing code.
>
> or
>
> 3. use prototypal inheritance and "hide" all ClojureScript internal
> properties in a new link in the prototype chain, plain javascript objects
> would miss this link so it could be easily detected, properties would not
> clash even if they got same names. ClojureScript functions like satisfies?
> would properly
> walk the chain and read properties from proper link which belongs only to
> ClojureScript. Ale we would not need any special "magic" marker - the
> Javascript type of the link in prototype would safely identify it.
> I believe this would be correct solution. But I guess, this would be too
> dramatic change in ClojureScript internals and might break a lot of other
> things I currently don't understand. Also performance could get a hit.
>
> Better ideas, anyone? :-)
>
> ps. don't use :advanced mode when programming atomic reactors in
> ClojureScript ;-p
>
> On Saturday, October 15, 2016 at 10:59:14 PM UTC+2, John Szakmeister wrote:
>
>> On Sat, Oct 15, 2016 at 2:49 PM, David Nolen 
>> wrote:
>> > This issue is somewhat to be expected if you're going to use `js->clj`.
>> This
>> > issue has nothing to do with ClojureScript compiler versions - you just
>> got
>> > lucky before. Google Closure will collapse properties, but some of
>> these
>> > collapsed properties are going to be used to determine protocol
>> membership.
>> > That's it.
>>
>> Wow.  I did not that expect that at all.  It makes sense, but it's
>> unfortunate.
>>
>> > I suggest just avoiding `js->clj` and using your own simple helper for
>> > recursively converting JSON into Clojure values. Changing the
>> (admittedly
>> > questionable) behavior of `js->clj` will only lead to more breakage.
>>
>> I'll definitely look at alternatives.  It'd be nice if js->clj had
>> documentation on this shortcoming though, and perhaps pointers to
>> better alternatives.
>>
>> Thanks for the help David!
>>
>> -John
>>
> --
> 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 

Re: Possible ClojureScript compiler issue...

[Thomas Heller]

FWIW I investigated the check with "true" and a sentinel value and found 
them to both have a small performance impact over just checking for a 
true-ish property.

http://dev.clojure.org/jira/browse/CLJS-1658

The impact is really small so it might be worth the trade-off.

/thomas

On Sunday, October 16, 2016 at 3:59:20 PM UTC+2, David Nolen wrote:
>
> It's true that there other scenarios where you can encounter this but it 
> gets reported infrequently enough that I don't think these kinds of 
> property name collisions are common.
>
> Still it has come up before and I think the simplest solution least likely 
> to adversely affect performance is to test for a def'onced unique object 
> instead of `true`.
>
> David
>
> On Sat, Oct 15, 2016 at 8:46 PM, Antonin Hildebrand <
> antonin.h...@gmail.com > wrote:
>
>> Unfortunately, this problem is not specific to `js->clj` only.
>>
>> I believe in general under :advanced optimizations, any object which was 
>> created or modified by a code which 
>> was not subject of the same closure compiler optimization pass could 
>> exhibit similar problems when used with ClojureScript core functions like 
>> `satisfies?`.
>>
>> That also includes working with external data (your case), and working 
>> with objects created/modified by adding properties by string names.
>>
>> To illustrate, I created a screenshot of cljs type instance with two 
>> protocols, to see the internals in dev mode:
>> https://dl.dropboxusercontent.com/u/559047/cljs-protocol-internals-01.png
>> In the selected text I highlighted part of generated code for 
>> `satisfies?` call.
>>
>> ClojureScript adds/checks $cljs prefixed properties to objects. These 
>> internal properties get renamed by closure compiler.
>> So any object which happens to have one of those renamed names 
>> independently added as their property will potentially confuse functions 
>> like `satisfies?`.
>>
>> Possible solutions I see:
>>
>> 1. use string names for clojurescript internal properties, and avoid 
>> clashes by using "unique-enough" prefix even in advanced mode - still not 
>> safe solution, but would minimize clash chances
>>
>> or 
>>
>> 2. start tracking which objects belong to cljs land, have one 
>> "unique-enough" string name as a marker, clojurescript functions like 
>> satisfies? would check this marker before proceeding further. Still dirty, 
>> one could clobber cljs properties by modifying a cljs-land-object from 
>> unaware Javascript code. And this would probably change behaviour of some 
>> existing code.
>>
>> or
>>
>> 3. use prototypal inheritance and "hide" all ClojureScript internal 
>> properties in a new link in the prototype chain, plain javascript objects 
>> would miss this link so it could be easily detected, properties would not 
>> clash even if they got same names. ClojureScript functions like satisfies? 
>> would properly
>> walk the chain and read properties from proper link which belongs only to 
>> ClojureScript. Ale we would not need any special "magic" marker - the 
>> Javascript type of the link in prototype would safely identify it.
>> I believe this would be correct solution. But I guess, this would be too 
>> dramatic change in ClojureScript internals and might break a lot of other 
>> things I currently don't understand. Also performance could get a hit.
>>
>> Better ideas, anyone? :-)
>>
>> ps. don't use :advanced mode when programming atomic reactors in 
>> ClojureScript ;-p
>>
>> On Saturday, October 15, 2016 at 10:59:14 PM UTC+2, John Szakmeister 
>> wrote:
>>
>>> On Sat, Oct 15, 2016 at 2:49 PM, David Nolen  
>>> wrote: 
>>> > This issue is somewhat to be expected if you're going to use 
>>> `js->clj`. This 
>>> > issue has nothing to do with ClojureScript compiler versions - you 
>>> just got 
>>> > lucky before. Google Closure will collapse properties, but some of 
>>> these 
>>> > collapsed properties are going to be used to determine protocol 
>>> membership. 
>>> > That's it. 
>>>
>>> Wow.  I did not that expect that at all.  It makes sense, but it's 
>>> unfortunate. 
>>>
>>> > I suggest just avoiding `js->clj` and using your own simple helper for 
>>> > recursively converting JSON into Clojure values. Changing the 
>>> (admittedly 
>>> > questionable) behavior of `js->clj` will only lead to more breakage. 
>>>
>>> I'll definitely look at alternatives.  It'd be nice if js->clj had 
>>> documentation on this shortcoming though, and perhaps pointers to 
>>> better alternatives. 
>>>
>>> Thanks for the help David! 
>>>
>>> -John 
>>>
>> -- 
>> 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
>> --- 

Re: [ANN] clj-xchart – A charting/plotting library for Clojure

[Alan Thompson]

Looks nice - I'll be keeping it in mind.
Alan

On Sat, Oct 15, 2016 at 5:31 AM, Jean Niklas L'orange  wrote:

> Hi Clojurians,
>
> I am happy to announce clj-xchart !
> XChart  is a lightweight charting
> library for Java. clj-xchart wraps this library and tries to be a
> succinct yet evident charting library for Clojure. The library can
> emit the following chart types:
>
> - Line charts
> - Scatter charts
> - Area charts
> - Bar charts
> - Histogram charts
> - Pie charts
> - Donut charts
> - Bubble charts
> - Stick charts
>
> It also provides the following useful features:
>
> - Easy to compare, view and make charts from a REPL
> - Logarithmic axes
> - Number, Date and Category X-Axis
> - Export to png, gif, jpg, svg, pdf and eps
> - Extensive customisation
>
> Note that clj-xchart is a Clojure only library; if you need
> interactive or animated charts in a web browser, then this library
> will not help you with that. However, if you need png/jpg/svg/pdfs of
> charts, then this may be a viable option.
>
> To see a couple of example charts, along with the code required to
> generate them, head over to the examples page
> .
>
> The tutorial
>  for
> the current release should give you a good
> introduction in how to use the library, and the render options page
> 
> page has additional information about how to style the charts. The
> majority of all commits and work has been related to examples and
> documentation, and I hope this will make the library easy to use.
>
> The source code is over at https://github.com/hyPiRion/clj-xchart
>
> Suggestions and contributions are welcome!
>
> -- Jean Niklas
>
> --
> 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: Java like static typing for Clojure?

[Alan Thompson]

Be sure to check out Plumatic Schema 
(previously Prismatic Schema) if you haven't already.  There is also a
good Clojure
Conj video  from 2013.
Alan

On Sat, Oct 15, 2016 at 3:14 PM, Didier  wrote:

> I know a lot of people like to say how unhelpful Java like static typing
> is, and only more powerful type systems of the ML family add value, but
> I've been wondering recently if for Clojure it wouldn't make more sense to
> simply extend the type hints to enable an optional Java like static typing
> scheme.
>
> It is my understanding that ML style static typing is incredibly difficult
> to add properly and without compromise to a dynamic language. That doing so
> limits the scope of type inference, rendering the task of adding type info
> more tedious then in ML languages themselves.
>
> ML style static typing provide enhanced safety grantees, but seem to add
> too much complexity to Clojure to be practical. What about a Java like
> static typing scheme though?
>
> I haven't found in practice that the safety of Clojure was an issue, as
> the REPL workflow tend to promote quite a lot of testing. So I'm not too
> worried about needing the state of the art of provable correctness for my
> programs. What has been a biggest cause of issue to me was refactoring and
> shared code base across a team. Those last two use cases are actually
> pretty well handled by Java like static type checking. Is it a powerful
> type checker, not really, but it enables most trivial type errors to be
> caught early, and it allows easier integration points for other devs to
> follow, as well as documentation for functions, better tools support and
> easier refactoring, while also enabling performance optimizations.
>
> I have limited knowledge in typing systems, and have no idea how easy it
> is to implement them, but as a user of Clojure, I feel like I would find an
> optional Java like static typing a great addition, one that I am more
> willing to use and benefit from then Typed Clojure's more complex ML style
> type checking.
>
> What do other think?
> Can anyone with better knowledge tell me if this would be feasible or if
> adding such gradual typing system is effectively as hard as adding ML style
> type checking?
>
> --
> 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: Is there an easy way for s/keys spec to work against both qualified/unqualiffied keys at the same time?

[Ikuru Kanuma]

Mauricio, thanks for the response!
I agree that that gets what I asked for done, but that solution is in 
essence writing the same 
qualified/unqualified version of the spec twice and sounded redundant, 
which lead to my question.
I guess it is what it is in that case...

Leon, thanks for the response.
what I meant to say by 'exclusive' is the 'same'(difference in namespaced 
or not)
keyword that get checked by req/req-un options.
i.e. req only checks for the qualified version and req-un only checks for 
the unqualified version.
Sorry, should have been clearer.

-- 
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] clj-xchart – A charting/plotting library for Clojure

[Mars0i]

Looks very nice! Thanks Jean Niklas.  I've been using Incanter for charts, 
which has been fine so far for my needs, but clj-xchart looks like it will 
make it easier to make nicer charts, and it would avoid loading much of 
Incanter when you don't need some of the other things Incanter provides.  
(I also use nvd3 to generate charts in a browser with Clojurescript.)

Since you've developed a charting library, maybe I'll mention a feature 
that I have wanted (I think!): 

I've been making plots with a large number of points--100K, sometimes even 
1M or 2M per data sequence.  Sometimes I will sample a larger sequence 
every 10 or 100 steps to reduce the burden on the Incanter or nvd3 plotting 
function, but sometimes I want to see what the data looks like with all of 
the points.

I generate the data in a lazy sequence, using iterate, where, let's say, 
each element of the sequence is a map containing several pieces  of y 
values for the x value corresponding to that element of the sequence, e.g.

data = ({:a y-a-1, :b y-b-1, :c y-c-1}, {:a y-a-2, :b y-b-2, :c y-c-2}, ...)

In order to plot all three sequences of y values in Incanter or nvd3 (and 
clj-xchart?), I have to extract a new sequence of values for each data 
series, e.g. like this:

(map :a data)
(map :b data)
(map :c data)

and I have to generate several sequences of x values by calling (range) 
repeatedly.  I pass these six lazy sequences to the chart function, but at 
least in Incanter and nvd3, I don't believe Incanter does anything until it 
realizes all of the sequences.  That means that it realizes six distinct 
sequences, I think, and my initial sequence of maps will have been realized 
as well.  

But if I'm plotting several sequences of y values that are embedded in a 
sequence of maps or vectors, each with several y values for the same x, I 
wonder if it could be more to efficient pass the entire complex sequence to 
the plotting function at once, and only provide one set of x values if all 
of the y values will share the same x's.  If the plotting function extracts 
the y values as it reads through the sequence of maps/vectors, and needs 
only one sequence of x's, then only two sequences are realized.

Maybe this is an unusual need, at present, but as Clojure is used for more 
scientific applications, it might become more common.


-- 
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}} Carmine-sentinel: connect redis by sentinel, make carmine to support sentinel.

[dennis zhuang]

hi, all

I released carmine-sentinel 0.1.0-RC1, it supports reading data from  Redis
slave and supports other APIs(MQ, Pub/Sub,Lock etc) in carmine.

(def slave-conn {:pool {} :spec {}
 :sentinel-group :group1 :master-name "mymaster"
 :prefer-slave? true})

(defmacro wcars* [& body] `(cs/wcar slave-conn ~@body))

(wcars* (car/set "key" 1)) ;; ExceptionInfo READONLY You can't write
against a read only slave


More info please visit https://github.com/killme2008/carmine-sentinel



2016-10-13 19:43 GMT+08:00 dennis zhuang :

> Hi, all
>
> I wrote a library to make carmine 
> support redis sentinel :
>
> https://github.com/killme2008/carmine-sentinel
>
> Someone may want to try it if you are interested. It's a beta release,
> feedback is welcome.
>
> --
> 庄晓丹
> Email:killme2...@gmail.com xzhu...@avos.com
> Site:   http://fnil.net
> Twitter:  @killme2008
>
>
>


-- 
庄晓丹
Email:killme2...@gmail.com xzhu...@avos.com
Site:   http://fnil.net
Twitter:  @killme2008

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