Ensure more concurrency

['bertschi' via Clojure]

For a lecture I have implemented the write-skew example from Mark 
Volkmann's article:

(defn write-skew []
  (let [cats (ref 1)
dogs (ref 1)

john (future
   (dosync
 (when (< (+ @cats @dogs) 3)
   (alter cats inc
mary (future
   (dosync
 (when (< (+ @cats @dogs) 3)
   (alter dogs inc]
(do @john @mary)
(dosync
 (> (+ @cats @dogs) 3

(defn write-skew-demo []
  (let [count-write-skews (atom 0)]
(doseq [_ (range 25)]
  (when (write-skew)
(swap! count-write-skews inc)))
@count-write-skews))

(write-skew-demo)

When I try to fix this program using ensure, i.e. using (ensure dogs) in 
john and (ensure cats) in mary, I find that it sometimes runs very slow.

>From the docs it says "Allows for more concurrency than (ref-set ref 
@ref)". I would read that as "runs at least as fast as (ref-set ref @ref)", 
but using (ref-set dogs @dogs) instead of (ensure dogs) and the same with 
cats, does not exhibit these occasional runtime spikes.

Am I misunderstanding something or is it a bug in ensure?


Nils

-- 
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: 1.9.0-alpha14 doesn't allow Java classes as return type in gen-class :method clause?

[Mars0i]

On Monday, March 6, 2017 at 1:16:38 AM UTC-6, Mars0i wrote:
>
>
> On Sunday, March 5, 2017 at 6:51:57 PM UTC-6, Alex Miller wrote:
>>
>> I would really appreciate seeing the ns declaration that caused the 
>> original error. I have not been able to exactly reproduce what you are 
>> describing. If you can't share it publicly, you can send it to me at 
>> alex@cognitect.com.
>>
>> Thanks,
>> Alex
>>
>
> Thanks--sure, I am willing to make public the ... bad things I am doing in 
> my code.  I have to explain that the ns declaration is very large; it's 
> generated by a macro that creates a lot of code.  I wrote it to ease 
> interop with a useful but not entirely Clojure-friendly Java library I'm 
> using.  This required violating some standard, useful coding guidelines.
>
> This file 
> 
>  
> contains pretty-printed output from macroexpand-1 (made with Clojure 
> 1.8.0--the offending macro call is in an aot-compiled file, so it would 
> have been harder to start the repl with 1.9.0).  There are actually two ns 
> declarations (a trick to avoid some cyclic references).  The code that 
> caused the errors begins at line 66 in the second ns.
>
> The macro call in my source is here 
> on
>  
> line 29, and the macro definition is at the bottom of this file 
> .
>   
> Both of those links are to the code just before the commit in which I added 
> apostrophes to the instances of java.lang.Object (at line 210 of the macro 
> definition file).  This got rid of the errors, and the application seems to 
> run correctly.
>
> (If you look at the current version of the code, you'll see that I 
> recently changed the project name from free-agent to pasta; 'lein uberjar' 
> didn't like the hyphen.)
>
> If you need me to make a minimal example, I can probably do that.
>

I meant to mention, in case it turns out to be relevant, that the other odd 
thing about this code is that the second ns declaration generated by the 
macro is a second instance of the ns declaration at the top of the source 
file.  i.e. at the top of SimConfig.clj there's a hardcoded ns declaration 
(ns free-agent.SimConfig ...), and then the macro inserts a different ns 
declaration (ns free-agent.config-data), followed a few lines later by a 
different instance of (ns free-agent.SimConfig ...).  It's in the latter 
that the :gen-class clause which causes the error occurs.  The reason for 
the (ns X), (ns Y), (ns X) strategy is to avoid the potential cyclic 
dependency problem (forced on me by the MASON library I'm using).

-- 
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: 1.9.0-alpha14 doesn't allow Java classes as return type in gen-class :method clause?

[Alex Miller]

Ok, this looks like it's related to the macro gen, so I don't see any issue 
to fix in the spec - valid inputs at the point are either strings or 
symbols - I think through eval you were ending up with a class instance.

On Monday, March 6, 2017 at 1:16:38 AM UTC-6, Mars0i wrote:
>
>
>
> On Sunday, March 5, 2017 at 6:51:57 PM UTC-6, Alex Miller wrote:
>>
>> I would really appreciate seeing the ns declaration that caused the 
>> original error. I have not been able to exactly reproduce what you are 
>> describing. If you can't share it publicly, you can send it to me at 
>> alex@cognitect.com.
>>
>> Thanks,
>> Alex
>>
>
> Thanks--sure, I am willing to make public the ... bad things I am doing in 
> my code.  I have to explain that the ns declaration is very large; it's 
> generated by a macro that creates a lot of code.  I wrote it to ease 
> interop with a useful but not entirely Clojure-friendly Java library I'm 
> using.  This required violating some standard, useful coding guidelines.
>
> This file 
> 
>  
> contains pretty-printed output from macroexpand-1 (made with Clojure 
> 1.8.0--the offending macro call is in an aot-compiled file, so it would 
> have been harder to start the repl with 1.9.0).  There are actually two ns 
> declarations (a trick to avoid some cyclic references).  The code that 
> caused the errors begins at line 66 in the second ns.
>
> The macro call in my source is here 
> on
>  
> line 29, and the macro definition is at the bottom of this file 
> .
>   
> Both of those links are to the code just before the commit in which I added 
> apostrophes to the instances of java.lang.Object (at line 210 of the macro 
> definition file).  This got rid of the errors, and the application seems to 
> run correctly.
>
> (If you look at the current version of the code, you'll see that I 
> recently changed the project name from free-agent to pasta; 'lein uberjar' 
> didn't like the hyphen.)
>
> If you need me to make a minimal example, I can probably do that.
>

-- 
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: 1.9.0-alpha14 doesn't allow Java classes as return type in gen-class :method clause?

[Mars0i]

On Monday, March 6, 2017 at 9:32:37 AM UTC-6, Alex Miller wrote:
>
> Ok, this looks like it's related to the macro gen, so I don't see any 
> issue to fix in the spec - valid inputs at the point are either strings or 
> symbols - I think through eval you were ending up with a class instance.
>

OK, that makes sense.  The new version with the added quote works with 
1.8.0 as well as 1.9.0--no doubt that's what you'd expect.  I wouldn't have 
to known for sure until I tried it.  Use of gen-class can seem like a black 
art sometimes :-) but I'm glad it's available.

-- 
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: 1.9.0-alpha14 doesn't allow Java classes as return type in gen-class :method clause?

[Mars0i]

On Monday, March 6, 2017 at 10:33:43 AM UTC-6, Mars0i wrote:
>
> On Monday, March 6, 2017 at 9:32:37 AM UTC-6, Alex Miller wrote:
>>
>> Ok, this looks like it's related to the macro gen, so I don't see any 
>> issue to fix in the spec - valid inputs at the point are either strings or 
>> symbols - I think through eval you were ending up with a class instance.
>>
>
> OK, that makes sense.  The new version with the added quote works with 
> 1.8.0 as well as 1.9.0--no doubt that's what you'd expect.  I wouldn't have 
> to known for sure until I tried it.  Use of gen-class can seem like a black 
> art sometimes :-) but I'm glad it's available.
>

Of course the problem arose due to my decision to dabble, imperfectly, in 
the black art of macro-writing (which I usually can avoid).

btw when I first saw the 1.9.0 error dump I thought it was horrible--worse 
than a simple Java stacktrace.  It was pretty ugly because my macro had 
generated a very large expression.  Once I figured out what the spec output 
was saying, though, I realized how incredibly helpful it was.  Very nice.  
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: Contribute Specter to Clojure core?

[Asim Jalis]

Moe: Good point. The specific use case I had was that I wanted to be able
to extract all the values that were on a path—in other words the ability to
use a wildcard in get-in. For example, this returns "X1". I would like to
use get-in to return ["X1" "X2"]. In other words use a wildcard for :b1.

(get-in {:a [{:b1 "X1"} {:b2 "X2"}]} [:a 0 :b1])

On Sat, Mar 4, 2017 at 1:14 PM, Moe Aboulkheir  wrote:

>
>
> On Sat, Mar 4, 2017 at 6:35 AM, Asim Jalis  wrote:
>
>> What might be a Clojurey syntax for doing path navigation? In other words
>> how could get-in be extended so that it could parse nested vectors like it
>> parses nested maps? Thinking out aloud, an integer in the path when the
>> data structure at that level is a vector should treat the integer as an
>> index.
>>
>
> If I'm reading you correctly, that is Clojure's current behaviour -
> (get-in {:a [{:b "X"}]}  [:a 0 :b]) => "X"
>
> Take care,
> Moe
>
> --
> 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.

loop macro generates a wrapping let

[juan.facorro]

While I was debugging some code I found something related to the *loop *macro 
that I found curious. I'm probably missing something but here it goes.

The expression generated by the *loop* macro includes a wrapping *let *when 
there is any de-structuring in the bindings.

(require '[clojure.walk :as walk])
(walk/macroexpand-all '(loop [[x & xs] xs a 3]))


Which returns:


(let* [G__1249 xs
   vec__1250 G__1249
   x (clojure.core/nth vec__1250 0 nil)
   xs (clojure.core/nthnext vec__1250 1)
   a 3]
  (loop* [G__1249 G__1249 a a]
(let* [vec__1251 G__1249
   x (clojure.core/nth vec__1251 0 nil)
   xs (clojure.core/nthnext vec__1251 1)
   a a])))


Since all bindings get re-defined in the inner *let*, why is the outer *let* 
even generated? Is there a reason for not having the following generated 
instead? 


(loop* [G__1249 xs a a]
  (let* [vec__1251 G__1249
 x (clojure.core/nth vec__1251 0 nil)
 xs (clojure.core/nthnext vec__1251 1)
 a a]))


The change in the loop macro is pretty simple and it seems to work (at least 
with the tests available in GitHub's clojure/clojure).


(defmacro loop
  "Evaluates the exprs in a lexical context in which the symbols in  the 
binding-forms are bound to their respective init-exprs or parts  therein. Acts 
as a recur target."
  {:added "1.0", :special-form true, :forms '[(loop [bindings*] exprs*)]}
  [bindings & body]
(assert-args
  (vector? bindings) "a vector for its binding"
  (even? (count bindings)) "an even number of forms in binding vector")
(let [db (destructure bindings)]
  (if (= db bindings)
`(loop* ~bindings ~@body)
(let [vs (take-nth 2 (drop 1 bindings))
  bs (take-nth 2 bindings)
  gs (map (fn [b] (if (symbol? b) b (gensym))) bs)]
  `(loop* ~(vec (interleave gs vs))
  (let ~(vec (interleave bs gs))
~@body))


But maybe this hasn't been changed because of the importance of the *loop* 
macro, or maybe the impact in compile- and run-time is insignificant to justify 
the change. 

Anyways... I thought I'd put the question out there.


Cheers!

Juan


-- 
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: loop macro generates a wrapping let

[Kevin Downey]

On 03/06/2017 03:28 PM, juan.facorro wrote:
> While I was debugging some code I found something related to the *loop
> *macro that I found curious. I'm probably missing something but here it
> goes.
> 
> The expression generated by the *loop* macro includes a wrapping *let
> *when there is any de-structuring in the bindings.
> 
> (require '[clojure.walk :as walk])
> (walk/macroexpand-all '(loop [[x & xs] xs a 3]))

The init value of `a` could rely on `x` or `xs`, so those bindings need
to be established before the loop, which is what the outer loop does.
For example checkout `(walk/macroexpand-all '(loop [[x & xs] xs a x]))`.

> 
> Which returns:
> 
> 
> (let*[G__1249xsvec__1250G__1249x(clojure.core/nthvec__12500nil)
> xs(clojure.core/nthnextvec__12501) a3] (loop*[G__1249G__1249a a]
> (let*[vec__1251G__1249x(clojure.core/nthvec__12510nil)
> xs(clojure.core/nthnextvec__12511) aa])))
> 
> 
> Since all bindings get re-defined in the inner *let*, why is the outer
> *let* even generated? Is there a reason for not having the following
> generated instead? 
> 
> 
> (loop* [G__1249 xs a a]
>   (let* [vec__1251 G__1249
>  x (clojure.core/nth vec__1251 0 nil)
>  xs (clojure.core/nthnext vec__1251 1)
>  a a]))
> 
> 
> The change in the loop macro is pretty simple and it seems to work (at
> least with the tests available in GitHub's clojure/clojure).
> 
> 
> (defmacro loop
>   "Evaluates the exprs in a lexical context in which the symbols in
> the binding-forms are bound to their respective init-exprs or parts
> therein. Acts as a recur target."
>   {:added "1.0", :special-form true, :forms '[(loop [bindings*] exprs*)]}
>   [bindings & body]
> (assert-args
>   (vector? bindings) "a vector for its binding"
>   (even? (count bindings)) "an even number of forms in binding vector")
> (let [db (destructure bindings)]
>   (if (= db bindings)
> `(loop* ~bindings ~@body)
> (let [vs (take-nth 2 (drop 1 bindings))
>   bs (take-nth 2 bindings)
>   gs (map (fn [b] (if (symbol? b) b (gensym))) bs)]
>   `(loop* ~(vec (interleave gs vs))
>   (let ~(vec (interleave bs gs))
> ~@body))
> 
> 
> But maybe this hasn't been changed because of the importance of the
> *loop* macro, or maybe the impact in compile- and run-time is
> insignificant to justify the change.
> 
> Anyways... I thought I'd put the question out there.
> 
> 
> Cheers!
> 
> Juan
> 
> 
> -- 
> 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.


-- 
And what is good, Phaedrus,
And what is not good—
Need we ask anyone to tell us these things?

-- 
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: loop macro generates a wrapping let

[juan.facorro]

Right, of course! It seems almost obvious now :P

Thanks Kevin

On Tuesday, March 7, 2017 at 12:42:08 AM UTC+1, red...@gmail.com wrote:
>
> On 03/06/2017 03:28 PM, juan.facorro wrote: 
> > While I was debugging some code I found something related to the *loop 
> > *macro that I found curious. I'm probably missing something but here it 
> > goes. 
> > 
> > The expression generated by the *loop* macro includes a wrapping *let 
> > *when there is any de-structuring in the bindings. 
> > 
> > (require '[clojure.walk :as walk]) 
> > (walk/macroexpand-all '(loop [[x & xs] xs a 3])) 
>
> The init value of `a` could rely on `x` or `xs`, so those bindings need 
> to be established before the loop, which is what the outer loop does. 
> For example checkout `(walk/macroexpand-all '(loop [[x & xs] xs a x]))`. 
>
> > 
> > Which returns: 
> > 
> > 
> > (let*[G__1249xsvec__1250G__1249x(clojure.core/nthvec__12500nil) 
> > xs(clojure.core/nthnextvec__12501) a3] (loop*[G__1249G__1249a a] 
> > (let*[vec__1251G__1249x(clojure.core/nthvec__12510nil) 
> > xs(clojure.core/nthnextvec__12511) aa]))) 
> > 
> > 
> > Since all bindings get re-defined in the inner *let*, why is the outer 
> > *let* even generated? Is there a reason for not having the following 
> > generated instead? 
> > 
> > 
> > (loop* [G__1249 xs a a] 
> >   (let* [vec__1251 G__1249 
> >  x (clojure.core/nth vec__1251 0 nil) 
> >  xs (clojure.core/nthnext vec__1251 1) 
> >  a a])) 
> > 
> > 
> > The change in the loop macro is pretty simple and it seems to work (at 
> > least with the tests available in GitHub's clojure/clojure). 
> > 
> > 
> > (defmacro loop 
> >   "Evaluates the exprs in a lexical context in which the symbols in 
> > the binding-forms are bound to their respective init-exprs or parts 
> > therein. Acts as a recur target." 
> >   {:added "1.0", :special-form true, :forms '[(loop [bindings*] 
> exprs*)]} 
> >   [bindings & body] 
> > (assert-args 
> >   (vector? bindings) "a vector for its binding" 
> >   (even? (count bindings)) "an even number of forms in binding 
> vector") 
> > (let [db (destructure bindings)] 
> >   (if (= db bindings) 
> > `(loop* ~bindings ~@body) 
> > (let [vs (take-nth 2 (drop 1 bindings)) 
> >   bs (take-nth 2 bindings) 
> >   gs (map (fn [b] (if (symbol? b) b (gensym))) bs)] 
> >   `(loop* ~(vec (interleave gs vs)) 
> >   (let ~(vec (interleave bs gs)) 
> > ~@body)) 
> > 
> > 
> > But maybe this hasn't been changed because of the importance of the 
> > *loop* macro, or maybe the impact in compile- and run-time is 
> > insignificant to justify the change. 
> > 
> > Anyways... I thought I'd put the question out there. 
> > 
> > 
> > Cheers! 
> > 
> > Juan 
> > 
> > 
> > -- 
> > 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. 
>
>
> -- 
> And what is good, Phaedrus, 
> And what is not good— 
> Need we ask anyone to tell us these things? 
>

-- 
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: Application silently shuts down by itself after running for some hours

[JokkeB]

After adding this, I still can't see an exception before the app dies.

maanantai 6. maaliskuuta 2017 12.04.16 UTC+2 JokkeB kirjoitti:
>
> Thanks for the reply.
>
> I haven't tried catching any or all errors. Is it a false assumption that 
> an error should be logged if it comes from the main thread? Can an 
> exception in another thread kill the app? Anyways, I now added this piece 
> of code in main, like instructed in 
> https://stuartsierra.com/2015/05/27/clojure-uncaught-exceptions and let's 
> see what happens. Is this what you meant?
>
>   (Thread/setDefaultUncaughtExceptionHandler
>(reify Thread$UncaughtExceptionHandler
>  (uncaughtException [_ thread ex]
>(log/error ex "Uncaught exception on" (.getName thread)
>
>
>
> lauantai 4. maaliskuuta 2017 13.02.53 UTC+2 Scott Bauer kirjoitti:
>>
>> Out of curiosity, have you tried catching any and all errors as opposed 
>> to expecting to see an error message logged upon the system dying?
>>
>> While searching for possible causes, I did come across this similar post 
>>  
>> from a few years ago... not sure if it will help, but it may.
>>
>>
>> On Friday, March 3, 2017 at 10:57:20 AM UTC-5, JokkeB wrote:
>>>
>>> I have an application which I run with "lein run". The main looks 
>>> something like this
>>>
>>> (defn -main []
>>>  (log/info "start")
>>>  (log/info "channel returned" (async/>> 9121) (websocket-server 9122
>>>  (log/info "quit"))
>>>
>>> start-server returns a channel created with async/reduce which shouldn't 
>>> ever produce a value. I see the "start" logged, the application runs for a 
>>> day or two (not sure if the time is always the same) and then it closes 
>>> without any errors or without logging "channel returned" or "quit". 
>>>
>>> If there is an error in my code and the program quits I should see the 
>>> "quit" message. If there is a memory leak or something I would assume I'd 
>>> get an error message. Has anyone experienced anything similar?
>>>
>>> Could the reason be running it with lein (I haven't tried a jar)? If so, 
>>> why?
>>>
>>>

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

Clojure has been selected to participate in GSoC 2017!

[Daniel Solano Gómez]

We are pleased to announce that Google has selected Clojure as a mentoring 
organisation for this year’s summer of code! This means that Google will 
sponsor students from around the world to work on projects that are part of 
the Clojure ecosystem. Now that we know that Clojure will be participating, 
what happens next?

Getting involved

The student application period will be open from the 20th of March through 
the 3rd of April. In the meantime, there are a number of ways to get 
involved:

*Mentors*

If you maintain an open source Clojure(Script) project and would like to 
grow it, you should consider becoming a mentor. You can find out more about 
what being a mentor is about out on the mentors page 
.

*Students*

While it is still to early to formally apply as GSoC student, this is a 
great time to start thinking about project ideas and reach out to potential 
mentors. Check out the students page  
for more information on how to apply successfully.

*Everyone else*

Even if you can’t participate as student or don’t want to be a mentor, you 
can still help by letting people know about GSoC at your local Clojure 
meetup, university, or other local group.

Thanks

We would also like to extend a big thank you to all of the people who 
contributed to our project ideas . 
 Without their help, it is likely our application would not have been a 
success.

-- 
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: Release date for 1.9

[Alexander Kiel]

We also run Clojure 1.9-alpha with great success in production. Being alpha 
doesn't mean that it's buggy. It just means that the new stuff can still 
change.

Am Dienstag, 28. Februar 2017 21:10:59 UTC+1 schrieb Dan Burton:
>
> Obligatory: "our team uses clojure-future-spec with clojure-1.8" -- no 
> problems so far.
>
> -- Dan Burton
>
> On Tue, Feb 28, 2017 at 11:59 AM, Sean Corfield  > wrote:
>
>> On 2/28/17, 10:26 AM, "Erik Assum" > on behalf of er...@assum.net > wrote:
>> > And, yes, I'm aware of the fact that the 1.9-alphas are very stable wrt 
>> putting it in production.
>>
>> Obligatory: “we’ve been running the 1.9 Alphas in production for months 
>> so that we can leverage clojure.spec” – no problems so far.
>>
>> Sean Corfield -- (904) 302-SEAN -- (970) FOR-SEAN
>> World Singles -- http://worldsingles.com/
>>
>>
>>
>>
>>
>> --
>> 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: Release date for 1.9

[Mark Engelberg]

However, it does mean that libraries depending on 1.9 may be waiting to
release so as not to support a Clojure version that can make breaking
changes to the new features at any time.

On Mon, Mar 6, 2017 at 12:41 AM, Alexander Kiel 
wrote:

> We also run Clojure 1.9-alpha with great success in production. Being
> alpha doesn't mean that it's buggy. It just means that the new stuff can
> still change.
>
> Am Dienstag, 28. Februar 2017 21:10:59 UTC+1 schrieb Dan Burton:
>>
>> Obligatory: "our team uses clojure-future-spec with clojure-1.8" -- no
>> problems so far.
>>
>> -- Dan Burton
>>
>> On Tue, Feb 28, 2017 at 11:59 AM, Sean Corfield 
>> wrote:
>>
>>> On 2/28/17, 10:26 AM, "Erik Assum" >> of er...@assum.net> wrote:
>>> > And, yes, I'm aware of the fact that the 1.9-alphas are very stable
>>> wrt putting it in production.
>>>
>>> Obligatory: “we’ve been running the 1.9 Alphas in production for months
>>> so that we can leverage clojure.spec” – no problems so far.
>>>
>>> Sean Corfield -- (904) 302-SEAN -- (970) FOR-SEAN
>>> World Singles -- http://worldsingles.com/
>>>
>>>
>>>
>>>
>>>
>>> --
>>> 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.
>

-- 
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: GSoC 2017 - KLIPSE

[Daniel Solano Gómez]

On Friday, March 3, 2017 at 7:36:27 AM UTC-6, Maitreya Verma wrote:
>
> Hello, 
> I am Maitreya Verma, second year undergrad student. 
> I am very enthusiastic to work on the idea of adding cool features to 
> KLIPSE for GSoC. There are many other ideas which I think can be 
> implemented on this plugin. Can anybody guide me on how can I work on this 
> plugin. I am quite profeicient in Javascript and am trying to learn more 
> about clojure nowadays.  
>

Hello,

Thanks for expressing interest in being a student for GSoC!  The good news 
is that the developer of KLIPSE is interested in being a mentor this year 
and posted an idea on our project ideas page 
.  Your best bet is to get in touch 
with him.

Sincerely,

Daniel

-- 
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: Application silently shuts down by itself after running for some hours

[JokkeB]

Thanks for the reply.

I haven't tried catching any or all errors. Is it a false assumption that 
an error should be logged if it comes from the main thread? Can an 
exception in another thread kill the app? Anyways, I now added this piece 
of code in main, like instructed 
in https://stuartsierra.com/2015/05/27/clojure-uncaught-exceptions and 
let's see what happens. Is this what you meant?

  (Thread/setDefaultUncaughtExceptionHandler
   (reify Thread$UncaughtExceptionHandler
 (uncaughtException [_ thread ex]
   (log/error ex "Uncaught exception on" (.getName thread)



lauantai 4. maaliskuuta 2017 13.02.53 UTC+2 Scott Bauer kirjoitti:
>
> Out of curiosity, have you tried catching any and all errors as opposed to 
> expecting to see an error message logged upon the system dying?
>
> While searching for possible causes, I did come across this similar post 
>  
> from a few years ago... not sure if it will help, but it may.
>
>
> On Friday, March 3, 2017 at 10:57:20 AM UTC-5, JokkeB wrote:
>>
>> I have an application which I run with "lein run". The main looks 
>> something like this
>>
>> (defn -main []
>>  (log/info "start")
>>  (log/info "channel returned" (async/> 9121) (websocket-server 9122
>>  (log/info "quit"))
>>
>> start-server returns a channel created with async/reduce which shouldn't 
>> ever produce a value. I see the "start" logged, the application runs for a 
>> day or two (not sure if the time is always the same) and then it closes 
>> without any errors or without logging "channel returned" or "quit". 
>>
>> If there is an error in my code and the program quits I should see the 
>> "quit" message. If there is a memory leak or something I would assume I'd 
>> get an error message. Has anyone experienced anything similar?
>>
>> Could the reason be running it with lein (I haven't tried a jar)? If so, 
>> why?
>>
>>

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