Re: Rabid wild animals in my clojure argument lists, code gets infected.

[dmichulke]

If you have assertions enabled, you can 

declare

(defn foo [a b & {:keys [c d]}] 
{:pre [c d]}
1)

to make sure that c and d are not nil

(defn foo [a b & {:keys [c d] :as m}] 
{:pre [(every? m [:c :d]]}
1)

to make sure that c and d are contained and

(defn foo [a b & {:keys [c d] :as m}] 
{:pre [(zero? (count (dissoc m :c :d)))]}
1)

to make sure that m contains only :c and :d

It will only complain at run-time but at least it will complain.

On Sunday, August 23, 2015 at 1:34:11 AM UTC+2, Dave Tenny wrote:
>
> I sure wish Clojure would generate "IllegalArgumentException" in the 
> following sample case:
>
> (defn foo [a b & {:keys [c d]}] 1)
> (foo 1 2 :e 5) ; blithely ignores :e 5
>
> I understand that Clojure's destructuring things are very nice, and more 
> powerful than Common Lisp's, and I like
> that when I need it.
>
> However I can't tell you how many times I've been bitten by this. Some 
> simple typo or other other parameter name error on keyword arguments
> with untended and way-too-long-to-debug consequences.
>
> In my mind, on this subject, Common Lisp lambda lists got this right and 
> Clojure gets a poor grade.
> Something about being doomed to repeat history.  In Common Lisp, if you 
> really wanted to allow other (arbitrary) keywords you'd
> just use &allow-other-keys.  
>
> Maybe clojure should only allow the above case to go un-complained-about 
> if :as was specified for the map.
>
> If there's some automatic enforcement I'm missing that comes with 'defn' 
> please let me know, I'm still learning the language.
>
> I've thought more that once about making a common lisp DEFUN statement 
> that maps to DEFN but implements
> lambda list semantics (including 'supplied-p' parameters).  I've just been 
> too lazy to do it.  
>
> It would also likely perform poorly after injecting the additional 
> checks/rearrangements into the function on top of what Clojure has already 
> done,
> so I suppose it would have to be taken a step further so that it didn't 
> generate DEFN expressions at all but was implemented at DEFN's level as 
> a seperately named form.
>
> Tips welcome.  Just thinking aloud.
>
> - Dave
>

-- 
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: Rabid wild animals in my clojure argument lists, code gets infected.

[dmichulke]

Oh and (zero (count x)) is probably less idiomatic than (empty? x)

-- 
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: Rabid wild animals in my clojure argument lists, code gets infected.

[dmichulke]

Sorry, I answered too quickly:

The second one was wrong - this one ensures c and d are contained.

(defn foo [a b & {:keys [c d] :as m}] 
{:pre [(every? (partial contains? m) [:c :d]]}
1)

And the last one was un-idiomatic - this one checks whether only c and d 
are contained.

(defn foo [a b & {:keys [c d] :as m}] 
{:pre [(empty? (dissoc m :c :d))]}
1)


-- 
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: I am looking for xml parsing lib

[Josh Kamau]

Thanks all. clojure.xml/parse worked for me.

On Tue, Aug 25, 2015 at 1:52 AM, Jordan Schatz  wrote:

> Which is the recommended xml parsing lib for clojure?
>
>
> I think you are after clojure.xml/parse
> http://conj.io/store/v1/org.clojure/clojure/1.7.0/clj/clojure.xml/parse/
> and friends:
> http://conj.io/store/v1/org.clojure/clojure/1.7.0/clj/clojure.core/xml-seq/
> http://conj.io/store/v1/org.clojure/clojure/1.7.0/clj/clojure.zip/xml-zip/
>
> - Jordan
>
> On Mon, Aug 24, 2015 at 12:50 PM, blake watson 
> wrote:
>
>> I believe that's it, though.
>>
>> On Mon, Aug 24, 2015 at 10:48 AM, Josh Kamau 
>> wrote:
>>
>>> Hello;
>>>
>>> Which is the recommended xml parsing lib for clojure?
>>>
>>> clojure.data.xml was last updated 10months ago and is still on version
>>> 0.0.8
>>>
>>> Thanks
>>> Josh
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To post to this group, send email to clojure@googlegroups.com
>>> Note that posts from new members are moderated - please be patient with
>>> your first post.
>>> To unsubscribe from this group, send email to
>>> clojure+unsubscr...@googlegroups.com
>>> For more options, visit this group at
>>> http://groups.google.com/group/clojure?hl=en
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to clojure+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

map over a Map with conditional conj

[Sven Richter]

Hi,

I find myself repeating a certain pattern from time to time.

I have a map like this:
{:answer_correct_1 2 :answer_correct_3 4 :foo "bar"}

There is a hidden index answer_correct_idx which might range from 1 to x. 
So, what I want is to "iterate" over the map and produce a vec of maps 
given some other fields like this:
[{:id 123 :answer_correct_1 2} {:id 123 :answer_correct_3 4} ...]

The pattern that I use then is reduce like this:
(reduce
  (fn [a b]
(let [id-correct (keyword (str "answer_correct_" b))]
  (if (id-correct params)
(conj a {:question_id q-id :user_id user-id :answer_id (id-correct 
params)})
a)))
  [] (range 1 11))

If have an if condition inside the reduce and then either conj or return 
the unchanged vec. This works. But I wondered if there is a higher 
abstraction for it and a very nice guy on slack proposed this:

(let [->id (comp keyword (partial str "answer_correct_"))]
(map
  (partial hash-map :question_id q-id :user_id user-id :answer_id)
  (keep
(partial get params)
(map ->id (range 1 11)

It also works, but, regarding readibility I don't think it's easier to get 
(this is subjective of course).

Are there other ways to achieve the same? Maybe something a bit more dense?

Thanks,
Sven

-- 
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] Grenada 1.0.0-rc.2

[zcaudate]

Hey Richard,

Great work on the project! I'd love to see the final generated output if 
you have time to do so. Also, we at Helpshift are working on a similar 
project here - https://github.com/helpshift/hydrox. It'll be great to get 
your input to see how the two libraries compare, what each one potentially 
solves and whether there is synergy for solving the documentation problem.

Chris.


On Wednesday, August 19, 2015 at 1:37:56 PM UTC+5:30, Richard Möhn wrote:
>
> This project was announced three months ago as a ‘Common Clojure Source 
> Metadata Model’. You might also have read about it 
>  
> in the Clojure Gazette. It is now called Grenada 
>  and can be described 
> vaguely as a Clojure metadata build and distribution system. Features:
>
>- for library authors: assemble and publish (API) documentation 
>packages similar to Javadoc JARs, but containing well-defined data instead 
>of HTML.
>- for developers: provide structured information in addition to doc 
>strings. Annotate Clojure objects that don't support doc strings with 
>easily accessible documentation (to be implemented).
>- for documentation editors: jazz up the documentation of existing 
>Clojure libraries; assemble documentation and examples from different 
>sources.
>- for toolsmiths: build on a rigorously flexible model of metadata 
>about things in the Clojure ecosystem
>
> (Taken from the project home page 
> .)
>
> Notable products of the project:
>
>- a data model 
> 
>(can be understood as a draft)
>- lib-grenada , 
>implementing the model and providing convenience
>- the concept of Datadoc JARs – like Javadoc JARs, but instead of HTML 
>containing EDN files with documentation and arbitrary other data 
>- a Leiningen plugin  
>producing and deploying such JARs for your project
>
> Status:
>
>- Everything is usable, though not very convenient at times. If you've 
>read the example of Dorothy the Documenter in the Clojure Gazette 
>interview: what is described there works 
>
>.
>- The documentation is fairly extensive, though not well-organized.
>- The auxiliary library Jolly  
>can be used to convert Grimoire  data to Datadoc JARs 
>.
>- I would be happy if you use the Leiningen plugin to deploy Datadoc 
>JARs for your libraries to Clojars. – Some day there might be an 
>application which displays those data in a way similar to Autodoc or 
> Codox. 
>– The plugin has some issues, though, so don't get wound up.
>
> There's still plenty to do 
> , but 
> I'd be happy if you take a look. Code and history can be found under the 
> Grenada 
> organization  on GitHub.
>
>
> Richard
>

-- 
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: map over a Map with conditional conj

[Moe Aboulkheir]

Sven,

To me, the keep version would be a lot more readable if it were creating a
literal map in a fn.

I think (for) is almost always the right thing.  It's not as fun to write,
but much easier to read:

(for [i (range 1 11)
  :let [id (keyword (str "answer_correct_" i))]
  :when (params id)]
  {:question_id q-id :user_id user-id :answer_id (params id)})

It's possible to shrink the reduce, but I prefer the above.

(reduce
 (fn [acc i]
   (let [id-correct (->> i (str "answer_correct_) keyword params)]
 (cond-> acc id-correct
   (conj {:question_id q-id :user_id user-id :answer_id id-correct}
 [] (range 1 11))

Take care,
Moe

On Tue, Aug 25, 2015 at 9:42 AM, Sven Richter 
wrote:

> Hi,
>
> I find myself repeating a certain pattern from time to time.
>
> I have a map like this:
> {:answer_correct_1 2 :answer_correct_3 4 :foo "bar"}
>
> There is a hidden index answer_correct_idx which might range from 1 to x.
> So, what I want is to "iterate" over the map and produce a vec of maps
> given some other fields like this:
> [{:id 123 :answer_correct_1 2} {:id 123 :answer_correct_3 4} ...]
>
> The pattern that I use then is reduce like this:
> (reduce
>   (fn [a b]
> (let [id-correct (keyword (str "answer_correct_" b))]
>   (if (id-correct params)
> (conj a {:question_id q-id :user_id user-id :answer_id (id-correct
> params)})
> a)))
>   [] (range 1 11))
>
> If have an if condition inside the reduce and then either conj or return
> the unchanged vec. This works. But I wondered if there is a higher
> abstraction for it and a very nice guy on slack proposed this:
>
> (let [->id (comp keyword (partial str "answer_correct_"))]
> (map
>   (partial hash-map :question_id q-id :user_id user-id :answer_id)
>   (keep
> (partial get params)
> (map ->id (range 1 11)
>
> It also works, but, regarding readibility I don't think it's easier to get
> (this is subjective of course).
>
> Are there other ways to achieve the same? Maybe something a bit more dense?
>
> Thanks,
> Sven
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: map over a Map with conditional conj

[Sven Richter]

Hi Moe,

Thanks, i didn't know about :when and :let in for. That is my favorite so 
far, small and readable, looks good.

Sven

Am Dienstag, 25. August 2015 11:17:23 UTC+2 schrieb Moe Aboulkheir:
>
> Sven,
>
> To me, the keep version would be a lot more readable if it were creating a 
> literal map in a fn.
>
> I think (for) is almost always the right thing.  It's not as fun to write, 
> but much easier to read:
>
> (for [i (range 1 11)
>   :let [id (keyword (str "answer_correct_" i))]
>   :when (params id)]
>   {:question_id q-id :user_id user-id :answer_id (params id)})
>
> It's possible to shrink the reduce, but I prefer the above.
>
> (reduce
>  (fn [acc i]
>(let [id-correct (->> i (str "answer_correct_) keyword params)]
>  (cond-> acc id-correct
>(conj {:question_id q-id :user_id user-id :answer_id id-correct}))
> ))
>  [] (range 1 11))
>
> Take care,
> Moe
>
> On Tue, Aug 25, 2015 at 9:42 AM, Sven Richter  > wrote:
>
>> Hi,
>>
>> I find myself repeating a certain pattern from time to time.
>>
>> I have a map like this:
>> {:answer_correct_1 2 :answer_correct_3 4 :foo "bar"}
>>
>> There is a hidden index answer_correct_idx which might range from 1 to x. 
>> So, what I want is to "iterate" over the map and produce a vec of maps 
>> given some other fields like this:
>> [{:id 123 :answer_correct_1 2} {:id 123 :answer_correct_3 4} ...]
>>
>> The pattern that I use then is reduce like this:
>> (reduce
>>   (fn [a b]
>> (let [id-correct (keyword (str "answer_correct_" b))]
>>   (if (id-correct params)
>> (conj a {:question_id q-id :user_id user-id :answer_id 
>> (id-correct 
>> params)})
>> a)))
>>   [] (range 1 11))
>>
>> If have an if condition inside the reduce and then either conj or return 
>> the unchanged vec. This works. But I wondered if there is a higher 
>> abstraction for it and a very nice guy on slack proposed this:
>>
>> (let [->id (comp keyword (partial str "answer_correct_"))]
>> (map
>>   (partial hash-map :question_id q-id :user_id user-id :answer_id)
>>   (keep
>> (partial get params)
>> (map ->id (range 1 11)
>>
>> It also works, but, regarding readibility I don't think it's easier to 
>> get (this is subjective of course).
>>
>> Are there other ways to achieve the same? Maybe something a bit more 
>> dense?
>>
>> Thanks,
>> Sven
>>
>> -- 
>> 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.

top-level lets or private globals

[Kurt Sys]

I'm refering to a few posts in an old thread:
https://groups.google.com/d/msg/clojure/r_ym-h53f1E/RzUdb5oYeX4J

What really puzzles me is that it doesn't seem to be generally 
> regarded as idiomatic Clojure style to just use top-level (let)s for 
> your "private" globals.

 
So, here's the question: what's considered best practice in Clojure (what 
is idiomatic in Clojure): using private (namespace-scoped) globals 
variables or one big let over all (or at least, most) defns in a namespace? 
And why :)?

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

Clojure 1.6 NoClassDefFoundError and a story

[Emin Kura]

Hi,

I'm relatively new to Clojure, maybe this is well known problem please 
excuse me for this. First, let me give some context and then ask the 
question; (maybe it's interesting story for somebody out there )

I was developing remote logger server in Clojure recently. Core.async, 
generally Clojure realms is perfect but I needed some java libraries in the 
process. For example, Netty for handling TCP connections, I've been using 
it for years with Java projects and suddenly It took my one day to start it 
working in Clojure. It was a bug or something else, thanks to this link 
saved my time:

http://blog.quiptiq.com/2013/05/20/porting-the-netty-discardserver-example-to-clojure/

I tried to understand the reason behind it, but I couldn't dig deeper at 
the time. ( It's working but in project I can't use CIDER with emacs 
anymore, but that's ok for now, I made it library for my real project which 
is using it.)

I want to move forward, that was the irrelevant part. Now, I can see my 
logs but in terminal, not formatted or something, it's like using tail 
(full of println 's), let's add some UI part to it. First, I want to listen 
for HTTP on some port and give a web page which renders the result but it 
needs more work to make it like streaming rather than static page. This is 
only for my use and I decided to use simple Java-based UI, but all the 
hassle we all know with Swing and I wondered again the solution was to use 
JavaFX but in a cool way with basic web page (I can style(layout) it 
easily), the solution is WebView. Ok it's easy to setup, let's do that. At 
the time, (one hour ago) I was using Clojure 1.6 (in Java 8 runtime), I can 
run simple things with JavaFX but here is the deal;

(import 'javafx.scene.web.WebEngine)


or 

(Class/forName "javafx.scene.web.WebEngine")



give me;

*NoClassDefFoundError Could not initialize class javafx.scene.web.WebEngine 
>  java.lang.Class.forName0 (Class.java:-2)*



I couldn't figure out first, I dig deeper and found nothing wrong with my 
code. I removed all context (lein, project etc.) and simply downloaded 
clojure from clojure.org and fired up REPL and boom! same thing again. It's 
working with clojure 1.7 (huge relief).

The real question here is I want to understand why and what's different 
from java's Class.forName and Clojure's Class/forName semantic ?


*( By the way, java interop is enough to get things working but from my 
experience it causes a lot of pains in the process, you can see it in two 
big problems in a simple getting started project.  I guess it's not so easy 
for us to get out of Java's hell )*






-- 
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: Cursive and gen-class

[Alex Miller]

Fluid, I agree with Daniel that calling something "junk" is unnecessary, 
especially when the people making and using such a tool are on the list. We 
would like this to be a thoughtful, encouraging forum for discussion.

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.

ANN: s3-wagon-private 1.2.0

[Daniel Compton]

Hi folks

s3-wagon-private  is a
Leiningen plugin which lets you use a private S3 bucket as a Maven repo,
typically for internal artifacts that you don't want to publish to Clojars.
If you are spending any time at all lein installing your coworkers projects
to use their changes, chances are you could benefit from this (or a more
full featured Maven repo).

I've taken over from Phil Hagelberg (technomancy) for maintaining the
s3-wagon-private  plugin
and am happy to announce the release of version 1.2.0
.
Almost all of the work for this was done by Allen Rohner for CircleCI, I've
just merged their fork back into the main project.

The major internal changes in this release are updating the version of
aws-maven used, and replacing Jets3t with the official Amazon S3 client.
This eliminates the noisy logging that you would have seen if you had used
previous versions of s3-wagon-private.

The list of IAM permissions required on your S3 bucket have changed because
of the change in S3 client, they now include:

   - getBucketLocation
   - listObjects
   - getObject
   - getObjectMetadata
   - putObject (when deploying)

You can install it by adding :plugins [[s3-wagon-private "1.2.0"]] to your
project.clj.

At Day8 we've been using the CircleCI fork for a couple of months with
success, but would appreciate any feedback or bug reports from other users
as you upgrade.

Thanks!

P.S. If anyone has an example of the magical incantations required to sign
a Maven pom and jar when deploying to Clojars through Maven, that would be
much appreciated.
-- 
-
Daniel

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

Scripting with Clojure(Script) : plain Clojure ? Node.js ? Boot ? Planck ? Pixie ?

[Khalid Jebbari]

Hi every one,

Just starting this thread to gather feedback from people who used CLJ(S) to 
script and replace, you know, shell/Python/Ruby/Whatever. Pretty sure it's 
a dream to code AND script with CLJ(S). I know that it's possible to do it 
with CLJS backed by Node.js/io.js, with Boot somehow, with plain Clojure, 
with Mike Fikes' Planck (only OSX for now though), and Timothy Baldridge's 
Pixie which is not Clojure but quite close.

If you use any or several, please post your feeback here. It's a nice time 
to CLJ(S) all the things :)

(X-posted in the ClojureScript mailing-list)

-- 
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: Reviewers needed for new Clojure book!

[Brian]

A bit late to the party but please include me in the list of possible
reviews.
thanks,
BDF.


On Tue, Aug 25, 2015 at 12:06 AM, Akhil Wali 
wrote:

> Thank you everyone for the great response!
> I'll notify Packt and they shall contact anyone who is shortlisted as a
> reviwer.
>
>
> On Monday, August 24, 2015 at 12:16:06 PM UTC+5:30, Akhil Wali wrote:
>>
>> If anyone is interested in being a reviewer for a new book "*Mastering
>> Clojure*" by Packt Publishing, please let me know.
>> Reviewers will be entitled to a 6 montn subscription of PacktLib
>> .
>>
>> Here's the list of topics covered in this title.
>>
>>-
>>- Working with Sequences and Types
>>- Orchestrating Concurrency and Parallelism
>>- Parallelization using Reducers
>>- Writing Macros
>>- Composing Transducers
>>- Using Functors and Monads
>>- Programming with Logic
>>- Asynchronous Programming
>>- Reactive Programming
>>- Working with Tests
>>- Troubleshooting and Best Practices
>>
>>
>> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [ANN] io.aviso/rook 0.1.36

[Atamert Ölçgen]

Hi Howard,

In the example application it seems the routing information is encoded in
the beginning of the docstring and not the actual metadata. Is there an
option to put this info in the metadata of the var?

On Mon, Aug 24, 2015 at 6:31 PM, Howard Lewis Ship  wrote:

> Rook is a set of middleware and handlers to enable metadata-based routing
> for Ring web applications.
>
> The intention is to expose a Clojure namespace as a web service resource;
> there’s a default mapping of HTTP verbs and paths to function names; these
> can be extended or overridden by metadata on the functions in the namespace.
>
> The end result is that a compliant web service resource can be created in
> very little code.
>
> Rook also supports Swagger 2.0: a detailed JSON description of your web
> service is generated directly from the functions and metadata.
>
> Recent changes:
>
> * Described more of the APIs using Prismatic Schema
> * Added ability to reuse the argument resolution logic outside of endpoint
> functions
> * Many improvements to the Swagger 2.0 description support
>
> https://github.com/AvisoNovate/rook
>
> --
> Howard M. Lewis Ship
>
> Looking for Clojure engagements: coding, architecture, mentoring & more!
>
> Creator of Apache Tapestry
>
> (971) 678-5210
> http://howardlewisship.com
> @hlship
>
> --
> 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.
>



-- 
Kind Regards,
Atamert Ölçgen

◻◼◻
◻◻◼
◼◼◼

www.muhuk.com

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

Re: Cursive and gen-class

[Fluid Dynamics]

On Tuesday, August 25, 2015 at 8:25:12 AM UTC-4, Alex Miller wrote:
>
> Fluid, I agree with Daniel that calling something "junk" is unnecessary, 
> especially when the people making and using such a tool are on the list. We 
> would like this to be a thoughtful, encouraging forum for discussion.
>
> Alex
>

I seem to recall criticizing a piece of Clojure-relevant *technology* that 
had the rather remarkable property that it could be working, be deleted and 
reinstalled (exact same version), and suddenly be *not* working.

Daniel, on the other hand,  criticized a *person* and moreover his post had 
nothing whatsoever to do with 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: Cursive and gen-class

[Colin Fleming]

On 25 August 2015 at 18:22, Fluid Dynamics  wrote:

> I seem to recall criticizing a piece of Clojure-relevant *technology* that
> had the rather remarkable property that it could be working, be deleted and
> reinstalled (exact same version), and suddenly be *not* working.
>

Except that's not actually what happened. The sequence of events is
difficult to work out from the email chain, but William was trying to
install a version of Cursive into a version of IntelliJ it didn't support.
That never works, and I'm 100% sure that it hadn't worked for him
previously. It's a fairly common mistake that users make when upgrading
IntelliJ for the first time when using Cursive, it's no big deal.


> Daniel, on the other hand,  criticized a *person* and moreover his post
> had nothing whatsoever to do with Clojure.
>

No, he didn't, he criticized the comment you made and said it wasn't
appropriate for the Clojure community, which is very relevant to Clojure.

Personally, I'm pretty confident in the ability of this community to
recognise and disregard uninformed ranting when they see it, so I'm not at
all bothered by 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.
>

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

How to move an element within a vector?

[Hussein B.]

Hi,

For a vector like [A B C D E], how to remove an element to a specific 
location? For example [A D B C E] ?

I thought about converting the vector into array but I would feel bad if I 
did that.

What would be the idiomatic way to do that in Clojure?

Thanks for help and time.

-- 
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: Cursive and gen-class

[Alex Miller]

On Tuesday, August 25, 2015 at 11:23:00 AM UTC-5, Fluid Dynamics wrote:
>
> On Tuesday, August 25, 2015 at 8:25:12 AM UTC-4, Alex Miller wrote:
>>
>> Fluid, I agree with Daniel that calling something "junk" is unnecessary, 
>> especially when the people making and using such a tool are on the list. We 
>> would like this to be a thoughtful, encouraging forum for discussion.
>>
>> Alex
>>
>
> I seem to recall criticizing a piece of Clojure-relevant *technology* that 
> had the rather remarkable property that it could be working, be deleted and 
> reinstalled (exact same version), and suddenly be *not* working.
>

Criticism and discussion of problems is perfectly fine. Throwing insults 
that don't add to that discussion is unnecessary and potentially harmful.
 

> Daniel, on the other hand,  criticized a *person* and moreover his post 
> had nothing whatsoever to do with Clojure.
>

No, Daniel criticized *behavior*. I'm sure you're a fine person. His post 
had to do with the tone of the discussion here and I believe that's 
entirely relevant. 

There are community expectations here for civil discussion and Daniel (and 
now me) are telling you it went a step too far. I know that you have been a 
long time contributor to the list and often provide valuable discussion, 
but sometimes you also cross the line (this is not the first time someone 
has complained). My suggestion would be that you just tone it down a notch 
and we all get back to talking Clojure.

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: Cursive and gen-class

[Colin Yates]

+1, let's keep the Clojure community respectful and welcoming.  This has
been distracting enough already.
On 25 Aug 2015 18:12, "Alex Miller"  wrote:

>
> On Tuesday, August 25, 2015 at 11:23:00 AM UTC-5, Fluid Dynamics wrote:
>>
>> On Tuesday, August 25, 2015 at 8:25:12 AM UTC-4, Alex Miller wrote:
>>>
>>> Fluid, I agree with Daniel that calling something "junk" is unnecessary,
>>> especially when the people making and using such a tool are on the list. We
>>> would like this to be a thoughtful, encouraging forum for discussion.
>>>
>>> Alex
>>>
>>
>> I seem to recall criticizing a piece of Clojure-relevant *technology*
>> that had the rather remarkable property that it could be working, be
>> deleted and reinstalled (exact same version), and suddenly be *not* working.
>>
>
> Criticism and discussion of problems is perfectly fine. Throwing insults
> that don't add to that discussion is unnecessary and potentially harmful.
>
>
>> Daniel, on the other hand,  criticized a *person* and moreover his post
>> had nothing whatsoever to do with Clojure.
>>
>
> No, Daniel criticized *behavior*. I'm sure you're a fine person. His post
> had to do with the tone of the discussion here and I believe that's
> entirely relevant.
>
> There are community expectations here for civil discussion and Daniel (and
> now me) are telling you it went a step too far. I know that you have been a
> long time contributor to the list and often provide valuable discussion,
> but sometimes you also cross the line (this is not the first time someone
> has complained). My suggestion would be that you just tone it down a notch
> and we all get back to talking Clojure.
>
> 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.
>

-- 
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: I am looking for xml parsing lib

[Atamert Ölçgen]

Just a general note: if a library is not updated for X months/years, it
doesn't necessarily mean it's obsolete/totally useless. I sometimes do this
myself too, but I've recently found a library that hasn't been updated for
a looong time and it works perfectly fine.

On Tue, Aug 25, 2015 at 11:31 AM, Josh Kamau  wrote:

> Thanks all. clojure.xml/parse worked for me.
>
> On Tue, Aug 25, 2015 at 1:52 AM, Jordan Schatz 
> wrote:
>
>> Which is the recommended xml parsing lib for clojure?
>>
>>
>> I think you are after clojure.xml/parse
>> http://conj.io/store/v1/org.clojure/clojure/1.7.0/clj/clojure.xml/parse/
>> and friends:
>>
>> http://conj.io/store/v1/org.clojure/clojure/1.7.0/clj/clojure.core/xml-seq/
>> http://conj.io/store/v1/org.clojure/clojure/1.7.0/clj/clojure.zip/xml-zip/
>>
>> - Jordan
>>
>> On Mon, Aug 24, 2015 at 12:50 PM, blake watson 
>> wrote:
>>
>>> I believe that's it, though.
>>>
>>> On Mon, Aug 24, 2015 at 10:48 AM, Josh Kamau 
>>> wrote:
>>>
 Hello;

 Which is the recommended xml parsing lib for clojure?

 clojure.data.xml was last updated 10months ago and is still on version
 0.0.8

 Thanks
 Josh

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

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



-- 
Kind Regards,
Atamert Ölçgen

◻◼◻
◻◻◼
◼◼◼

www.muhuk.com

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

Re: How to move an element within a vector?

[Fluid Dynamics]

On Tuesday, August 25, 2015 at 1:06:30 PM UTC-4, Hussein B. wrote:
>
> Hi,
>
> For a vector like [A B C D E], how to remove an element to a specific 
> location? For example [A D B C E] ?
>

How about (assoc (assoc v j (v i)) i (v j)), once you have the indices i 
and j of two elements you wish to swap?

If you want to actually slide all the other elements to the right, though, 
then vectors are not well designed for that. In fact doing such a move with 
arrays, vectors, *or* lists will take time linear in whichever index is 
larger, the position to move from or the position to move to.

-- 
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: Cursive and gen-class

[Fluid Dynamics]

On Tuesday, August 25, 2015 at 1:05:30 PM UTC-4, Colin Fleming wrote:
>
> On 25 August 2015 at 18:22, Fluid Dynamics  > wrote:
>
>> I seem to recall criticizing a piece of Clojure-relevant *technology* 
>> that had the rather remarkable property that it could be working, be 
>> deleted and reinstalled (exact same version), and suddenly be *not* working.
>>
>
> Except that's not actually what happened. The sequence of events is 
> difficult to work out from the email chain, but William was trying to 
> install a version of Cursive into a version of IntelliJ it didn't support. 
> That never works, and I'm 100% sure that it hadn't worked for him 
> previously.
>

I'm pretty sure he said he uninstalled Cursive, then reinstalled the exact 
same version of Cursive that he had just uninstalled, and it didn't work. 
That clearly is broken behavior. If it was there and working fine before, 
then scrozzled itself, and then reinstalling it made things *worse* instead 
of getting it back into the pre-scrozzled state, then that's broken.
 

-- 
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: Cursive and gen-class

[Niels van Klaveren]

If you had read more attentively, he uninstalled Cursive because he 
suspected a reinstall might fix an error. However, the error was caused 
because in Cursive, an extra step is necessary configuring the project to 
make gen-class work in certain situations, so the unistall was unnecessary.

When reinstalling, he added the wrong update site version when installing 
the plugin, which is why Cursive didn't work. Fixing the update link fixed 
Cursive.

So no problems were caused by Cursive or IntelliJ, just two 
misconfigurations.


On Tuesday, August 25, 2015 at 8:08:16 PM UTC+2, Fluid Dynamics wrote:
>
> On Tuesday, August 25, 2015 at 1:05:30 PM UTC-4, Colin Fleming wrote:
>>
>> On 25 August 2015 at 18:22, Fluid Dynamics  wrote:
>>
>>> I seem to recall criticizing a piece of Clojure-relevant *technology* 
>>> that had the rather remarkable property that it could be working, be 
>>> deleted and reinstalled (exact same version), and suddenly be *not* working.
>>>
>>
>> Except that's not actually what happened. The sequence of events is 
>> difficult to work out from the email chain, but William was trying to 
>> install a version of Cursive into a version of IntelliJ it didn't support. 
>> That never works, and I'm 100% sure that it hadn't worked for him 
>> previously.
>>
>
> I'm pretty sure he said he uninstalled Cursive, then reinstalled the exact 
> same version of Cursive that he had just uninstalled, and it didn't work. 
> That clearly is broken behavior. If it was there and working fine before, 
> then scrozzled itself, and then reinstalling it made things *worse* instead 
> of getting it back into the pre-scrozzled state, then that's broken.
>  
>

-- 
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: Cursive and gen-class

[William la Forge]

Actually what happened is that the cursive plugin continued working even
after I upgraded to idea 14.1. Though obviously I could not reinstall the
same plugin subsequent to that upgrade after an uninstall. At least, I am
pretty sure that that is what happened. :-)

Can we close this thread please?

On Tue, Aug 25, 2015 at 2:23 PM, Niels van Klaveren <
niels.vanklave...@gmail.com> wrote:

> If you had read more attentively, he uninstalled Cursive because he
> suspected a reinstall might fix an error. However, the error was caused
> because in Cursive, an extra step is necessary configuring the project to
> make gen-class work in certain situations, so the unistall was unnecessary.
>
> When reinstalling, he added the wrong update site version when installing
> the plugin, which is why Cursive didn't work. Fixing the update link fixed
> Cursive.
>
> So no problems were caused by Cursive or IntelliJ, just two
> misconfigurations.
>
>
>
> On Tuesday, August 25, 2015 at 8:08:16 PM UTC+2, Fluid Dynamics wrote:
>>
>> On Tuesday, August 25, 2015 at 1:05:30 PM UTC-4, Colin Fleming wrote:
>>>
>>> On 25 August 2015 at 18:22, Fluid Dynamics  wrote:
>>>
 I seem to recall criticizing a piece of Clojure-relevant *technology*
 that had the rather remarkable property that it could be working, be
 deleted and reinstalled (exact same version), and suddenly be *not* 
 working.

>>>
>>> Except that's not actually what happened. The sequence of events is
>>> difficult to work out from the email chain, but William was trying to
>>> install a version of Cursive into a version of IntelliJ it didn't support.
>>> That never works, and I'm 100% sure that it hadn't worked for him
>>> previously.
>>>
>>
>> I'm pretty sure he said he uninstalled Cursive, then reinstalled the
>> exact same version of Cursive that he had just uninstalled, and it didn't
>> work. That clearly is broken behavior. If it was there and working fine
>> before, then scrozzled itself, and then reinstalling it made things *worse*
>> instead of getting it back into the pre-scrozzled state, then that's broken.
>>
>>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "Clojure" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/clojure/rCfF1_Gc_tg/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Reviewers needed for new Clojure book!

[Bryant]

I'd be interested in reviewing this book as well. Thanks!

On Monday, August 24, 2015 at 1:46:06 AM UTC-5, Akhil Wali wrote:
>
> If anyone is interested in being a reviewer for a new book "*Mastering 
> Clojure*" by Packt Publishing, please let me know.
> Reviewers will be entitled to a 6 montn subscription of PacktLib 
> .
>
> Here's the list of topics covered in this title.
>
>- 
>- Working with Sequences and Types
>- Orchestrating Concurrency and Parallelism
>- Parallelization using Reducers
>- Writing Macros
>- Composing Transducers
>- Using Functors and Monads
>- Programming with Logic
>- Asynchronous Programming
>- Reactive Programming
>- Working with Tests
>- Troubleshooting and Best Practices
>
>
>

-- 
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: Cursive and gen-class

[Alan Moore]

I'll second that motion.

A minor point of clarification re my previous comment: the issues with 
Eclipse have nothing to do with CCW as it wasn't even installed. My comment 
was more broadly aimed, lest anyone mistakenly think I was slighting CCW in 
any way.

Moving on...

Alan


On Tuesday, August 25, 2015 at 11:55:56 AM UTC-7, William la Forge wrote:
>
> Actually what happened is that the cursive plugin continued working even 
> after I upgraded to idea 14.1. Though obviously I could not reinstall the 
> same plugin subsequent to that upgrade after an uninstall. At least, I am 
> pretty sure that that is what happened. :-) 
>
> Can we close this thread please?
>
> On Tue, Aug 25, 2015 at 2:23 PM, Niels van Klaveren  > wrote:
>
>> If you had read more attentively, he uninstalled Cursive because he 
>> suspected a reinstall might fix an error. However, the error was caused 
>> because in Cursive, an extra step is necessary configuring the project to 
>> make gen-class work in certain situations, so the unistall was unnecessary.
>>
>> When reinstalling, he added the wrong update site version when installing 
>> the plugin, which is why Cursive didn't work. Fixing the update link fixed 
>> Cursive.
>>
>> So no problems were caused by Cursive or IntelliJ, just two 
>> misconfigurations.
>>
>>
>>
>> On Tuesday, August 25, 2015 at 8:08:16 PM UTC+2, Fluid Dynamics wrote:
>>>
>>> On Tuesday, August 25, 2015 at 1:05:30 PM UTC-4, Colin Fleming wrote:

 On 25 August 2015 at 18:22, Fluid Dynamics  wrote:

> I seem to recall criticizing a piece of Clojure-relevant *technology* 
> that had the rather remarkable property that it could be working, be 
> deleted and reinstalled (exact same version), and suddenly be *not* 
> working.
>

 Except that's not actually what happened. The sequence of events is 
 difficult to work out from the email chain, but William was trying to 
 install a version of Cursive into a version of IntelliJ it didn't support. 
 That never works, and I'm 100% sure that it hadn't worked for him 
 previously.

>>>
>>> I'm pretty sure he said he uninstalled Cursive, then reinstalled the 
>>> exact same version of Cursive that he had just uninstalled, and it didn't 
>>> work. That clearly is broken behavior. If it was there and working fine 
>>> before, then scrozzled itself, and then reinstalling it made things *worse* 
>>> instead of getting it back into the pre-scrozzled state, then that's broken.
>>>  
>>>
>> -- 
>> 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/rCfF1_Gc_tg/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/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: [Meta] Anyone else having trouble with this site recently?

[Chad Harrington]

The site is working fine for me.

In case it's helpful, I have had trouble loading Google sites in the past
when I have inadvertently left my iPhone's personal hotspot turned on while
my computer is connected to both my phone and my home network. The multiple
routes seem to confuse Google's ability to load content. Interestingly,
most other sites worked fine. Turning off my personal hotspot cleared
things up immediately.

No idea if that is a problem you have, but I thought I'd mention it just in
case.

Best regards,


Chad Harrington
chad.harring...@gmail.com

On Mon, Aug 24, 2015 at 10:35 AM, Fluid Dynamics  wrote:

> I'm frequently seeing my browser get stuck at "Transferring data from
> groups.google.com" and then failing to progress further, when refreshing
> the topic list. This has been going on intermittently, but frequently, for
> several days now.
>
> Is anyone else seeing this? What is the fix?
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: top-level lets or private globals

[Alan Thompson]

Ya know, I've never seen that before but I like it!

I have noticed that you can have "naked" expressions in a file (i.e. not
inside of a def/defn).  For example, I use a statement like this:

(require '[tupelo.core :refer [spyx]])
(spyx *clojure-version*)

at the top of my main testing namespace tst.tupelo.core to get:

*clojure-version* => {:major 1, :minor 8, :incremental 0, :qualifier
"alpha4"}

printed


Alan

On Tue, Aug 25, 2015 at 12:06 AM, Kurt Sys  wrote:

> I'm refering to a few posts in an old thread:
> https://groups.google.com/d/msg/clojure/r_ym-h53f1E/RzUdb5oYeX4J
>
> What really puzzles me is that it doesn't seem to be generally
>> regarded as idiomatic Clojure style to just use top-level (let)s for
>> your "private" globals.
>
>
> So, here's the question: what's considered best practice in Clojure (what
> is idiomatic in Clojure): using private (namespace-scoped) globals
> variables or one big let over all (or at least, most) defns in a namespace?
> And why :)?
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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: top-level lets or private globals

[Alan Thompson]

*** premature send ***

Ya know, I've never seen that before but I like it!

I have previously noticed (by accident) that you can have "naked"
expressions in a file/namespace (i.e. not inside of a def/defn).  For
example, I use a statement like this:

(ns ...
  (:require [tupelo.core :refer [spyx]] ...
(spyx *clojure-version*)


at the top of my main testing namespace tst.tupelo.core to get:

*clojure-version* => {:major 1, :minor 8, :incremental 0, :qualifier
"alpha4"}


printed at the top of every test run.  Another favorite is:

(ns ...

  (:require [schema.core :as s] ...

; Prismatic Schema type definitions
(s/set-fn-validation! true)


to control Prismatic Schema in each namespace.

I have also used other naked expressions (in both test and regular
files/namespaces) as a kind of free-form scratchpad when experimenting with
new code (since I can type so much faster in the editor than the repl).

Thanks for the suggestion,
Alan


On Tue, Aug 25, 2015 at 2:19 PM, Alan Thompson  wrote:

> Ya know, I've never seen that before but I like it!
>
> I have noticed that you can have "naked" expressions in a file (i.e. not
> inside of a def/defn).  For example, I use a statement like this:
>
> (require '[tupelo.core :refer [spyx]])
> (spyx *clojure-version*)
>
> at the top of my main testing namespace tst.tupelo.core to get:
>
> *clojure-version* => {:major 1, :minor 8, :incremental 0, :qualifier
> "alpha4"}
>
> printed
>
>
> Alan
>
> On Tue, Aug 25, 2015 at 12:06 AM, Kurt Sys  wrote:
>
>> I'm refering to a few posts in an old thread:
>> https://groups.google.com/d/msg/clojure/r_ym-h53f1E/RzUdb5oYeX4J
>>
>> What really puzzles me is that it doesn't seem to be generally
>>> regarded as idiomatic Clojure style to just use top-level (let)s for
>>> your "private" globals.
>>
>>
>> So, here's the question: what's considered best practice in Clojure (what
>> is idiomatic in Clojure): using private (namespace-scoped) globals
>> variables or one big let over all (or at least, most) defns in a namespace?
>> And why :)?
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
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] - New Clojure Instant Answer on DuckDuckGo

[Rafik NACCACHE]

Hi Guys,

I contributed an Instant Answer to DuckDuckGo.


When you search for "Clojure" with a number of terms, you directly have
under the "software" tab all the packages matching your query from Clojars.

Enjoy !

Rafik

-- 
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] - New Clojure Instant Answer on DuckDuckGo

[Nicolas Herry]

> On 26 Aug 2015, at 00:04, Rafik NACCACHE  wrote:
> 
> Hi Guys,
> 
> I contributed an Instant Answer to DuckDuckGo.
> 
> 
> When you search for "Clojure" with a number of terms, you directly have under 
> the "software" tab all the packages matching your query from Clojars.

Nice ! Very handy, thanks !

Nicolas.

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


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [ANN] - New Clojure Instant Answer on DuckDuckGo

[James Reeves]

Nice work :)

- James

On 25 August 2015 at 23:04, Rafik NACCACHE  wrote:

> Hi Guys,
>
> I contributed an Instant Answer to DuckDuckGo.
>
>
> When you search for "Clojure" with a number of terms, you directly have
> under the "software" tab all the packages matching your query from Clojars.
>
> Enjoy !
>
> Rafik
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [ANN] - New Clojure Instant Answer on DuckDuckGo

[Reid McKenzie]

Nice!

Reid

On 08/25/2015 05:04 PM, Rafik NACCACHE wrote:
> Hi Guys,
>
> I contributed an Instant Answer to DuckDuckGo.
>
>
> When you search for "Clojure" with a number of terms, you directly
> have under the "software" tab all the packages matching your query
> from Clojars.
>
> Enjoy !
>
> Rafik
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient
> with your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to clojure+unsubscr...@googlegroups.com
> .
> For more options, visit https://groups.google.com/d/optout.

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

Re: How to move an element within a vector?

[Georgi Danov]

How about filtering? 
BTW I don't see how it would help converting to array - what would be the 
solution then?

On Tuesday, August 25, 2015 at 7:06:30 PM UTC+2, Hussein B. wrote:
>
> Hi,
>
> For a vector like [A B C D E], how to remove an element to a specific 
> location? For example [A D B C E] ?
>
> I thought about converting the vector into array but I would feel bad if I 
> did that.
>
> What would be the idiomatic way to do that in Clojure?
>
> Thanks for help and time.
>

-- 
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: Reviewers needed for new Clojure book!

[Nicolas Modrzyk]

Hi,

I have reviewed other IT books before and also using clojure on an everyday 
basis.
I would really love to be able to review this new Clojure book. 


Nico

On Monday, August 24, 2015 at 3:46:06 PM UTC+9, Akhil Wali wrote:
>
> If anyone is interested in being a reviewer for a new book "*Mastering 
> Clojure*" by Packt Publishing, please let me know.
> Reviewers will be entitled to a 6 montn subscription of PacktLib 
> .
>
> Here's the list of topics covered in this title.
>
>- 
>- Working with Sequences and Types
>- Orchestrating Concurrency and Parallelism
>- Parallelization using Reducers
>- Writing Macros
>- Composing Transducers
>- Using Functors and Monads
>- Programming with Logic
>- Asynchronous Programming
>- Reactive Programming
>- Working with Tests
>- Troubleshooting and Best Practices
>
>
>

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

Re: How can find something inside heavily nested data structure ?

[Brian Marick]

Dave Tenny wrote:

Specter looks nice.  I didn't see any examples in the readme or tests
for working with more deeply nested data structures such as those
discussed in this thread, any pointers?


Here's an example that might be relevant to the original question. 
Suppose you have this structure:


(def deep {:a [{:b [{:key 33 :uuid "zyx"}]}
   {:b [{:key 4, :uuid "zzz"}]}]})

You want to print out the terminal maps where the `:uuid` is "zyx". You 
can do that like this:


user=> (select [:a ALL :b ALL #(= "zyx" (:uuid %))] deep)
[{:key 33, :uuid "zyx"}]


My `structural-typing` library builds a DSL for sort-of type 
declarations on top of specter. 
https://github.com/marick/structural-typing/ The code is kind of tricksy 
in the parts that use Specter, so I don't know if it'll be of much help.


I plan to propose a short (50 pp.) booklet on specter, to be published 
on Leanpub. I'll announce it on this mailing list shortly, and use 
Leanpub to gauge whether there's enough 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: [ANN] Grenada 1.0.0-rc.2

[Richard Möhn]

Am Dienstag, 25. August 2015 18:11:25 UTC+9 schrieb zcaudate:
>
> […]
> Great work on the project! I'd love to see the final generated output if 
> you have time to do so. Also, we at Helpshift are working on a similar 
> project here - https://github.com/helpshift/hydrox. It'll be great to get 
> your input to see how the two libraries compare, what each one potentially 
> solves and whether there is synergy for solving the documentation problem.
>
> Chris.
>


Hi Chris,

you can download a Datadoc JAR from 
https://clojars.org/repo/org/clojars/rmoehn/clojure/1.7.0+003/clojure-1.7.0+003-datadoc.jar
 
and have a look at its contents. It's pretty bare-bones right now.

Hydrox looks good! (As do your other libraries. – I hadn't had them on my 
radar at all until now.) It appears to be a cool new tack on documentation 
for me. A more expressive alternative to Codox, Autodoc & co. Correct me if 
I oversimplify. What I've developed is a universal container for data about 
Clojure code. You could store Hydrox data in it for distribution and 
digestion by other tools. After the end of the GSoC my schedule is in a 
state confusion, but as soon as this has abated I will have a closer look 
at Hydrox and also include it in my comparison 
(https://github.com/clj-grenada/grenada-spec#comparison).

Regarding the documentation problem (as I see it): Hydrox and Grenada could 
be parts of the solution. Still lacking are conventions for the structure 
of Clojure libraries and documentation, a unified approach to API 
documentation (as opposed to people putting Codox or Autodoc on github.io 
or private pages or nothing at all) and a dedicated search engine for 
Clojure libraries.

I would love to continue working on those things (and Grenada), but first I 
have to wait for feedback from Alex Miller, who was my GSoC mentor, and 
then I need to find some funding.

Richard

-- 
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] ike.cljj 0.2.2

[Andrew Oberstar]

After some lein mishaps, 0.2.2 (which is really 0.2.0) is now available
through Clojars. ike.cljj is meant to support better interop with Java 7/8
APIs (such as Stream and Function).

The sole addition in 0.2.2 is the ike.cljj.file namespace which provides
wrappers for java.nio.file APIs.

https://github.com/ike-tools/ike.cljj

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: [ANN] Grenada 1.0.0-rc.2

[Chris Zheng]

Hey Richard,

Yep, it’s exactly how you’ve described. The main emphasis is on writing 
documentation that can be verified through tests and so if the api changes, 
then the documentation can be fixed accordingly.

The grenada project looks to be very ambitious in it’s scope and yeah, it’ll be 
amazing to have a hoogle-like search engine for clojure.

btw… is datadoc a grenada thing or a java thing?

Chris

> Hi Chris,
> 
> you can download a Datadoc JAR from 
> https://clojars.org/repo/org/clojars/rmoehn/clojure/1.7.0+003/clojure-1.7.0+003-datadoc.jar
>  and have a look at its contents. It's pretty bare-bones right now.
> 
> Hydrox looks good! (As do your other libraries. – I hadn't had them on my 
> radar at all until now.) It appears to be a cool new tack on documentation 
> for me. A more expressive alternative to Codox, Autodoc & co. Correct me if I 
> oversimplify. What I've developed is a universal container for data about 
> Clojure code. You could store Hydrox data in it for distribution and 
> digestion by other tools. After the end of the GSoC my schedule is in a state 
> confusion, but as soon as this has abated I will have a closer look at Hydrox 
> and also include it in my comparison 
> (https://github.com/clj-grenada/grenada-spec#comparison).
> 
> Regarding the documentation problem (as I see it): Hydrox and Grenada could 
> be parts of the solution. Still lacking are conventions for the structure of 
> Clojure libraries and documentation, a unified approach to API documentation 
> (as opposed to people putting Codox or Autodoc on github.io or private pages 
> or nothing at all) and a dedicated search engine for Clojure libraries.
> 
> I would love to continue working on those things (and Grenada), but first I 
> have to wait for feedback from Alex Miller, who was my GSoC mentor, and then 
> I need to find some funding.
> 
> Richard
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en 
> 
> --- 
> You received this message because you are subscribed to a topic in the Google 
> Groups "Clojure" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/clojure/TTO5AfqXXf4/unsubscribe 
> .
> To unsubscribe from this group and all its topics, send an email to 
> clojure+unsubscr...@googlegroups.com 
> .
> For more options, visit https://groups.google.com/d/optout 
> .

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

Re: Reviewers needed for new Clojure book!

[Akhil Wali]

It's great to see so many volunteers for this project!
Like I mentioned earlier, I have notified Packt and they shall contact 
anyone who is shortlisted as a reviewer.

On Monday, August 24, 2015 at 12:16:06 PM UTC+5:30, Akhil Wali wrote:
>
> If anyone is interested in being a reviewer for a new book "*Mastering 
> Clojure*" by Packt Publishing, please let me know.
> Reviewers will be entitled to a 6 montn subscription of PacktLib 
> 
> .
>
> Here's the list of topics covered in this title.
>
>- 
>- Working with Sequences and Types
>- Orchestrating Concurrency and Parallelism
>- Parallelization using Reducers
>- Writing Macros
>- Composing Transducers
>- Using Functors and Monads
>- Programming with Logic
>- Asynchronous Programming
>- Reactive Programming
>- Working with Tests
>- Troubleshooting and Best Practices
>
>
>

-- 
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] Grenada 1.0.0-rc.2

[Richard Möhn]

Am Mittwoch, 26. August 2015 14:52:31 UTC+9 schrieb zcaudate:
>
> […]
> Yep, it’s exactly how you’ve described. The main emphasis is on writing 
> documentation that can be verified through tests and so if the api changes, 
> then the documentation can be fixed accordingly.
>
> The grenada project looks to be very ambitious in it’s scope and yeah, 
> it’ll be amazing to have a hoogle-like search engine for clojure.
>
> btw… is datadoc a grenada thing or a java thing?
>

Datadoc JARs are a way of packaging and exchanging Grenada data. Purely my 
invention. :-P And sorry for the naming confusion; here is a clarification: 
https://github.com/clj-grenada/grenada-spec#names

Hmm, I thought Grenada's isn't too ambitious in its scope. Maybe I didn't 
make it clear. – Currently Grenada is only about the model for Clojure 
metadata (including documentation) and its implementations. Conventions, 
search engine etc. are – like Grenada – part of the way to a better 
ecosystem, but should be separate projects. The so-called roadmap might 
give you a good idea of where Grenada could be going: 
https://github.com/clj-grenada/grenada-spec/blob/devel/roadmap.md

Do you think Hoogle is an example for a good search engine? I just took a 
look. – The search results page is pretty awful. Almost as bad as Clojars 
search. From the functionality perspective something metacpan.org or 
search.cpan.org would be the minimum for me. For the UI I would keep Bret 
Victor's redesign of the amazon.com search in mind.

Richard

-- 
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: top-level lets or private globals

[Kurt Sys]

Well, honestly, I tend to use pretty big lets in my namespaces. I know I 
can use (private) namespace-scoped variables (or rather, contstants :) ) , 
but somehow, I don't really like them. So what I mostly have now:

(ns my.namespece
  (require [other.namespace : as o]
  [cool.namespace :refer [coolyo]]

(defn- silly-function []
  <...>)

(defn- another-variable-independent-function []
  <...>)

(let []
  (defn some-api-function []
<...>)
  (defn call-me-please []
<...>) )

I've put some (private, mostly pretty small) 'helper'-functions outside the 
let-block. I like this kind of construct in some way. It makes a clear 
distinction between:

   1. functions that don't use the 'namespace constants'
   2. helper functions (very often, most of these can be put in a kind of 
   seperate 'utility' namespace, but not always)
   
However, there are some againsts this as well (as slightly discussed in 
other threads), by example:
https://groups.google.com/d/msg/clojure/r_ym-h53f1E/2brnaduLYr4J
https://groups.google.com/d/msg/clojure/r_ym-h53f1E/O-Tvhgqt8lcJ

Instead of putting most stuff inside a big 'let', one could also argue to 
define a bunch of 'globals':
(def ^const ^{:private true} my-constant )
I'm not sure whether it makes a difference to add the ^{private 
true}-metadata, but ^const surely does improve performance, which might be 
important. Anyway, defining a bunch of global constants seems to work quite 
similar to a rather big let. 

I'm just wondering what's idiomatic or considered best practice in Clojure 
(and why) because euh... well, just because I want to know :).



Op dinsdag 25 augustus 2015 23:27:19 UTC+2 schreef Alan Thompson:
>
> *** premature send ***
>
> Ya know, I've never seen that before but I like it!
>
> I have previously noticed (by accident) that you can have "naked" 
> expressions in a file/namespace (i.e. not inside of a def/defn).  For 
> example, I use a statement like this:
>
> (ns ...
>   (:require [tupelo.core :refer [spyx]] ...
> (spyx *clojure-version*)
>
>
> at the top of my main testing namespace tst.tupelo.core to get:
>
> *clojure-version* => {:major 1, :minor 8, :incremental 0, :qualifier 
> "alpha4"}
>
>
> printed at the top of every test run.  Another favorite is:
>
> (ns ...
>
>   (:require [schema.core :as s] ...
>
> ; Prismatic Schema type definitions
> (s/set-fn-validation! true) 
>
>
> to control Prismatic Schema in each namespace.
>
> I have also used other naked expressions (in both test and regular 
> files/namespaces) as a kind of free-form scratchpad when experimenting with 
> new code (since I can type so much faster in the editor than the repl).
>
> Thanks for the suggestion,
> Alan
>  
>
> On Tue, Aug 25, 2015 at 2:19 PM, Alan Thompson  > wrote:
>
>> Ya know, I've never seen that before but I like it!
>>
>> I have noticed that you can have "naked" expressions in a file (i.e. not 
>> inside of a def/defn).  For example, I use a statement like this:
>>
>> (require '[tupelo.core :refer [spyx]])
>> (spyx *clojure-version*)
>>
>> at the top of my main testing namespace tst.tupelo.core to get:
>>
>> *clojure-version* => {:major 1, :minor 8, :incremental 0, :qualifier 
>> "alpha4"}
>>
>> printed
>>
>>
>> Alan
>>
>> On Tue, Aug 25, 2015 at 12:06 AM, Kurt Sys > > wrote:
>>
>>> I'm refering to a few posts in an old thread:
>>> https://groups.google.com/d/msg/clojure/r_ym-h53f1E/RzUdb5oYeX4J
>>>
>>> What really puzzles me is that it doesn't seem to be generally 
 regarded as idiomatic Clojure style to just use top-level (let)s for 
 your "private" globals.
>>>
>>>  
>>> So, here's the question: what's considered best practice in Clojure 
>>> (what is idiomatic in Clojure): using private (namespace-scoped) globals 
>>> variables or one big let over all (or at least, most) defns in a namespace? 
>>> And why :)?
>>>
>>> -- 
>>> 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.

Re: top-level lets or private globals

[Kurt Sys]

**EDIT:
I've put some (private, mostly pretty small) 'helper'-functions outside the 
let-block. I like this kind of construct in some way. It makes a clear 
distinction between:

   1. functions that don't use the 'namespace constants', mostly helper 
   functions (very often, most of these can be put in a kind of seperate 
   'utility' namespace, but not always)
   2. functions that do use the 'namespace constants', mostly the public 
   namespace functions (to be called from another namespace)
   


Op dinsdag 25 augustus 2015 14:14:52 UTC+2 schreef Kurt Sys:
>
> I'm refering to a few posts in an old thread:
> https://groups.google.com/d/msg/clojure/r_ym-h53f1E/RzUdb5oYeX4J
>
> What really puzzles me is that it doesn't seem to be generally 
>> regarded as idiomatic Clojure style to just use top-level (let)s for 
>> your "private" globals.
>
>  
> So, here's the question: what's considered best practice in Clojure (what 
> is idiomatic in Clojure): using private (namespace-scoped) globals 
> variables or one big let over all (or at least, most) defns in a namespace? 
> And why :)?
>

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