Re: Use latest stable

[James Elliott]

I was going to recommend the same thing! I used to use lein ancient all the 
time, but now love how VersionEye keeps track of all my open source 
projects for me so I don’t have to do that. That became even more important 
as the projects started spinning off other projects. :)

On Friday, July 15, 2016 at 9:25:30 AM UTC-5, Matthew Boston wrote:
>
> On the topic of keeping dependencies up-to-date, I use 
> https://www.versioneye.com. I sign in with GitHub and it watches all the 
> projects that I choose for out-of-date deps. It sends me a weekly/daily 
> email so I'm rarely behind every new release.
>
> Cheers.
>
> On Thursday, July 14, 2016 at 11:58:41 AM UTC-6, Alan Thompson wrote:
>>
>> If you haven't seen it yet, lein-ancient (
>> https://github.com/xsc/lein-ancient) provides an easy way of checking 
>> your project for out of date dependencies.  For example:
>>
>> > lein ancient
>> [criterium "0.4.4"] is available but we use "0.4.3"
>> [tupelo "0.9.0"] is available but we use "0.1.60"
>> [com.rpl/specter "0.11.2"] is available but we use "0.9.1"
>>
>>
>> I tend to run it every couple of months, or whenever I remember.  Then it 
>> is easy to update project.clj
>>
>> Alan
>>
>>
>> On Thu, Jul 14, 2016 at 3:52 AM, Cecil Westerhof  
>> wrote:
>>
>>> Is there a way to signify latest stable version? Because when you use:
>>>   :dependencies [[org.clojure/clojure"LATEST"]
>>> it wants to work with:
>>> clojure-1.9.0-alpha10
>>>
>>> I prefer to use clojure-1.8.0. There is a reason it is called alpha. But 
>>> when there is a stable 1.9.0 I want to use that one.
>>>
>>> -- 
>>> Cecil Westerhof
>>>
>>> -- 
>>> 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.

Sneaky ways to get people to learn Clojure

[James Elliott]

As a spinoff from Afterglow 
, my Clojure-based 
live-coding environment for light shows, I’ve created a library 
 that facilitates 
synchronizing things with Pioneer’s professional DJ equipment. And then I 
was talked into creating an example application 
 showing 
how to use it. With the help of seesaw and inspector-jay, among other great 
Clojure and Java libraries, I was able to quickly create something far more 
useful than I expected, and people are starting to find it.

Of course, I provide an embedded editor for you to use Clojure expressions 
to customize and extend it, so I have DJs and show producers around the 
world learning a little Clojure as an unexpected outcome. Thankfully our 
community has great learning resources I can point them towards as well! 
Thus it is being used successfully at events like this one 

:




If anyone is curious to see how Afterglow itself has come along since I 
first announced it here last year, the recording of the presentation I gave 
to the Madison Clojure Meetup, Afterglow: Live Coding for Light Shows 
, turned out halfway decent, especially once 
I added captions.


Thanks again to everyone who helped me in my own learning and coding 
journey in this wonderful environment!

-- 
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: Unum in Clojure/ClojureScript?

[James Elliott]

It is actually a correct claim, if you read the article I mentioned. It 
does not attempt to represent impossible things: When exact representation 
is impossible it represents a range that includes the correct value. The 
size of the range (and thus the loss of precision) is tracked, and grows 
far more slowly with repeated calculations than floating point numbers do. 
It really is a brilliant idea.

-James

On Tuesday, May 3, 2016 at 8:03:01 PM UTC-5, Jason Felice wrote:
>
> Just to point out, the OP claimed the number format has no rounding or 
> precision problems, which is not possible.  Think about ways to represent 
> pi for a bit!
>
> -Jason
>
>
> On Tue, May 3, 2016 at 5:51 PM, James Elliott <brun...@gmail.com 
> > wrote:
>
>> Heh! I just read about these in an email from ACM, and found your post by 
>> searching this Group for UNUM. It looks like not yet, but perhaps we should 
>> do something about that?
>>
>> The article which excited me:
>> http://ubiquity.acm.org/article.cfm?id=2913029
>>
>>
>> On Friday, November 6, 2015 at 8:23:35 AM UTC-6, Richard Davies wrote:
>>>
>>> Unum is a number representation system that is a superset of IEEE 
>>> integers and IEEE floats which avoids many problems (especially in floating 
>>> point arithmetic) as it has no rounding, no overflow to infinity, no 
>>> underflow to zero, and is safe to parallelize.
>>>
>>> I was wondering if anyone has implemented or is interested in 
>>> implementing this in Clojure/ClojureScript (or Java/JavaScript)?
>>>
>>> There is an existing reference implementation written in Mathematica and 
>>> it appears a port has already been done to Python: 
>>> https://github.com/jrmuizel/pyunum
>>>
>>> For more details of unum see
>>> https://www.youtube.com/watch?v=jN9L7TpMxeA
>>>
>>> https://www.crcpress.com/The-End-of-Error-Unum-Computing/Gustafson/9781482239867
>>> http://arith22.gforge.inria.fr/slides/06-gustafson.pdf
>>>
>>>
>>> -- 
>> 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: Unum in Clojure/ClojureScript?

[James Elliott]

Heh! I just read about these in an email from ACM, and found your post by 
searching this Group for UNUM. It looks like not yet, but perhaps we should 
do something about that?

The article which excited me:
http://ubiquity.acm.org/article.cfm?id=2913029

On Friday, November 6, 2015 at 8:23:35 AM UTC-6, Richard Davies wrote:
>
> Unum is a number representation system that is a superset of IEEE integers 
> and IEEE floats which avoids many problems (especially in floating point 
> arithmetic) as it has no rounding, no overflow to infinity, no underflow to 
> zero, and is safe to parallelize.
>
> I was wondering if anyone has implemented or is interested in implementing 
> this in Clojure/ClojureScript (or Java/JavaScript)?
>
> There is an existing reference implementation written in Mathematica and 
> it appears a port has already been done to Python: 
> https://github.com/jrmuizel/pyunum
>
> For more details of unum see
> https://www.youtube.com/watch?v=jN9L7TpMxeA
>
> https://www.crcpress.com/The-End-of-Error-Unum-Computing/Gustafson/9781482239867
> http://arith22.gforge.inria.fr/slides/06-gustafson.pdf
>
>
>

-- 
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: Recur in an overloaded function does not work?

[James Elliott]

Does trampoline really help in this case? I don’t see where we are ever 
returning a new function for trampoline to call, avoiding a new stack 
frame. It seems to me no different than simply calling the other arities 
directly in this example. What am I missing?

On Wednesday, April 20, 2016 at 12:00:35 PM UTC-5, J.-F. Rompre wrote:
>
> You can prevent stack consumption by using trampoline for tail-recursive 
> calls to a different arity, and recur for same arity, something like:
>
> (defn find-comment-in-line
>
> ([s] (when (pos? (count s))
>   (if-let [cs (seq (comment-s? s))]
>  ;; yes, a comment symbol found,
>  ;; just return the remainder of a string
>   (subs s (count (first cs)))
>
>  ;; no, lets check for an opening quote
>
>   (if-let [qs (seq (quote-s? s))]
>
>   ;; yes, an opening quote found,
>   ;; now go look for an end quote
>   (trampoline find-comment-in-line (subs s 1) qs)
>
>   ;; no, just some other symbol found,
>   ;; check for the rest
>   (recur (subs s 1))
>
>  ([s q] (when (pos? (count s))
>  ;; lets check if it is a quote
>  (if-let [qs (seq (quote-s? s))]
>
>  ;; is it a closing quote?
>  (if (= qs q)
>;; yes, lets check for the rest
>(trampoline find-comment-in-line (subs s 1))
>
>;; no, just ignore the symbol,
>;;continue looking for a closing quote
>(recur (subs s 1) q))
>
>
>
> On Tuesday, April 19, 2016 at 11:18:40 AM UTC-4, andmed wrote:
>>
>> Thank you. That the point. If "recur" binds to fn, why it can not know 
>> the binding point as the function method based on the number of arguments 
>> passed to it? I mean it is clear that Clojure can't do that, but I can see 
>> no reason why it could or should not if we choose to implement such 
>> syntactic nicety as recur in a function
>>
>

-- 
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: Recur in an overloaded function does not work?

[James Elliott]

But recur does not do that. Recur does not call a function at all. It is 
the opposite of calling a function, it says “I want to loop, without the 
overhead of calling a function and creating a stack frame.” Recur is even 
used outside of functions entirely; it is how you iterate using the (loop 
...) form, and that is almost always how I have used it.

If you want to call a different arity of your function, that has to be an 
actual function call. recur is only a way to branch back to where you 
started a loop, or a particular function body.

On Tuesday, April 19, 2016 at 10:18:40 AM UTC-5, andmed wrote:
>
> Thank you. That the point. If "recur" binds to fn, why it can not know the 
> binding point as the function method based on the number of arguments 
> passed to it? I mean it is clear that Clojure can't do that, but I can see 
> no reason why it could or should not if we choose to implement such 
> syntactic nicety as recur in a function
>

-- 
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: Recur in an overloaded function does not work?

[James Elliott]

And the reason for this is to be able to simulate tail-call optimization 
even though the Java VM doesn’t natively support that; recur can allow you 
to express things in a style that looks recursive, but does not suffer from 
stack space limitations that actual recursive calls do. If you actually 
want to perform a recursive call, you can simply do so by calling the 
function normally, without using recur.

On Monday, April 18, 2016 at 3:47:10 PM UTC-5, adrian...@mail.yu.edu wrote:
>
> Each arity defined for a particular Clojure function is actually a 
> separate "method" under the hood for that particular functional instance. 
> `recur` in Clojure should be thought of as more like a primitive looping 
> construct than a recursive call to some named function.
>
> The documentation for the recur special form explains this in more detail: 
> http://clojure.org/reference/special_forms#recur. 
>
> On Monday, April 18, 2016 at 4:16:30 PM UTC-4, andmed wrote:
>>
>> Hello
>>
>> I am just a beginner Clojure programmer and I am unhappy with the way 
>> recur behaves in Clojure
>>
>> I have implemented kata from here 
>> https://github.com/alvarogarcia7/kata-formulation-find-comments/pull/3
>> What it does: it outputs 'comments' (sequences starting with "#" or "//") 
>> and ignores 'comments' in quotes
>>
>> Here is the code:
>>
>> (def comment-s '("#" "//"))
>> (def quote-s '("'" "\""))
>>
>> (defn comment-s? [s]
>>   (filter #(.startsWith s %) comment-s))
>>
>> (defn quote-s? [s]
>>(filter #(.startsWith s %) quote-s))
>>
>> (defn find-comment-in-line
>>   "We implement a FSM via an overloaded function -- when inside a quote, 
>> pass two arguments, including opening quote symb, otherwise just one 
>> (string itself). Don't know yet hot to recur in an 
>> ([s] (when (pos? (count s))
>>   (if-let [cs (seq (comment-s? s))]
>>   (subs s (count (first cs))) ; yes, a comment symbol found, just 
>> return the remainder of a string
>>   (if-let [qs (seq (quote-s? s))] ; no, lets check for an opening 
>> quote
>>   (find-comment-in-line (subs s 1) qs) ; yes, an opening 
>> quote found, now go look for an end quote
>>   (find-comment-in-line (subs s 1)) ; no, just some other 
>> symbol found, check for the rest
>>  ([s q] (when (pos? (count s))
>>(if-let [qs (seq (quote-s? s))] ; lets check if it is a quote
>>  (if (= qs q) ; is it a closing quote?
>>(find-comment-in-line (subs s 1)) ; yes, lets check for the 
>> rest
>>(find-comment-in-line (subs s 1) q)) ; no, just ignore the 
>> symbol, continue looking for a closing quote
>>
>>  My idea was to make it via recur: it does not work however because recur 
>> apparently binds to an implementation with particular number of arguments, 
>> not to a function call, and I can not see any reason why it would not.
>>
>> With recur I was getting 
>> Caused by: java.lang.IllegalArgumentException: Mismatched argument count 
>> to recur, expected: 1 args, got: 2
>>
>>
>> I guess the code is a bit "imperative" and imperative programmer I am. 
>> Also, I can make recur work with a nullable argument and a helper function, 
>> still... is there any reason Clojure can not bind recur to a function call 
>> in accordance with the number of arguments passed?
>>
>>

-- 
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: Emacs cider mode has problems with macros

[James Elliott]

You might have better luck asking in the cider-emacs group, 
https://groups.google.com/forum/#!forum/cider-emacs

or even more active, the Gitter chat: https://gitter.im/clojure-emacs/cider

  -James

On Wednesday, March 16, 2016 at 3:01:23 PM UTC-5, JvJ wrote:
>
>
>
> Something unusual happens when I'm writing macros while in modes cider and 
> ClojureC with autocomplete enabled.
>
> I have a macro derive-component (definition is too long to put in here). 
> When I attempt to use this macro, as follows:
>
> ;; s refers to schema.core in this context
>
> (derive-component
>  Position
>  "It has x and y coordinates."
>[s/Int s/Int])
>
>
> If I try to type anywhere within the above form, I get a massive exception 
> printout in the repl.  Furthermore, my cursor automatically switches to the 
> repl from the file buffer.
>
> I realize that something may be wrong with my macro definition, but that's 
> not the point.  The repl should be able to handle these errors gracefully. 
>  Furthermore, There is nothing to my knowledge that should be actively 
> evaluating code.
>
> Does anyone know what may be doing this?
>
> Thanks
>
> Here's the error stack trace:
>
> RuntimeException [Int Int] is not a valid sequence schema; a valid 
> sequence schema consists of zero or more `one` elements, followed by zero 
> or more `optional` elements, followed by an optional schema that will match 
> the remaining elements.  schema.core/parse-sequence-schema (core.clj:901)
> java.lang.IllegalArgumentException: Don't know how to create ISeq from: 
> clojure.lang.Symbol
>  at clojure.lang.RT.seqFrom (RT.java:528)
> clojure.lang.RT.seq (RT.java:509)
> clojure.core/seq (core.clj:137)
> clojure.core.protocols$seq_reduce.invoke (protocols.clj:30)
> clojure.core.protocols/fn (protocols.clj:84)
> clojure.core.protocols$fn__6452$G__6447__6465.invoke (protocols.clj:13)
> clojure.core$reduce.invoke (core.clj:6519)
> clojure.core$mapv.invoke (core.clj:6616)
> cider.nrepl.middleware.info$format_eldoc$fn__26048.invoke 
> (info.clj:290)
> clojure.core$map$fn__4553.invoke (core.clj:2622)
> clojure.lang.LazySeq.sval (LazySeq.java:40)
> clojure.lang.LazySeq.seq (LazySeq.java:49)
> clojure.lang.RT.seq (RT.java:507)
> clojure.core/seq (core.clj:137)
> clojure.core$map$fn__4553.invoke (core.clj:2616)
> clojure.lang.LazySeq.sval (LazySeq.java:40)
> clojure.lang.LazySeq.seq (LazySeq.java:49)
> clojure.lang.RT.seq (RT.java:507)
> clojure.core/seq (core.clj:137)
> clojure.core$dorun.invoke (core.clj:3009)
> clojure.core$doall.invoke (core.clj:3025)
> clojure.walk$walk.invoke (walk.clj:46)
> clojure.walk$postwalk.invoke (walk.clj:58)
> clojure.core$partial$fn__4527.invoke (core.clj:2493)
> clojure.core$map$fn__4553.invoke (core.clj:2622)
> clojure.lang.LazySeq.sval (LazySeq.java:40)
> clojure.lang.LazySeq.seq (LazySeq.java:49)
> clojure.lang.RT.seq (RT.java:507)
> clojure.lang.LazilyPersistentVector.create 
> (LazilyPersistentVector.java:30)
> clojure.core$vec.invoke (core.clj:361)
> clojure.walk$walk.invoke (walk.clj:45)
> clojure.walk$postwalk.invoke (walk.clj:58)
> clojure.core$partial$fn__4527.invoke (core.clj:2493)
> 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.next (RT.java:674)
> clojure.core/next (core.clj:64)
> clojure.core.protocols/fn (protocols.clj:170)
> clojure.core.protocols$fn__6478$G__6473__6487.invoke (protocols.clj:19)
> clojure.core.protocols$seq_reduce.invoke (protocols.clj:31)
> clojure.core.protocols/fn (protocols.clj:101)
> clojure.core.protocols$fn__6452$G__6447__6465.invoke (protocols.clj:13)
> clojure.core$reduce.invoke (core.clj:6519)
> clojure.core$into.invoke (core.clj:6600)
> clojure.walk$walk.invoke (walk.clj:49)
> clojure.walk$postwalk.invoke (walk.clj:58)
> clojure.walk$stringify_keys.invoke (walk.clj:107)
> clojure.tools.nrepl.transport.FnTransport.send (transport.clj:28)
> 
> clojure.tools.nrepl.middleware.pr_values$pr_values$fn$reify__13898.send 
> (pr_values.clj:27)
> cider.nrepl.middleware.info$eldoc_reply.invoke (info.clj:302)
> cider.nrepl.middleware.info$wrap_info$fn__26058.invoke (info.clj:315)
> clojure.tools.nrepl.middleware$wrap_conj_descriptor$fn__13724.invoke 
> (middleware.clj:22)
> cemerick.piggieback$wrap_cljs_repl$fn__20579.invoke 
> (piggieback.clj:299)
> clojure.tools.nrepl.middleware$wrap_conj_descriptor$fn__13724.invoke 
> (middleware.clj:22)
> cider.nrepl.middleware.track_state$wrap_tracker$fn__27148.invoke 
> (track_state.clj:200)
> clojure.tools.nrepl.middleware$wrap_conj_descriptor$fn__13724.invoke 
> (middleware.clj:22)
> cider.nrepl.middleware.pprint$wrap_pprint$fn__22366.invoke 
> (pprint.clj:106)
> 

Re: [ANN] Elements of Clojure

[James Elliott]

That’s excellent! I had high hopes after watching your keynote on this 
topic, and the chapter has more than lived up to my expectations. I’ve 
bought the book in anticipation of the remaining chapters.

Leanpub looks like a really interesting platform! I thought about 
converting my Afterglow documentation, and then was defeated by the fact 
that they support only Markdown. I quickly had to graduate to Asciidoc in 
writing it because of the lack of some features I was used to from back in 
the Framemaker days. I really hope they support it someday; I see they are 
working on a competing standard they call Markua, but even when that is 
finished, I would have to have to rewrite all my existing chapters.

On Thursday, March 17, 2016 at 12:47:55 PM UTC-5, Zach Tellman wrote:
>
> I'm writing a book about Clojure, aimed at people who already know the 
> core concepts, and want to use them more effectively.  The first chapter, 
> "Names", is complete and can be read for free.  Details can be found at 
> http://elementsofclojure.com/.  
>
> I'm happy to answer any questions here, or on the book's mailing list at 
> https://groups.google.com/forum/#!forum/elements-of-clojure.
>

-- 
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: XOR two arrays into a third on Clojure

[James Elliott]

Thanks, that does look nice. If I end up wanting to do any image manipulation I 
will definitely check it out. For now, all I need to do is be able to create a 
graphics context into which I can draw the user interface, then convert it into 
bits in the proper format, and blast them over USB to the Ableton Push 2. And 
that is working, to much rejoicing!

Cheers,

-James

> On Mar 13, 2016, at 01:04, Mikera <mike.r.anderson...@gmail.com> wrote:
> 
> I have a useful library for image manipulation in Clojure, you may find it 
> useful:
> 
> https://github.com/mikera/imagez
> 
> New ideas / PRs gratefully received!
> 
> On Sunday, 13 March 2016 04:14:34 UTC+8, James Elliott wrote:
> Interesting! This is the first time I have had to drop out of Clojure for 
> performance reasons. It is not too surprising, given that I am doing 
> low-level byte bashing in a tight loop to send pixels to a display over USB 
> at sixty frames per second. But it is surprising that nothing like this has 
> happened before in building my Clojure environment for running light shows.
> 
> I have created a separate Java library which I am calling Wayang, to make it 
> easy for any Java project to drive this display. Once that’s done, I may add 
> a small Clojure convenience wrapper, or I may just have Afterglow use Wayang 
> directly. https://github.com/brunchboy/wayang 
> <https://github.com/brunchboy/wayang>
> 
> But first I have a bunch of Java2D integration to implement!
> 
> On Thursday, March 13, 2014 at 12:26:33 AM UTC-5, Ignacio Corderi wrote:
> Hey guys, here is a huge performance problem I'm trying to figure out:
> 
> ;; Say you have 2 data arrays sitting out there of 1 MB
> 
> (def one-mb (byte-array (* 1024 1024))) 
> (def another-mb (byte-array (* 1024 1024))) 
> 
> ;; and another one that should have the byte-by-byte XOR of the previous two 
> 
> (def out-mb (byte-array (* 1024 1024)))
> 
> ;; question is... how do you code this guy, so that it doesn't take forever
> 
> (defn inplace-xor [a b out]
>   (def ln (count a))
>   (loop [x 0]
> (if (< x ln)
>   (do 
> (aset-byte out x (bit-xor (nth a x) (nth b x)))
> (recur (+ x 1))
> 
> 
> ;; checking the time 
> 
> (time (inplace-xor one-mb another-mb out-mb))
> 
> ;; takes about ~400ms which is well... A LOT
> 
> ;; I'm happy to receive a solution that involves calling some java library...
> 
> Thanks in advance!
> -Ignacio
> 
>  
> 
> -- 
> 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 
> <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/kcx5eKdMxcs/unsubscribe 
> <https://groups.google.com/d/topic/clojure/kcx5eKdMxcs/unsubscribe>.
> To unsubscribe from this group and all its topics, send an email to 
> clojure+unsubscr...@googlegroups.com 
> <mailto:clojure+unsubscr...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout 
> <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: XOR two arrays into a third on Clojure

[James Elliott]

Interesting! This is the first time I have had to drop out of Clojure for 
performance reasons. It is not too surprising, given that I am doing 
low-level byte bashing in a tight loop to send pixels to a display over USB 
at sixty frames per second. But it is surprising that nothing like this has 
happened before in building my Clojure environment for running light shows.

I have created a separate Java library which I am calling Wayang, to make 
it easy for any Java project to drive this display. Once that’s done, I may 
add a small Clojure convenience wrapper, or I may just have Afterglow use 
Wayang directly. https://github.com/brunchboy/wayang

But first I have a bunch of Java2D integration to implement!

On Thursday, March 13, 2014 at 12:26:33 AM UTC-5, Ignacio Corderi wrote:
>
> Hey guys, here is a huge performance problem I'm trying to figure out:
>
> ;; Say you have 2 data arrays sitting out there of 1 MB
>
> (def one-mb (byte-array (* 1024 1024))) 
> (def another-mb (byte-array (* 1024 1024))) 
>
> ;; and another one that should have the byte-by-byte XOR of the previous 
> two 
>
> (def out-mb (byte-array (* 1024 1024)))
>
> ;; question is... how do you code this guy, so that it doesn't take forever
>
> (defn inplace-xor [a b out]
>   (def ln (count a))
>   (loop [x 0]
> (if (< x ln)
>   (do 
> (aset-byte out x (bit-xor (nth a x) (nth b x)))
> (recur (+ x 1))
> 
>
> ;; checking the time 
>
> (time (inplace-xor one-mb another-mb out-mb))
>
> ;; takes about ~400ms which is well... A LOT
>
> ;; I'm happy to receive a solution that involves calling some java 
> library...
>
> Thanks in advance!
> -Ignacio
>
>  
>

-- 
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] dali SVG library 0.7.0

[James Elliott]

I agree, lovely indeed--I am already being tempted to learn to use it to 
just create some diagrams for my own documentation! Thank you.

On Wednesday, February 10, 2016 at 7:40:57 PM UTC-6, Colin Fleming wrote:
>
> This looks really lovely, thanks!
>
> On 11 February 2016 at 13:51, Stathis Sideris  > wrote:
>
>> ...aaand the link to the repo: https://github.com/stathissideris/dali
>>
>>
>> On Thursday, 11 February 2016 00:49:54 UTC, Stathis Sideris wrote:
>>>
>>> Hello all,
>>>
>>> dali is a Clojure library for representing the SVG graphics format. It 
>>> allows the creation and manipulation of SVG files. The syntax 
>>>  used 
>>> to describe the graphical elements is based on hiccup 
>>>  with a few extensions.
>>>
>>> The main advantage of dali is that it provides facilities to perform 
>>> complex layouts 
>>>  
>>> without having to position elements explicitly.
>>>
>>> The 0.7.0 brings a lot of new features and very complete documentation 
>>> to get you started.
>>>
>>> All feedback very welcome.
>>>
>>>
>>> Thanks,
>>>
>>> Stathis Sideris
>>>
>> -- 
>> 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: Undocumented reader macros?

[James Elliott]

Understood! I am certainly not diving in to submit pull requests to add 
features.

On Wednesday, February 10, 2016 at 10:43:25 AM UTC-6, Andy Fingerhut wrote:
>
> It may be as finished as it will ever be.
>
> Andy
>
> On Wed, Feb 10, 2016 at 8:35 AM, James Elliott <brun...@gmail.com 
> > wrote:
>
>> Ah, I see that part of the reason it’s not yet documented is that it’s 
>> not really finished; you can’t, for example, use a keyword as a function 
>> with it. Trying to use #=(:tap-tempo control-buttons) as a case target 
>> fails with clojure.lang.Keyword cannot be cast to clojure.lang.Symbol. I 
>> guess I will give up on it until/unless it gets finished and becomes 
>> official. :)
>>
>>
>> On Monday, February 8, 2016 at 9:49:57 PM UTC-6, James Elliott wrote:
>>>
>>> Quite dissonant, I mean, derp.
>>>
>>> On Monday, February 8, 2016 at 9:49:28 PM UTC-6, James Elliott wrote:
>>>>
>>>> Oh, I see… interesting. What would it take to achieve commitment? :) I 
>>>> humbly submit that it feels qiote dissonant to stumble across something 
>>>> like this in a language that is attaining such wide adoption as Clojure is 
>>>> now.
>>>>
>>>> On Monday, February 8, 2016 at 8:53:45 PM UTC-6, Alex Miller wrote:
>>>>>
>>>>> Rich has never committed to officially making this part of Clojure so 
>>>>> it has been left as an undocumented feature.
>>>>>
>>>>> On Monday, February 8, 2016 at 12:33:44 PM UTC-6, James Elliott wrote:
>>>>>>
>>>>>> I learned recently <http://stackoverflow.com/a/15332367/802383> that 
>>>>>> you can tell the reader to evaluate a function at read time, if you want 
>>>>>> some potentially costly operation that you know will result in a 
>>>>>> constant 
>>>>>> value to be done just once, rather than every time the surrounding form 
>>>>>> is 
>>>>>> evaluated, by prefixing it with the reader macro #= and I found this 
>>>>>> surprising. Shouldn’t this be documented in the Reader reference 
>>>>>> <http://clojure.org/reference/reader>?
>>>>>>
>>>>> -- 
>> 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: Undocumented reader macros?

[James Elliott]

Ah, I see that part of the reason it’s not yet documented is that it’s not 
really finished; you can’t, for example, use a keyword as a function with 
it. Trying to use #=(:tap-tempo control-buttons) as a case target fails 
with clojure.lang.Keyword cannot be cast to clojure.lang.Symbol. I guess I 
will give up on it until/unless it gets finished and becomes official. :)

On Monday, February 8, 2016 at 9:49:57 PM UTC-6, James Elliott wrote:
>
> Quite dissonant, I mean, derp.
>
> On Monday, February 8, 2016 at 9:49:28 PM UTC-6, James Elliott wrote:
>>
>> Oh, I see… interesting. What would it take to achieve commitment? :) I 
>> humbly submit that it feels qiote dissonant to stumble across something 
>> like this in a language that is attaining such wide adoption as Clojure is 
>> now.
>>
>> On Monday, February 8, 2016 at 8:53:45 PM UTC-6, Alex Miller wrote:
>>>
>>> Rich has never committed to officially making this part of Clojure so it 
>>> has been left as an undocumented feature.
>>>
>>> On Monday, February 8, 2016 at 12:33:44 PM UTC-6, James Elliott wrote:
>>>>
>>>> I learned recently <http://stackoverflow.com/a/15332367/802383> that 
>>>> you can tell the reader to evaluate a function at read time, if you want 
>>>> some potentially costly operation that you know will result in a constant 
>>>> value to be done just once, rather than every time the surrounding form is 
>>>> evaluated, by prefixing it with the reader macro #= and I found this 
>>>> surprising. Shouldn’t this be documented in the Reader reference 
>>>> <http://clojure.org/reference/reader>?
>>>>
>>>

-- 
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-refactor.el and refactor-nrepl 2.0.0 is released

[James Elliott]

Yes, that is such an intractable problem. It would be wonderful if you 
could make things work even better, but I am happy to see them getting this 
far already.

On Tuesday, February 9, 2016 at 3:31:24 AM UTC-6, benedek fazekas wrote:
>
> Thanks Colin, James. re. warning about evaluation, we are looking into 
> further improving this area, watch 
> https://github.com/clojure-emacs/refactor-nrepl/issues/134 (slightly 
> misleading title) for discussion around it.
>
> On Monday, February 8, 2016 at 6:10:22 PM UTC, James Elliott wrote:
>>
>> Thank you all! I have been watching progress on the Gitter chat and am 
>> very excited to be able to use all the great new features in this amazing 
>> package. The fact that I am now warned when the project needs to be 
>> re-evaluated, and that I can recover from issues with my protocols being 
>> redefined when I go ahead and allow that to happen by calling 
>> cider-refresh, means I can now learn and apply these tools without fear.
>>
>> On Saturday, February 6, 2016 at 5:30:39 PM UTC-6, benedek fazekas wrote:
>>>
>>> The stable release for clj-refactor.el is out together with its nrepl 
>>> middleware backend refactor-nrepl.
>>>
>>> clj-refactor.el is an Emacs package for clojure and clojure script 
>>> refactorings while refactor-nrepl is an editor agnostic nrepl middleware 
>>> backend supporting refactoring features in your editor of choice. For a 
>>> state of art demo what you can achieve with clj-refactor and Emacs see 
>>> Magnar's <https://github.com/magnars> parens of the dead 
>>> <http://www.parens-of-the-dead.com/> series.
>>>
>>> The main areas of improvement for this release are
>>>
>>>- supporting refactorings for *cljc and clojurescript* files
>>>- *boot* support
>>>- *find usages* (and related features) supporting *macros*.
>>>- *improve discoverability* of features via hydra menus 
>>><https://github.com/clojure-emacs/clj-refactor.el/wiki/Hydra> and 
>>>the project wiki 
>>><https://github.com/clojure-emacs/clj-refactor.el/wiki>.
>>>
>>> Apart from these there are a huge number of changes, improvements and 
>>> bugfixes, see full changelog for clj-refactor 
>>> <https://github.com/clojure-emacs/clj-refactor.el/blob/master/CHANGELOG.md#200>
>>>  and refactor-nrepl 
>>> <https://github.com/clojure-emacs/refactor-nrepl/blob/master/CHANGELOG.md#200>
>>> .
>>>
>>> This release is also compatible with the latest cider stable release. 
>>> Unfortunately tho we had to drop support for clojure 1.6 and older.
>>>
>>> As for almost all releases Lars Andersen <https://github.com/expez> 
>>> invested 
>>> a lot of time and energy in commits and also in support, also the original 
>>> creator of clj-refactor Magnar Sveen <https://github.com/magnars> helped 
>>> *create function from example* to grow brains for this release. Thanks 
>>> for both of them and all the contributors 
>>> <https://github.com/clojure-emacs/clj-refactor.el/graphs/contributors>! 
>>> Also thanks for the maintainers and contributors of the packages we build 
>>> on, like cider, tools.nrepl, tools.analyzer, tools.namespace and others!
>>>
>>> As always any contribution and/or feedback is welcome. We are available 
>>> on gitter <https://gitter.im/clojure-emacs/refactor-nrepl> and usually 
>>> hang out on clojurian slack #cider channel too.
>>>
>>> Enjoy!
>>>
>>> --
>>> Benedek Fazekas
>>>
>>

-- 
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: Scripting with Clojure / "slow" boot time

[James Elliott]

I don’t have any examples to share, I just wanted to thank you for doing 
this. It is really wonderful to see how responsive Clojure is to community 
input and concerns, and the launch of an effort like this so quickly in 
response to the survey feedback.

On Tuesday, February 9, 2016 at 12:36:43 PM UTC-6, Alex Miller wrote:
>
> I'm doing some research on slow Clojure boot time and would be interested 
> in collecting info about example use cases where it's been a problem for 
> people.
>
> http://goo.gl/forms/eSpn8M5FNB
>
> I'm not expecting to release the results in any formal way, mostly looking 
> to use it to pull out particular use cases and/or commonalities across 
> anecdotes so that we can work on boot time problems that matter the most 
> (and solutions likely to help the most). Any numbers you can provide would 
> be great.
>
> Alex
>
>
>

-- 
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: Undocumented reader macros?

[James Elliott]

Oh, I see… interesting. What would it take to achieve commitment? :) I 
humbly submit that it feels qiote dissonant to stumble across something 
like this in a language that is attaining such wide adoption as Clojure is 
now.

On Monday, February 8, 2016 at 8:53:45 PM UTC-6, Alex Miller wrote:
>
> Rich has never committed to officially making this part of Clojure so it 
> has been left as an undocumented feature.
>
> On Monday, February 8, 2016 at 12:33:44 PM UTC-6, James Elliott wrote:
>>
>> I learned recently <http://stackoverflow.com/a/15332367/802383> that you 
>> can tell the reader to evaluate a function at read time, if you want some 
>> potentially costly operation that you know will result in a constant value 
>> to be done just once, rather than every time the surrounding form is 
>> evaluated, by prefixing it with the reader macro #= and I found this 
>> surprising. Shouldn’t this be documented in the Reader reference 
>> <http://clojure.org/reference/reader>?
>>
>

-- 
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: Undocumented reader macros?

[James Elliott]

Quite dissonant, I mean, derp.

On Monday, February 8, 2016 at 9:49:28 PM UTC-6, James Elliott wrote:
>
> Oh, I see… interesting. What would it take to achieve commitment? :) I 
> humbly submit that it feels qiote dissonant to stumble across something 
> like this in a language that is attaining such wide adoption as Clojure is 
> now.
>
> On Monday, February 8, 2016 at 8:53:45 PM UTC-6, Alex Miller wrote:
>>
>> Rich has never committed to officially making this part of Clojure so it 
>> has been left as an undocumented feature.
>>
>> On Monday, February 8, 2016 at 12:33:44 PM UTC-6, James Elliott wrote:
>>>
>>> I learned recently <http://stackoverflow.com/a/15332367/802383> that 
>>> you can tell the reader to evaluate a function at read time, if you want 
>>> some potentially costly operation that you know will result in a constant 
>>> value to be done just once, rather than every time the surrounding form is 
>>> evaluated, by prefixing it with the reader macro #= and I found this 
>>> surprising. Shouldn’t this be documented in the Reader reference 
>>> <http://clojure.org/reference/reader>?
>>>
>>

-- 
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-refactor.el and refactor-nrepl 2.0.0 is released

[James Elliott]

Thank you all! I have been watching progress on the Gitter chat and am very 
excited to be able to use all the great new features in this amazing 
package. The fact that I am now warned when the project needs to be 
re-evaluated, and that I can recover from issues with my protocols being 
redefined when I go ahead and allow that to happen by calling 
cider-refresh, means I can now learn and apply these tools without fear.

On Saturday, February 6, 2016 at 5:30:39 PM UTC-6, benedek fazekas wrote:
>
> The stable release for clj-refactor.el is out together with its nrepl 
> middleware backend refactor-nrepl.
>
> clj-refactor.el is an Emacs package for clojure and clojure script 
> refactorings while refactor-nrepl is an editor agnostic nrepl middleware 
> backend supporting refactoring features in your editor of choice. For a 
> state of art demo what you can achieve with clj-refactor and Emacs see 
> Magnar's  parens of the dead 
>  series.
>
> The main areas of improvement for this release are
>
>- supporting refactorings for *cljc and clojurescript* files
>- *boot* support
>- *find usages* (and related features) supporting *macros*.
>- *improve discoverability* of features via hydra menus 
> and the 
>project wiki .
>
> Apart from these there are a huge number of changes, improvements and 
> bugfixes, see full changelog for clj-refactor 
> 
>  and refactor-nrepl 
> 
> .
>
> This release is also compatible with the latest cider stable release. 
> Unfortunately tho we had to drop support for clojure 1.6 and older.
>
> As for almost all releases Lars Andersen  invested 
> a lot of time and energy in commits and also in support, also the original 
> creator of clj-refactor Magnar Sveen  helped 
> *create 
> function from example* to grow brains for this release. Thanks for both 
> of them and all the contributors 
> ! 
> Also thanks for the maintainers and contributors of the packages we build 
> on, like cider, tools.nrepl, tools.analyzer, tools.namespace and others!
>
> As always any contribution and/or feedback is welcome. We are available on 
> gitter  and usually hang 
> out on clojurian slack #cider channel too.
>
> Enjoy!
>
> --
> Benedek Fazekas
>

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

Undocumented reader macros?

[James Elliott]

I learned recently  that you 
can tell the reader to evaluate a function at read time, if you want some 
potentially costly operation that you know will result in a constant value 
to be done just once, rather than every time the surrounding form is 
evaluated, by prefixing it with the reader macro #= and I found this 
surprising. Shouldn’t this be documented in the Reader reference 
?

-- 
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] Leiningen 2.6.0

[James Elliott]

Thanks, I’ve created a PR to update the version in homebrew (this time I 
checked to make sure nobody else had already done so first... *blush*)

  -James

On Monday, February 8, 2016 at 12:06:32 PM UTC-6, Jean Niklas L'orange 
wrote:
>
> Hi all,
>
> Instead of creating a new thread for the 2.6.1 release of Leiningen,
> I'll just piggyback on this one.
>
> Leiningen 2.6.1 is a small release to fix an issue with 2.6.0. Some
> popular plugins (`lein midje`, `lein ring` to mention a few) broke
> because of a change in eval-in-project. This has now been fixed.
>
> Sorry for any inconvenience caused.
>
> -- Jean Niklas
>
> On Friday, February 5, 2016 at 2:27:37 AM UTC+1, Jean Niklas L'orange 
> wrote:
>>
>> Greetings!
>>
>> I am happy to announce Leiningen 2.6.0! This release contains mostly
>> usability improvements, along with some bugfixes. 
>>
>> The biggest notable change will likely be for Homebrew users. When the
>> Homebrew formula is updated to 2.6.0, you will likely experience startup
>> time improvements.
>>
>> In addition, `lein release` now supports '-SNAPSHOT' on qualifiers (alpha,
>> beta, RC), and signing GPG artifacts from the terminal will give you
>> feedback on whether you managed to type in your passphrase correctly or
>> not.
>>
>> Due to syntax changes from Clojure 1.1.0 to 1.2.0, we had to drop
>> support for Clojure 1.1.0 and older.
>>
>> The full list of significant changes:
>>
>> * The templates, repl and Leiningen itself now use Clojure 1.8.
>> * Support for Clojure 1.1.0 and older is now dropped.
>> * Warn if possibly stale native dependencies end up in `:native-path`.
>>   (Jean Niklas L'orange)
>> * Speed up restarts after `:dependency` changes. (Jean Niklas L'orange)
>> * `lein release` now supports SNAPSHOT on qualifiers. (Chris Price)
>> * Synchronise `lein-pkg` and `lein` scripts. (Thu Trang Pham)
>> * Decrease timeout for the Clojure compiler agent thread pool. (Ryan
>>   Fowler)
>> * Fix a bug where implicit resource directories were created by default.
>>   (Jean Niklas L'orange)
>> * Avoid optimizing away stack traces by default. (solicode)
>> * Fix a bug where duplicate profiles were merged when profile merging.
>>   (Jean Niklas L'orange)
>> * Improved GPG artifact signing feedback. (Jean Niklas L'orange, Andrea
>>   Richiardi)
>> * Add function to support binary files with `lein-new`. (Sergiy Bondaryev)
>> * Show better error message when java is not found on the path. (Pavel
>>   Prokopenko, Jürgen Hötzel)
>> * Fix a bug with non-GitHub SCM urls in pom files. (Ralf Schmitt)
>> * Don't send aot warning if `:aot` contains regex matching the main
>>   namespace. (Emlyn Corrin)
>>
>> As usual, for those who manually installed, `lein upgrade` will pull in
>> the latest. `lein downgrade 2.5.3` will back it down to the previous
>> version if you run into any issues.
>>
>> Thanks to all the contributors who made this happen!
>>
>> -- 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.

Re: Clojure beyond Java 6 ?

[James Elliott]

Thanks, Andrew, and to be clear this is an obscure side environment of my 
main project, and I am resigned to the fact that it seems doomed because 
the developers of Max/MSP are choosing to respond to Apple’s deprecation of 
their Java 1.6 environment by entirely abandoning support for working with 
the Java VM. So I agree, Java 1.6 is very old now, and at some point the 
burden of maintaining support for it starts slowing down other important 
progress.

The main thrust of my Clojure development is in the latest release 
candidate of Clojure on the latest Oracle JVM.

On Saturday, August 8, 2015 at 1:03:38 PM UTC-5, Andrew Oberstar wrote:
>
> [...]
> I can understand James' (Elliott) desire to keep Java 6 compatibility for 
> platforms that are slower to adopt newer JVMs, but I hope that doesn't 
> become an excuse for Clojure to stay moored to the JVM's past for the 
> long-term.
>
> Andrew Oberstar
>

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

Re: Clojure beyond Java 6 ?

[James Elliott]

El Capitan is now the current version of OS X (although I have not yet 
personally been able to update to it, because of some straggling 
compatibility issues with DJ equipment), so the next version of OS X will 
no longer support Apple’s 1.6 JDK.

On Saturday, August 8, 2015 at 3:44:36 PM UTC-5, Colin Fleming wrote:
>
> El Capitan (the next version of OSX) is going to be the last to support 
> Apple's 1.6 JDK. But that still means that I'm going to be stuck supporting 
> 1.6 until the vast majority of people have moved on from El Capitan - 
> that's a long way off.
>
> On 8 August 2015 at 20:52, James Elliott <brun...@gmail.com > 
> wrote:
>
>> That sounds like a great project. And I know that in the medium to long 
>> term, even if Clojure continues to support Java 1.6, eventually Apple will 
>> stop supporting their legacy VM, so I just hope Afterglow will catch on 
>> enough by then to convince Cycling ’74 to update their MXJ bridge. ;^)
>>
>> -James
>>
>> On Aug 8, 2015, at 13:03, Andrew Oberstar <ajobe...@gmail.com 
>> > wrote:
>>
>> I may end up in the same incomplete, unmaintained state as the other 
>> libraries you've seen, but I'm slowly starting on a Java interop library 
>> "cljj" (https://github.com/ike-tools/ike.cljj).
>>
>> - AutoCloseable - As James (Reeves) mentioned, clojure.core/with-open 
>> meets this need.
>> - NIO2 - Standard Java interop is functional, but can be a pain due to 
>> the heavy use of varargs in NIO2 APIs. I'd like to wrap this in cljj.
>> - Streams - Can add reduce/transduce support by implementing CollReduce 
>> protocol. There's not a clean way to support the clojure.core/seq function, 
>> that I've seen without wrapping the stream. I plan to support this in cljj.
>> - Lambdas - I do find these to be a pain, and had a thread on this list a 
>> week or two ago. Right now I'm planning to just have functions/macros to 
>> wrap/define methods implementing java.util.function interfaces. Ideally, 
>> the compiler would support this better. This is the only one that really 
>> would require any change to Clojure itself for better Java 8 support IMO.
>>
>> I can understand James' (Elliott) desire to keep Java 6 compatibility for 
>> platforms that are slower to adopt newer JVMs, but I hope that doesn't 
>> become an excuse for Clojure to stay moored to the JVM's past for the 
>> long-term.
>>
>> Andrew Oberstar
>>
>> On Fri, Aug 7, 2015 at 7:12 AM Morten Christensen <m...@41concepts.com 
>> > wrote:
>>
>>> I am new to Clojure which I am evaluating using Clojure for a Java 8 
>>> based framework with code in clojure, java and possibly other jvm based 
>>> languages that all need to interoperate.
>>>
>>> Clojure has many smart features which I like but there is at least one 
>>> drawback. I could be wrong (?) but it appears to me that feature-wise it is 
>>> limited to a legacy version of java - Java version 6 from 2008.
>>>
>>> Happily Clojure tolerate running under Java 7/8 but I have found no 
>>> specific support for Java 7/8 features. In particular there is no support 
>>> for NIO 2.0 or interoperability support for @FunctionalInterface, 
>>> java.lang.AutoCloseable, Method parameter reflection, java.util.stream etc. 
>>>
>>> I could do my own Clojure wrapper for NIO 2 but it seems to be quite 
>>> hard for that particular tech (other people in the community have tried 
>>> without being 100% complete and could not find anything that is actively 
>>> maintained). All the other stuff seems like something that need in Clojure 
>>> itself along with invokedynamic and other optimizations. 
>>>
>>> Is there any plans for actively supporting Java 7/8 ?
>>>
>>> /Morten
>>>
>>>
>>> -- 
>>> 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 cl

Re: [ANN] Truss, an assertions lib for Clojure/Script

[James Elliott]

Wow, this feels exactly right. I am eager to start using it, and delighted 
it will be so easy.

On Wednesday, January 13, 2016 at 12:21:53 AM UTC-6, Peter Taoussanis wrote:
>
> BTW have had some folks comment on the length of the video.
>
> This wasn't clear, so will point it out now: if you're looking for a quick 
> overview I'd start with the Quickstart (
> https://github.com/ptaoussanis/truss#quickstart) and examples (
> https://github.com/ptaoussanis/truss#detailed-usage) rather than the talk.
>
> The lib's *really* small and takes 2 seconds to learn - the talk's mostly 
> there to go into motivations behind the lib and its design choices. If that 
> stuff's obvious to you (or not interesting), feel free to just dive in to 
> the examples.
>
> Only warning: the examples are mostly for syntax, not use case. You can 
> certainly use Truss for simple type assertions, but that's rarely where 
> it's most interesting. Personally, I've found it most useful in verifying 
> assumptions about application state and that sort of thing. Or for more 
> subtle type assertions in hairy code (e.g. re: the presence of nils, blank 
> strings, number ranges, specific collection types or counts, conditions 
> w/in `reduce`(or transducer) calls, etc.).
>
> Sweet spot's often in larger and/or more complex code but that's largely 
> to taste.
>
> Litmus test: if you're writing a complex piece of code and you find 
> yourself making implementation choices based on context that's currently 
> clear to you from your understanding of how the application works or the 
> state it'd be in if this code is running - that context might be worth 
> formally capturing in a Truss assertion.
>

-- 
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] Clojure 1.8.0-RC5

[James Elliott]

I’ve done some testing and Afterglow appears to work fine with this latest 
release candidate as well.

On Monday, January 11, 2016 at 8:52:11 AM UTC-6, Alex Miller wrote:
>
> Clojure 1.8.0-RC5 is now available. 
>
> *This is likely the final "release candidate" for 1.8. Please test this 
> build with your libraries and applications and provide feedback as soon as 
> possible. If we have not heard any critical issues, we expect to make this 
> the final release in about a week.*
>
> Try it via:
>
>- Download: 
>https://repo1.maven.org/maven2/org/clojure/clojure/1.8.0-RC5
>- Leiningen: [org.clojure/clojure "1.8.0-RC5"]
>
> Below are the changes since 1.8.0-RC4. See the full 1.8 change log here: 
> https://github.com/clojure/clojure/blob/master/changes.md.
>
>- CLJ-1868  - Fixes 
>regression in the error message returned in the case of a bad return type 
>class
>- CLJ-1829  - Modifies 
>the socket server to avoid an issue with the locking macro in Android
>
>

-- 
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.lang.IllegalArgumentException: Parameter declaration make-response should be a vector

[James Elliott]

Ah, but it actually does make sense now!

> Exception in thread "main" java.lang.IllegalArgumentException: Parameter 
declaration make-response should be a vector, compiling:(server.clj:1:1)

The compiler is complaining about finding "(make-response"… where it was 
looking for a parameter declaration vector in the defn for 
get-stop-response.

If you look further along in the stack trace, you may even find the line 
number in the file where it was trying to compile get-stop-response.

On Sunday, January 10, 2016 at 11:28:17 AM UTC-6, Laws wrote:
>
> Ah, finally found it:
>
> (defn get-stop-response
>   (make-response "No company specified" "Session ended" true))
>
>
> I am surprised that the error was for "make-response" and not 
> "get-stop-response". It is "get-stop-response" where I forgot the parameter 
> declaration. 
>
>
>
> On Sunday, January 10, 2016 at 12:25:57 PM UTC-5, Laws wrote:
>>
>> The implication, as I read it, is that there is some place where I do 
>> something like this: 
>>
>> response-in-amazon-format (make-response company-name 
>> outputSpeech-text false)]
>>
>> In some other function, and the compiler feels that I am defining a new 
>> arity for that other function? But then I would expect to see the name of 
>> the other function.
>>
>>
>> On Sunday, January 10, 2016 at 2:52:48 AM UTC-5, James Elliott wrote:
>>>
>>> That is puzzling indeed. There doesn’t seem to be anything wrong with 
>>> the function itself, as you say. I can evaluate it and run it.
>>>
>>> There must be some other element of your environment which you have not 
>>> shared here which is throwing sand in the gears.
>>>
>>> On Sunday, January 10, 2016 at 1:28:00 AM UTC-6, Laws wrote:
>>>>
>>>> I've been staring at this for awhile, and moving it around, and 
>>>> re-typing it, without seeing what the real error is. 
>>>>
>>>> I have a file called server.clj which includes this at the top in its 
>>>> namespace declaration: 
>>>>
>>>> (ns salesvoice.server
>>>>   (:require
>>>>[salesvoice.query :as query]
>>>>
>>>>
>>>> In query.clj, I have this: 
>>>>
>>>>
>>>> (defn make-response
>>>>   [company-name outputSpeech-text]
>>>>   {"version"  "1.0"
>>>>"sessionAttributes"  {
>>>>  "company-name"  company-name
>>>>  "user-id" "user-id"
>>>>  }
>>>>"response"  {
>>>> "outputSpeech"  {
>>>>  "type"  "PlainText"
>>>>  "text"  outputSpeech-text
>>>>  }
>>>> "card"  {
>>>>  "type"  "Simple"
>>>>  "title"  (str "Sales Report for " company-name)
>>>>  "content"  outputSpeech-text
>>>>  } 
>>>> "reprompt"  {
>>>>  "outputSpeech"  {
>>>>   "type"  "PlainText"
>>>>   "text"  "Can I help you 
>>>> with anything else?"
>>>>   }
>>>>  }
>>>> "shouldEndSession"  true
>>>> }
>>>>})
>>>>
>>>>
>>>> When I type "lein uberjar" at the command line I get: 
>>>>
>>>>
>>>> Exception in thread "main" java.lang.IllegalArgumentException: 
>>>> Parameter declaration make-response should be a vector, 
>>>> compiling:(server.clj:1:1)
>>>>
>>>> The parameter declaration for make-response is a vector. I am not clear 
>>>> why I am getting this error. 
>>>>
>>>> Things I tried:
>>>>
>>>> 1.) moving this around in the file. It had been in the middle of 
>>>> query.clj, but I moved it to the top, its now the first function defined 
>>>> in 
>>>> that file
>>>>
>>>> 2.) re-typing the parameter declaration
>>>>
>>>> 3.) looking for other functions that have the same name, but grep shows 
>>>> this is the only declaration
>>>>
>>>> So what could the real issue be? 
>>>>
>>>> Also, why does the error seem to show up when server.clj is including 
>>>> query.clj. Shouldn't the error appear when query.clj is compiled? 
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>

-- 
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.lang.IllegalArgumentException: Parameter declaration make-response should be a vector

[James Elliott]

That is puzzling indeed. There doesn’t seem to be anything wrong with the 
function itself, as you say. I can evaluate it and run it.

There must be some other element of your environment which you have not 
shared here which is throwing sand in the gears.

On Sunday, January 10, 2016 at 1:28:00 AM UTC-6, Laws wrote:
>
> I've been staring at this for awhile, and moving it around, and re-typing 
> it, without seeing what the real error is. 
>
> I have a file called server.clj which includes this at the top in its 
> namespace declaration: 
>
> (ns salesvoice.server
>   (:require
>[salesvoice.query :as query]
>
>
> In query.clj, I have this: 
>
>
> (defn make-response
>   [company-name outputSpeech-text]
>   {"version"  "1.0"
>"sessionAttributes"  {
>  "company-name"  company-name
>  "user-id" "user-id"
>  }
>"response"  {
> "outputSpeech"  {
>  "type"  "PlainText"
>  "text"  outputSpeech-text
>  }
> "card"  {
>  "type"  "Simple"
>  "title"  (str "Sales Report for " company-name)
>  "content"  outputSpeech-text
>  } 
> "reprompt"  {
>  "outputSpeech"  {
>   "type"  "PlainText"
>   "text"  "Can I help you with 
> anything else?"
>   }
>  }
> "shouldEndSession"  true
> }
>})
>
>
> When I type "lein uberjar" at the command line I get: 
>
>
> Exception in thread "main" java.lang.IllegalArgumentException: Parameter 
> declaration make-response should be a vector, compiling:(server.clj:1:1)
>
> The parameter declaration for make-response is a vector. I am not clear 
> why I am getting this error. 
>
> Things I tried:
>
> 1.) moving this around in the file. It had been in the middle of 
> query.clj, but I moved it to the top, its now the first function defined in 
> that file
>
> 2.) re-typing the parameter declaration
>
> 3.) looking for other functions that have the same name, but grep shows 
> this is the only declaration
>
> So what could the real issue be? 
>
> Also, why does the error seem to show up when server.clj is including 
> query.clj. Shouldn't the error appear when query.clj is compiled? 
>
>
>
>
>
>
>
>
>
>

-- 
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: lein cljsbuild once works, but another build method doesn't -- ?

[James Elliott]

Indeed. If your project has dependencies that are being managed by 
Leiningen, you probably want to use Leiningen to run it (so that the 
classpath can be set properly to include all those dependencies; it can vet 
very long), or tell Leiningen to build an uberjar that embeds both your 
code and all of the dependencies. Then you can run that simply with java 
-jar

https://github.com/technomancy/leiningen/blob/stable/doc/TUTORIAL.md#running-code

https://github.com/technomancy/leiningen/blob/stable/doc/TUTORIAL.md#uberjar

  -James

On Monday, December 28, 2015 at 5:10:35 PM UTC-6, Erik Price wrote:
>
> The -cp flag should be passed a colon-separated list of entires to search 
> for dependency code. Each entry in the list can be either a directory (in 
> which case the contents of the directory must immediately contain Java or 
> Clojure source files) or a JAR file. So the command you’re currently using 
> says “look for dependencies in the cljs.jar file and the src directory”.
>
> Leiningen downloads and locally caches the dependencies you list in your 
> project.clj for you. If you’re sure those dependencies have already been 
> downloaded to your system, try including the paths to those dependencies’ 
> JAR files in your -cp argument.
>
> e
> ​
>
> On Mon, Dec 28, 2015 at 5:54 PM,  wrote:
>
>> hi
>>
>> I have a ClojureScript project. It builds successfully with lein 
>> cljsbuild once and I'm able to run my program on node.
>>
>> I'm trying to follow the QuickStart guide for getting a node REPL.
>>
>> I have node.clj
>> (require 'cljs.build.api)
>>
>> (cljs.build.api/build "src"
>>   {:main 'hello-world.core
>>:output-to "main.js"
>>:target :nodejs})
>>
>> But when I run java -cp cljs.jar:src clojure.main node.clj
>>
>> It says: No such namespace and refers to a dependency that I've listed in 
>> project.clj. Do I need to add something to the -cp argument when I call 
>> java? 
>>
>> Thanks in advance for any help!
>>
>> -- 
>> 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: gen-class: override only 1 method of an arity-overloaded method of a (Java) superclass

[James Elliott]

I don’t have a ton of experience with gen-class, but I think you need to 
tell it to expose the superclass methods you want to call using 
:exposes-methods, as described 
in 
http://stackoverflow.com/questions/9060127/how-to-invoke-superclass-method-in-a-clojure-gen-class-method

In case it is of any use, here is an example of where I successfully 
subclassed a Java class from an external library and called some superclass 
methods: 
https://github.com/brunchboy/afterglow-max/blob/master/src/afterglow/max/Var.clj

On Wednesday, December 23, 2015 at 3:23:41 AM UTC-6, Kurt Sys wrote:
>
> When using gen-class and arity-overloaded methods of a superclass seems 
> not very obvious, or I am missing something...
>
> There's a (java) superclass 'some.Superclass' (which is from a library, so 
> I can't change this one):
>
> public abstract class Superclass {
>public void method() {
>}
>
>public void method(Object something) {
>   this.method();
>   // other logic
>}
> }
>
>
> I want to extend that base (abstract) class in clojure, using gen-class 
> (since the class needs to accessible as a normal Java class). So the first 
> thing I did was:
>
> (ns my.namespace
>   (:gen-class
>:name "my.namespace.ArityTest"
>:extends some.Superclass
>:prefix "some-")
>  )
>
> (defn some-method
>   [this]
>   (println "1-arity"))
>
> However, this doesn't work: 'method' is arity-overloaded, when calling 
> new ArityTest().method(new Object())
>
> I get a ArityException, wrong number of arguments (2). I suppose this is 
> because I override 'method', so I have to override all arities? I'd like to 
> have the 1-arity version to call it's superclass method, and I seem to fail 
> at that. The last attempt is this: get the method of the superclass and 
> call that method on 'this':
>
> (ns be.admb.kbf.vertx.shell.test
> (:gen-class
>   :name "my.namespace.ArityTest"
>   :extends some.Superclass
>   :prefix "some-")
> )
>
>
> (defn some-method
>   ([this]
> (println "1-arity"))
>   ([this o]
> (.invoke (-> this
>  (.getClass)
>  (.getSuperclass)
>  (.getMethod "method"
>  (into-array Class [java.lang.Object])))
>  this (into-array Object [o]))
> ))
>
> This fails: it calls the overriden method, not the superclass' method... 
> (and the method keeps on calling itself).
>
> The question: how do I override only 1 method of an arity-overloaded 
> method of a superclass in Clojure (using gen-class to generate a Java 
> class)?
>

-- 
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] Clojure 1.8.0-RC4 is now available

[James Elliott]

This release candidate appears to be working fine for me, as have the 
previous ones.

On Wednesday, December 16, 2015 at 3:45:21 PM UTC-6, Alex Miller wrote:
>
> Clojure 1.8.0-RC4 is now available. *This build is a "release candidate"!* We 
> would appreciate any and all testing you can do on your own libraries or 
> internal projects to find problems. 
>
> Of particular note, CLJ-1861 removes the interning of unused vars. This 
> change reduces compiled class size (clojure jar is 8% smaller), which 
> reduces classloading time, and thus improves startup time (in some tests 
> ~10-15% faster). Code that uses direct linking (like Clojure core) sees the 
> greatest benefits as most direct-linked vars are unused, but you may also 
> see some benefits with code that is not direct linked as well.  Feedback 
> on startup time or other impacts in actual projects (with or without direct 
> linking) is appreciated.
>
> Try it via
>
>- Download: 
>https://repo1.maven.org/maven2/org/clojure/clojure/1.8.0-RC4
>- Leiningen: [org.clojure/clojure "1.8.0-RC4"]
>
> Below are the changes since 1.8.0-RC3. See the full 1.8 change log here: 
> https://github.com/clojure/clojure/blob/master/changes.md.
>
>- CLJ-1861  - Remove 
>unused var interning
>- CLJ-1161  - Clojure 
>-sources.jar includes a bad properties file in release builds
>- Commit ae7ac 
>
> 
>  - 
>Unrolls the remainder of the Tuple changes from earlier in the release 
>cycle, most significantly rolling back the addition of IMapEntry to 
>APersistentVector
>
>

-- 
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: Clojars maintenance this weekend

[James Elliott]

I second both of those thanks. And what timing, I just happen to be 
catching up on this mailing list right as the upgrade is happening, so I am 
perfectly forewarned. I hope it goes smoothly!

Also, evidence of karma? Shortly after contributing to the Clojars 
Bountysource campaign, I received an unexpected and unsolicited 
contribution for my own open-source project which relies on Clojars. ^_^

  -James

On Wednesday, December 16, 2015 at 9:40:04 PM UTC-6, Devin Walters (devn) 
wrote:
>
> Thanks for the heads up, and for the work you're doing. It is much 
> appreciated.
> On Wed, Dec 16, 2015 at 4:31 PM Toby Crawley  > wrote:
>
>> This weekend I'll be taking clojars.org down to migrate to a larger
>> instance to gain more disk space. The process should take about 45
>> minutes, but I'm blocking out a two hour window just in case. During
>> the migration period, the repo will be completely unavailable.
>>
>> The migration will start at Sunday, December 20, 2015 2:00 AM UTC
>> and last for up to two hours. To see what that time that is in your
>> TZ, visit:
>>
>>   
>> https://www.timeanddate.com/worldclock/fixedtime.html?iso=20151220T02=2
>>
>> I'll announce the start and end of the maintenance on the Clojars
>> twitter account (https://twitter.com/clojars).
>>
>> Let me know if you have any issues or questions.
>>
>> - Toby
>>
>> --
>> 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: [ANN] Clojure 1.8.0-RC3

[James Elliott]

I’ve been working with it for a few days and have seen no issues yet.

On Wednesday, December 2, 2015 at 10:03:31 AM UTC-6, Alex Miller wrote:
>
> Clojure 1.8.0-RC3 is now available. *This build is a "release candidate"!* We 
> would appreciate any and all testing you can do on your own libraries or 
> internal projects to find problems. 
>
> Try it via
>
>- Download: 
>https://repo1.maven.org/maven2/org/clojure/clojure/1.8.0-RC3
>- Leiningen: [org.clojure/clojure "1.8.0-RC3"]
>
> Below are the changes since 1.8.0-RC2. See the full 1.8 change log here: 
> https://github.com/clojure/clojure/blob/master/changes.md.
>
>- CLJ-1845  / CLJ-1851 
> New ^:redef to mark vars 
>that should not be direct linked
>   - The metadata ^:redef can be used to mark function vars that 
>   should not be direct linked
>   - clojure.core/load was previously marked with ^:dynamic for this 
>   purpose, but is now marked ^:redef
>- CLJ-1856  Direct 
>linking breaks clojure.test location reporting for failures
>- CLJ-1854  Set line 
>number in bytecode prior to invokeStatic call
>- CLJ-1853  In socket 
>server, require the ns of the accept-fn before resolving it
>
>

-- 
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: core.async mult "damaged" on reload

[James Elliott]

If I understand what you’re saying, then it sounds like you are reloading a 
protocol definition, which creates a new protocol with the same name as the 
old protocol, but they are different things. Old objects which implement 
the old protocol do not implement the new protocol, even though it looks 
identical and has the same name. This kind of issue has bit me when working 
in iterative development on files, so I tend to protect my protocol 
definitions inside defonce forms, so they do not get redefined when I 
reload the file. It looks awkward, but helps. The example which inspired me 
to do this was in Overtone:
https://github.com/overtone/overtone/blob/master/src/overtone/music/rhythm.clj#L7-L28

  -James

On Friday, November 13, 2015 at 2:50:10 PM UTC-6, Terje Dahl wrote:
>
> I put a core.async/mult instance in a map structure in a map.
> When i do load-file ... (from La Clojure in IntelliJ) the structure with 
> the object instance is still there, but it isn't possible to use.
> I get:
>
>> CompilerException java.lang.IllegalArgumentException: No implementation 
>> of method: :tap* of protocol: #'clojure.core.async/Mult found for class: 
>> clojure.core.async$mult$reify__7262
>>
>
> Is this something to do with core.async itself, or perhaps a more general 
> issue with protocol?
> Any thoughts? 
>

-- 
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: Examples of core.async usage in production?

[James Elliott]

We have as well, for a similar time frame. And, separately, I don’t know if 
you would consider it “production” or “server” since it is a completely 
different realm, but my open-source live-coding environment for creating 
light shows with theatrical lighting hardware uses core.async as well.

On Monday, November 9, 2015 at 5:50:28 PM UTC-6, Derek Troy-West wrote:
>
> We have a number of back-end services which use core.async fairly 
> extensively, some of which have been in production for over a year.
>
> They tend to utilise Netty (Java non-blocking networking framework) to 
> serve/send requests, for example Alia (https://github.com/mpenet/alia) is 
> an excellent Cassandra client which provides a core.async interface.
>
> On Tuesday, October 27, 2015 at 3:26:19 AM UTC+11, juan.facorro wrote:
>>
>> Hi all,
>>
>> From what I've seen/heard/understand core.async has been mostly used in 
>> production on the *client side* or UI programming, since it frees us 
>> from the dreaded callback hell. There are some instances where 
>> *core.async* is used on the *server side* to provide asynchronous 
>> communication between client and server [1][2]; and I wonder how many are 
>> using those libraries/features and how. 
>>
>> I'm sure there are a lot more libraries built on top of *core.async* to 
>> be used on the server, but my question/survey is related to *how many of 
>> those are used in production today*. I have also found some comments 
>> about using Pulsar  as an 
>> alternative for asynchronous message passing scenarios [3][4]. How many of 
>> you have gone that way instead?
>>
>> Looking forward to your comments & replies.
>>
>> Cheers!
>> Juan
>>
>> [1] https://github.com/ptaoussanis/sente
>> [2] https://github.com/bguthrie/async-sockets
>> [3] https://groups.google.com/d/msg/clojure/m6bqGd8vQZQ/hR5rxE4oHSMJ
>> [4] 
>> http://stackoverflow.com/questions/32299299/is-it-safe-to-use-clojure-core-async-in-production-even-though-its-alpha
>>
>

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

Cryptic crashes in Leiningen

[James Elliott]

This weekend I was thrilled to have two people pick up and start 
experimenting with Afterglow, the live-coding light show software I’ve been 
working on this year, and both are new to Clojure as well. Unfortunately 
one is stuck and I am stumped about how to try to help: He’s been able to 
use Afterglow when running it from source, but when he tries including it 
as a library in a new Leiningen project, the attempt to require the 
examples namespace in the REPL, which is the first step in the walkthrough, 
fails in an utterly cryptic way:


(require 'afterglow.examples)

CompilerException java.lang.ExceptionInInitializerError, 
compiling:(afterglow/examples.clj:1:1

There is no stack trace shown, nor a root cause, and this leaves me baffled 
as to how to diagnose it. Starting a new project on my own system works 
fine. Is there a way we can try to load things in smaller pieces and see 
the underlying issues?

I have suggested trying adding the :verbose flag in the require, and we 
will see if that helps any, but I am hoping for some other angles of attack 
too. The issue thread where we are working on this is 
here: https://github.com/brunchboy/afterglow/issues/7

Thanks for any help you can offer me in helping fan these flames of 
interest!

-- 
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: Cryptic crashes in Leiningen

[James Elliott]

Thanks, Gary! Kevin tried a :verbose require, and the last few lines 
involved loading tools.reader and the ExceptionInfo class, so it seems very 
likely that you are correct about the problem. I have suggested trying this 
exclusion, does that look like it might do the trick? (I’m not entirely 
confident of the semantics of Leiningen exclusions and how they propagate 
to recursive dependencies):

  :dependencies [[org.clojure/clojure "1.7.0"]
 [org.clojure/tools.reader "0.10.0"]  ; Or perhaps 1.0.0-alpha1
 [afterglow "0.1.4" :exclusions [org.clojure/tools.reader]]]


On Sunday, November 8, 2015 at 1:17:47 PM UTC-6, Gary Trakhman wrote:
>
> Just a guess, since your project has many dependencies, and I have little 
> time right now, but I had a recent issue with tools.reader <=0.9.2 and the 
> ExceptionInfo class.  The maven artifacts for tools.reader bundled .class 
> files, and triggered this bug: http://dev.clojure.org/jira/browse/CLJ-1639
>
> Our stacktraces looked like this:
> Caused by: java.lang.ExceptionInInitializerError
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:348)
> at clojure.lang.RT.classForName(RT.java:2154)
> at clojure.lang.RT.classForName(RT.java:2163)
> at clojure.lang.RT.loadClassForName(RT.java:2182)
> at clojure.lang.RT.load(RT.java:436)
> at clojure.lang.RT.load(RT.java:412)
> at clojure.core$load$fn__7859.invoke(core.clj:5866)
> at clojure.core$load.doInvoke(core.clj:5865)
> at clojure.lang.RestFn.invoke(RestFn.java:408)
> at clojure.core$load_one.invoke(core.clj:5671)
> at clojure.core$load_lib$fn__7808.invoke(core.clj:5711)
> at clojure.core$load_lib.doInvoke(core.clj:5710)
> at clojure.lang.RestFn.applyTo(RestFn.java:142)
> at clojure.core$apply.invoke(core.clj:632)
> ...
> at 
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.instantiateBean(AbstractAutowireCapableBeanFactory.java:1069)
> ... 32 more
> Caused by: java.lang.RuntimeException: Unable to resolve symbol: init in 
> this context, compiling:(clojure/tools/reader/impl/ExceptionInfo.clj:1:1)
> at clojure.lang.Compiler.analyze(Compiler.java:6543)
> at clojure.lang.Compiler.analyze(Compiler.java:6485)
> at clojure.lang.Compiler$InvokeExpr.parse(Compiler.java:3791)
> at clojure.lang.Compiler.analyzeSeq(Compiler.java:6725)
> at clojure.lang.Compiler.analyze(Compiler.java:6524)
> at clojure.lang.Compiler.analyze(Compiler.java:6485)
> at clojure.lang.Compiler$BodyExpr$Parser.parse(Compiler.java:5861)
> ...
>
> I'm not sure what's causing leiningen to omit the full stacktrace, but 
> it's possible you can get to it with *e from the repl, since you're doing a 
> dynamic require.
>
> In this case, we bumped up to 0.10.0 which no longer had the ExceptionInfo 
> class nor AOT issue.
>
> On Sun, Nov 8, 2015 at 2:10 PM James Elliott <brun...@gmail.com 
> > wrote:
>
>> This weekend I was thrilled to have two people pick up and start 
>> experimenting with Afterglow, the live-coding light show software I’ve been 
>> working on this year, and both are new to Clojure as well. Unfortunately 
>> one is stuck and I am stumped about how to try to help: He’s been able to 
>> use Afterglow when running it from source, but when he tries including it 
>> as a library in a new Leiningen project, the attempt to require the 
>> examples namespace in the REPL, which is the first step in the walkthrough, 
>> fails in an utterly cryptic way:
>>
>>
>> (require 'afterglow.examples)
>>
>> CompilerException java.lang.ExceptionInInitializerError, 
>> compiling:(afterglow/examples.clj:1:1
>>
>> There is no stack trace shown, nor a root cause, and this leaves me 
>> baffled as to how to diagnose it. Starting a new project on my own system 
>> works fine. Is there a way we can try to load things in smaller pieces and 
>> see the underlying issues?
>>
>> I have suggested trying adding the :verbose flag in the require, and we 
>> will see if that helps any, but I am hoping for some other angles of attack 
>> too. The issue thread where we are working on this is here: 
>> https://github.com/brunchboy/afterglow/issues/7
>>
>> Thanks for any help you can offer me in helping fan these flames of 
>> interest!
>>
>> -- 
>> 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 

Re: core.cache limits?

[James Elliott]

And yes, the first time you look at the details of map destructuring for 
optional keyword arguments in Clojure functions it can be a bit confusing, 
but it is such a handy idiom once you get used to it.

On Monday, November 2, 2015 at 5:53:33 PM UTC-6, James Elliott wrote:
>
> If you really do want to set both parameters, you need both to be 
> keywords, i.e:
>
>   (f :s-history-limit 1000 :q-history-limit 1000)
>
> That may have just been a typo in your posting, but I wanted to be sure it 
> was not also in your code.
>
>   -James
>
> On Monday, November 2, 2015 at 5:11:03 PM UTC-6, William la Forge wrote:
>>
>> Solved by repl.
>>
>> (f :s-history-limit 1000 q-history-limit 1000) is what I want.
>>
>> (I'm finding clojure to be a rich language.)
>>
>

-- 
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: core.cache limits?

[James Elliott]

If you really do want to set both parameters, you need both to be keywords, 
i.e:

  (f :s-history-limit 1000 :q-history-limit 1000)

That may have just been a typo in your posting, but I wanted to be sure it 
was not also in your code.

  -James

On Monday, November 2, 2015 at 5:11:03 PM UTC-6, William la Forge wrote:
>
> Solved by repl.
>
> (f :s-history-limit 1000 q-history-limit 1000) is what I want.
>
> (I'm finding clojure to be a rich language.)
>

-- 
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: deprecation warnings?

[James Elliott]

Sweet, I’m starting to really look forward to that release. :D

On Monday, October 19, 2015 at 10:54:04 AM UTC-5, Lars Andersen wrote:
>
> Font-locking of deprecated vars was just added to CIDER.  It's available 
> in snapshots now, and will be included in 0.10.
>
> On Wednesday, October 14, 2015 at 6:09:21 PM UTC+2, William la Forge wrote:
>>
>> Going forward, I'd like to deprecate some functions and have a warning 
>> displayed on first use. So I've done this:
>>
>> (def emptyAAMap ^{:deprecated "0.3.4"}
>>   (new AAMap emptyNode {:comparator RT/DEFAULT_COMPARATOR}))
>>
>>
>> But I am not seeing any warnings from either lein or cursive. Do I need 
>> to add a plugin?
>>
>> 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: [ANN] Leiningen 2.5.3

[James Elliott]

Awesome! I got the Homebrew recipe updated to include this (there were some 
additional changes needed to accommodate their new sandbox mechanism on 
their Continuous Integration server), so now everyone using Homebrew is 
past the GPG issue, and I can be back on their mainline release.

On Monday, September 21, 2015 at 5:04:12 PM UTC-5, Jean Niklas L'orange 
wrote:
>
> Greetings, Clojurians.
>
> I am happy to announce the release of Leiningen version 2.5.3. This version
> contains mostly bugfixes, most notably an issue where environment 
> variables were
> not propagated down to GPG. This caused `lein deploy` and similar commands 
> to
> fail if you set up GPG with the `GPG_AGENT_INFO` environment variable. In
> addition, `lein vcs tag` now supports `--no-sign` if you do not want to 
> sign
> your git tags.
>
> Here's a list of user-visible changes:
>
> ## 2.5.3 / 2015-09-21
>
> * Add CHANGELOG.md to default lein templates. (Daniel Compton)
> * `lein vcs tag` now supports the `--no-sign` flag. (Daniel Compton)
> * Fix a bug where javac errors were not printed to terminal. (Brandon 
> Shimanek)
> * Fix a bug where environment variables were not propagated down to GPG. 
> (Brandon Shimanek)
> * `lein retest` now saves information on which tests that fail. (Shalaka 
> Patil)
>
> For those who manually installed, `lein upgrade` will pull in 2.5.3, and 
> `lein
> downgrade 2.5.2` will bring you back to the previous version if you run 
> into any
> issues.
>
> Thanks to all the contributors who made this happen!
>
> -- 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.

Puzzlement over closing core.async channels asynchronously

[James Elliott]

We’ve been watching Timothy Baldridge’s great O’Reilly video series on 
core.async, but are perplexed by one of the examples. In lecture 14 on 
tuning back-pressure, he introduces a function map-pipe for giving a 
channel a pipeline of work to do, and then as the final step, adds the 
ability to add a level of parallelism. (Later in the series we find out 
that there are more sophisticated tools along these lines already built in 
to core.async, but this example is still interesting.)

I can’t figure out how one aspect of it works, however. Here is the simple 
function:

(defn map-pipe
  ([in out f]
   (map-pipe 0 in out f))
  ([p in out f]
   (dotimes [_ p]
 (go (loop []
   (when-some [v (! out (f v))
 (recur)))
 (close! out)

The idea being that you can supply a level of parallelism by passing in a 
value for p which is greater than 1, and the dotimes will spin up that many 
go blocks working on the channel in parallel. My concern was this: Since 
the close! happens asynchronously on one of those parallel go blocks, 
surely the first instance which finds that in has closed can call (close! 
out) while the other instances are still working on their last task. Won’t 
they then be unable to write their results to the now-closed channel? Or is 
there some subtlety that none of us could figure out which prevents this 
from being an issue?

In writing up this question, though, I noticed another issue. The 
three-argument arity of map-pipe should surely call the four-argument 
version with a p value of 1, not 0, or nothing will ever get processed, 
right? In fact that is what he says while he is editing the code, but ends 
up typing a zero rather than a one. So I am thinking this may have just 
been a quick example that ended up slightly wrong; it is one of the few 
cases in the video series where the code is not run as it is written, so it 
might have just been missed.

But I worry that it is our understanding that is incorrect, not the 
example, so I would appreciate some independent confirmation or correction.

Cheers,
  -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: Puzzlement over closing core.async channels asynchronously

[James Elliott]

Thanks for the rapid response! You could say that you put this in there as 
an exercise for the viewer; I know that in discussing it amongst ourselves, 
we definitely sharpened our understanding of some of the concepts.

I had tried submitting an erratum via O’Reilly before posting to this list, 
but for some reason that feature is not turned on for this video series. It 
is for others, so hopefully they can enable it for you as well.

Cheers,

  -James

On Thursday, September 17, 2015 at 3:54:54 PM UTC-5, tbc++ wrote:
>
> Yes, I'm pretty sure that was a quick-and-dirty example, and I probably 
> should have clarified that in the course. 
>
> You are correct, there is a race condition between the go loops, and that 
> one of them may close the output channel before the others have finished 
> processing their results. Probably better to stick with async/pipeline with 
> a map transducer. 
>
> And yes, the 0 vs 1 thing is a typeo. I'll have to see if there is a way I 
> can submit some errata to O’Reilly. Thanks for the report. 
>
> Timothy Baldridge
>
> On Thu, Sep 17, 2015 at 2:40 PM, James Elliott <brun...@gmail.com 
> > wrote:
>
>> We’ve been watching Timothy Baldridge’s great O’Reilly video series on 
>> core.async, but are perplexed by one of the examples. In lecture 14 on 
>> tuning back-pressure, he introduces a function map-pipe for giving a 
>> channel a pipeline of work to do, and then as the final step, adds the 
>> ability to add a level of parallelism. (Later in the series we find out 
>> that there are more sophisticated tools along these lines already built in 
>> to core.async, but this example is still interesting.)
>>
>> I can’t figure out how one aspect of it works, however. Here is the 
>> simple function:
>>
>> (defn map-pipe
>>   ([in out f]
>>(map-pipe 0 in out f))
>>   ([p in out f]
>>(dotimes [_ p]
>>  (go (loop []
>>(when-some [v (>  (>! out (f v))
>>  (recur)))
>>  (close! out)
>>
>> The idea being that you can supply a level of parallelism by passing in a 
>> value for p which is greater than 1, and the dotimes will spin up that 
>> many go blocks working on the channel in parallel. My concern was this: 
>> Since the close! happens asynchronously on one of those parallel go 
>> blocks, surely the first instance which finds that in has closed can 
>> call (close! out) while the other instances are still working on their 
>> last task. Won’t they then be unable to write their results to the 
>> now-closed channel? Or is there some subtlety that none of us could figure 
>> out which prevents this from being an issue?
>>
>> In writing up this question, though, I noticed another issue. The 
>> three-argument arity of map-pipe should surely call the four-argument 
>> version with a p value of 1, not 0, or nothing will ever get processed, 
>> right? In fact that is what he says while he is editing the code, but ends 
>> up typing a zero rather than a one. So I am thinking this may have just 
>> been a quick example that ended up slightly wrong; it is one of the few 
>> cases in the video series where the code is not run as it is written, so it 
>> might have just been missed.
>>
>> But I worry that it is our understanding that is incorrect, not the 
>> example, so I would appreciate some independent confirmation or correction.
>>
>> Cheers,
>>   -James
>>
>> -- 
>> 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.
>>
>
>
>
> -- 
> “One of the main causes of the fall of the Roman Empire was that–lacking 
> zero–they had no way to indicate successful termination of their C 
> programs.”
> (Robert Firth) 
>

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

Re: cider-error go to line

[James Elliott]

W00t, look at what just was released! :D

https://github.com/clojure/tools.nrepl/commit/64238a10a8465e0c590acb660ec5d54bf7cc3af4

On Friday, July 3, 2015 at 1:59:23 PM UTC-5, Ritchie Cai wrote:
>
> Ah, ha, good to know I'm not crazy. For sure I'm join the voices to push 
> the changes on nrepl side.
>
> Thanks
>
> On Friday, July 3, 2015 at 12:52:20 AM UTC-5, Bozhidar Batsov wrote:
>>
>> This is a problem on nREPL, not CIDER. See 
>> http://dev.clojure.org/jira/browse/NREPL-59 for details.
>>
>> There aren't any real solutions to this, other than fixing nREPL, but 
>> we're considering some workarounds (e.g. trying to find the definition 
>> using a regular expression and using the relative position from there) 
>> https://github.com/clojure-emacs/cider/issues/1175
>>
>> But as I said NREPL-59 has to be fixed eventually, as this is killing us 
>> (and everyone using nREPL), so consider dropping by the issue and voicing 
>> your support for the proposed patch. 
>>
>> On 3 July 2015 at 02:44, Ritchie Cai  wrote:
>>
>>> When I get a cider-error, it tells me line number within the function 
>>> that raised the error, but is there an easy way to go to that line?
>>> Since the line number is within the function, I've been counting lines 
>>> manually at the moment ... getting tired of this.
>>>
>>> Anyone has any suggestions?
>>>
>>> Thanks
>>> Ritchie
>>>
>>> -- 
>>> 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: is there a way I can use a co-worker's uberjar without unpacking it to ./.m2?

[James Elliott]

To hopefully help address another aspect of your question:

This local repo is *not* inside ~/.m2

It is a directory that can be part of your project, and checked into git 
along with it. You just tell Leiningen where to find it using something 
like this:

:repositories {"project" "file:repo"}

And then Leiningen will look for artifacts in the directory "repo" at the 
project root.

So, you do not have to put things into your actual local Maven repository. 
But you *do* have to put artifacts into a properly structured Maven 
repository (even if it is entirely fictitious, using made up artifact names 
and versions), to use them with Leiningen.

I do this in my project afterglow-max, for example, to build against an API 
that is provided by its vendor as a jar file but not as a Maven artifact. 
You can find the full project here, if it helps:

https://github.com/brunchboy/afterglow-max#afterglow-max

I hope this helps!
  -James

On Monday, September 14, 2015 at 3:48:24 AM UTC-5, Ralf Schmitt wrote:
>
> Lawrence Krubner  writes: 
>
> >> lein-localrepo helps with installing jar files into the 
> >> local maven repository 
> > 
> > But they give examples like this: 
> > 
> > lein localrepo install foo-1.0.6.jar com.example/foo 1.0.6 
> > 
> > If I had that info I probably would not need to ask any questions 
> > here. 
>
> I'm using lein localrepo to install a jar file with a completely made up 
> version and group id. you just need to use the same values in 
> project.clj. 
>
> -- 
> Cheers 
> Ralf 
>

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

Filter predicates and side-effects

[James Elliott]

I notice that the documentation for filter and filterv are emphatic that 
the predicate you are using be free of side effects. Why is that so? For 
example, I would like to use filterv to collect a list of lighting effects 
which respond false to a protocol method which asks whether they have 
finished. In the implementation of that method, the effects are free to 
update their internal state based on the current show state and time, when 
deciding whether or not they are finished, and so I can’t guarantee there 
will be no side effects while filtering the effects. Does that mean I can’t 
use filterv? If not, why not? Looking at the source, I see no obvious 
problems.

-- 
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: Filter predicates and side-effects

[James Elliott]

Indeed, that would make sense for filter, but since filterv immediately 
puts them all into a vector, I was particularly puzzled by the warning on 
its doc string.

In my case I am not relying on the side effects for anything, I merely 
cannot guarantee there are none (and even if chunking were an issue, the 
list is immediately fully consumed). So I tentatively think I am ok, but it 
is still an unsettling warning.

On Wednesday, September 2, 2015 at 11:06:01 AM UTC-5, Raymond Huang wrote:
>
> I believe the reason it's not recommended is because it returns a lazy 
> chunked sequence. This means that it's not guaranteed to eagerly perform 
> your side-effects, unless you wrap it in `doall`.
>
> On Wed, Sep 2, 2015 at 8:48 AM, James Elliott <brun...@gmail.com 
> > wrote:
>
>> I notice that the documentation for filter and filterv are emphatic that 
>> the predicate you are using be free of side effects. Why is that so? For 
>> example, I would like to use filterv to collect a list of lighting 
>> effects which respond false to a protocol method which asks whether they 
>> have finished. In the implementation of that method, the effects are free 
>> to update their internal state based on the current show state and time, 
>> when deciding whether or not they are finished, and so I can’t guarantee 
>> there will be no side effects while filtering the effects. Does that mean I 
>> can’t use filterv? If not, why not? Looking at the source, I see no 
>> obvious problems.
>>
>> -- 
>> 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: Live rendering of AsciiDoc files in Chrome browser

[James Elliott]

Wow, thank you, this is fantastic! I have been developing an extensive set 
of AsciiDoc documentation (having been forced to transition from FrameMaker 
to DocBook XML, then driven by its complexity to Markdown, and frustrated 
by its limitations to AsciiDoc), but found it frustrating that I had to 
push my changes up to GitHub in order to see how they were working.

One snag I ran into, in case this helps others: I could not see the “Allow 
access to file URLs” setting in Chrome which is mentioned by the Extension 
as a requirement for it to work properly until I had turned on the 
“Developer mode” checkbox at the top of the Extensions page. People who use 
Chrome regularly have probably already done that, I suppose. :)

  -James

On Wednesday, September 2, 2015 at 2:06:23 PM UTC-5, Alan Thompson wrote:
>
> Hey, 
>
> As you all know, the README files on Github, etc can be formatted using 
> the either AsciiDoc (my favorite) or the older MarkDown format.  However, 
> it is a pain to edit these files in just a plain text editor without a good 
> way of seeing the final, rendered format until you commit and push your 
> latest changes up to GH.
>
> If you haven't seen it yet, there is a Chrome extension named 
> "Asciidoctor.js" that will render both AsciiDoc *and* MarkDown files into 
> HTML right in your browser.  It even features automatic reloading of 
> changes (~2 sec delay) whenever you make a change to the source file.
>
> If you are not already using this or a similar tool, you should give it a 
> try. Enjoy!
>
> Alan
>

-- 
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: Decomplecting Clojure

[James Elliott]

Wow, this is fantastic, I now have a new link to send anyone who asks me 
why I find Clojure valuable. Thanks so much!

As a small return of favor, may I point a few small things that look like 
editing errors?

The last limitation bullet in the JVM section states “The JVM is not design 
with code reloading in mind,” and you probably meant “is not design*ed*”? 
At least, that would read more naturally to me.

The end of the Immutability section reads:

Immutability makes Clojure programs *easy to reason about it*.


I suspect you did not mean to include that final “it”.

In the Principles and Community section, there is a sentence “The standard 
settings apply to your system and are easy to setup since they come modules 
that fit together.” I feel like there is a word or two missing at the end 
there, I am not sure what it is trying to say. Perhaps “come *with*
 modules”?

But again, thanks so much for this wonderful document!

  -James
On Wednesday, August 12, 2015 at 1:52:39 PM UTC-5, Sebastian Bensusan wrote:

 Hi everybody!

 I've written a short post on my interpretation of Clojure. It is meant for 
 people that are curious about the language and want to understand what the 
 language is about.

 http://bensu.github.io/decomplecting_clojure/

 Any feedback is welcome.

 Thanks to the folks at Slack that read the initial draft, specially Jeff 
 Kayser, Colin Fleming, and Viktor Eriksson.

 Best,

 Sebastian


-- 
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: Friendlier deploy rejection messages from Clojars

[James Elliott]

Nice! That will be very helpful.

On Wednesday, August 12, 2015 at 5:50:55 AM UTC-5, Toby Crawley wrote:

 We just deployed some changes to Clojars that should make it more 
 user-friendly when a deployment is rejected due to validation 
 failures. 

 Before this release, when you deployed an artifact that failed 
 validation of its group name, artifact name, or version, or you 
 redeployed a non-snapshot version, you got a non-helpful message from 
 Aether (the underlying lib shared by mvn, lein, and boot): 

 Failed to deploy artifacts: Could not transfer artifact 
 ham:biscuit:pom:0.1.0 from/to local (https://clojars.org/repo/): 
 Access denied to: 
 https://clojars.org/repo/ham/biscuit/0.1.0/biscuit-0.1.0.pom, 
 ReasonPhrase: Forbidden 

 which provides no indication as to why the request was forbidden. 

 The 'ReasonPhrase' is just the HTTP status message from the response, 
 and we now override the default status message with something more 
 useful, so a redeploy now results in: 

 Failed to deploy artifacts: Could not transfer artifact 
 ham:biscuit:pom:0.1.0 from/to local (https://clojars.org/repo/): 
 Access denied to: 
 https://clojars.org/repo/ham/biscuit/0.1.0/biscuit-0.1.0.pom, 
 ReasonPhrase: Forbidden - redeploying non-snapshots is not allowed 
 (see http://git.io/vO2Tg) 

 with similar messages for name or version validation 
 failures. Hopefully this will make it easier to understand the cause 
 of a rejected deployment. 

 If you are using mvn, lein, or boot (or anything else that delegates 
 to Aether), you don't have to do anything to see these new messages. 

 If this causes any issues for you, please let us know: 
 https://github.com/ato/clojars-web/issues. 

 - Toby 


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

[ANN] ola-clojure 0.1.0, Open Lighting Architecture from Clojure

[James Elliott]

In response to an excellent request from the Open Lighting Architecture 
team, I have separated the low-level communication library I developed for 
Afterglow into its own project, ola-clojure 
https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fbrunchboy%2Fola-clojure%23ola-clojuresa=Dsntz=1usg=AFQjCNEwB7r4vsHMlzXLc2TLNSzNIGlsHw,
 cleaned 
it up a bit as befits a standalone effort, and added documentation. Now 
anyone who wants to talk to OLA from Clojure will find it easy.

Afterglow itself is now using this standalone library, and its own build 
process is faster because it no longer needs to generate and compile the 
Google Protocol Buffers Java classes nor the supporting Clojure functions 
that handle all the boilerplate of marshaling and unmarshaling the protobuf 
messages.

And in addition to spawning this lower-level project, Afterglow has also 
inspired a higher-level project, afterglow-max 
https://cycling74.com/toolbox/afterglow-max-control-light-shows-max/, 
which embeds it into Cycling ‘74’s Max https://cycling74.com/, a visual 
data-flow environment for musical and visual experimentation and 
performance.

ola-clojure is on github at 
https://github.com/brunchboy/ola-clojure#ola-clojure

Cheers,

  -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: Clojure beyond Java 6 ?

[James Elliott]

That sounds like a great project. And I know that in the medium to long term, 
even if Clojure continues to support Java 1.6, eventually Apple will stop 
supporting their legacy VM, so I just hope Afterglow will catch on enough by 
then to convince Cycling ’74 to update their MXJ bridge. ;^)

-James

 On Aug 8, 2015, at 13:03, Andrew Oberstar ajobers...@gmail.com wrote:
 
 I may end up in the same incomplete, unmaintained state as the other 
 libraries you've seen, but I'm slowly starting on a Java interop library 
 cljj (https://github.com/ike-tools/ike.cljj 
 https://github.com/ike-tools/ike.cljj).
 
 - AutoCloseable - As James (Reeves) mentioned, clojure.core/with-open meets 
 this need.
 - NIO2 - Standard Java interop is functional, but can be a pain due to the 
 heavy use of varargs in NIO2 APIs. I'd like to wrap this in cljj.
 - Streams - Can add reduce/transduce support by implementing CollReduce 
 protocol. There's not a clean way to support the clojure.core/seq function, 
 that I've seen without wrapping the stream. I plan to support this in cljj.
 - Lambdas - I do find these to be a pain, and had a thread on this list a 
 week or two ago. Right now I'm planning to just have functions/macros to 
 wrap/define methods implementing java.util.function interfaces. Ideally, the 
 compiler would support this better. This is the only one that really would 
 require any change to Clojure itself for better Java 8 support IMO.
 
 I can understand James' (Elliott) desire to keep Java 6 compatibility for 
 platforms that are slower to adopt newer JVMs, but I hope that doesn't become 
 an excuse for Clojure to stay moored to the JVM's past for the long-term.
 
 Andrew Oberstar
 
 On Fri, Aug 7, 2015 at 7:12 AM Morten Christensen m...@41concepts.com 
 mailto:m...@41concepts.com wrote:
 I am new to Clojure which I am evaluating using Clojure for a Java 8 based 
 framework with code in clojure, java and possibly other jvm based languages 
 that all need to interoperate.
 
 Clojure has many smart features which I like but there is at least one 
 drawback. I could be wrong (?) but it appears to me that feature-wise it is 
 limited to a legacy version of java - Java version 6 from 2008.
 
 Happily Clojure tolerate running under Java 7/8 but I have found no specific 
 support for Java 7/8 features. In particular there is no support for NIO 2.0 
 or interoperability support for @FunctionalInterface, 
 java.lang.AutoCloseable, Method parameter reflection, java.util.stream etc. 
 
 I could do my own Clojure wrapper for NIO 2 but it seems to be quite hard for 
 that particular tech (other people in the community have tried without being 
 100% complete and could not find anything that is actively maintained). All 
 the other stuff seems like something that need in Clojure itself along with 
 invokedynamic and other optimizations. 
 
 Is there any plans for actively supporting Java 7/8 ?
 
 /Morten
 
 
 -- 
 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 
 mailto: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 
 mailto:clojure%2bunsubscr...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en 
 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 
 mailto:clojure+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout 
 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 
 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/PjK0kYP1nCs/unsubscribe 
 https://groups.google.com/d/topic/clojure/PjK0kYP1nCs/unsubscribe.
 To unsubscribe from this group and all its topics, send an email to 
 clojure+unsubscr...@googlegroups.com 
 mailto:clojure+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout 
 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

Re: Clojure beyond Java 6 ?

[James Elliott]

This fact has become hugely important for me, as it allowed me to host my 
Clojure-based lighting control system inside Cycling ’74’s Max visual 
data-flow environment for music, synthesis and video. Their Java 
integration on the Mac currently requires the use of the legacy Apple VM, 
which is Java 1.6. I had to fork a couple of libraries Afterglow depends on 
(the ones which included Java source) in order to get them to compile Java 
1.6 compatible classes, but once I had done that, everything worked, and it 
opened the system up to a focused audience of exactly the kind of motivated 
tinkerers that it is aimed at.

I don’t know if or when Cycling ‘74 are going to update MXJ, their Max to 
Java bridge, to be compatible with Oracle JVMs, so I am relieved to hear 
that Clojure is planning to remain compatible with Java 1.6 for a while.

On Friday, August 7, 2015 at 7:51:49 AM UTC-5, Alex Miller wrote:

 The plan for Clojure 1.8 is to retain Java 1.6 support. After that, it is 
 something we will continue evaluating.

 It is possible in some cases to provide jdk-specific features as is done 
 with the fork/join library and a few other things. If you have a specific 
 enhancement request, feel free to file a jira.

 Alex



-- 
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: Complete lack of helpful compilation errors with :gen-class

[James Elliott]

Indeed, I visited the page you cite while trying to pin down this problem. 
However, I am fairly certain that in my case it is a weird side effect, not 
a root cause: I get that message when compiling my Clojure file if I try to 
call a function which is defined later in the file. If I move the function 
definition up before the point where I was calling it, everything compiles 
fine, and no linkage error. No library changes in between the two tests. 
And this only happens when my Clojure file is subclassing a Java object. 
Very, very strange...

On Monday, August 3, 2015 at 12:27:38 AM UTC-5, Mars0i wrote:

 I don't have anything helpful to say, but:  I've often gotten a useful 
 stacktrace from compile-time errors using 'lein compile' with :gen-class.  
 Not always.  Sometimes I have to use the guess-and-comment-out method.  So 
 I think that whatever's happening is not just an issue with compilation of 
 gen-class.  Maybe an issue involving libraries?  This page 
 http://examples.javacodegeeks.com/java-basics/exceptions/java-lang-unsatisfiedlinkerror-how-to-handle-unsatisfied-link-error/
  
 is consistent with that hypothesis.


-- 
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: Complete lack of helpful compilation errors with :gen-class

[James Elliott]

Wow, that is a challenge, Alex! I would have no idea how to even compile a 
project without Leiningen. If I ever am not using 200% of my free time working 
on these projects, I may try to research that. I am afraid it may be some time, 
though. I was just hoping this was a known issue with know solutions.

Thanks,

  -James

 On Aug 3, 2015, at 09:41, Alex Miller a...@puredanger.com wrote:
 
 If you can create a small, reproducible test case (that does not require 
 Leiningen), please file a ticket.
 
 On Monday, August 3, 2015 at 9:27:47 AM UTC-5, James Elliott wrote:
 Indeed, I visited the page you cite while trying to pin down this problem. 
 However, I am fairly certain that in my case it is a weird side effect, not a 
 root cause: I get that message when compiling my Clojure file if I try to 
 call a function which is defined later in the file. If I move the function 
 definition up before the point where I was calling it, everything compiles 
 fine, and no linkage error. No library changes in between the two tests. And 
 this only happens when my Clojure file is subclassing a Java object. Very, 
 very strange...
 
 On Monday, August 3, 2015 at 12:27:38 AM UTC-5, Mars0i wrote:
 I don't have anything helpful to say, but:  I've often gotten a useful 
 stacktrace from compile-time errors using 'lein compile' with :gen-class.  
 Not always.  Sometimes I have to use the guess-and-comment-out method.  So I 
 think that whatever's happening is not just an issue with compilation of 
 gen-class.  Maybe an issue involving libraries?  This page 
 http://examples.javacodegeeks.com/java-basics/exceptions/java-lang-unsatisfiedlinkerror-how-to-handle-unsatisfied-link-error/
  is consistent with that hypothesis.
 
 -- 
 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 
 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/yONboCAt-UA/unsubscribe 
 https://groups.google.com/d/topic/clojure/yONboCAt-UA/unsubscribe.
 To unsubscribe from this group and all its topics, send an email to 
 clojure+unsubscr...@googlegroups.com 
 mailto:clojure+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout 
 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: Complete lack of helpful compilation errors with :gen-class

[James Elliott]

Yay, this is the kind of insight I was hoping for! ^_^

On Monday, August 3, 2015 at 9:49:17 AM UTC-5, Mars0i wrote:

 Ah--if that's the problem, it sounds familiar.  Try doing 'lein clean' 
 before 'lein compile' and see whether you get the same error.  That's 
 assuming you have namespaces/classes listed after :aot in project.clj.  (If 
 not, then I don't think that 'lein compile' is actually doing anything.)


Excellent point, I completely forgot about that (something about spending 
fifty or so hours in the previous three days cranking out code). The only 
time compilation would actually happen, given my project configuration, 
would be in creating the überjar, because that is the only profile which 
has :aot turned on. So I should have not been surprised that my lein 
compile did nothing.
 

 You probably know this, but: When using Java classes, whether defined by 
 gen-class or one of the other four ways to define classes (defrecord, 
 deftype, proxy, reify), Clojure is very persnickety about compilation 
 order.   A class has to be compiled before you can compile something that 
 explicitly references it.  (No cyclic dependencies between explicit 
 references to classes.)


I had not thought in precisely those terms before, but I am definitely used 
to struggling with cyclic dependencies and the Clojure compiler, so I am 
fairly confident that I did not have this issue.

I think, though, that between what you just reminded me about when 
compilation (doesn't) happen, and what Alex is suggesting about running the 
compiler directly, I likely have a workaround. When I get in this state, I 
will try running the compiler directly on just the suspect Clojure file and 
see what it says.

I now strongly suspect the problem is that somewhere in the bowels of 
Leiningen, this output is being discarded.

Thanks,

  -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: Complete lack of helpful compilation errors with :gen-class

[James Elliott]

Thanks, Alex, I will give this a try the next time I run into this. Given a 
little distance from the problem, and the insights that you and Mars0i have 
been sharing, I have a clearer picture of what was going on at compile 
time. I suspect the problem is something along these lines: Leiningen 
invokes the compiler on the file that is supposed to create my class, and 
it fails because of my incorrect ordering of function invocation and 
definition. For reasons unknown, but which if I can pin down better I will 
open as an issue with Leiningen, the output from this failed compilation is 
lost. Then when something tries tor refer to the class which was supposed 
to have been compiled and fails, the linkage error happens.

But now that you have pointed me at a way to just invoke the compiler 
directly on my problem source file, I bet I will be able to see the 
compilation errors when I do that, which will enable me to fix them without 
trial and error. 

Indeed, I just tested that by commenting out one of the functions in my 
source, confirming that Leiningen gives me the cryptic linkage error, and 
tried a manual compile from the REPL, and was given this completely helpful 
compilation error:
 

afterglow.max.core= (compile 'afterglow.max.Metro)

CompilerException java.lang.RuntimeException: Unable to resolve symbol: 
set-bar in this context, compiling:(afterglow/max/Metro.clj:121:7) 


So the next time I screw up, I will be able to figure out how.

Thanks, everyone! Perhaps I should open a Leiningen issue about this now.

Cheers,

  -James

On Monday, August 3, 2015 at 9:59:57 AM UTC-5, Alex Miller wrote:

 You can just use the clojure.core/compile function to compile. There is a 
 simple example at http://clojure.org/compilation.  

 I have not seen or experienced a linkage error like this before and I'm 
 not aware of any ticket like this. Generally a linkage error indicates you 
 are seeing the wrong version of a class loaded by a different classloader.


 On Monday, August 3, 2015 at 9:47:10 AM UTC-5, James Elliott wrote:

 Wow, that is a challenge, Alex! I would have no idea how to even compile 
 a project without Leiningen. If I ever am not using 200% of my free time 
 working on these projects, I may try to research that. I am afraid it may 
 be some time, though. I was just hoping this was a known issue with know 
 solutions.

 Thanks,

   -James

 On Aug 3, 2015, at 09:41, Alex Miller al...@puredanger.com wrote:

 If you can create a small, reproducible test case (that does not require 
 Leiningen), please file a ticket.

 On Monday, August 3, 2015 at 9:27:47 AM UTC-5, James Elliott wrote:

 Indeed, I visited the page you cite while trying to pin down this 
 problem. However, I am fairly certain that in my case it is a weird side 
 effect, not a root cause: I get that message when compiling my Clojure file 
 if I try to call a function which is defined later in the file. If I move 
 the function definition up before the point where I was calling it, 
 everything compiles fine, and no linkage error. No library changes in 
 between the two tests. And this only happens when my Clojure file is 
 subclassing a Java object. Very, very strange...

 On Monday, August 3, 2015 at 12:27:38 AM UTC-5, Mars0i wrote:

 I don't have anything helpful to say, but:  I've often gotten a useful 
 stacktrace from compile-time errors using 'lein compile' with :gen-class.  
 Not always.  Sometimes I have to use the guess-and-comment-out method.  So 
 I think that whatever's happening is not just an issue with compilation of 
 gen-class.  Maybe an issue involving libraries?  This page 
 http://examples.javacodegeeks.com/java-basics/exceptions/java-lang-unsatisfiedlinkerror-how-to-handle-unsatisfied-link-error/
  
 is consistent with that hypothesis.


 -- 
 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 a topic in the 
 Google Groups Clojure group.
 To unsubscribe from this topic, visit 
 https://groups.google.com/d/topic/clojure/yONboCAt-UA/unsubscribe.
 To unsubscribe from this group and all its topics, 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

Complete lack of helpful compilation errors with :gen-class

[James Elliott]

I don't know if this is an issue with the compiler in general, with 
Leiningen more specifically, or something I am doing wrong in trying to use 
them, but I have wasted many hours over the last couple weeks while working 
on afterglow-max https://github.com/brunchboy/afterglow-max#afterglow-max due 
to the fact that when I am compiling a Clojure source file which extends a 
Java class, any little mistake I make while coding gives me the following 
opaque output when I try to compile, rather than the helpful message 
telling me where the problem occurred that I am used to:

lein -U uberjar

Compiling afterglow.max.core

Compiling afterglow.max.Cue

Compiling afterglow.max.Eval

Compiling afterglow.max.init

Compiling afterglow.max.Metro


Exception: java.lang.UnsatisfiedLinkError thrown from the 
UncaughtExceptionHandler in thread main

Compilation failed: Subprocess failed

Uberjar aborting because jar failed: Compilation failed: Subprocess failed

Error encountered performing task 'uberjar' with profile(s): 
'base,system,user,provided,dev,update'

Uberjar aborting because jar failed: Compilation failed: Subprocess failed

Trying to just do a lein compile seems to silently do nothing at all when 
it is in this state. In this case it was because I had called a function 
which was not defined until later in the file. Normally super easy to 
figure out from the compiler error messages, of course!

So I end up having to tediously try commenting out sections of my code 
until I can get it compiling again and then narrow down the problem. I had 
developed a style of making a tiny addition then rebuilding the uberjar to 
avoid this problem (and this is made worse by the fact that the compilation 
process creates futures at some point, due to one of the libraries 
involved, so compilation delays for an extra sixty seconds each time, 
waiting for Clojure's agent thread pool to shut itself down! I can't 
believe that *still* does not use daemon threads)... But this time I was 
writing the final object, which was very similar to others I had already 
written, and forged through until the end until trying to compile, then had 
to spend hours figuring out my simple stupid error.

Has anyone else seen a problem like this? Don't get me wrong, I still think 
Clojure is the best thing going, but it could be better without this 
problem. Is there anything I can do to avoid it, beyond what I already was?

-- 
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 :book] ClojureScript Unraveled

[James Elliott]

This looks like it will be great when I am ready to dive into 
ClojureScript! Thanks for writing it. One quick erratum you may want to 
jump on, since it rather sticks out: The title of Section 4.4 is missing a 
“t” at the end.

On Friday, July 17, 2015 at 12:30:34 PM UTC-5, Alejandro Gómez wrote:

 Hello everybody, 

 I'm happy to announce that Andrey Antoukh (@niwinz) and I published the 
 book about ClojureScript 
 that we have been writing lately on Leanpub. It's not still 100% 
 complete but the sections about 
 the language and compiler are almost done. We'd greatly appreciate any 
 feedback, errata or suggestions 
 for the book. 

 It is an open source book licensed under a Creative Commons BY-SA 
 license and will forever remain 
 free and open to community participation. Publishing it on Leanpub is a 
 convenient way for readers 
 to be notified whenever a new release comes out and not to go through 
 the process of generating the 
 book themselves. If you feel like it and can afford it you can make a 
 donation and buy us a beer too! 

 - Leanpub: https://leanpub.com/clojurescript-unraveled 
 - GitHub repository: https://github.com/funcool/clojurescript-unraveled 
 - HTML version: http://funcool.github.io/clojurescript-unraveled/ 

 Yours, 

 Alejandro 


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

[ANN] Afterglow 0.1.0, an open-source live-coding Clojure environment for light shows

[James Elliott]

I just released version 0.1.0 of Afterglow so that other interested people 
can start exploring it. I simply cannot believe I have been able to create 
a system like this in a couple of months, after being inspired by the 
example of Overtone. Thank you, Clojure community, for making software 
development so powerful and so much fun again!

Interested parties can find the repository 
here: https://github.com/brunchboy/afterglow

From the online manual:

 Afterglow is a lighting controller designed to support live coding 
 https://en.wikipedia.org/wiki/Live_coding, written in Clojure 
 http://clojure.org/, intended to enable people to produce spectacular 
 and highly customizable light shows using modern stage and effect lighting, 
 and which are related in deep ways to the phrasing of music being played. 
 (Its creator http://deepsymmetry.org/ is a DJ and producer of light and 
 laser shows by avocation.) Currently, the lighting effects 
 https://github.com/brunchboy/afterglow/blob/master/doc/effects.adoc#effects
  and fixture definitions 
 https://github.com/brunchboy/afterglow/blob/master/doc/fixture_definitions.adoc#fixture-definitions
  are 
 written and organized through Clojure code, so you will either need to 
 learn Clojure or work with a Clojure programmer to create new ones, but 
 they are controlled through MIDI control surfaces or Open Sound Control, so 
 once they are set up, there is great flexibility in how you can perform 
 them.

 Someday a user interface for building shows and fixture definitions may be 
 created, either within Afterglow, or as a companion project, but that is 
 not currently planned. For now the focus is on building rich user 
 interfaces for controlling shows, such as the Ableton Push mapping 
 https://github.com/brunchboy/afterglow/blob/master/doc/mapping_sync.adoc#using-ableton-push
  and web interface 
 https://github.com/brunchboy/afterglow/blob/master/doc/README.adoc#the-embedded-web-interface,
  
 while using the concise expressive power of Clojure for writing the fixture 
 definitions, effects, and cues.

 Afterglow communicates with the lighting hardware using the Open Lighting 
 Architecture https://www.openlighting.org/ola/, so it supports a wide 
 variety of communication methods and interfaces. Information about installing 
 OLA https://github.com/brunchboy/afterglow#installation is included in 
 the project README https://github.com/brunchboy/afterglow.




-- 
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: cider-error go to line

[James Elliott]

Yes, please comment in support of merging that patch!

On Friday, July 3, 2015 at 12:52:20 AM UTC-5, Bozhidar Batsov wrote:

 This is a problem on nREPL, not CIDER. See 
 http://dev.clojure.org/jira/browse/NREPL-59 for details.

 There aren't any real solutions to this, other than fixing nREPL, but 
 we're considering some workarounds (e.g. trying to find the definition 
 using a regular expression and using the relative position from there) 
 https://github.com/clojure-emacs/cider/issues/1175

 But as I said NREPL-59 has to be fixed eventually, as this is killing us 
 (and everyone using nREPL), so consider dropping by the issue and voicing 
 your support for the proposed patch. 

 On 3 July 2015 at 02:44, Ritchie Cai ritch...@gmail.com javascript: 
 wrote:

 When I get a cider-error, it tells me line number within the function 
 that raised the error, but is there an easy way to go to that line?
 Since the line number is within the function, I've been counting lines 
 manually at the moment ... getting tired of this.

 Anyone has any suggestions?

 Thanks
 Ritchie

  -- 
 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 
 javascript:
 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 javascript:
 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 javascript:.
 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: [ANN] Clojure 1.7.0-RC2

[James Elliott]

After using it all weekend, everything looks good for me. Thanks!

On Wednesday, June 17, 2015 at 12:44:39 PM UTC-5, Alex Miller wrote:

 Clojure 1.7.0-RC2 is now available.

 Try it via
 - Download: https://repo1.maven.org/maven2/org/clojure/clojure/1.7.0-RC2/
 - Leiningen: [org.clojure/clojure 1.7.0-RC2]

 1.7.0-RC2 has the following changes since 1.7.0-RC1:

 1) CLJ-1735 - Throwable-map was missing docstring

 2) CLJ-1237 - reduce gives a StackOverflow for seqs that switch back and 
 forth between chunked and unchunked many times

 This was an old problem that was amplified in 1.7, but has now been fixed.

 3) CLJ-1738 - Seqs over Java iterators that return the same mutating 
 object on every next() call

 Seqs are fundamentally incompatible with Java iterators that return the 
 same mutating object on every call to next().  Some Clojure libraries 
 incorrectly rely on calling seq on such iterators. In 1.7, iterator-seqs 
 are chunked, which will cause many of these incorrect usages to return 
 incorrect results immediately. The `seq` and `iterator-seq` docstrings have 
 been updated to include an explicit warning. Libraries that incorrectly use 
 `seq` and `iterator-seq` will need to be fixed before running against 1.7.

 4) CLJ-1745 - Exceptions thrown from macros wrapped in additional 
 CompilerException

 This was a regression from CLJ-1169 and most of that change has been 
 rolled back.

 For a full list of changes since 1.6.0, see: 
 https://github.com/clojure/clojure/blob/master/changes.md

 Please give it a try and let us know if things are working (or not). The 
 more and quicker feedback we get, the sooner we can release 1.7.0 final!

 - Alex


-- 
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] Clojure 1.7.0-RC2

[James Elliott]

After some quick testing, everything is looking good for me. I will pound 
on it more heavily this weekend, and report back if that changes, although 
I do not expect it to. Thanks!

On Wednesday, June 17, 2015 at 12:44:39 PM UTC-5, Alex Miller wrote:

 Clojure 1.7.0-RC2 is now available.

 Try it via
 - Download: https://repo1.maven.org/maven2/org/clojure/clojure/1.7.0-RC2/
 - Leiningen: [org.clojure/clojure 1.7.0-RC2]

 1.7.0-RC2 has the following changes since 1.7.0-RC1:

 1) CLJ-1735 - Throwable-map was missing docstring

 2) CLJ-1237 - reduce gives a StackOverflow for seqs that switch back and 
 forth between chunked and unchunked many times

 This was an old problem that was amplified in 1.7, but has now been fixed.

 3) CLJ-1738 - Seqs over Java iterators that return the same mutating 
 object on every next() call

 Seqs are fundamentally incompatible with Java iterators that return the 
 same mutating object on every call to next().  Some Clojure libraries 
 incorrectly rely on calling seq on such iterators. In 1.7, iterator-seqs 
 are chunked, which will cause many of these incorrect usages to return 
 incorrect results immediately. The `seq` and `iterator-seq` docstrings have 
 been updated to include an explicit warning. Libraries that incorrectly use 
 `seq` and `iterator-seq` will need to be fixed before running against 1.7.

 4) CLJ-1745 - Exceptions thrown from macros wrapped in additional 
 CompilerException

 This was a regression from CLJ-1169 and most of that change has been 
 rolled back.

 For a full list of changes since 1.6.0, see: 
 https://github.com/clojure/clojure/blob/master/changes.md

 Please give it a try and let us know if things are working (or not). The 
 more and quicker feedback we get, the sooner we can release 1.7.0 final!

 - Alex


-- 
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]: Matcha, a library for composable test assertions with human readable error messages

[James Elliott]

This looks pretty cool! One thing I wonder, though, why am I seeing all 
these \n values rather than actual newlines in the actual value, which 
would make the output so much easier to read? Is there any way to configure 
or use it differently that would avoid this issue? (This is with lein test 
right after adding the dependency to my project.clj and changing one test 
to use matcha). Also, the expected message looks a little broken, should 
it not instead say something like expected: a map with entry :status that 
equals 201? (there is no word between that and 201):

FAIL in (starting-and-stopping-production-server-works-as-expected) 
(httpkit_test.clj:17)

start-production-server causes HttpKit and Hazelcast to start

expected: a map with entry :status that 201

  actual: a map with 200\n class java.lang.Integer\ndiff:\n   +: 
201\n\n   -: 200\n at key :status (was {:orig-content-encoding nil, 
:trace-redirects [\http://localhost:12081/idp/status\;], :request-time 
355, :status 200, :headers {\Date\ \Tue, 26 May 2015 21:36:11 GMT\, 
\Server\ \http-kit\, \Content-Length\ \319\, \Content-Type\ 
\application/json\}, :body \{\\n  \\\status\\\ : \\\up\\\,\\n  
\\\database\\\ : \\\READ FAILED\\\,\\n  \\\build\\\ : 
\\\DEV\\\,\\n  \\\time\\\ : \\\2015-05-26T21:36:11Z\\\,\\n  
\\\loadAverage\\\ : 1.82666015625,\\n  \\\heap\\\ : {\\n
\\\committed\\\ : 476053504,\\n\\\max\\\ : 3817865216,\\n
\\\used\\\ : 277027488\\n  },\\n  \\\nonHeap\\\ : {\\n
\\\committed\\\ : 75104256,\\n\\\max\\\ : -1,\\n\\\used\\\ : 
71632504\\n  }\\n}\})

On Monday, May 25, 2015 at 3:27:13 PM UTC-5, tcrayford wrote:

 Matcha lets you write flexible, composable test assertions with human 
 friendly error messages. It's modeled after the excellent Java Hamcrest 
 library.

 As a quick example, you might build up a matcher that says this map has 5 
 elements, and the :foo key must be greater than 10 like so:

 ```
 (require '[matcha :as m])

 (deftest my-map-test
   (m/is (m/and (m/has-entry-that :foo (m/ 10)) (m/has-count 5))
my-map))
 ```

 If that ever returns false, you'll get an *excellently* readable error 
 message, detailing exactly why it failed.

 Matcha is completely test framework independent, though it does ship with 
 clojure.test support out of the box. Wiring it up to your test framework of 
 choice should take only a few minutes.

 Read more examples here 
 http://yellerapp.com/posts/2015-25-05-matcha.html, grab the code on 
 github https://github.com/yeller/matcha or checkout the api docs 
 http://yeller.github.io/matcha/doc/matcha.html.


-- 
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]: Matcha, a library for composable test assertions with human readable error messages

[James Elliott]

Oh, sorry, here is my actual test:

(m/is (m/has-entry-that :status (m/= 200)) (http/get 
http://localhost:12081/idp/status;))

-- 
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]: Matcha, a library for composable test assertions with human readable error messages

[James Elliott]

The API docs need a little love too... It seems that the examples for 
has-nth are actually for has-count; the second example for both 
has-denominator and has-numerator are actually about nil?, the examples for 
has-key appear to actually be testing the values, not the keys, the 
examples for not are reversed... Actually, rather than make you wade 
through and figure out what I mean, I will just submit a pull request, and 
suggest some improved wording and more disambiguation while I am at it.

Someone will need to double check the examples I came up with for has-nth 
because I came up with them by inspecting the code, and I am new to this 
package.

Also, for clarity, I proposed adding the following example for matcha/every?

  (matcha/run-match (matcha/every? (matcha/= 1)) [])  ; = passes

Is this true? An empty sequence does not have any items which fail, so I 
would expect so.

I am not sure if the isa? documentation is correct. It looks backwards to 
me, but I may just not understand what isa? is trying to test. Which 
suggests it could and should be clarified, at least!

Anyway, please take my suggestions and questions in the spirit in which I 
intend them: Excitement about this new package, and a desire to help it get 
even better!

  -James

On Monday, May 25, 2015 at 3:27:13 PM UTC-5, tcrayford wrote:

 Matcha lets you write flexible, composable test assertions with human 
 friendly error messages. It's modeled after the excellent Java Hamcrest 
 library.

 As a quick example, you might build up a matcher that says this map has 5 
 elements, and the :foo key must be greater than 10 like so:

 ```
 (require '[matcha :as m])

 (deftest my-map-test
   (m/is (m/and (m/has-entry-that :foo (m/ 10)) (m/has-count 5))
my-map))
 ```

 If that ever returns false, you'll get an *excellently* readable error 
 message, detailing exactly why it failed.

 Matcha is completely test framework independent, though it does ship with 
 clojure.test support out of the box. Wiring it up to your test framework of 
 choice should take only a few minutes.

 Read more examples here 
 http://yellerapp.com/posts/2015-25-05-matcha.html, grab the code on 
 github https://github.com/yeller/matcha or checkout the api docs 
 http://yeller.github.io/matcha/doc/matcha.html.


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

[ANN] kibit-helper.el 0.1.1 on melpa.org

[James Elliott]

If you are in the set of Clojure developers who use Emacs and the Kibit 
https://github.com/jonase/kibit Leiningen plugin, you may be interested 
in kibit-helper https://github.com/brunchboy/kibit-helper. I started out 
by submitting a small pull request to Kibit to fix the sample Emacs lisp 
code in their README so the links to your source code when navigating 
errors would work properly, and then added a new command to enable you to 
automatically apply most suggestions from Kibit when you decide you like 
them. At the suggestion of the Kibit maintainers, I moved this out of the 
README and into its own Emacs Lisp package.

So now, if you are already using MELPA, all you need to do is M-x 
package-install kibit-helper. (If you have the old code from the Kibit 
README in your .emacs you will want to remove that and reload Emacs). For 
more information, please see the kibit-helper page on GitHub 
https://github.com/brunchboy/kibit-helper.

Cheers,

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