[ANN] [helpshift/gulfstream "0.2.1"] - rapid graph visualizations

[zcaudate]

gulfstream (https://github.com/helpshift/gulfstream) is a library with 
similar functionality to https://github.com/aysylu/loom and 
https://github.com/ztellman/rhizome

Built on top of graphstream(http://graphstream-project.org), it's main 
advantage lies in rapid visualisation, interaction and styling of the 
directed graph.

The documentation is at http://helpshift.github.io/gulfstream/

-- 
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: Stuart Sierra's Component: retries & restarts in production

[Dave Tenny]

I'm using components to encapsulate Langohr/RabbitMQ interactions in cases 
where Langohr auto-recovery wasn't happy with what was going on.

I make sure the Lifecycle methods are idempotent, built the component stack 
in the correct order.  

To make sure that I can deal with the exceptions that require restarting 
the component stack, I have some macros that wrap up exception handling, 
retries, and component stack restarts.

So

(with-rmq-publisher! [channel component-system]
  ... do my stuff ...)

The body of the macro ("... do my stuff ...") is turned into a function and 
and will be re-executed if the system is restarted, so you have to beware
of side effects or other things you may not want executed multiple times. 
 Not a problem for me, all I'm doing is entering the macro long enough
to get a channel and publish to it, or similar types of things.

The component-system is a wrap of the system-map call with some other data, 
in an atom, that will be mutated
if we do things like dynamically add subscribers to the system or call 
(restart! component-system).
There are some thread safety/locking concerns, since a connection failure 
is likely to be seen by callers
on multiple threads using the components, and I try to avoid race 
conditions on restarts (only one thread will do the restart until it 
succeeds, 
the unblock the others).

Hope this helps with strategy, even if the code is omitted.

The trick to me was not in restarting the component stack, but in managing 
the shared state across threads safely and making sure (with-stack-activity 
[system] )
code was prepared to re-execute on failures with new connections or other 
stack components.

In my case I also needed to add components to the stack dynamically.  Not 
often, but dynamcially, not at (system-map) call time.  That required some 
lock consideration,
and I'd have to call Lifecycle/start on the stack every time I added a 
component.  They methods have to be idempotent.

  

-- 
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: numbers, why?

[dennis zhuang]

Because the literal is readed as BigInt:

user=> (class 6546546546546546546850348954895480584039545804 )
clojure.lang.BigInt

2015-09-04 22:48 GMT+08:00 Ali M :

> why?
>
> 
> user=> (+ 6546546546546546546850348954895480584039545804
> 7548979534287548957345843954749357348757897)
> 6554095526080834095807694798850229941388303701N
>
> user=> (+ Long/MAX_VALUE Long/MAX_VALUE)
>
> ArithmeticException integer overflow
> clojure.lang.Numbers.throwIntOverflow (Numbers.java:1501)
>
> user=> Long/MAX_VALUE
> 9223372036854775807
> 
>
> Why the much bigger numbers get promoted, and a smaller number overflows?
>
> Thank you
> Ali
>
> --
> 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.
>



-- 
庄晓丹
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.

numbers, why?

[Ali M]

why?


user=> (+ 6546546546546546546850348954895480584039545804 
7548979534287548957345843954749357348757897)
6554095526080834095807694798850229941388303701N

user=> (+ Long/MAX_VALUE Long/MAX_VALUE)

ArithmeticException integer overflow  clojure.lang.Numbers.throwIntOverflow 
(Numbers.java:1501)

user=> Long/MAX_VALUE
9223372036854775807


Why the much bigger numbers get promoted, and a smaller number overflows?

Thank you
Ali

-- 
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: Stuart Sierra's Component: retries & restarts in production

[Dave Tenny]

Caveat: my approach may have been all wrong.  It's the first time I tried
stuartsierra components.  Frankly I'd have been happier with some CLOS
objects and before and after methods, I'm still getting the hang of this
clojure stuff.

On Fri, Sep 4, 2015 at 7:57 AM, Dave Tenny  wrote:

> I'm using components to encapsulate Langohr/RabbitMQ interactions in cases
> where Langohr auto-recovery wasn't happy with what was going on.
>
> I make sure the Lifecycle methods are idempotent, built the component
> stack in the correct order.
>
> To make sure that I can deal with the exceptions that require restarting
> the component stack, I have some macros that wrap up exception handling,
> retries, and component stack restarts.
>
> So
>
> (with-rmq-publisher! [channel component-system]
>   ... do my stuff ...)
>
> The body of the macro ("... do my stuff ...") is turned into a function
> and and will be re-executed if the system is restarted, so you have to
> beware
> of side effects or other things you may not want executed multiple times.
> Not a problem for me, all I'm doing is entering the macro long enough
> to get a channel and publish to it, or similar types of things.
>
> The component-system is a wrap of the system-map call with some other
> data, in an atom, that will be mutated
> if we do things like dynamically add subscribers to the system or call
> (restart! component-system).
> There are some thread safety/locking concerns, since a connection failure
> is likely to be seen by callers
> on multiple threads using the components, and I try to avoid race
> conditions on restarts (only one thread will do the restart until it
> succeeds,
> the unblock the others).
>
> Hope this helps with strategy, even if the code is omitted.
>
> The trick to me was not in restarting the component stack, but in managing
> the shared state across threads safely and making sure (with-stack-activity
> [system] )
> code was prepared to re-execute on failures with new connections or other
> stack components.
>
> In my case I also needed to add components to the stack dynamically.  Not
> often, but dynamcially, not at (system-map) call time.  That required some
> lock consideration,
> and I'd have to call Lifecycle/start on the stack every time I added a
> component.  They methods have to be idempotent.
>
>
>
> --
> 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/JCvKLIsfSgA/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: numbers, why?

[Ali M]

Ok, so to give myself a safe and consistent way to reason about this
the addition operator, and probably other arithmetic operator 
dont promote ouput 

so long+ long = long or exception 
long + bigint = bigint

if i need outpout promition i can use +'

hmmm, a bit tricky

On Friday, September 4, 2015 at 10:51:15 AM UTC-4, dennis wrote:
>
> Because the literal is readed as BigInt:
>
> user=> (class 6546546546546546546850348954895480584039545804 )
> clojure.lang.BigInt
>
> 2015-09-04 22:48 GMT+08:00 Ali M :
>
>> why?
>>
>> 
>> user=> (+ 6546546546546546546850348954895480584039545804 
>> 7548979534287548957345843954749357348757897)
>> 6554095526080834095807694798850229941388303701N
>>
>> user=> (+ Long/MAX_VALUE Long/MAX_VALUE)
>>
>> ArithmeticException integer overflow  
>> clojure.lang.Numbers.throwIntOverflow (Numbers.java:1501)
>>
>> user=> Long/MAX_VALUE
>> 9223372036854775807
>> 
>>
>> Why the much bigger numbers get promoted, and a smaller number overflows?
>>
>> Thank you
>> Ali
>>
>> -- 
>> 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.
>>
>
>
>
> -- 
> 庄晓丹 
> Email:killm...@gmail.com  xzh...@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.

supporting metadata caret reader syntax with deftype

[Gregg Reynolds]

I have a deftype that supports with-meta, but I can't figure out how to
support caret reader syntax.

To support with-meta, I include a "meta" field and implement IObj methods
"meta" and "withMeta".  Seems to work just fine:

(with-meta (entity-map [:A/B] {:a 1})  {:foo "metadata here"})

But this doesn't work:  ^{:foo "metadata there"}(entity-map [:A/B] {:a 1})

In LispReader.clj it looks to me like the MetaReader checks to see if
object is instanceof IMeta, ISeq (so it can call assoc) and IReference (so
it can call resetMeta).  My deftype supports both of those interfaces, but
the methods are not called when I construct an object using caret syntax,
as above.

Can anybody shed some light on this?

Thanks,

Gregg

-- 
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: Stuart Sierra's Component: retries & restarts in production

[zcaudate]

We make sure the components we build know how to restart themselves. This 
avoids the use of start/stop.

-- 
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: some guidance sought

[William la Forge]

I've now finished an initial draft of AA Tree Map and it passes 
collection-check:


(deftest tests
  (assert-map-like (create-aamap)
   gen-element gen-element
   ;   {:base (sorted-map) :ordered? true}
   ))


Unfortunately I had to comment out the test against sorted-map. I was 
getting this error:

ERROR in (tests) (generators.clj:366)
Uncaught exception, not in assertion.
expected: nil
  actual: java.lang.AssertionError: Assert failed: Args to tuple must be 
generators
(every? generator? generators)
 at clojure.test.check.generators$tuple.doInvoke (generators.clj:366)
clojure.lang.RestFn.invoke (RestFn.java:421)
collection_check$gen_meta.invoke (collection_check.clj:30)
collection_check$gen_map_actions.invoke (collection_check.clj:91)
collection_check$assert_map_like.invoke (collection_check.clj:306)
collection_check$assert_map_like.invoke (collection_check.clj:299)
aatree.core_test/fn (core_test.clj:36)
clojure.test$test_var$fn__7670.invoke (test.clj:704)
clojure.test$test_var.invoke (test.clj:704)
clojure.test$test_vars$fn__7692$fn__7697.invoke (test.clj:722)
clojure.test$default_fixture.invoke (test.clj:674)
clojure.test$test_vars$fn__7692.invoke (test.clj:722)
clojure.test$default_fixture.invoke (test.clj:674)
clojure.test$test_vars.invoke (test.clj:718)
clojure.test$test_all_vars.invoke (test.clj:728)
clojure.test$test_ns.invoke (test.clj:747)
clojure.core$map$fn__4553.invoke (core.clj:2624)
clojure.lang.LazySeq.sval (LazySeq.java:40)
clojure.lang.LazySeq.seq (LazySeq.java:49)
clojure.lang.Cons.next (Cons.java:39)
clojure.lang.RT.boundedLength (RT.java:1735)
clojure.lang.RestFn.applyTo (RestFn.java:130)
clojure.core$apply.invoke (core.clj:632)
clojure.test$run_tests.doInvoke (test.clj:762)
clojure.lang.RestFn.applyTo (RestFn.java:137)
clojure.core$apply.invoke (core.clj:630)
user$eval85$fn__140$fn__171.invoke (form-init7529748499207850099.clj:1)
user$eval85$fn__140$fn__141.invoke (form-init7529748499207850099.clj:1)
user$eval85$fn__140.invoke (form-init7529748499207850099.clj:1)
user$eval85.invoke (form-init7529748499207850099.clj:1)
clojure.lang.Compiler.eval (Compiler.java:6782)
clojure.lang.Compiler.eval (Compiler.java:6772)
clojure.lang.Compiler.load (Compiler.java:7227)
clojure.lang.Compiler.loadFile (Compiler.java:7165)
clojure.main$load_script.invoke (main.clj:275)
clojure.main$init_opt.invoke (main.clj:280)
clojure.main$initialize.invoke (main.clj:308)
clojure.main$null_opt.invoke (main.clj:343)
clojure.main$main.doInvoke (main.clj:421)
clojure.lang.RestFn.invoke (RestFn.java:421)
clojure.lang.Var.invoke (Var.java:383)
clojure.lang.AFn.applyToHelper (AFn.java:156)
clojure.lang.Var.applyTo (Var.java:700)
clojure.main.main (main.java:37)

Any suggestions?

On Monday, August 24, 2015 at 8:46:12 AM UTC-4, icamts wrote:
>
> Not a pointer but this may help in testing your implementation: 
> https://github.com/ztellman/collection-check
>
> Il giorno lunedì 10 agosto 2015 00:31:25 UTC+2, William la Forge ha 
> scritto:
>>
>> I've done a lot with AA trees in the past, creating variations that are 
>> immutable, durable (replacing b-trees) and versioned of vectors, maps and 
>> sets.
>>
>> I would like to migrate these ideas from Java to Clojure, while 
>> implementing the interfaces appropriate for Clojure.
>>
>> Still being very much a newbie, I'd appreciate some pointers, relevant 
>> docs and/or examples.
>>
>> 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.

Re: supporting metadata caret reader syntax with deftype

[Gregg Reynolds]

On Fri, Sep 4, 2015 at 11:30 AM, Gregg Reynolds  wrote:

> I have a deftype that supports with-meta, but I can't figure out how to
> support caret reader syntax.
>
> To support with-meta, I include a "meta" field and implement IObj methods
> "meta" and "withMeta".  Seems to work just fine:
>
> (with-meta (entity-map [:A/B] {:a 1})  {:foo "metadata here"})
>
> But this doesn't work:  ^{:foo "metadata there"}(entity-map [:A/B] {:a 1})
>

Ok, so (entity-map...) is passed to the MetaReader as a PersistentList.  Of
course.  And if I say (def em (entity-map [:A/B] {:a 2})) and then say (def
em2 ^{:foo "bar"} em), then em gets passed as a symbol so the metadata does
not stick.

So it looks like you can only use caret metadata syntax with forms, rather
than types/values.  If I wanted my deftype to support caret metadata,  I
would have to defined a custom reader syntax for it, which as I understand
is not currently possible.  Does that sound accurate?

Then again, the doc says

*Metadata (^)
   Metadata is a map associated with some kinds of objects: Symbols, Lists,
Vector, Sets, Maps, tagged literals returning an IMeta, and record, type,
and constructor calls."

So let's try a Symbol:
  (symbol? 'a) is true,
 (instance? clojure.lang.IMeta 'a) is true, but
 (meta ^{:foo 3} 'a)  is nil, while
 (meta ^{:foo 4} [1 2])  is {:foo 4}

So now I'm confused.  Is the documentation just out of sync or am I
misunderstanding something?

Thanks,

Gregg

-- 
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: some guidance sought

[William la Forge]

Fixed. I left out the n argument, which is not optional when specifying 
options:

(deftest tests
  (assert-map-like 100
(create-aamap)
gen-element gen-element
{:base (sorted-map) :ordered? true}))


Runs great. :-)

On Friday, September 4, 2015 at 2:29:49 PM UTC-4, William la Forge wrote:
>
> Here's the link to the test file: 
> https://github.com/laforge49/aatree/blob/master/test/aatree/core_test.clj
>
> On Friday, September 4, 2015 at 2:26:52 PM UTC-4, William la Forge wrote:
>>
>> I've now finished an initial draft of AA Tree Map and it passes 
>> collection-check:
>>
>>
>> (deftest tests
>>   (assert-map-like (create-aamap)
>>gen-element gen-element
>>;   {:base (sorted-map) :ordered? true}
>>))
>>
>>
>> Unfortunately I had to comment out the test against sorted-map. I was 
>> getting this error:
>>
>> ERROR in (tests) (generators.clj:366)
>> Uncaught exception, not in assertion.
>> expected: nil
>>   actual: java.lang.AssertionError: Assert failed: Args to tuple must be 
>> generators
>> (every? generator? generators)
>>  at clojure.test.check.generators$tuple.doInvoke (generators.clj:366)
>> clojure.lang.RestFn.invoke (RestFn.java:421)
>> collection_check$gen_meta.invoke (collection_check.clj:30)
>> collection_check$gen_map_actions.invoke (collection_check.clj:91)
>> collection_check$assert_map_like.invoke (collection_check.clj:306)
>> collection_check$assert_map_like.invoke (collection_check.clj:299)
>> aatree.core_test/fn (core_test.clj:36)
>> clojure.test$test_var$fn__7670.invoke (test.clj:704)
>> clojure.test$test_var.invoke (test.clj:704)
>> clojure.test$test_vars$fn__7692$fn__7697.invoke (test.clj:722)
>> clojure.test$default_fixture.invoke (test.clj:674)
>> clojure.test$test_vars$fn__7692.invoke (test.clj:722)
>> clojure.test$default_fixture.invoke (test.clj:674)
>> clojure.test$test_vars.invoke (test.clj:718)
>> clojure.test$test_all_vars.invoke (test.clj:728)
>> clojure.test$test_ns.invoke (test.clj:747)
>> clojure.core$map$fn__4553.invoke (core.clj:2624)
>> clojure.lang.LazySeq.sval (LazySeq.java:40)
>> clojure.lang.LazySeq.seq (LazySeq.java:49)
>> clojure.lang.Cons.next (Cons.java:39)
>> clojure.lang.RT.boundedLength (RT.java:1735)
>> clojure.lang.RestFn.applyTo (RestFn.java:130)
>> clojure.core$apply.invoke (core.clj:632)
>> clojure.test$run_tests.doInvoke (test.clj:762)
>> clojure.lang.RestFn.applyTo (RestFn.java:137)
>> clojure.core$apply.invoke (core.clj:630)
>> user$eval85$fn__140$fn__171.invoke 
>> (form-init7529748499207850099.clj:1)
>> user$eval85$fn__140$fn__141.invoke 
>> (form-init7529748499207850099.clj:1)
>> user$eval85$fn__140.invoke (form-init7529748499207850099.clj:1)
>> user$eval85.invoke (form-init7529748499207850099.clj:1)
>> clojure.lang.Compiler.eval (Compiler.java:6782)
>> clojure.lang.Compiler.eval (Compiler.java:6772)
>> clojure.lang.Compiler.load (Compiler.java:7227)
>> clojure.lang.Compiler.loadFile (Compiler.java:7165)
>> clojure.main$load_script.invoke (main.clj:275)
>> clojure.main$init_opt.invoke (main.clj:280)
>> clojure.main$initialize.invoke (main.clj:308)
>> clojure.main$null_opt.invoke (main.clj:343)
>> clojure.main$main.doInvoke (main.clj:421)
>> clojure.lang.RestFn.invoke (RestFn.java:421)
>> clojure.lang.Var.invoke (Var.java:383)
>> clojure.lang.AFn.applyToHelper (AFn.java:156)
>> clojure.lang.Var.applyTo (Var.java:700)
>> clojure.main.main (main.java:37)
>>
>> Any suggestions?
>>
>> On Monday, August 24, 2015 at 8:46:12 AM UTC-4, icamts wrote:
>>>
>>> Not a pointer but this may help in testing your implementation: 
>>> https://github.com/ztellman/collection-check
>>>
>>> Il giorno lunedì 10 agosto 2015 00:31:25 UTC+2, William la Forge ha 
>>> scritto:

 I've done a lot with AA trees in the past, creating variations that are 
 immutable, durable (replacing b-trees) and versioned of vectors, maps and 
 sets.

 I would like to migrate these ideas from Java to Clojure, while 
 implementing the interfaces appropriate for Clojure.

 Still being very much a newbie, I'd appreciate some pointers, relevant 
 docs and/or examples.

 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 

Re: Stuart Sierra's Component: retries & restarts in production

[Josh Tilles]

I just found the other resources from the Component wiki 
—it may be that 
something linked from there addresses exactly my situation.

On Wednesday, September 2, 2015 at 8:44:07 PM UTC-4, jo...@signafire.com 
wrote:
>
> TLDR: how do you use Component when the application logic involves 
> retrying failed components?
>
> Background:
> I'm writing an app that consumes events from a streaming HTTP connection 
> and writes those events to a message queue (see Code Illustration #1). It 
> seems like that could be captured easily with three components —an HTTP 
> stream, a message queue connection, and a "shoveler" that depends on the 
> other two (see Code Illustration #2)— *but* the reconnection requirements 
> complicate things…
> The HTTP connection may be closed at any time by the server; if that 
> happens, the app should persistently attempt to reconnect using an 
> exponential back-off pattern. In addition, if the app goes thirty seconds 
> without receiving any data, it should close the connection and try to 
> reconnect. (see Code Illustration #3) It's not clear to me how to best 
> express these "retry" requirements in the component lifecycle. Like, is it 
> blasphemous for a component to be calling stop and start on its injected 
> dependencies?
>
> Some possible approaches:
>
>- Throw different kinds of exceptions to indicate what should happen 
>(using namespaced keywords, perhaps?), handled by whoever calls 
>component/start on the system-map.
>- The exception provides the component and system at the time of the 
>   exception, enabling a sort of "resume" capability.
>   - I'm under the impression that relying on exceptions for control 
>   flow is an anti-pattern.
>- Create a sort of custom system implementation, one that goes beyond 
>calling start on its components in dependency order to monitor 
>failures and direct retries "appropriately".
>   - "A system is a component which knows how to start and stop other 
>   components." (from the README)
>   So the fact that we want the shoveler component to be capable of 
>   restarting the HTTP component indicates that the shoveler should 
> actually 
>   be considered a system. (right?)
>  - If the HTTP stream is *injected* into the shoveler as a 
>  dependency, how is it possible for the shoveler to stop the HTTP 
>  stream and then start it again *with* any dependencies the 
>  stream may have?
>   - Ensure that every component/Lifecycle method implementation is 
>idempotent, so that I can get good-enough "restart" semantics by just 
>calling start-system again.
>   - I know that idempotence is generally a Good Thing anyway, but 
>   using start-system as a panacea strikes me as crude.
>
>
> Code Illustrations:
>
> 1. Rough sketch of app without timeout/retry logic or component:
> (defn -main []
>   (let [mq-conn (connect-to-queue mq-config)
> {event-stream :body} (http/get endpoint {:as :stream})]
> (with-open [rdr (java.io/reader event-stream)]
>   (doseq [entity (line-seq rdr)]
> (write mq-conn entity)
>
> 2. Rough sketch of app with component but still without timeout/retry 
> logic:
> (defrecord EventStream [endpoint
> http-config
> stream]
>   component/Lifecycle
>   (start [this]
> (let [response (http/get endpoint (merge {:as :stream} http-config))]
>   (assoc this :http-response response, :stream (:body response)))
>   (stop [this]
> (.close stream)
> (-> this (dissoc :http-response) (assoc :stream nil
>
> (defrecord MessageQueue [config
>  connection]
>   component/Lifecycle
>   (start [this]
> (assoc this :connection (connect-to-queue config)))
>   (stop [this]
> (.close connection)
> (assoc this :connection nil)))
>
> (defrecord Shoveler [source sink
>  worker]
>   component/Lifecycle
>   (start [this]
> ;; To avoid blocking indefinitely, we put the processing in a future.
> (assoc this :worker (future
>  (with-open [rdr (java.io/reader (:stream source)]
>(doseq [entity (line-seq rdr)]
>  (write sink entity)
>   (stop [this]
> (future-cancel worker)
> (assoc this :worker nil)))
>
> (defn -main []
>   (-> (component/system-map :config (read-config)
> :events (map->EventStream {:endpoint endpoint
> })
> :mq-client (map->MessageQueue {})
> :shoveler (map->Shoveler {}))
>   (component/using {:events {:http-config :config}
> :mq-client {:config :config}
> :shoveler {:source :events
>:sink :mq-client}})
>   component/start))
>
> 3. Rough sketch of 

Re: Stuart Sierra's Component: retries & restarts in production

[James Reeves]

On 3 September 2015 at 00:03,  wrote:
>
> The HTTP connection may be closed at any time by the server; if that
> happens, the app should persistently attempt to reconnect using an
> exponential back-off pattern. In addition, if the app goes thirty seconds
> without receiving any data, it should close the connection and try to
> reconnect. It's not clear to me how to best express these "retry"
> requirements in the component lifecycle.
>

It seems to me that retrying connections is orthogonal to the component
lifecycle. Don't fall into the trap of thinking that start and stop are
your only tools. They only determine what should happen when your system
begins, and what happens when it ends.

So what *does* happen when your system starts? Well, from your description:

I'm writing an app that consumes events from a streaming HTTP connection
> and writes those events to a message queue


It seems to me that a naïve implementation of this would be:

(loop []
  (when-let [event (read-event! stream)]
(deliver! queue event)
(recur)

So we block until we can read an event, and once we have the event we write
it to the message queue.

>From your description, it seems as if the event stream needs to maintain an
open HTTP connection, but we expect to need to reconnect for various
reasons. The connection will therefore change over the system's runtime, so
we need a mutable reference:

(defrecord HttpEventStream [url]
  component/Lifecycle
  (start [component]
(if (:conn component)
  component
  (assoc component :conn (volatile! (open-connection url
  (stop [component]
(if-let [conn (:conn component)]
  (do (locking conn
(close-connection @conn)
(vreset! conn nil))
  (dissoc component :conn))
  component)))

(defn read-event! [{:keys [conn url]}]
  (when conn
(locking conn
  (when @conn
(loop []
  (if (closed? @conn)
(do (vswap! conn (open-connection url)) (recur))
(read-line-from-body! @conn)

Because we're dealing with I/O, instead of using an atom I'm using a
volatile and locks, as we explicitly don't want two threads accessing the
same connection at once.

Note that I'm also making sure that read-event! can handle being given a
component that's been stopped.

If you want the connection to reconnect if there has been too much
inactivity, then you'll need to maintain another reference that holds a
timestamp of when an event was last read.

- James

-- 
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: numbers, why?

[Mikera]

You can use *unchecked-math* if you want unchecked arithmetic behaviour:

=> (set! *unchecked-math* true)
true
=> (+ Long/MAX_VALUE Long/MAX_VALUE)
-2

On Friday, 4 September 2015 23:04:27 UTC+8, Ali M wrote:
>
> Ok, so to give myself a safe and consistent way to reason about this
> the addition operator, and probably other arithmetic operator 
> dont promote ouput 
>
> so long+ long = long or exception 
> long + bigint = bigint
>
> if i need outpout promition i can use +'
>
> hmmm, a bit tricky
>
> On Friday, September 4, 2015 at 10:51:15 AM UTC-4, dennis wrote:
>>
>> Because the literal is readed as BigInt:
>>
>> user=> (class 6546546546546546546850348954895480584039545804 )
>> clojure.lang.BigInt
>>
>> 2015-09-04 22:48 GMT+08:00 Ali M :
>>
>>> why?
>>>
>>> 
>>> user=> (+ 6546546546546546546850348954895480584039545804 
>>> 7548979534287548957345843954749357348757897)
>>> 6554095526080834095807694798850229941388303701N
>>>
>>> user=> (+ Long/MAX_VALUE Long/MAX_VALUE)
>>>
>>> ArithmeticException integer overflow  
>>> clojure.lang.Numbers.throwIntOverflow (Numbers.java:1501)
>>>
>>> user=> Long/MAX_VALUE
>>> 9223372036854775807
>>> 
>>>
>>> Why the much bigger numbers get promoted, and a smaller number overflows?
>>>
>>> Thank you
>>> Ali
>>>
>>> -- 
>>> 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.
>>>
>>
>>
>>
>> -- 
>> 庄晓丹 
>> Email:killm...@gmail.com xzh...@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.

Re: some guidance sought

[William la Forge]

Here's the link to the test 
file: https://github.com/laforge49/aatree/blob/master/test/aatree/core_test.clj

On Friday, September 4, 2015 at 2:26:52 PM UTC-4, William la Forge wrote:
>
> I've now finished an initial draft of AA Tree Map and it passes 
> collection-check:
>
>
> (deftest tests
>   (assert-map-like (create-aamap)
>gen-element gen-element
>;   {:base (sorted-map) :ordered? true}
>))
>
>
> Unfortunately I had to comment out the test against sorted-map. I was 
> getting this error:
>
> ERROR in (tests) (generators.clj:366)
> Uncaught exception, not in assertion.
> expected: nil
>   actual: java.lang.AssertionError: Assert failed: Args to tuple must be 
> generators
> (every? generator? generators)
>  at clojure.test.check.generators$tuple.doInvoke (generators.clj:366)
> clojure.lang.RestFn.invoke (RestFn.java:421)
> collection_check$gen_meta.invoke (collection_check.clj:30)
> collection_check$gen_map_actions.invoke (collection_check.clj:91)
> collection_check$assert_map_like.invoke (collection_check.clj:306)
> collection_check$assert_map_like.invoke (collection_check.clj:299)
> aatree.core_test/fn (core_test.clj:36)
> clojure.test$test_var$fn__7670.invoke (test.clj:704)
> clojure.test$test_var.invoke (test.clj:704)
> clojure.test$test_vars$fn__7692$fn__7697.invoke (test.clj:722)
> clojure.test$default_fixture.invoke (test.clj:674)
> clojure.test$test_vars$fn__7692.invoke (test.clj:722)
> clojure.test$default_fixture.invoke (test.clj:674)
> clojure.test$test_vars.invoke (test.clj:718)
> clojure.test$test_all_vars.invoke (test.clj:728)
> clojure.test$test_ns.invoke (test.clj:747)
> clojure.core$map$fn__4553.invoke (core.clj:2624)
> clojure.lang.LazySeq.sval (LazySeq.java:40)
> clojure.lang.LazySeq.seq (LazySeq.java:49)
> clojure.lang.Cons.next (Cons.java:39)
> clojure.lang.RT.boundedLength (RT.java:1735)
> clojure.lang.RestFn.applyTo (RestFn.java:130)
> clojure.core$apply.invoke (core.clj:632)
> clojure.test$run_tests.doInvoke (test.clj:762)
> clojure.lang.RestFn.applyTo (RestFn.java:137)
> clojure.core$apply.invoke (core.clj:630)
> user$eval85$fn__140$fn__171.invoke (form-init7529748499207850099.clj:1)
> user$eval85$fn__140$fn__141.invoke (form-init7529748499207850099.clj:1)
> user$eval85$fn__140.invoke (form-init7529748499207850099.clj:1)
> user$eval85.invoke (form-init7529748499207850099.clj:1)
> clojure.lang.Compiler.eval (Compiler.java:6782)
> clojure.lang.Compiler.eval (Compiler.java:6772)
> clojure.lang.Compiler.load (Compiler.java:7227)
> clojure.lang.Compiler.loadFile (Compiler.java:7165)
> clojure.main$load_script.invoke (main.clj:275)
> clojure.main$init_opt.invoke (main.clj:280)
> clojure.main$initialize.invoke (main.clj:308)
> clojure.main$null_opt.invoke (main.clj:343)
> clojure.main$main.doInvoke (main.clj:421)
> clojure.lang.RestFn.invoke (RestFn.java:421)
> clojure.lang.Var.invoke (Var.java:383)
> clojure.lang.AFn.applyToHelper (AFn.java:156)
> clojure.lang.Var.applyTo (Var.java:700)
> clojure.main.main (main.java:37)
>
> Any suggestions?
>
> On Monday, August 24, 2015 at 8:46:12 AM UTC-4, icamts wrote:
>>
>> Not a pointer but this may help in testing your implementation: 
>> https://github.com/ztellman/collection-check
>>
>> Il giorno lunedì 10 agosto 2015 00:31:25 UTC+2, William la Forge ha 
>> scritto:
>>>
>>> I've done a lot with AA trees in the past, creating variations that are 
>>> immutable, durable (replacing b-trees) and versioned of vectors, maps and 
>>> sets.
>>>
>>> I would like to migrate these ideas from Java to Clojure, while 
>>> implementing the interfaces appropriate for Clojure.
>>>
>>> Still being very much a newbie, I'd appreciate some pointers, relevant 
>>> docs and/or examples.
>>>
>>> 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.

Re: supporting metadata caret reader syntax with deftype

[Gregg Reynolds]

On Fri, Sep 4, 2015 at 7:51 PM, Mike Rodriguez  wrote:

> This has came up numerous times in other posts here. I can't hunt them
> down currently but the quoted symbol issue you showed is just a
> misunderstanding of how the reader macro for metadata works.
>
> Try (meta '^{:foo :bar} a)
>

Ewww!  It works, but it's kinda sorta hideous, or at least non-obvious.

I guess somebody smarter than me could figure that out, but the official
documentation really should make this clear, no?  I'm thinking the The
Reader  page and the Metadata
 page.  But I don't see where the source for
that is kept, it doesn't seem to be in the Clojure source tree.  Any idea
how to submit a doc fix?

Thanks,

Gregg

-- 
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: supporting metadata caret reader syntax with deftype

[Mike Rodriguez]

This has came up numerous times in other posts here. I can't hunt them down 
currently but the quoted symbol issue you showed is just a misunderstanding of 
how the reader macro for metadata works. 

Try (meta '^{:foo :bar} a)

When you put the reader macro in front of the quote it is applied to the quote 
form itself - as a data structure list - and then the metadata is not 
propagated to the return of the eval of the quote so it seems "lost". 

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