Re: JAVA_OPTS not accessible in my Clojure project

[aidy lewis]

Hi Phill,

Thanks for the heads up.

I've entered this in project.clj
:jvm-opts ["javax.net.ssl.keyStore"]

Restarted the CIDER REPL and entered in core.clj

(System/getProperty "javax.net.ssl.keyStore")

I evaluated that expression and it returns nil.

But, if I go to the command-line and at the root of the project type 'lein
repl'

a-project.core=> (System/getProperty "javax.net.ssl.keyStore")

The certificate path is returned

> ./certs/dev.bbc.co.uk.p12\

Many Thanks

Aidy





On 13 January 2014 00:25, Matching Socks  wrote:

> The Leiningen sample project
> https://github.com/technomancy/leiningen/blob/master/sample.project.clj
> refers to a :jvm-opts key and a JVM_OPTS environment variable.
>
>   --
> --
> 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/groups/opt_out.
>



-- 
@AidyLewis

-- 
-- 
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/groups/opt_out.

Re: JAVA_OPTS not accessible in my Clojure project

[Softaddicts]

To set java properties on the cmd line you need to enter something like:

-Djavax.net.ssl.keyStore=value

try

:jvm-opts ["-Djavax.net.ssl.keyStore=full-spec-of-your-file"]

Luc P.

> Hi Phill,
> 
> Thanks for the heads up.
> 
> I've entered this in project.clj
> :jvm-opts ["javax.net.ssl.keyStore"]
> 
> Restarted the CIDER REPL and entered in core.clj
> 
> (System/getProperty "javax.net.ssl.keyStore")
> 
> I evaluated that expression and it returns nil.
> 
> But, if I go to the command-line and at the root of the project type 'lein
> repl'
> 
> a-project.core=> (System/getProperty "javax.net.ssl.keyStore")
> 
> The certificate path is returned
> 
> > ./certs/dev.bbc.co.uk.p12\
> 
> Many Thanks
> 
> Aidy
> 
> 
> 
> 
> 
> On 13 January 2014 00:25, Matching Socks  wrote:
> 
> > The Leiningen sample project
> > https://github.com/technomancy/leiningen/blob/master/sample.project.clj
> > refers to a :jvm-opts key and a JVM_OPTS environment variable.
> >
> >   --
> > --
> > 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/groups/opt_out.
> >
> 
> 
> 
> -- 
> @AidyLewis
> 
> -- 
> -- 
> 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/groups/opt_out.
> 
--
Softaddicts sent by ibisMail from my ipad!

-- 
-- 
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/groups/opt_out.

>! on channels that are not yet closed

[t x]

Hi,

  I have the following problem:

  I have a set of channels #{ ... }

  some of the channels are closed, some of the channels are open

  * for the channels that are open, I want to (>! chan msg)

  * for the channels that are closed, I want to remove the channel from the
hash-set


## Problems:

(1) (>! ... ...) always returns nil, regardless of whether the channel is
open or closed, and thus useless

(2) I could use (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/groups/opt_out.

[ANN] Simbase: A vector similarity database

[Mingli Yuan]

Hi, folks,

We just release an alpha version of Simbase, a vector similarity database
that talks redis protocol. Since it is the first version of all its
releases, we decided to keep it in alpha right now, for we want to hear
from the community for any comments and improvements.

Github page
--

https://github.com/guokr/simbase

We introduce the basic idea, limitations, build process and commands there.

Background
--

Simbase is a tool we developed during the process we revise our content
recommendation engine.

Our document set have 300k docs, and we use LDA to change them into
vectors. But how to compare the 300k vectors was a problem for us then. We
had tried different method, but the performance is not very good.

Since the comparison logic is quit simple, we decided to write a new data
store to do the tricks.

So far, we are satisfied by its performance. Under the setting of an i7
MacBook and 120k 1k-dimensional vector set:

   - write: about 1 ops per second
   - read: up to 1k ops per second

The real read performance may be higher than the current result, because
our testing method is limited.

Regards,

Mingli

-- 
-- 
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/groups/opt_out.

Re: >! on channels that are not yet closed

[t x]

Is there anyway, to "pierce the deftype"

https://github.com/clojure/core.async/blob/master/src/main/clojure/clojure/core/async/impl/channels.clj#L31

to read the "closed" field of the ManytoMany Channel?

That's basically all I need to do.


On Mon, Jan 13, 2014 at 1:47 AM, t x  wrote:

> Hi,
>
>   I have the following problem:
>
>   I have a set of channels #{ ... }
>
>   some of the channels are closed, some of the channels are open
>
>   * for the channels that are open, I want to (>! chan msg)
>
>   * for the channels that are closed, I want to remove the channel from
> the hash-set
>
>
> ## Problems:
>
> (1) (>! ... ...) always returns nil, regardless of whether the channel is
> open or closed, and thus useless
>
> (2) I could use ( then would remove an item from the channel, which I don't want to do
>
>
> ## Question:
>
> Thus, without changing the state of the channel, is there a way to see if
> the channel is open/closed?
>
> Thanks!
>

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

Re: >! on channels that are not yet closed

[t x]

(let [c (async/chan 10)]
  (println @(.-closed c))
  (async/close! c)
  (println @(.-closed c)))


And we're done. Sorry for the spam. Last message send in case someone finds
my question via Google.


On Mon, Jan 13, 2014 at 2:11 AM, t x  wrote:

> Is there anyway, to "pierce the deftype"
>
>
> https://github.com/clojure/core.async/blob/master/src/main/clojure/clojure/core/async/impl/channels.clj#L31
>
> to read the "closed" field of the ManytoMany Channel?
>
> That's basically all I need to do.
>
>
> On Mon, Jan 13, 2014 at 1:47 AM, t x  wrote:
>
>> Hi,
>>
>>   I have the following problem:
>>
>>   I have a set of channels #{ ... }
>>
>>   some of the channels are closed, some of the channels are open
>>
>>   * for the channels that are open, I want to (>! chan msg)
>>
>>   * for the channels that are closed, I want to remove the channel from
>> the hash-set
>>
>>
>> ## Problems:
>>
>> (1) (>! ... ...) always returns nil, regardless of whether the channel is
>> open or closed, and thus useless
>>
>> (2) I could use (> but then would remove an item from the channel, which I don't want to do
>>
>>
>> ## Question:
>>
>> Thus, without changing the state of the channel, is there a way to see if
>> the channel is open/closed?
>>
>> Thanks!
>>
>
>

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

Re: JAVA_OPTS not accessible in my Clojure project

[aidy lewis]

Hi Softaddicts

Thanks for the advice, but my aim was to retrieve the JAVA_OPTS from my
environment variables in order to not hard-code them.

Aidy


On 13 January 2014 09:46, Softaddicts  wrote:

> To set java properties on the cmd line you need to enter something like:
>
> -Djavax.net.ssl.keyStore=value
>
> try
>
> :jvm-opts ["-Djavax.net.ssl.keyStore=full-spec-of-your-file"]
>
> Luc P.
>
> > Hi Phill,
> >
> > Thanks for the heads up.
> >
> > I've entered this in project.clj
> > :jvm-opts ["javax.net.ssl.keyStore"]
> >
> > Restarted the CIDER REPL and entered in core.clj
> >
> > (System/getProperty "javax.net.ssl.keyStore")
> >
> > I evaluated that expression and it returns nil.
> >
> > But, if I go to the command-line and at the root of the project type
> 'lein
> > repl'
> >
> > a-project.core=> (System/getProperty "javax.net.ssl.keyStore")
> >
> > The certificate path is returned
> >
> > > ./certs/dev.bbc.co.uk.p12\
> >
> > Many Thanks
> >
> > Aidy
> >
> >
> >
> >
> >
> > On 13 January 2014 00:25, Matching Socks  wrote:
> >
> > > The Leiningen sample project
> > >
> https://github.com/technomancy/leiningen/blob/master/sample.project.clj
> > > refers to a :jvm-opts key and a JVM_OPTS environment variable.
> > >
> > >   --
> > > --
> > > 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/groups/opt_out.
> > >
> >
> >
> >
> > --
> > @AidyLewis
> >
> > --
> > --
> > 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/groups/opt_out.
> >
> --
> Softaddicts sent by ibisMail from my ipad!
>
> --
> --
> 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/groups/opt_out.
>



-- 
@AidyLewis

-- 
-- 
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/groups/opt_out.

Re: JAVA_OPTS not accessible in my Clojure project

[aidy lewis]

The problem - if anyone is interested - is that I had not set $JAVA_OPTS in
the Emacs config file.

Sorry, for being a balloon.

Thanks

Aidy


On 13 January 2014 10:34, aidy lewis  wrote:

> Hi Softaddicts
>
> Thanks for the advice, but my aim was to retrieve the JAVA_OPTS from my
> environment variables in order to not hard-code them.
>
> Aidy
>
>
> On 13 January 2014 09:46, Softaddicts  wrote:
>
>> To set java properties on the cmd line you need to enter something like:
>>
>> -Djavax.net.ssl.keyStore=value
>>
>> try
>>
>> :jvm-opts ["-Djavax.net.ssl.keyStore=full-spec-of-your-file"]
>>
>> Luc P.
>>
>> > Hi Phill,
>> >
>> > Thanks for the heads up.
>> >
>> > I've entered this in project.clj
>> > :jvm-opts ["javax.net.ssl.keyStore"]
>> >
>> > Restarted the CIDER REPL and entered in core.clj
>> >
>> > (System/getProperty "javax.net.ssl.keyStore")
>> >
>> > I evaluated that expression and it returns nil.
>> >
>> > But, if I go to the command-line and at the root of the project type
>> 'lein
>> > repl'
>> >
>> > a-project.core=> (System/getProperty "javax.net.ssl.keyStore")
>> >
>> > The certificate path is returned
>> >
>> > > ./certs/dev.bbc.co.uk.p12\
>> >
>> > Many Thanks
>> >
>> > Aidy
>> >
>> >
>> >
>> >
>> >
>> > On 13 January 2014 00:25, Matching Socks  wrote:
>> >
>> > > The Leiningen sample project
>> > >
>> https://github.com/technomancy/leiningen/blob/master/sample.project.clj
>> > > refers to a :jvm-opts key and a JVM_OPTS environment variable.
>> > >
>> > >   --
>> > > --
>> > > 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/groups/opt_out.
>> > >
>> >
>> >
>> >
>> > --
>> > @AidyLewis
>> >
>> > --
>> > --
>> > 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/groups/opt_out.
>> >
>> --
>> Softaddicts sent by ibisMail from my ipad!
>>
>> --
>> --
>> 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/groups/opt_out.
>>
>
>
>
> --
> @AidyLewis
>



-- 
@AidyLewis

-- 
-- 
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/groups/opt_out.

How to handle configuration in Clojure?

[James Trunk]

I've been investigating how to handle configuration in a Clojure 
application/library, and have discovered two main candidates: dynamics vars 
and argument passing.

The downsides to dynamic vars seem to be: hiddenness, thread safety, and 
more complex tests (binding before each test).

The downside to argument passing is noise in the code (especially when 
you're just passing the config through). Longer and more descriptive names 
for the config (i.e. not "ctx" or "cfg") make this noise even more painful.

Are there any alternatives that I've missed? What is the current best 
practice for handling configuration?

Cheers,
James

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

Re: ClojureScript integration with Emacs/Cider ?

[Gary Trakhman]

I've released a cljs port of clojure-complete:

Here's the mailing list announcement, also inlined.

https://groups.google.com/forum/#!topic/clojurescript/Dt1s4laHFXc
cljs-complete, A Clojure library designed to auto-complete clojurescript 
based on cljs compiler state.

- With leiningen:
 [cljs-complete "0.1.0"]

- Usage

;; env is pulled from cljs compiler state
=> (completions @cljs.env/*compiler* "al" 'cljs.core)
("alength" "alter-meta!")

This is meant to hook into piggieback, that'll be the next thing I try. I 
hope I can get some help with the hairy emacs bits :-).


On Tuesday, January 7, 2014 1:54:27 AM UTC-5, Bozhidar Batsov wrote:
>
> I'm cider's maintainer. The problem with code completion for ClojureScript 
> is that the default mechanism is based on the Clojure-only library 
> https://github.com/ninjudd/clojure-complete. As I don't use ClojureScript 
> I haven't paid much attention to it so far. If there is a similar library 
> for ClojureScript I might add support for it. Btw, cider will also pick up 
> any nREPL middleware that provides a "complete" op - if there is a 
> ClojureScript nREPL completion middleware it can be used with cider even 
> now. Ideally at some point we'll have unified middleware supporting both 
> Clojure & ClojureScript.
>
> On Sunday, January 5, 2014 10:30:44 PM UTC+2, Alexandru Nedelcu wrote:
>>
>> Hi,
>>
>> I can’t get auto-completion or jumping to the definition of a function in 
>> Emacs, while working with ClojureScript. Is this a limitation of Emacs’ 
>> Cider  plugin?
>>
>> I managed to get nRepl working by using the awesome 
>> com.cemerick/austinplugin for lein 
>> (besides including the plugin in 
>> project.clj I’ve got no other special configuration). So to work with 
>> ClojureScript, from inside an nRepl session, I execute the following (not 
>> sure if this is right):
>>
>> (cemerick.austin.repls/exec :exec-cmds ["google-chrome"])
>>
>> In Emacs I do the same thing, by first starting the repl with 
>> cider-jack-in and then I execute the above command. Compiling the 
>> current buffer works (C-c C-k), I can also send expressions for evaluation 
>> to the repl (C-x C-e).
>>
>> However, as I said, auto-completion doesn’t work and neither does jumping 
>> to the definition of a function. Is there any way to get these features 
>> while working with ClojureScript in Emacs? Or maybe in another IDE?
>>
>> Thanks,
>> -- 
>> Alexandru Nedelcu
>> www.bionicspirit.com
>>
>> PGP Public Key:
>> https://bionicspirit.com/key.aexpk 
>>
>

-- 
-- 
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/groups/opt_out.

Re: ANN: cljson, for faster browser deserialization

[Murtaza Husain]

Alan,

I am exploring what option to use for exchanging data between my server and 
client. EDN and Cljson are two of the options. What are the pros / cons of 
using cljson over edn ?

What was the motive in creating this library ?

Thanks,
Murtaza

On Tuesday, June 25, 2013 12:58:11 AM UTC+5:30, Alan Dipert wrote:
>
> Glad you enjoy!  And yes, totally into the cljson->clj [map data] arity.
> Alan
>
> On Monday, June 24, 2013 1:50:00 PM UTC-4, Thomas Heller wrote:
>>
>> Hey,
>>
>> this looks pretty sweet! I stuck with EDN for now but its way too slow, 
>> so I'm gonna give this a shot.
>>
>> One thing: I'm don't think its the best idea to fall back to 
>> *default-data-readers*, would you be open to adding a second argument to 
>> 'cljson->clj which takes a map specifying readers? eg. (cljson->clj 
>> {:readers {"my.ns/test" my-reader-fn}} json-string), basically the same API 
>> as clojure.edn/read?
>>
>> Thanks,
>> /thomas
>>
>>
>>
>> On Monday, June 24, 2013 7:23:26 PM UTC+2, Alan Dipert wrote:
>>>
>>> Hi all,
>>> I'm pleased to announce the release of cljson 1.0.0, a Clojure and 
>>> ClojureScript data serialization library designed for maximal Clojure data 
>>> deserialization speed in the browser: 
>>> https://github.com/tailrecursion/cljson.  cljson was designed to take 
>>> advantage of the native JSON parsing facilities most browsers provide.
>>>
>>> cljson provides clj->cljson and cljson->clj functions on both platforms. 
>>>  cljson->clj on ClojureScript is roughly 5-6x faster than 
>>> cljs.reader/read-string, and cljson data is roughly 10% fatter on the wire 
>>> than EDN. 
>>>
>>> Thanks in advance for your feedback and contributions!
>>>
>>> Alan
>>>
>>

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

Re: ClojureScript integration with Emacs/Cider ?

[Gary Trakhman]

On talking to Chas,
https://github.com/cemerick/piggieback/issues/22

it seems like the right approach is to reify ac-nrepl's use of eval into a
real "complete" op, and reimplement it to use that, then a common
middleware can either use clojure's environment (clojure-complete) or
piggieback's compiler state to implement the appropriate auto-complete
based on the active repl.

The issue here is that clojure's auto-complete takes the JVM state as an
implicit parameter, whereas cljs-complete requires an 'env' arg that has to
come from somewhere (piggieback has a var that keeps track of repl session
state).  Ac-nrepl shouldn't be able to eval code, that means it's being
coupled to the JVM state, which won't do for cljs or other sorts of
repls-on-repls.



On Mon, Jan 13, 2014 at 9:03 AM, Gary Trakhman wrote:

> I've released a cljs port of clojure-complete:
>
> Here's the mailing list announcement, also inlined.
>
> https://groups.google.com/forum/#!topic/clojurescript/Dt1s4laHFXc
> cljs-complete, A Clojure library designed to auto-complete clojurescript
> based on cljs compiler state.
>
> - With leiningen:
>  [cljs-complete "0.1.0"]
>
> - Usage
>
> ;; env is pulled from cljs compiler state
> => (completions @cljs.env/*compiler* "al" 'cljs.core)
> ("alength" "alter-meta!")
>
> This is meant to hook into piggieback, that'll be the next thing I try. I
> hope I can get some help with the hairy emacs bits :-).
>
>
> On Tuesday, January 7, 2014 1:54:27 AM UTC-5, Bozhidar Batsov wrote:
>>
>> I'm cider's maintainer. The problem with code completion for
>> ClojureScript is that the default mechanism is based on the Clojure-only
>> library https://github.com/ninjudd/clojure-complete. As I don't use
>> ClojureScript I haven't paid much attention to it so far. If there is a
>> similar library for ClojureScript I might add support for it. Btw, cider
>> will also pick up any nREPL middleware that provides a "complete" op - if
>> there is a ClojureScript nREPL completion middleware it can be used with
>> cider even now. Ideally at some point we'll have unified middleware
>> supporting both Clojure & ClojureScript.
>>
>> On Sunday, January 5, 2014 10:30:44 PM UTC+2, Alexandru Nedelcu wrote:
>>>
>>> Hi,
>>>
>>> I can’t get auto-completion or jumping to the definition of a function
>>> in Emacs, while working with ClojureScript. Is this a limitation of Emacs’
>>> Cider  plugin?
>>>
>>> I managed to get nRepl working by using the awesome 
>>> com.cemerick/austinplugin for lein 
>>> (besides including the plugin in
>>> project.clj I’ve got no other special configuration). So to work with
>>> ClojureScript, from inside an nRepl session, I execute the following (not
>>> sure if this is right):
>>>
>>> (cemerick.austin.repls/exec :exec-cmds ["google-chrome"])
>>>
>>> In Emacs I do the same thing, by first starting the repl with
>>> cider-jack-in and then I execute the above command. Compiling the
>>> current buffer works (C-c C-k), I can also send expressions for evaluation
>>> to the repl (C-x C-e).
>>>
>>> However, as I said, auto-completion doesn’t work and neither does
>>> jumping to the definition of a function. Is there any way to get these
>>> features while working with ClojureScript in Emacs? Or maybe in another IDE?
>>>
>>> Thanks,
>>> --
>>> Alexandru Nedelcu
>>> www.bionicspirit.com
>>>
>>> PGP Public Key:
>>> https://bionicspirit.com/key.aexpk
>>>
>>  --
> --
> 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/groups/opt_out.
>

-- 
-- 
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/groups/opt_out.

Re: ClojureScript integration with Emacs/Cider ?

[Bozhidar Batsov]

Cider’s completion understands a `complete` op, so the middleware is the best 
approach if you ask me. The only reason that there’s also an eval based 
completion mechanism (the one used by default) is that clojure-complete is 
present as a REPLy (which is used by lein) dependency and many newcomers have 
absolutely no idea what an nREPL middleware is. Unfortunately it’s hard to 
balance initial easy of setup and good design decisions.  

--  
Cheers,
Bozhidar


On Monday, January 13, 2014 at 4:55 PM, Gary Trakhman wrote:

> On talking to Chas,  
> https://github.com/cemerick/piggieback/issues/22
>  
> it seems like the right approach is to reify ac-nrepl's use of eval into a 
> real "complete" op, and reimplement it to use that, then a common middleware 
> can either use clojure's environment (clojure-complete) or piggieback's 
> compiler state to implement the appropriate auto-complete based on the active 
> repl.  
>  
> The issue here is that clojure's auto-complete takes the JVM state as an 
> implicit parameter, whereas cljs-complete requires an 'env' arg that has to 
> come from somewhere (piggieback has a var that keeps track of repl session 
> state).  Ac-nrepl shouldn't be able to eval code, that means it's being 
> coupled to the JVM state, which won't do for cljs or other sorts of 
> repls-on-repls.  
>   
>  
>  
>  
> On Mon, Jan 13, 2014 at 9:03 AM, Gary Trakhman  (mailto:gary.trakh...@gmail.com)> wrote:
> > I've released a cljs port of clojure-complete:
> >  
> > Here's the mailing list announcement, also inlined.  
> >  
> > https://groups.google.com/forum/#!topic/clojurescript/Dt1s4laHFXc
> > cljs-complete, A Clojure library designed to auto-complete clojurescript 
> > based on cljs compiler state.
> >  
> > - With leiningen:
> >  [cljs-complete "0.1.0"]
> >  
> > - Usage
> >  
> > ;; env is pulled from cljs compiler state
> > => (completions @cljs.env/*compiler* "al" 'cljs.core)
> > ("alength" "alter-meta!")
> >  
> > This is meant to hook into piggieback, that'll be the next thing I try. I 
> > hope I can get some help with the hairy emacs bits :-).
> >  
> >  
> > On Tuesday, January 7, 2014 1:54:27 AM UTC-5, Bozhidar Batsov wrote:
> > > I'm cider's maintainer. The problem with code completion for 
> > > ClojureScript is that the default mechanism is based on the Clojure-only 
> > > library https://github.com/ninjudd/clojure-complete. As I don't use 
> > > ClojureScript I haven't paid much attention to it so far. If there is a 
> > > similar library for ClojureScript I might add support for it. Btw, cider 
> > > will also pick up any nREPL middleware that provides a "complete" op - if 
> > > there is a ClojureScript nREPL completion middleware it can be used with 
> > > cider even now. Ideally at some point we'll have unified middleware 
> > > supporting both Clojure & ClojureScript.
> > >  
> > > On Sunday, January 5, 2014 10:30:44 PM UTC+2, Alexandru Nedelcu wrote:
> > > >  
> > > > Hi,
> > > >  
> > > >  
> > > > I can’t get auto-completion or jumping to the definition of a function 
> > > > in Emacs, while working with ClojureScript. Is this a limitation of 
> > > > Emacs’ Cider (https://github.com/clojure-emacs/cider) plugin?
> > > >  
> > > >  
> > > > I managed to get nRepl working by using the awesome com.cemerick/austin 
> > > > (https://github.com/cemerick/austin) plugin for lein (besides including 
> > > > the plugin in project.clj I’ve got no other special configuration). So 
> > > > to work with ClojureScript, from inside an nRepl session, I execute the 
> > > > following (not sure if this is right):
> > > >  
> > > > (cemerick.austin.repls/exec :exec-cmds ["google-chrome"])
> > > >  
> > > > In Emacs I do the same thing, by first starting the repl with 
> > > > cider-jack-in and then I execute the above command. Compiling the 
> > > > current buffer works (C-c C-k), I can also send expressions for 
> > > > evaluation to the repl (C-x C-e).
> > > >  
> > > >  
> > > > However, as I said, auto-completion doesn’t work and neither does 
> > > > jumping to the definition of a function. Is there any way to get these 
> > > > features while working with ClojureScript in Emacs? Or maybe in another 
> > > > IDE?
> > > >  
> > > >  
> > > > Thanks,
> > > >  
> > > >  
> > > > --  
> > > > Alexandru Nedelcu
> > > > www.bionicspirit.com (http://www.bionicspirit.com)
> > > >  
> > > > PGP Public Key:
> > > > https://bionicspirit.com/key.aexpk  
> >  
> > --  
> > --  
> > You received this message because you are subscribed to the Google
> > Groups "Clojure" group.
> > To post to this group, send email to clojure@googlegroups.com 
> > (mailto:clojure@googlegroups.com)
> > Note that posts from new members are moderated - please be patient with 
> > your first post.
> > To unsubscribe from this group, send email to
> > clojure+unsubscr...@googlegroups.com 
> > (mailto:clojure%2bunsubscr...@googlegroups.com)
> > For more options, visit this group at
> > http://groups.google.com/group

Re: How to handle configuration in Clojure?

[Josh Smith]

On Monday, January 13, 2014 8:50:54 AM UTC-5, James Trunk wrote:
>
> I've been investigating how to handle configuration in a Clojure 
> application/library, and have discovered two main candidates: dynamics vars 
> and argument passing.
>

I would suggest you add Environment variables to your list.Also,  check 
out the 12 factor app (especially the parts about configuration).   
http://12factor.net/config

I use env vars for most things in my clojure deploys, and it's easy to 
manage/move/everything.  YMMV.

-jbs

-- 
-- 
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/groups/opt_out.

Re: How to handle configuration in Clojure?

[Josh Glover]

On 13 January 2014 14:50, James Trunk  wrote:

> What is the current best practice for handling configuration?

While I haven't tried this myself, this popped up on Planet Clojure a
couple of days back:

http://tech.puredanger.com/2014/01/03/clojure-dependency-injection/

Whilst DI is not precisely config management, the pattern described in
the blog seems applicable.

Cheers,
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/groups/opt_out.

A question about lazy seq with io

[Kashyap CK]

Hi,
I've been dabbling with Clojure for a bit and I am really loving it!!!

I am trying to write a clojure program to download a bunch of URLs and I 
was wondering what is the right way to do it - 
My current implementation is as follows

(def url-sequence (map #(str "http://www.mysite.com/list.php?pageID="; %) 
(range)))

(def download
  (loop [urls url-sequence lst []]
(let
[
 u (first urls)
 r (rest urls)
 resp (client/get u)
 next (re-find #"(s?)title=\"next page\">Next >>" (:body 
resp))
 segments ((html2data (:body resp)) :segment)
 data (map segment2data segments)
 ]
  (if next 
(recur r (conj lst data))
(conj lst data)

I was wondering if I could replace the loop thingy with a map - that is 
when I experimented with a simple piece of code and found something that 
was not intuitive.
I'd really appreciate it if someone could tell me what's going on when I do 
the following -

user> (defn xx [] (map println [1 2 3 4 5 6]))
#'user/xx
user> (take 2 (xx))
(1
2
3
4
5
6
nil nil)
user> 

Regards,
Kashyap

-- 
-- 
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/groups/opt_out.

Re: ANN: cljson, for faster browser deserialization

[Alan Dipert]

Hi Murtaza, the primary motivation of cljson is to improve browser 
deserialization performance when the client is ClojureScript and the server 
is Clojure.  You can start with EDN and easily move to cljson if 
client-side deserialization becomes your bottleneck.

Alan

On Monday, January 13, 2014 9:45:00 AM UTC-5, Murtaza Husain wrote:
>
> Alan,
>
> I am exploring what option to use for exchanging data between my server 
> and client. EDN and Cljson are two of the options. What are the pros / cons 
> of using cljson over edn ?
>
> What was the motive in creating this library ?
>
> Thanks,
> Murtaza
>
> On Tuesday, June 25, 2013 12:58:11 AM UTC+5:30, Alan Dipert wrote:
>>
>> Glad you enjoy!  And yes, totally into the cljson->clj [map data] arity.
>> Alan
>>
>> On Monday, June 24, 2013 1:50:00 PM UTC-4, Thomas Heller wrote:
>>>
>>> Hey,
>>>
>>> this looks pretty sweet! I stuck with EDN for now but its way too slow, 
>>> so I'm gonna give this a shot.
>>>
>>> One thing: I'm don't think its the best idea to fall back to 
>>> *default-data-readers*, would you be open to adding a second argument to 
>>> 'cljson->clj which takes a map specifying readers? eg. (cljson->clj 
>>> {:readers {"my.ns/test" my-reader-fn}} json-string), basically the same API 
>>> as clojure.edn/read?
>>>
>>> Thanks,
>>> /thomas
>>>
>>>
>>>
>>> On Monday, June 24, 2013 7:23:26 PM UTC+2, Alan Dipert wrote:

 Hi all,
 I'm pleased to announce the release of cljson 1.0.0, a Clojure and 
 ClojureScript data serialization library designed for maximal Clojure data 
 deserialization speed in the browser: 
 https://github.com/tailrecursion/cljson.  cljson was designed to take 
 advantage of the native JSON parsing facilities most browsers provide.

 cljson provides clj->cljson and cljson->clj functions on both 
 platforms.  cljson->clj on ClojureScript is roughly 5-6x faster than 
 cljs.reader/read-string, and cljson data is roughly 10% fatter on the wire 
 than EDN. 

 Thanks in advance for your feedback and contributions!

 Alan

>>>

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

Re: ClojureScript integration with Emacs/Cider ?

[Gary Trakhman]

Austin's lein-plugin already manipulates project middlewares, so that's an
easy target.  Onward!


On Mon, Jan 13, 2014 at 10:10 AM, Bozhidar Batsov wrote:

> Cider’s completion understands a `complete` op, so the middleware is the
> best approach if you ask me. The only reason that there’s also an eval
> based completion mechanism (the one used by default) is that
> clojure-complete is present as a REPLy (which is used by lein) dependency
> and many newcomers have absolutely no idea what an nREPL middleware is.
> Unfortunately it’s hard to balance initial easy of setup and good design
> decisions.
>
> --
> Cheers,
> Bozhidar
>
> On Monday, January 13, 2014 at 4:55 PM, Gary Trakhman wrote:
>
> On talking to Chas,
> https://github.com/cemerick/piggieback/issues/22
>
> it seems like the right approach is to reify ac-nrepl's use of eval into a
> real "complete" op, and reimplement it to use that, then a common
> middleware can either use clojure's environment (clojure-complete) or
> piggieback's compiler state to implement the appropriate auto-complete
> based on the active repl.
>
> The issue here is that clojure's auto-complete takes the JVM state as an
> implicit parameter, whereas cljs-complete requires an 'env' arg that has to
> come from somewhere (piggieback has a var that keeps track of repl session
> state).  Ac-nrepl shouldn't be able to eval code, that means it's being
> coupled to the JVM state, which won't do for cljs or other sorts of
> repls-on-repls.
>
>
>
> On Mon, Jan 13, 2014 at 9:03 AM, Gary Trakhman wrote:
>
> I've released a cljs port of clojure-complete:
>
> Here's the mailing list announcement, also inlined.
>
> https://groups.google.com/forum/#!topic/clojurescript/Dt1s4laHFXc
> cljs-complete, A Clojure library designed to auto-complete clojurescript
> based on cljs compiler state.
>
> - With leiningen:
>  [cljs-complete "0.1.0"]
>
> - Usage
>
> ;; env is pulled from cljs compiler state
> => (completions @cljs.env/*compiler* "al" 'cljs.core)
> ("alength" "alter-meta!")
>
> This is meant to hook into piggieback, that'll be the next thing I try. I
> hope I can get some help with the hairy emacs bits :-).
>
>
> On Tuesday, January 7, 2014 1:54:27 AM UTC-5, Bozhidar Batsov wrote:
>
> I'm cider's maintainer. The problem with code completion for ClojureScript
> is that the default mechanism is based on the Clojure-only library
> https://github.com/ninjudd/clojure-complete. As I don't use ClojureScript
> I haven't paid much attention to it so far. If there is a similar library
> for ClojureScript I might add support for it. Btw, cider will also pick up
> any nREPL middleware that provides a "complete" op - if there is a
> ClojureScript nREPL completion middleware it can be used with cider even
> now. Ideally at some point we'll have unified middleware supporting both
> Clojure & ClojureScript.
>
> On Sunday, January 5, 2014 10:30:44 PM UTC+2, Alexandru Nedelcu wrote:
>
> Hi,
>
> I can’t get auto-completion or jumping to the definition of a function in
> Emacs, while working with ClojureScript. Is this a limitation of Emacs’
> Cider  plugin?
>
> I managed to get nRepl working by using the awesome 
> com.cemerick/austinplugin for lein 
> (besides including the plugin in
> project.clj I’ve got no other special configuration). So to work with
> ClojureScript, from inside an nRepl session, I execute the following (not
> sure if this is right):
>
> (cemerick.austin.repls/exec :exec-cmds ["google-chrome"])
>
> In Emacs I do the same thing, by first starting the repl with
> cider-jack-in and then I execute the above command. Compiling the current
> buffer works (C-c C-k), I can also send expressions for evaluation to the
> repl (C-x C-e).
>
> However, as I said, auto-completion doesn’t work and neither does jumping
> to the definition of a function. Is there any way to get these features
> while working with ClojureScript in Emacs? Or maybe in another IDE?
>
> Thanks,
> --
> Alexandru Nedelcu
> www.bionicspirit.com
>
> PGP Public Key:
> https://bionicspirit.com/key.aexpk
>
>  --
> --
> 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/groups/opt_out.
>
>
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group,

Re: How to handle configuration in Clojure?

[Joachim De Beule]

There's also 
this: 
https://github.com/clojure-cookbook/clojure-cookbook/blob/master/local-io/edn-config/edn-config.asciidoc

Joachim

-- 
-- 
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/groups/opt_out.

[ANN] cljs-start 0.1.1

[Mimmo Cosenza]

I just published to clojars the 0.1.1 release of cljs-start lein template to 
create a batteries included Clojurescript lib. 

https://github.com/magomimmo/cljs-start

This release uses lein profiles (:user, :dev, :simple and :advanced) to keep 
the corresponding CLJS builds separated from each other (thanks so much to 
Laurent Petit for the suggestion).  

quick start:

lein new cljs-start wonderful-lib
cd wonderful-lib
lein compile
lein repl
(run)
(browser-repl)

Then visit the localhost:3000 and after the connection is established (few 
moments) you can start repling in CLJS with your browser.

Quick start with latest Eclipse/CCW (Thanks to Laurent Petit):

1. File -> New Project -> Clojure Project: 
- project name: wonderful-lib
- Leingen template: cljs-start
Click Finish
2. Right Click on wonderful-lib in the Package Explorer -> Leiningen -> Launch 
Headless REPL for the project
Once in the REPL:
(run)
(browser-repl) 

Then visit the localhost:3000 and after the connection is established (few 
moments) you can start repling in CLJS with your browser

HIH 
Mimmo




signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: ANN: cljson, for faster browser deserialization

[Murtaza Husain]

Alan,

Thanks for your reply. I was also looking for a RPC mechanism, and I looked 
at castra from the hoplon stack. 

One thing that is turning me off is that I will have to define my api as 
special 'defn', instead of regular defns. I have used shoreleave / fetch 
before and have liked their simplicity in just defining regular fns and 
then remoting them. 

Is it possible to use castra without the sugar ? Or to use it more 
explicitly ?

Thanks,
Murtaza 



On Monday, January 13, 2014 8:51:21 PM UTC+5:30, Alan Dipert wrote:
>
> Hi Murtaza, the primary motivation of cljson is to improve browser 
> deserialization performance when the client is ClojureScript and the server 
> is Clojure.  You can start with EDN and easily move to cljson if 
> client-side deserialization becomes your bottleneck.
>
> Alan
>
> On Monday, January 13, 2014 9:45:00 AM UTC-5, Murtaza Husain wrote:
>>
>> Alan,
>>
>> I am exploring what option to use for exchanging data between my server 
>> and client. EDN and Cljson are two of the options. What are the pros / cons 
>> of using cljson over edn ?
>>
>> What was the motive in creating this library ?
>>
>> Thanks,
>> Murtaza
>>
>> On Tuesday, June 25, 2013 12:58:11 AM UTC+5:30, Alan Dipert wrote:
>>>
>>> Glad you enjoy!  And yes, totally into the cljson->clj [map data] arity.
>>> Alan
>>>
>>> On Monday, June 24, 2013 1:50:00 PM UTC-4, Thomas Heller wrote:

 Hey,

 this looks pretty sweet! I stuck with EDN for now but its way too slow, 
 so I'm gonna give this a shot.

 One thing: I'm don't think its the best idea to fall back to 
 *default-data-readers*, would you be open to adding a second argument to 
 'cljson->clj which takes a map specifying readers? eg. (cljson->clj 
 {:readers {"my.ns/test" my-reader-fn}} json-string), basically the same 
 API 
 as clojure.edn/read?

 Thanks,
 /thomas



 On Monday, June 24, 2013 7:23:26 PM UTC+2, Alan Dipert wrote:
>
> Hi all,
> I'm pleased to announce the release of cljson 1.0.0, a Clojure and 
> ClojureScript data serialization library designed for maximal Clojure 
> data 
> deserialization speed in the browser: 
> https://github.com/tailrecursion/cljson.  cljson was designed to take 
> advantage of the native JSON parsing facilities most browsers provide.
>
> cljson provides clj->cljson and cljson->clj functions on both 
> platforms.  cljson->clj on ClojureScript is roughly 5-6x faster than 
> cljs.reader/read-string, and cljson data is roughly 10% fatter on the 
> wire 
> than EDN. 
>
> Thanks in advance for your feedback and contributions!
>
> Alan
>


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

Re: How to handle configuration in Clojure?

[Andrey Antukh]

https://github.com/james-henderson/nomad can be one option for manage/store
a configuration ;) (it uses edn...)

Andrey


2014/1/13 Joachim De Beule 

> There's also this:
> https://github.com/clojure-cookbook/clojure-cookbook/blob/master/local-io/edn-config/edn-config.asciidoc
>
> Joachim
>
> --
> --
> 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/groups/opt_out.
>



-- 
Andrey Antukh - Андрей Антух -  / 
http://www.niwi.be 
https://github.com/niwibe

-- 
-- 
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/groups/opt_out.

Re: How to handle configuration in Clojure?

[Travis Vachon]

Another option is to use leiningen profiles to change the classpath,
loading different versions of a (eg) config.clj file in different
environments. This lets you `require` the config namespace and refer
to config parameters like `config/the-configured-value`

Travis

On Mon, Jan 13, 2014 at 11:05 AM, Andrey Antukh  wrote:
> https://github.com/james-henderson/nomad can be one option for manage/store
> a configuration ;) (it uses edn...)
>
> Andrey
>
>
> 2014/1/13 Joachim De Beule 
>>
>> There's also this:
>> https://github.com/clojure-cookbook/clojure-cookbook/blob/master/local-io/edn-config/edn-config.asciidoc
>>
>> Joachim
>>
>> --
>> --
>> 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/groups/opt_out.
>
>
>
>
> --
> Andrey Antukh - Андрей Антух -  /
> 
> http://www.niwi.be
> https://github.com/niwibe
>
> --
> --
> 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/groups/opt_out.

-- 
-- 
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/groups/opt_out.

Re: A question about lazy seq with io

[Mauricio Aldazosa]

On Mon, Jan 13, 2014 at 8:49 AM, Kashyap CK  wrote:

>
> I'd really appreciate it if someone could tell me what's going on when I
> do the following -
>
> user> (defn xx [] (map println [1 2 3 4 5 6]))
> #'user/xx
> user> (take 2 (xx))
> (1
> 2
> 3
> 4
> 5
> 6
> nil nil)
> user>
>

There are many things that you need to be aware of here:

   1. Lazy seqs are chunked. As an optimization they are realized 32
   elementes at a time. There are ways to go around this:
   http://blog.fogus.me/2010/01/22/de-chunkifying-sequences-in-clojure/
   2. map returns a lazy seq of the return value of the function it uses,
   and println returns nil as a result.
   3. Lazy seqs and IO usually are a confusing mix.

So, as a result of chunking a println for all six elements is made. Each of
this calls, as a side effect prints the number and, returns nil. Then you
ask for the first two return values of that sequence, hence the "nil nil".
Everything is getting mixed up at the repl so it seems confusing, but the
result of xx is (nil nil) and the side-effect of it is the printing of 1 2
3 4 5 6.
Cheers,
Mauricio

-- 
-- 
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/groups/opt_out.

Re: How to handle configuration in Clojure?

[Kristoffer Skjutare]

This got me thinking about Stuart Sierras 
Component: https://github.com/stuartsierra/component

Kristoffer

Den måndagen den 13:e januari 2014 kl. 16:22:55 UTC+1 skrev Joachim De 
Beule:
>
> There's also this: 
> https://github.com/clojure-cookbook/clojure-cookbook/blob/master/local-io/edn-config/edn-config.asciidoc
>
> Joachim
>

-- 
-- 
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/groups/opt_out.

Re: A question about lazy seq with io

[Kashyap CK]

Thanks Mauricio ... I think I understand it now.
Regards,
Kashyap

On Monday, January 13, 2014 9:48:28 PM UTC+5:30, Mauricio Aldazosa wrote:
>
>
>
> On Mon, Jan 13, 2014 at 8:49 AM, Kashyap CK 
> > wrote:
>
>>
>> I'd really appreciate it if someone could tell me what's going on when I 
>> do the following -
>>
>> user> (defn xx [] (map println [1 2 3 4 5 6]))
>> #'user/xx
>> user> (take 2 (xx))
>> (1
>> 2
>> 3
>> 4
>> 5
>> 6
>> nil nil)
>> user> 
>>
>
> There are many things that you need to be aware of here:
>
>1. Lazy seqs are chunked. As an optimization they are realized 32 
>elementes at a time. There are ways to go around this: 
>http://blog.fogus.me/2010/01/22/de-chunkifying-sequences-in-clojure/ 
>2. map returns a lazy seq of the return value of the function it uses, 
>and println returns nil as a result.
>3. Lazy seqs and IO usually are a confusing mix.
>
> So, as a result of chunking a println for all six elements is made. Each 
> of this calls, as a side effect prints the number and, returns nil. Then 
> you ask for the first two return values of that sequence, hence the "nil 
> nil". Everything is getting mixed up at the repl so it seems confusing, but 
> the result of xx is (nil nil) and the side-effect of it is the printing of 
> 1 2 3 4 5 6.
> Cheers,
> Mauricio
>

-- 
-- 
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/groups/opt_out.

Re: How to handle configuration in Clojure?

[Stefan Kanev]

On 13/01/14, James Trunk wrote:
> The downsides to dynamic vars seem to be: hiddenness, thread safety, and 
> more complex tests (binding before each test).

I am curious about what you mean by 'thread safety'.  As far as I know,
dynamic variables are thread-local, which means that they are
thread-safe, at least to some extend.  I assume you mean something
specific?

-- 
Stefan Kanev  ¦  @skanev  ¦  http://skanev.com/
If a program manipulates a large amount of data, it does so in a small number
of ways.

-- 
-- 
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/groups/opt_out.

Re: How to handle configuration in Clojure?

[Jonah Benton]

A middle ground between dynamic vars and passing state through functions
that themselves don't need it, but which is needed by functions they call,
is to build on top of defprotocol and defrecord, to refactor so that the
functions that need "configuration" state in their operations are defined
by protocols, and the state they need is captured in a record, which can
then be prepared at initialization time with the necessary information.

In this solution, there is still "noise" in the sense that now protocol
"functions" have to take their record configuration as a first parameter,
but the semantic noise in having unused configuration data passing through
that first parameter should be relieved.

There's a lot more to say here, but the upshot/goal of the refactoring
should be that explicit dependencies between the function call tree-
organized into protocols- and initialization/configuration state- organized
into records- should be nicely revealed.
There are reasons that they might not, and then that's a time to look at
other state/configuration management approaches like atoms/refs and dynamic
vars.

Someone else mentioned Stuart Sierra's Component library:

https://github.com/stuartsierra/component

Stuart seems to have gone furthest in encapsulating this pattern, so his
examples are good to think about, even if you don't adopt the library.

HTH.



On Mon, Jan 13, 2014 at 8:50 AM, James Trunk  wrote:

> I've been investigating how to handle configuration in a Clojure
> application/library, and have discovered two main candidates: dynamics vars
> and argument passing.
>
> The downsides to dynamic vars seem to be: hiddenness, thread safety, and
> more complex tests (binding before each test).
>
> The downside to argument passing is noise in the code (especially when
> you're just passing the config through). Longer and more descriptive names
> for the config (i.e. not "ctx" or "cfg") make this noise even more painful.
>
> Are there any alternatives that I've missed? What is the current best
> practice for handling configuration?
>
> Cheers,
> James
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
-- 
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/groups/opt_out.

Re: Nginx-Clojure Let You Deploy Clojure Web App on Nginx Without Any Java Web Server

[Sergey Didenko]

Looks very interesting, thank you for your work!

I wonder how this is going to improve latency in comparison to nginx +
http-kit for some real world test that is not using heavy DB operations.


On Mon, Jan 13, 2014 at 5:57 AM, Xfeep Zhang  wrote:

>
> So far I have found why nginx-clojure is slower than http-kit when 1
> concurrents. (when < = 1000 concurrents nginx-clojure is faster than
> http-kit.)
> I have set too many connections per nginx worker (worker_connections =
> 2) . This make nginx only use one worker to handle ab  requests (every
> request is tiny).
> I plan to take note of 
> c-erlang-java-performanceand
>  fork
> clojure-web-server-benchmarksto
>   do some  real world tests.
>
>
>
> On Sunday, January 12, 2014 11:21:06 PM UTC+8, Xfeep Zhang wrote:
>>
>> Sorry for my mistake!
>>
>> 1. In the static file test, the ring-jetty result is about 10
>> concurrents. NOT 1 concurrents  ("Concurrency Level:  10" in  the
>> ab report ).
>> 2. In the small string test, All results about three server are about 10
>> concurrents. NOT 1 concurrents.
>>
>> There are right results about these two mistake :
>>
>> 1. static file test
>>
>> (3) ring-jetty  more bad than 10 concurrents
>> ===
>> Document Path:  /
>> Document Length:29686 bytes
>>
>> *Concurrency Level:  1*
>> Time taken for tests:   6.303 seconds
>> Complete requests:  10
>> Failed requests:0
>> Write errors:   0
>> Total transferred:  298220 bytes
>> HTML transferred:   296860 bytes
>> Requests per second:15864.43 [#/sec] (mean)
>> Time per request:   630.341 [ms] (mean)
>> Time per request:   0.063 [ms] (mean, across all concurrent requests)
>> Transfer rate:  462020.65 [Kbytes/sec] received
>>
>> Connection Times (ms)
>>   min  mean[+/-sd] median   max
>> Connect:   12  328 535.0 433041
>> Processing:25  124 112.9 963523
>> Waiting:8   47  99.4 283523
>> Total: 52  452 544.51574546
>>
>> Percentage of the requests served within a certain time (ms)
>>   50%157
>>   66%305
>>   75%   1071
>>   80%   1102
>>   90%   1139
>>   95%   1155
>>   98%   1462
>>   99%   3100
>>  100%   4546 (longest request)
>>
>>
>> 2. simple string (1 concurrents)
>>
>> http-kit is the fastest.  But nginx-clojure is too young and has vast
>> room for growth ：）
>>
>> (1) nginx-clojure-0.1.0
>>
>> Document Path:  /
>> Document Length:15 bytes
>>
>> *Concurrency Level:  1*
>> Time taken for tests:   2.834 seconds
>> Complete requests:  10
>> Failed requests:0
>> Write errors:   0
>> Total transferred:  1700 bytes
>> HTML transferred:   150 bytes
>> Requests per second:35291.16 [#/sec] (mean)
>> Time per request:   283.357 [ms] (mean)
>> Time per request:   0.028 [ms] (mean, across all concurrent requests)
>> Transfer rate:  5858.88 [Kbytes/sec] received
>>
>> Connection Times (ms)
>>   min  mean[+/-sd] median   max
>> Connect:   51  118  21.6118 178
>> Processing:73  150  33.8146 263
>> Waiting:   42  110  32.0104 246
>> Total:177  268  25.6269 327
>>
>> Percentage of the requests served within a certain time (ms)
>>   50%269
>>   66%278
>>   75%285
>>   80%288
>>   90%297
>>   95%309
>>   98%314
>>   99%318
>>  100%327 (longest request)
>>
>>
>> (2) http-kit 2.1.16
>>
>> Document Path:  /
>> Document Length:15 bytes
>>
>> *Concurrency Level:  1*
>> Time taken for tests:   2.691 seconds
>> Complete requests:  10
>> Failed requests:0
>> Write errors:   0
>> Total transferred:  1340 bytes
>> HTML transferred:   150 bytes
>> Requests per second:37165.27 [#/sec] (mean)
>> Time per request:   269.068 [ms] (mean)
>> Time per request:   0.027 [ms] (mean, across all concurrent requests)
>> Transfer rate:  4863.42 [Kbytes/sec] received
>>
>> Connection Times (ms)
>>   min  mean[+/-sd] median   max
>> Connect:   72  118  46.21141094
>> Processing:31  134  26.1136 344
>> Waiting:   21   81  33.5 71 273
>> Total:183  252  43.82511435
>>
>> Percentage of the requests served within a certain time (ms)
>>   50%251
>>   66%258
>>   75%259
>>   80%261
>>   90%263
>>   95%263
>>   98%265
>>   99%266
>>  100%   1435 (longest request)
>>
>>
>>
>> (3) ring-jetty
>>
>> Document Path:  /
>> Document Length:15 bytes
>>
>> *Concurrency Level:  1*
>> Time taken for tests:   9.740 seconds
>> Complete requests:  10
>> Failed requests:  

Re: HttpKit, Enlive (html retrieval and parsing)

[Jarrod Swart]

This is exactly what I do and it works great!

On Saturday, January 11, 2014 7:00:22 PM UTC-5, Jan Herich wrote:
>
> I don't recommend using java's built in HTTP retrieval (by passing 
> java.net.URL object to enlive html-resource function).
> Not only is it significantly slower then using clj-http (which uses 
> apache-http client under the hood), but it's also unreliable
> when issuing more parallel requests. 
> Current enlive library supports plug-able parsers, the default one is 
> TagSoup, but you can switch it very easily for example
> for JSoup by setting *parser* dynamic var. 
> You can have a look at one of my little projects where i used enlive for 
> html scraping 
> here
>  , 
> in this case, i used clj-http as 
> http client:
>
> (ns lazada-quest.scrapper
>   (:require [clojure.string :as string]
> [clj-http.client :as client]
> [net.cgrand.enlive-html :as html]))
>
>
> (defn fetch-url
>   "Given some url string, fetch html content of the resource served under url 
> adress and return
>it in the form of enlive nodes"
>   [url]
>
>   (html/html-resource (:body (client/get url {:as :stream}
>
> It would be straightforward to replace use of clj-http with http-kit 
> synchronous api, or asynchronous api with some changes
>
> Dňa nedeľa, 12. januára 2014 0:24:48 UTC+1 Dave Tenny napísal(-a):
>>
>> I'm just playing around with tool kits to retrieve and parse html from 
>> web pages and files that I already have on disk (such as JDK API 
>> documentation).
>>
>> Based on too little time, it looks like [http-kit "2.1.16"] will retrieve 
>> but not parse html, and [enlive "1.1.5"] will retrieve AND parse html.
>>
>> Or is there a whole built-in parse capability I'm missing in http-kiit?
>>
>> Also, http-kit doesn't seem to want to retrieve content from a file:/// 
>> url, whereas enlive is happy with both local and remote content.
>>
>> I'm just messing around, I wanted to have some REPL javadoc logic that 
>> didn't fire up a browser or use the swing app (whose fonts are unreadable 
>> for me, and half a day spent trying to change it was not fruitful).
>>
>> Any tips or suggestions?  Just don't want to make sure I'm missing 
>> obvious things.
>>
>> Thanks!
>>
>>
>>
>>

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

Re: A question about lazy seq with io

[Jan Herich]

As Mauricio already mentioned, map is not meant to be used for 
side-effects, if you want to need to evaluate a sequence for side-effects, 
use doseq  instead.
Regarding your first question about explicit loop-recur, i think it's 
reasonable way to write the functionality you want to achieve, even if the 
for macro is maybe
little more idiomatic and shorter/more concise, here is the comparison:

(def url-sequence (map #(str "http://www.mysite.com/list.php?pageID="; %) 
(range)))
 
(def download
  (loop [urls url-sequence lst []]
(let [u (first urls)
  r (rest urls)
  resp (client/get u)
  next (re-find #"(s?)title=\"next page\">Next >>" (:body resp))
  segments ((html2data (:body resp)) :segment)
  data (map segment2data segments)]
  (if next 
(recur r (conj lst data))
(conj lst data)
 
(def download
  (->> (for [url url-sequence
 :let [body (:body (client/get url))
   next-pages (re-find #"(s?)title=\"next page\">Next >>" 
body)]
 :while next-pages]
 (map segment2data (-> body (html2data) :segment
   (into []))

Also note that i didn't use local binding named next, but instead i named it 
next-pages, because next
local name could lead to surprise if you forget that you aliased something to 
next and try to use clojure
core next function :)


Dňa pondelok, 13. januára 2014 15:49:50 UTC+1 Kashyap CK napísal(-a):
>
> Hi,
> I've been dabbling with Clojure for a bit and I am really loving it!!!
>
> I am trying to write a clojure program to download a bunch of URLs and I 
> was wondering what is the right way to do it - 
> My current implementation is as follows
>
> (def url-sequence (map #(str "http://www.mysite.com/list.php?pageID="; %) 
> (range)))
>
> (def download
>   (loop [urls url-sequence lst []]
> (let
> [
>  u (first urls)
>  r (rest urls)
>  resp (client/get u)
>  next (re-find #"(s?)title=\"next page\">Next >>" (:body 
> resp))
>  segments ((html2data (:body resp)) :segment)
>  data (map segment2data segments)
>  ]
>   (if next 
> (recur r (conj lst data))
> (conj lst data)
>
> I was wondering if I could replace the loop thingy with a map - that is 
> when I experimented with a simple piece of code and found something that 
> was not intuitive.
> I'd really appreciate it if someone could tell me what's going on when I 
> do the following -
>
> user> (defn xx [] (map println [1 2 3 4 5 6]))
> #'user/xx
> user> (take 2 (xx))
> (1
> 2
> 3
> 4
> 5
> 6
> nil nil)
> user> 
>
> Regards,
> Kashyap
>

-- 
-- 
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/groups/opt_out.

Eastwood lint tools - some Qs

[Sean Corfield (Clojure)]

Just started using this and I see the argslist caveat that causes
Eastwood to misdiagnose :wrong-arity (the readme specifies java.jdbc
0.3.x but it also gets tripped up by congomongo).

Can you (Andy or Jonas or any other Eastwood user) clarify how the
arglists cause the problem and what, if anything, can be done in the
source of java.jdbc and/or congomongo to alleviate the problem?

Thanx,
Sean

-- 
-- 
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/groups/opt_out.

Re: Eastwood lint tools - some Qs

[Nicola Mometto]

Sean, it looks like the issue is caused by arglists like this one:
https://github.com/clojure/java.jdbc/blob/master/src/main/clojure/clojure/java/jdbc.clj#L782-L783

tools.analyzer.jvm uses :arglists to detect possible invoke calls with a
misplaced arity, expecting that to be a valid value, in your case for
documentation purposes you are attaching a :arglists that does not match
a valid list of args vector, so t.a.j interprets that as a 6-arity
arglist.

Nicola


Sean Corfield (Clojure) writes:

> Just started using this and I see the argslist caveat that causes
> Eastwood to misdiagnose :wrong-arity (the readme specifies java.jdbc
> 0.3.x but it also gets tripped up by congomongo).
>
> Can you (Andy or Jonas or any other Eastwood user) clarify how the
> arglists cause the problem and what, if anything, can be done in the
> source of java.jdbc and/or congomongo to alleviate the problem?
>
> Thanx,
> Sean
>
> --

-- 
-- 
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/groups/opt_out.

Re: Eastwood lint tools - some Qs

[Sean Corfield]

Thanx for the specific example!

Yeah, I've used :arglists for "examples" in a couple of places instead of 
actual argument lists. I'll fix that in 0.3.3 and may do the same with 
CongoMongo (although it's a far worse culprit in several areas - and we're in 
the process of migrating to Monger now anyway).

Sean

On Jan 13, 2014, at 11:49 AM, Nicola Mometto  wrote:
> Sean, it looks like the issue is caused by arglists like this one:
> https://github.com/clojure/java.jdbc/blob/master/src/main/clojure/clojure/java/jdbc.clj#L782-L783
> 
> tools.analyzer.jvm uses :arglists to detect possible invoke calls with a
> misplaced arity, expecting that to be a valid value, in your case for
> documentation purposes you are attaching a :arglists that does not match
> a valid list of args vector, so t.a.j interprets that as a 6-arity
> arglist.
> 
> Nicola
> 
> 
> Sean Corfield (Clojure) writes:
> 
>> Just started using this and I see the argslist caveat that causes
>> Eastwood to misdiagnose :wrong-arity (the readme specifies java.jdbc
>> 0.3.x but it also gets tripped up by congomongo).
>> 
>> Can you (Andy or Jonas or any other Eastwood user) clarify how the
>> arglists cause the problem and what, if anything, can be done in the
>> source of java.jdbc and/or congomongo to alleviate the problem?
>> 
>> Thanx,
>> Sean



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Am I using core.async/go in an un-clojurish ?

[Stephen Cagle]

Did you mean 


*(go (loop [ ... ]*

*  (case ...*

*.. (func arg1 foo1)*

*.. (func arg2 foo2)*


*.. (func arg3 foo3)))*

*where (defn func [ ... ] (.. >! .. ))*
, as func (not foo) is the thing in function position?

Ignoring that, and working in a general sense:

I think that if the function you call into is synchronous, then you can 
just ! from within the go block, and call the function in the normal 
fashion. 

However, if the function is asynchronous, I think it is probably best to 
make the function itself into a go machine, and just take! on the returned 
channel returned from the go machine. something like
(defn func [...] (go  ))

calling it as 
...
(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/groups/opt_out.

Re: Managing role-based permissions in Ring apps

[Alexandr Kurilin]

Disclaimer: I think what Friend is trying to do is super important and
cemerick rocks.

However, I found Friend to be really difficult to grok the first time I
took a stab at it many months ago, perhaps I'm more capable of getting into
it now. My concern was that it is so broadly encompassing and there are too
few examples of how to use it in scenarios similar to the ones I face every
day. For example, I ended up rolling my own cookie-based role auth
middleware (relying on Ring's cookie store) in about 15 lines of clj,
significantly simpler for a basic scenario.

By the way, it would be really neat if someone added a Friend chapter to
the upcoming Clojure Cookbook. I created an issue for it over 6 months ago
and nobody's taken it up so far, so I can't tell if most of the community
has given up on the library or if it's just too much of a hassle to explain
to others.


On Sun, Jan 12, 2014 at 11:40 PM, Stefan Kamphausen wrote:

>
>
> On Monday, January 13, 2014 3:53:43 AM UTC+1, Sam Ritchie wrote:
>>
>> cemerick's Friend library is the way to do this:
>>
>> https://github.com/cemerick/friend
>>
>> I'm writing up a post on how to combine Friend with Liberator, for easy
>> ACL management for RESTful APIs. Take a look and let us know what you think!
>>
>>
> Can't wait to read that post. :)
>
> stefan
>
> --
> --
> 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/groups/opt_out.
>



-- 
Alexandr Kurilin
206.687.8740 | @alex_kurilin  |
blog

-- 
-- 
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/groups/opt_out.

Re: Managing role-based permissions in Ring apps

[Christopher Allen]

I might follow up with a more thorough reply, but I had to drop Friend for 
the same reason I had to drop Liberator. Customizing the 
assumptions/defaults the libraries made was too default. Relatively simple 
content negotiation involved trying to do insane monkey-patches of 
Liberator's protocols or vendoring and rewriting of the library.

Whereas, plain ole' Ring 
middleware: 
https://github.com/bitemyapp/berossus/blob/master/src/berossus/rocks/your/data/middleware.clj#L44-L51

has worked out just dandy.

I don't mind leveraging other peoples' code at all, but Liberator and 
Friend fall apart fairly quickly if you step outside their view of the 
universe even a little bit.

On Monday, January 13, 2014 12:16:56 PM UTC-8, Alexandr Kurilin wrote:
>
> Disclaimer: I think what Friend is trying to do is super important and 
> cemerick rocks.
>
> However, I found Friend to be really difficult to grok the first time I 
> took a stab at it many months ago, perhaps I'm more capable of getting into 
> it now. My concern was that it is so broadly encompassing and there are too 
> few examples of how to use it in scenarios similar to the ones I face every 
> day. For example, I ended up rolling my own cookie-based role auth 
> middleware (relying on Ring's cookie store) in about 15 lines of clj, 
> significantly simpler for a basic scenario.
>
> By the way, it would be really neat if someone added a Friend chapter to 
> the upcoming Clojure Cookbook. I created an issue for it over 6 months ago 
> and nobody's taken it up so far, so I can't tell if most of the community 
> has given up on the library or if it's just too much of a hassle to explain 
> to others.
>
>
> On Sun, Jan 12, 2014 at 11:40 PM, Stefan Kamphausen 
> 
> > wrote:
>
>>
>>
>> On Monday, January 13, 2014 3:53:43 AM UTC+1, Sam Ritchie wrote:
>>>
>>> cemerick's Friend library is the way to do this:
>>>
>>> https://github.com/cemerick/friend
>>>
>>> I'm writing up a post on how to combine Friend with Liberator, for easy 
>>> ACL management for RESTful APIs. Take a look and let us know what you think!
>>>
>>>
>> Can't wait to read that post. :)
>>
>> stefan 
>>
>> -- 
>> -- 
>> 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/groups/opt_out.
>>
>
>
>
> -- 
> Alexandr Kurilin
> 206.687.8740 | @alex_kurilin  | 
> blog
>  

-- 
-- 
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/groups/opt_out.

Re: Managing role-based permissions in Ring apps

[Christopher Allen]

To clarify, that was an example of content negotiation middleware, not ACL.

If I were to tackle this, I would try to find or implement a pure ACL (not 
aware of web apps per se) library and then hook it up via Ring middleware.

On Monday, January 13, 2014 12:45:23 PM UTC-8, Christopher Allen wrote:
>
> I might follow up with a more thorough reply, but I had to drop Friend for 
> the same reason I had to drop Liberator. Customizing the 
> assumptions/defaults the libraries made was too default. Relatively simple 
> content negotiation involved trying to do insane monkey-patches of 
> Liberator's protocols or vendoring and rewriting of the library.
>
> Whereas, plain ole' Ring middleware: 
> https://github.com/bitemyapp/berossus/blob/master/src/berossus/rocks/your/data/middleware.clj#L44-L51
>
> has worked out just dandy.
>
> I don't mind leveraging other peoples' code at all, but Liberator and 
> Friend fall apart fairly quickly if you step outside their view of the 
> universe even a little bit.
>
> On Monday, January 13, 2014 12:16:56 PM UTC-8, Alexandr Kurilin wrote:
>>
>> Disclaimer: I think what Friend is trying to do is super important and 
>> cemerick rocks.
>>
>> However, I found Friend to be really difficult to grok the first time I 
>> took a stab at it many months ago, perhaps I'm more capable of getting into 
>> it now. My concern was that it is so broadly encompassing and there are too 
>> few examples of how to use it in scenarios similar to the ones I face every 
>> day. For example, I ended up rolling my own cookie-based role auth 
>> middleware (relying on Ring's cookie store) in about 15 lines of clj, 
>> significantly simpler for a basic scenario.
>>
>> By the way, it would be really neat if someone added a Friend chapter to 
>> the upcoming Clojure Cookbook. I created an issue for it over 6 months ago 
>> and nobody's taken it up so far, so I can't tell if most of the community 
>> has given up on the library or if it's just too much of a hassle to explain 
>> to others.
>>
>>
>> On Sun, Jan 12, 2014 at 11:40 PM, Stefan Kamphausen wrote:
>>
>>>
>>>
>>> On Monday, January 13, 2014 3:53:43 AM UTC+1, Sam Ritchie wrote:

 cemerick's Friend library is the way to do this:

 https://github.com/cemerick/friend

 I'm writing up a post on how to combine Friend with Liberator, for easy 
 ACL management for RESTful APIs. Take a look and let us know what you 
 think!


>>> Can't wait to read that post. :)
>>>
>>> stefan 
>>>
>>> -- 
>>> -- 
>>> 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/groups/opt_out.
>>>
>>
>>
>>
>> -- 
>> Alexandr Kurilin
>> 206.687.8740 | @alex_kurilin  | 
>> blog
>>  
>

-- 
-- 
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/groups/opt_out.

Re: How to handle configuration in Clojure?

[Christopher Allen]

github.com/weavejester/environ/ + environment variables. 12-factor it that 
way, proxy the environment variables via a config namespace so that 
configuration values are programmatically generated in case something needs 
to intervene.

On Monday, January 13, 2014 5:50:54 AM UTC-8, James Trunk wrote:
>
> I've been investigating how to handle configuration in a Clojure 
> application/library, and have discovered two main candidates: dynamics vars 
> and argument passing.
>
> The downsides to dynamic vars seem to be: hiddenness, thread safety, and 
> more complex tests (binding before each test).
>
> The downside to argument passing is noise in the code (especially when 
> you're just passing the config through). Longer and more descriptive names 
> for the config (i.e. not "ctx" or "cfg") make this noise even more painful.
>
> Are there any alternatives that I've missed? What is the current best 
> practice for handling configuration?
>
> Cheers,
> James
>

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

Re: How to handle configuration in Clojure?

[Christopher Allen]

Example here: 
https://github.com/bitemyapp/berossus/blob/master/src/berossus/rocks/your/data/config.clj

On Monday, January 13, 2014 1:57:06 PM UTC-8, Christopher Allen wrote:
>
>
> github.com/weavejester/environ/ + environment variables. 12-factor it 
> that way, proxy the environment variables via a config namespace so that 
> configuration values are programmatically generated in case something needs 
> to intervene.
>
> On Monday, January 13, 2014 5:50:54 AM UTC-8, James Trunk wrote:
>>
>> I've been investigating how to handle configuration in a Clojure 
>> application/library, and have discovered two main candidates: dynamics vars 
>> and argument passing.
>>
>> The downsides to dynamic vars seem to be: hiddenness, thread safety, and 
>> more complex tests (binding before each test).
>>
>> The downside to argument passing is noise in the code (especially when 
>> you're just passing the config through). Longer and more descriptive names 
>> for the config (i.e. not "ctx" or "cfg") make this noise even more painful.
>>
>> Are there any alternatives that I've missed? What is the current best 
>> practice for handling configuration?
>>
>> Cheers,
>> James
>>
>

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

Ragtime w/ Korma

[Arlandis Lawrence]

I'm trying to use H2's in-memory database feature for running specs, so I'm 
using Ragtime to run migrations before the test.
Problem is, I can't get Korma to cooperate. Could someone take a look at 
this gist and see if it makes sense?

https://gist.github.com/arlandism/8408370

-- 
-- 
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/groups/opt_out.

Re: Eastwood lint tools - some Qs

[Andy Fingerhut]

Sean:

Eastwood's current use of :arglists for :wrong-arity linter checking is
definitely 'at odds' with the way java.jdbc and some other libraries use it
for clearer documentation of fn/macro args.

I would recommend leaving :arglists as-is for java.jdbc, and wait for the
next version of Eastwood to add a capability to have something like an
:eastwood-arglists for functions that explicitly replace their :arglists
like this. Such a capability might best belong in Eastwood itself, since it
is the new tool on the block.

As an example, I was considering that if a fn/macro explicitly chose to be
Eastwood-friendly in this way, it could have an :arglists and
:eastwood-arglists explicitly, for those few vars that replace their
:arglists. When one is using Eastwood with a library that they do not want
to modify in that way, there could be some extra config file for Eastwood
where one could specify these :eastwood-arglists.

Thoughts?
Andy


On Mon, Jan 13, 2014 at 11:56 AM, Sean Corfield  wrote:

> Thanx for the specific example!
>
> Yeah, I've used :arglists for "examples" in a couple of places instead of
> actual argument lists. I'll fix that in 0.3.3 and may do the same with
> CongoMongo (although it's a far worse culprit in several areas - and we're
> in the process of migrating to Monger now anyway).
>
> Sean
>
> On Jan 13, 2014, at 11:49 AM, Nicola Mometto  wrote:
> > Sean, it looks like the issue is caused by arglists like this one:
> >
> https://github.com/clojure/java.jdbc/blob/master/src/main/clojure/clojure/java/jdbc.clj#L782-L783
> >
> > tools.analyzer.jvm uses :arglists to detect possible invoke calls with a
> > misplaced arity, expecting that to be a valid value, in your case for
> > documentation purposes you are attaching a :arglists that does not match
> > a valid list of args vector, so t.a.j interprets that as a 6-arity
> > arglist.
> >
> > Nicola
> >
> >
> > Sean Corfield (Clojure) writes:
> >
> >> Just started using this and I see the argslist caveat that causes
> >> Eastwood to misdiagnose :wrong-arity (the readme specifies java.jdbc
> >> 0.3.x but it also gets tripped up by congomongo).
> >>
> >> Can you (Andy or Jonas or any other Eastwood user) clarify how the
> >> arglists cause the problem and what, if anything, can be done in the
> >> source of java.jdbc and/or congomongo to alleviate the problem?
> >>
> >> Thanx,
> >> Sean
>
>

-- 
-- 
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/groups/opt_out.

Re: How to handle configuration in Clojure?

[Mark Mandel]

+1 for environ as well.

I also have combined that with the Stuart Sierra reloaded workflow (started
it before Components, don't know if I want to switch).
http://thinkrelevance.com/blog/2013/06/04/clojure-workflow-reloaded

Finding it a great fit, as it's easy to switch out environ variables in
your system map when testing very easily, as you pass it all around.

Mark


On Tue, Jan 14, 2014 at 8:57 AM, Christopher Allen wrote:

> Example here:
> https://github.com/bitemyapp/berossus/blob/master/src/berossus/rocks/your/data/config.clj
>
>
> On Monday, January 13, 2014 1:57:06 PM UTC-8, Christopher Allen wrote:
>>
>>
>> github.com/weavejester/environ/ + environment variables. 12-factor it
>> that way, proxy the environment variables via a config namespace so that
>> configuration values are programmatically generated in case something needs
>> to intervene.
>>
>> On Monday, January 13, 2014 5:50:54 AM UTC-8, James Trunk wrote:
>>>
>>> I've been investigating how to handle configuration in a Clojure
>>> application/library, and have discovered two main candidates: dynamics vars
>>> and argument passing.
>>>
>>> The downsides to dynamic vars seem to be: hiddenness, thread safety, and
>>> more complex tests (binding before each test).
>>>
>>> The downside to argument passing is noise in the code (especially when
>>> you're just passing the config through). Longer and more descriptive names
>>> for the config (i.e. not "ctx" or "cfg") make this noise even more painful.
>>>
>>> Are there any alternatives that I've missed? What is the current best
>>> practice for handling configuration?
>>>
>>> Cheers,
>>> James
>>>
>>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>



-- 
E: mark.man...@gmail.com
T: http://www.twitter.com/neurotic
W: www.compoundtheory.com

2 Devs from Down Under Podcast
http://www.2ddu.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/groups/opt_out.

Re: Ragtime w/ Korma

[Christopher Allen]

Try it without H2 and check the contents of the database manually. "Korma 
cooperating" doesn't mean a lot if the tables don't actually exist.

Error messages should be provided in future.

On Monday, January 13, 2014 1:44:28 PM UTC-8, Arlandis Lawrence wrote:
>
> I'm trying to use H2's in-memory database feature for running specs, so 
> I'm using Ragtime to run migrations before the test.
> Problem is, I can't get Korma to cooperate. Could someone take a look at 
> this gist and see if it makes sense?
>
> https://gist.github.com/arlandism/8408370
>

-- 
-- 
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/groups/opt_out.

Re: Eastwood lint tools - some Qs

[Sean Corfield]

On Jan 13, 2014, at 2:05 PM, Andy Fingerhut  wrote:
> Eastwood's current use of :arglists for :wrong-arity linter checking is 
> definitely 'at odds' with the way java.jdbc and some other libraries use it 
> for clearer documentation of fn/macro args.
> 

Google seems to indicate that :arglists is used for all sorts of documentation 
clarifications and some libraries have pretty much arbitrary stuff in that 
metadata, based on the fact that clojure.repl/doc and autodoc and other tools 
don't parse it, they simply display it as-is :(

Sounds like Eastwood should ignore :arglists and just use the actual argument 
lists for the arity check, with perhaps an additional lint warning for when 
what's in :arglists doesn't match possible real signatures of the function? I 
can see the latter being useful on its own sometimes.

> As an example, I was considering that if a fn/macro explicitly chose to be 
> Eastwood-friendly in this way, it could have an :arglists and 
> :eastwood-arglists explicitly, for those few vars that replace their 
> :arglists. When one is using Eastwood with a library that they do not want to 
> modify in that way, there could be some extra config file for Eastwood where 
> one could specify these :eastwood-arglists.
> 

I'm not sure how I feel about a potential explosion of tool-specific metadata. 
Perhaps a single :eastwood map containing whatever flags are relevant for that 
tool? So in this case :eastwood {:arglists '(...)} to provide arglists-specific 
data to Eastwood which would also be a good place to add a way to exclude 
specific linters on a per-fn basis?

It found three bugs in our code on the first run so I'm figuring out a way to 
integrate it into our build as an additional QA step now :)

Sean Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)





signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Am I using core.async/go in an un-clojurish ?

[t x]

Hi Stephen,

  I don't undersand your suggestion:

(defn foo [c]
  (async/>! c "hi"))

(defn test []
  (let [c (async/chan 10)]
(async/go
 (foo c)
 (println (! not used in go block ...


On Mon, Jan 13, 2014 at 12:03 PM, Stephen Cagle  wrote:

> Did you mean
>
>
> *(go (loop [ ... ]*
>
> *  (case ...*
>
> *.. (func arg1 foo1)*
>
> *.. (func arg2 foo2)*
>
>
> *.. (func arg3 foo3)))*
>
> *where (defn func [ ... ] (.. >! .. ))*
> , as func (not foo) is the thing in function position?
>
> Ignoring that, and working in a general sense:
>
> I think that if the function you call into is synchronous, then you can
> just ! from within the go block, and call the function in the normal
> fashion.
>
> However, if the function is asynchronous, I think it is probably best to
> make the function itself into a go machine, and just take! on the returned
> channel returned from the go machine. something like
> (defn func [...] (go  ASYNC_STUFF._LAST_VALUE_IS_VALUE_OF_CHANNEL_RETURNED_BY_FN_CALL> ))
>
> calling it as
> ...
> ( ...
>
> Performance wise, I am not clear how expensive it is to spin up a go
> machine every time you make a call to func vs just passing around a channel
> to be processed by a looping go machine.
>
> --
> --
> 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/groups/opt_out.
>

-- 
-- 
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/groups/opt_out.

Re: Eastwood lint tools - some Qs

[Nicola Mometto]

Sean Corfield writes:

> Sounds like Eastwood should ignore :arglists and just use the actual argument 
> lists for the arity check, with perhaps an additional lint warning for when 
> what's in :arglists doesn't match possible real signatures of the function? I 
> can see the latter being useful on its own sometimes.

There's no way other than inspecting :arglists to determine the
signature of a function.

Eastwood *could* add a pass to put the arg vectors of defn forms in an
atom and use that to check for wrong arities, but this would work only
for functions that get analyzed by tools.analyzer.jvm, this means that
it wouldn't report the warning for i.e. calls to a function from a
dependency.

To be honest I don't like the idea of libraries attaching not-valid
:arglists meta to Vars at all since the doc[1] for `def` says that :arglists
will be "a list of vector(s) of argument forms, as were supplied to
defn" and the clojure Compiler uses :arglists for type-hints handling.

[1]http://clojure.org/special_forms#Special%20Forms--(def%20symbol%20init?)%20


Nicola

-- 
-- 
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/groups/opt_out.

Re: Am I using core.async/go in an un-clojurish ?

[Stephen Cagle]

I just want to re-iterate that there are many (some are probably better) 
ways to do this, but using what I suggested above it would be:

(defn foo []
  (async/go "hi"))

(defn test []
   (println (async/! c (async/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/groups/opt_out.

Re: Am I using core.async/go in an un-clojurish ?

[Stephen Cagle]

And already, I see that the first one should have been 

(defn test []
   (async/go 
 (println (async/
> I just want to re-iterate that there are many (some are probably better) 
> ways to do this, but using what I suggested above it would be:
>
> (defn foo []
>   (async/go "hi"))
>
> (defn test []
>(println (async/
> (defn test []
>   (let [c (async/chan 10)]
> (async/go
>  (async/>! c (async/  (println (
> (test)
>
> I wrote the first (test) minimally as you aren't really doing anything 
> with your 10 slot buffer. However, in real code maybe you are, so I tried 
> to write the second (test) in the fashion that you wrote it.
>
> There is nothing really to what I am saying other than that, yes, the 
> core.async codewalker cannot see into code that you call into. Therefore, 
> if the code you call into also needs to do asynchronous things, you need to 
> wrap it in something like a go block as well. With the above solution you 
> might have 2 go machines "live" at the same time (the test and the foo go 
> machines). 
>
> In short, you have a trade-off here. If you want to modularize your code 
> at the function (go machine) level, you are going to potentially have 
> multiple go machines "live" at the same time.
>
> I don't have an editor/compiler on this tablet, so apologies for any silly 
> errors.
>

-- 
-- 
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/groups/opt_out.

Re: A question about lazy seq with io

[Kashyap CK]

Thank you very very much Jan  idiomatic is what I need to learn :)
Regards,
Kashyap

On Tuesday, January 14, 2014 12:47:19 AM UTC+5:30, Jan Herich wrote:
>
> As Mauricio already mentioned, map is not meant to be used for 
> side-effects, if you want to need to evaluate a sequence for side-effects, 
> use doseq instead.
> Regarding your first question about explicit loop-recur, i think it's 
> reasonable way to write the functionality you want to achieve, even if the 
> for macro is maybe
> little more idiomatic and shorter/more concise, here is the comparison:
>
> (def url-sequence (map #(str "http://www.mysite.com/list.php?pageID="; %) 
> (range)))
>  
> (def download
>   (loop [urls url-sequence lst []]
> (let [u (first urls)
>   r (rest urls)
>   resp (client/get u)
>   next (re-find #"(s?)title=\"next page\">Next >>" (:body resp))
>   segments ((html2data (:body resp)) :segment)
>   data (map segment2data segments)]
>   (if next 
> (recur r (conj lst data))
> (conj lst data)
>  
> (def download
>   (->> (for [url url-sequence
>  :let [body (:body (client/get url))
>next-pages (re-find #"(s?)title=\"next page\">Next 
> >>" body)]
>  :while next-pages]
>  (map segment2data (-> body (html2data) :segment
>(into []))
>
> Also note that i didn't use local binding named next, but instead i named it 
> next-pages, because next
> local name could lead to surprise if you forget that you aliased something to 
> next and try to use clojure
> core next function :)
>
>
> Dňa pondelok, 13. januára 2014 15:49:50 UTC+1 Kashyap CK napísal(-a):
>>
>> Hi,
>> I've been dabbling with Clojure for a bit and I am really loving it!!!
>>
>> I am trying to write a clojure program to download a bunch of URLs and I 
>> was wondering what is the right way to do it - 
>> My current implementation is as follows
>>
>> (def url-sequence (map #(str "http://www.mysite.com/list.php?pageID="; %) 
>> (range)))
>>
>> (def download
>>   (loop [urls url-sequence lst []]
>> (let
>> [
>>  u (first urls)
>>  r (rest urls)
>>  resp (client/get u)
>>  next (re-find #"(s?)title=\"next page\">Next >>" (:body 
>> resp))
>>  segments ((html2data (:body resp)) :segment)
>>  data (map segment2data segments)
>>  ]
>>   (if next 
>> (recur r (conj lst data))
>> (conj lst data)
>>
>> I was wondering if I could replace the loop thingy with a map - that is 
>> when I experimented with a simple piece of code and found something that 
>> was not intuitive.
>> I'd really appreciate it if someone could tell me what's going on when I 
>> do the following -
>>
>> user> (defn xx [] (map println [1 2 3 4 5 6]))
>> #'user/xx
>> user> (take 2 (xx))
>> (1
>> 2
>> 3
>> 4
>> 5
>> 6
>> nil nil)
>> user> 
>>
>> Regards,
>> Kashyap
>>
>

-- 
-- 
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/groups/opt_out.

Re: Eastwood lint tools - some Qs

[Sean Corfield]

On Jan 13, 2014, at 3:09 PM, Nicola Mometto  wrote:
> To be honest I don't like the idea of libraries attaching not-valid
> :arglists meta to Vars at all since the doc[1] for `def` says that :arglists
> will be "a list of vector(s) of argument forms, as were supplied to
> defn" and the clojure Compiler uses :arglists for type-hints handling.

I agree with you in principle - and I'm happy to change java.jdbc to avoid the 
issue.

Could Eastwood (or j.t.a) flag invalid :arglists? The "example" ones in both 
java.jdbc and congomongo are clearly "invalid" according the special forms page 
(but they silently "work"). Perhaps if Eastwood finds invalid / suspicious 
metadata in :arglists, it could use a different linter warning?

Sean Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)





signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Am I using core.async/go in an un-clojurish ?

[t x]

Hi Stephen,

  I now understand what you meant. Thanks writing a minimal test case.


On Mon, Jan 13, 2014 at 3:34 PM, Stephen Cagle  wrote:

> And already, I see that the first one should have been
>
> (defn test []
>(async/go
>  (println (async/
> Boy I wish you could edit this post after the fact.
>
> On Monday, January 13, 2014 3:32:39 PM UTC-8, Stephen Cagle wrote:
>>
>> I just want to re-iterate that there are many (some are probably better)
>> ways to do this, but using what I suggested above it would be:
>>
>> (defn foo []
>>   (async/go "hi"))
>>
>> (defn test []
>>(println (async/>
>> (defn test []
>>   (let [c (async/chan 10)]
>> (async/go
>>  (async/>! c (async/>  (println (>
>> (test)
>>
>> I wrote the first (test) minimally as you aren't really doing anything
>> with your 10 slot buffer. However, in real code maybe you are, so I tried
>> to write the second (test) in the fashion that you wrote it.
>>
>> There is nothing really to what I am saying other than that, yes, the
>> core.async codewalker cannot see into code that you call into. Therefore,
>> if the code you call into also needs to do asynchronous things, you need to
>> wrap it in something like a go block as well. With the above solution you
>> might have 2 go machines "live" at the same time (the test and the foo go
>> machines).
>>
>> In short, you have a trade-off here. If you want to modularize your code
>> at the function (go machine) level, you are going to potentially have
>> multiple go machines "live" at the same time.
>>
>> I don't have an editor/compiler on this tablet, so apologies for any
>> silly errors.
>>
>  --
> --
> 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/groups/opt_out.
>

-- 
-- 
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/groups/opt_out.

go "kill infinite loop"

[t x]

Consider the following code block:


(defn make-stupid []
  (go (loop []
(recur

(def x (make-stupid))

;; ... is there a way to kill this infinite go-loop ?


Now, is there a way, using the variable "x", to kill this infinite loop --
or did I basically kill a java thread?

Thanks!

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

lein script installation errors on CentOS 6.5

[gvim]

The lein script is producing errors when I try to install it on CentOS 6.5:

$ lein
/sw/bin/lein: command substitution: line 93: syntax error near 
unexpected token `)'

/sw/bin/lein: command substitution: line 93: `dirname "$PWD")"'
/sw/bin/lein: command substitution: line 110: syntax error near 
unexpected token `)'

/sw/bin/lein: command substitution: line 110: `dirname "$0")"'
/sw/bin/lein: command substitution: line 123: syntax error near 
unexpected token `)'

/sw/bin/lein: command substitution: line 123: `dirname "$SCRIPT")"'
/sw/bin/lein: command substitution: line 44: syntax error near 
unexpected token `)'

/sw/bin/lein: command substitution: line 44: `make_native_path "$1")"'
/sw/bin/lein: command substitution: line 50: syntax error near 
unexpected token `)'

/sw/bin/lein: command substitution: line 50: `basename "$LEIN_JAVA_CMD")"'
/sw/bin/lein: command substitution: line 140: syntax error near 
unexpected token `)'
/sw/bin/lein: command substitution: line 140: `mktemp 
/tmp/lein-trampoline-X)"'


I downloaded it first with wget and when that failed I copied and pasted 
the online version into MacVim  and uploaded the file to my CentOS 
server. Same result. I have Oracle's jdk-7u45 installed.


gvim

--
--
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/groups/opt_out.

Re: lein script installation errors on CentOS 6.5

[Matching Socks]

Scripts in Red Hat ought to begin with #!/bin/bash which is writable only 
by root and kept updated by system updates. But lein uses #!/usr/bin/env 
bash -- "use whatever bash executable is on my path" -- which is less well 
controlled and might be different. Try "which bash" to see what shell is 
being used to run lein.  If it's not /bin/bash, try adjusting lein's first 
line.  If you get the error when using /bin/bash, see what version it is 
with "rpm -q bash". 

-- 
-- 
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/groups/opt_out.

Re: lein script installation errors on CentOS 6.5

[gvim]

Resolved, thanks. Still puzzled as Red Hat's /bin/bash is 4.1.2 and my 
custom /sw/bin/bash is 4.2.24. Surely such a minor version difference 
should not result in such a catastrophe?


gvim

On 14/01/2014 01:31, Matching Socks wrote:

Scripts in Red Hat ought to begin with #!/bin/bash which is writable
only by root and kept updated by system updates. But lein uses
#!/usr/bin/env bash -- "use whatever bash executable is on my path" --
which is less well controlled and might be different. Try "which bash"
to see what shell is being used to run lein.  If it's not /bin/bash, try
adjusting lein's first line.  If you get the error when using /bin/bash,
see what version it is with "rpm -q bash".



--
--
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/groups/opt_out.

Re: Nginx-Clojure Let You Deploy Clojure Web App on Nginx Without Any Java Web Server

[Xfeep Zhang]

You're welcome.

I think there are several difficult phases :

(1)  update the test program in 
clojure-web-server-benchmarks,
 make the some packages to be the latest. (eg. http-kit from 1.3.0-alpha2 
--> 2.1.16) and add nginx-php testing
(2)  test about real world size contents by group eg. tiny, small, medium, 
huge. 
(3)  test about real world connection circumstances where a lot of 
connection is inactive but keep open.
(4)  try some real asynchronous test to fetch external resources (eg. rest 
service , db) before response to the client. eg.  using 
libdrizzlea no-blocking mysql  client from  
https://launchpad.net/drizzle

On Tuesday, January 14, 2014 2:41:50 AM UTC+8, Sergey Didenko wrote:
>
> Looks very interesting, thank you for your work!
>
> I wonder how this is going to improve latency in comparison to nginx + 
> http-kit for some real world test that is not using heavy DB operations.
>
>
> On Mon, Jan 13, 2014 at 5:57 AM, Xfeep Zhang 
> > wrote:
>
>>
>> So far I have found why nginx-clojure is slower than http-kit when 1 
>> concurrents. (when < = 1000 concurrents nginx-clojure is faster than 
>> http-kit.)
>> I have set too many connections per nginx worker (worker_connections = 
>> 2) . This make nginx only use one worker to handle ab  requests (every 
>> request is tiny).
>> I plan to take note of 
>> c-erlang-java-performanceand
>>  fork 
>> clojure-web-server-benchmarksto
>>   do some  real world tests.
>>
>>
>>
>> On Sunday, January 12, 2014 11:21:06 PM UTC+8, Xfeep Zhang wrote:
>>>
>>> Sorry for my mistake!
>>>
>>> 1. In the static file test, the ring-jetty result is about 10 
>>> concurrents. NOT 1 concurrents  ("Concurrency Level:  10" in  the 
>>> ab report ).
>>> 2. In the small string test, All results about three server are about 10 
>>> concurrents. NOT 1 concurrents.
>>>
>>> There are right results about these two mistake :
>>>
>>> 1. static file test
>>>
>>> (3) ring-jetty  more bad than 10 concurrents
>>> ===
>>> Document Path:  /
>>> Document Length:29686 bytes
>>>
>>> *Concurrency Level:  1*
>>> Time taken for tests:   6.303 seconds
>>> Complete requests:  10
>>> Failed requests:0
>>> Write errors:   0
>>> Total transferred:  298220 bytes
>>> HTML transferred:   296860 bytes
>>> Requests per second:15864.43 [#/sec] (mean)
>>> Time per request:   630.341 [ms] (mean)
>>> Time per request:   0.063 [ms] (mean, across all concurrent requests)
>>> Transfer rate:  462020.65 [Kbytes/sec] received
>>>
>>> Connection Times (ms)
>>>   min  mean[+/-sd] median   max
>>> Connect:   12  328 535.0 433041
>>> Processing:25  124 112.9 963523
>>> Waiting:8   47  99.4 283523
>>> Total: 52  452 544.51574546
>>>
>>> Percentage of the requests served within a certain time (ms)
>>>   50%157
>>>   66%305
>>>   75%   1071
>>>   80%   1102
>>>   90%   1139
>>>   95%   1155
>>>   98%   1462
>>>   99%   3100
>>>  100%   4546 (longest request)
>>>
>>>
>>> 2. simple string (1 concurrents)
>>>
>>> http-kit is the fastest.  But nginx-clojure is too young and has vast 
>>> room for growth ：）
>>>
>>> (1) nginx-clojure-0.1.0
>>>
>>> Document Path:  /
>>> Document Length:15 bytes
>>>
>>> *Concurrency Level:  1*
>>> Time taken for tests:   2.834 seconds
>>> Complete requests:  10
>>> Failed requests:0
>>> Write errors:   0
>>> Total transferred:  1700 bytes
>>> HTML transferred:   150 bytes
>>> Requests per second:35291.16 [#/sec] (mean)
>>> Time per request:   283.357 [ms] (mean)
>>> Time per request:   0.028 [ms] (mean, across all concurrent requests)
>>> Transfer rate:  5858.88 [Kbytes/sec] received
>>>
>>> Connection Times (ms)
>>>   min  mean[+/-sd] median   max
>>> Connect:   51  118  21.6118 178
>>> Processing:73  150  33.8146 263
>>> Waiting:   42  110  32.0104 246
>>> Total:177  268  25.6269 327
>>>
>>> Percentage of the requests served within a certain time (ms)
>>>   50%269
>>>   66%278
>>>   75%285
>>>   80%288
>>>   90%297
>>>   95%309
>>>   98%314
>>>   99%318
>>>  100%327 (longest request)
>>>
>>>
>>> (2) http-kit 2.1.16
>>>
>>> Document Path:  /
>>> Document Length:15 bytes
>>>
>>> *Concurrency Level:  1*
>>> Time taken for tests:   2.691 seconds
>>> Complete requests:  10
>>> Failed requests:0
>>> Write errors:   0
>>> Total transferred:  1340 bytes
>>> HTML transferred:   150 bytes
>>> Request

Re: Eastwood lint tools - some Qs

[Colin Fleming]

This is an interesting discussion, I've been thinking about some of these
problems as I move towards adding inspections in Cursive. arglist parsing
is a real problem in Clojure. I'd like to be able to flag invocations of
functions with bad arities in the editor, but it's very difficult. Even
defn is complicated, given that its :arglists is:

:arglists '([name doc-string? attr-map? [params*] prepost-map? body]
[name doc-string? attr-map? ([params*] prepost-map? body)+
attr-map?])

and its actual args declaration is:

[&form &env name & fdecl]

There's really no way to parse either of them automatically well. Does
Eastwood use the actual fn declaration or :arglists for linting? What would
it do in the case above? It's impossible to tell if doc-string? is a
boolean or if it's an optional arg.

Oh, and I agree that invalid :arglists as documentation is probably a bad
idea, since it'll inevitably make this sort of tooling more difficult than
it already is.


On 14 January 2014 14:03, Sean Corfield  wrote:

> On Jan 13, 2014, at 3:09 PM, Nicola Mometto  wrote:
> > To be honest I don't like the idea of libraries attaching not-valid
> > :arglists meta to Vars at all since the doc[1] for `def` says that
> :arglists
> > will be "a list of vector(s) of argument forms, as were supplied to
> > defn" and the clojure Compiler uses :arglists for type-hints handling.
>
> I agree with you in principle - and I'm happy to change java.jdbc to avoid
> the issue.
>
> Could Eastwood (or j.t.a) flag invalid :arglists? The "example" ones in
> both java.jdbc and congomongo are clearly "invalid" according the special
> forms page (but they silently "work"). Perhaps if Eastwood finds invalid /
> suspicious metadata in :arglists, it could use a different linter warning?
>
> Sean Corfield -- (904) 302-SEAN
> An Architect's View -- http://corfield.org/
>
> "Perfection is the enemy of the good."
> -- Gustave Flaubert, French realist novelist (1821-1880)
>
>
>
>

-- 
-- 
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/groups/opt_out.

Re: Eastwood lint tools - some Qs

[Ben Wolfson]

Actual arglists have a set structure and can be parsed automatically:
https://github.com/bwo/macroparser/blob/master/src/macroparser/bindings.clj

It's true that you couldn't reconstruct something as informative as the
:arglists metadata on defn from the actual declaration, of course.


On Mon, Jan 13, 2014 at 6:57 PM, Colin Fleming
wrote:

> This is an interesting discussion, I've been thinking about some of these
> problems as I move towards adding inspections in Cursive. arglist parsing
> is a real problem in Clojure. I'd like to be able to flag invocations of
> functions with bad arities in the editor, but it's very difficult. Even
> defn is complicated, given that its :arglists is:
>
> :arglists '([name doc-string? attr-map? [params*] prepost-map? body]
> [name doc-string? attr-map? ([params*] prepost-map? body)+
> attr-map?])
>
> and its actual args declaration is:
>
> [&form &env name & fdecl]
>
> There's really no way to parse either of them automatically well. Does
> Eastwood use the actual fn declaration or :arglists for linting? What would
> it do in the case above? It's impossible to tell if doc-string? is a
> boolean or if it's an optional arg.
>
> Oh, and I agree that invalid :arglists as documentation is probably a bad
> idea, since it'll inevitably make this sort of tooling more difficult than
> it already is.
>
>
> On 14 January 2014 14:03, Sean Corfield  wrote:
>
>> On Jan 13, 2014, at 3:09 PM, Nicola Mometto  wrote:
>> > To be honest I don't like the idea of libraries attaching not-valid
>> > :arglists meta to Vars at all since the doc[1] for `def` says that
>> :arglists
>> > will be "a list of vector(s) of argument forms, as were supplied to
>> > defn" and the clojure Compiler uses :arglists for type-hints handling.
>>
>> I agree with you in principle - and I'm happy to change java.jdbc to
>> avoid the issue.
>>
>> Could Eastwood (or j.t.a) flag invalid :arglists? The "example" ones in
>> both java.jdbc and congomongo are clearly "invalid" according the special
>> forms page (but they silently "work"). Perhaps if Eastwood finds invalid /
>> suspicious metadata in :arglists, it could use a different linter warning?
>>
>> Sean Corfield -- (904) 302-SEAN
>> An Architect's View -- http://corfield.org/
>>
>> "Perfection is the enemy of the good."
>> -- Gustave Flaubert, French realist novelist (1821-1880)
>>
>>
>>
>>
>  --
> --
> 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/groups/opt_out.
>



-- 
Ben Wolfson
"Human kind has used its intelligence to vary the flavour of drinks, which
may be sweet, aromatic, fermented or spirit-based. ... Family and social
life also offer numerous other occasions to consume drinks for pleasure."
[Larousse, "Drink" entry]

-- 
-- 
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/groups/opt_out.

Re: Am I using core.async/go in an un-clojurish ?

[Timothy Baldridge]

This is a often asked question, but one I think requires a bit of thought.
The key to solving this kind of issue in your code is to think of channel
ops as "io" and as side-effecting. It's tempting to stick these operations
deep inside nested functions, but I think that's rather "un-functional",
and "un-clojureish". In pure functional programming we try to keep the io
at the edges.

So this is the pattern I try to follow when writing core.async code: keep
the core functionally pure, and the side effects to the edges. This has
several nice side effects:

1) Your functionally pure code is now much easier to test, you can rip off
the core.async specific bits and test the core synchronously.

2) Your inputs and outputs are now in a single place, and so are easier to
reason about.

As mentioned above, you can still wrap function bodies in gos, if needed.
And you can use core.async/put! and take! from anywhere in your code. But I
do recommend trying to avoid jumping to these by default.

That being said, creating gos is quite cheap. On my MBP, after the JIT has
warmed up, I'm estimating the CPU cost of creating a go is about 140ns
(yes, ns). So creating them may not be the bottleneck they seem to be at
first. (and take that number with a big grain of salt).

Just some points to ponder.

Timothy Baldridge


On Mon, Jan 13, 2014 at 6:05 PM, t x  wrote:

> Hi Stephen,
>
>   I now understand what you meant. Thanks writing a minimal test case.
>
>
> On Mon, Jan 13, 2014 at 3:34 PM, Stephen Cagle  wrote:
>
>> And already, I see that the first one should have been
>>
>> (defn test []
>>(async/go
>>  (println (async/>
>> Boy I wish you could edit this post after the fact.
>>
>> On Monday, January 13, 2014 3:32:39 PM UTC-8, Stephen Cagle wrote:
>>>
>>> I just want to re-iterate that there are many (some are probably better)
>>> ways to do this, but using what I suggested above it would be:
>>>
>>> (defn foo []
>>>   (async/go "hi"))
>>>
>>> (defn test []
>>>(println (async/>>
>>> (defn test []
>>>   (let [c (async/chan 10)]
>>> (async/go
>>>  (async/>! c (async/>>  (println (>>
>>> (test)
>>>
>>> I wrote the first (test) minimally as you aren't really doing anything
>>> with your 10 slot buffer. However, in real code maybe you are, so I tried
>>> to write the second (test) in the fashion that you wrote it.
>>>
>>> There is nothing really to what I am saying other than that, yes, the
>>> core.async codewalker cannot see into code that you call into. Therefore,
>>> if the code you call into also needs to do asynchronous things, you need to
>>> wrap it in something like a go block as well. With the above solution you
>>> might have 2 go machines "live" at the same time (the test and the foo go
>>> machines).
>>>
>>> In short, you have a trade-off here. If you want to modularize your code
>>> at the function (go machine) level, you are going to potentially have
>>> multiple go machines "live" at the same time.
>>>
>>> I don't have an editor/compiler on this tablet, so apologies for any
>>> silly errors.
>>>
>>  --
>> --
>> 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/groups/opt_out.
>>
>
>  --
> --
> 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/groups/opt_out.
>



-- 
“One of the main causes of the fall of the Roman Empire was that–lacking
zero–they had no way to indicate successful termination of their C
programs.”
(Robert Firth)

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 

Re: Am I using core.async/go in an un-clojurish ?

[t x]

This is what I ended up building:


  (defmacro wrap-error [& body]
`(slingshot.slingshot/try+
  (let [ans# ~body]
{:tag :ok :message ans#})
  (catch Exception e#
{:tag :error :message e#})))

  (defmacro wgo [& body]
`(clojure.core.async/go
  (wrap-error ~@body)))

  (defmacro ?>!! [chan msg]
(let [c (gensym)]
  `(let [~c ~chan]
 (and (not @(.-closed ~c))
  (not= :chan-full (async/alts!! [[~c ~msg]] :default
:chan-full))

  (defmacro ?>! [chan msg]
(let [c (gensym)]
  `(let [~c ~chan]
 (and (not @(.-closed ~c))
  (not= :chan-full (async/alts! [[~c ~msg]] :default
:chan-full))

  (defmacro ?!! and ?>! I want to do a
"put-if-possible-other-return-false". Normally, I'd like to write this as a
function, i.e.


(defn put-if-possible-other-return-false! ... )

but in this particular case, I seem to be forced to use a macro.






On Mon, Jan 13, 2014 at 8:01 PM, Timothy Baldridge wrote:

> This is a often asked question, but one I think requires a bit of thought.
> The key to solving this kind of issue in your code is to think of channel
> ops as "io" and as side-effecting. It's tempting to stick these operations
> deep inside nested functions, but I think that's rather "un-functional",
> and "un-clojureish". In pure functional programming we try to keep the io
> at the edges.
>
> So this is the pattern I try to follow when writing core.async code: keep
> the core functionally pure, and the side effects to the edges. This has
> several nice side effects:
>
> 1) Your functionally pure code is now much easier to test, you can rip off
> the core.async specific bits and test the core synchronously.
>
> 2) Your inputs and outputs are now in a single place, and so are easier to
> reason about.
>
> As mentioned above, you can still wrap function bodies in gos, if needed.
> And you can use core.async/put! and take! from anywhere in your code. But I
> do recommend trying to avoid jumping to these by default.
>
> That being said, creating gos is quite cheap. On my MBP, after the JIT has
> warmed up, I'm estimating the CPU cost of creating a go is about 140ns
> (yes, ns). So creating them may not be the bottleneck they seem to be at
> first. (and take that number with a big grain of salt).
>
> Just some points to ponder.
>
> Timothy Baldridge
>
>
> On Mon, Jan 13, 2014 at 6:05 PM, t x  wrote:
>
>> Hi Stephen,
>>
>>   I now understand what you meant. Thanks writing a minimal test case.
>>
>>
>> On Mon, Jan 13, 2014 at 3:34 PM, Stephen Cagle  wrote:
>>
>>> And already, I see that the first one should have been
>>>
>>> (defn test []
>>>(async/go
>>>  (println (async/>>
>>> Boy I wish you could edit this post after the fact.
>>>
>>> On Monday, January 13, 2014 3:32:39 PM UTC-8, Stephen Cagle wrote:

 I just want to re-iterate that there are many (some are probably
 better) ways to do this, but using what I suggested above it would be:

 (defn foo []
   (async/go "hi"))

 (defn test []
(println (async/>>>
 (defn test []
   (let [c (async/chan 10)]
 (async/go
  (async/>! c (async/>>>  (println (>>>
 (test)

 I wrote the first (test) minimally as you aren't really doing anything
 with your 10 slot buffer. However, in real code maybe you are, so I tried
 to write the second (test) in the fashion that you wrote it.

 There is nothing really to what I am saying other than that, yes, the
 core.async codewalker cannot see into code that you call into. Therefore,
 if the code you call into also needs to do asynchronous things, you need to
 wrap it in something like a go block as well. With the above solution you
 might have 2 go machines "live" at the same time (the test and the foo go
 machines).

 In short, you have a trade-off here. If you want to modularize your
 code at the function (go machine) level, you are going to potentially have
 multiple go machines "live" at the same time.

 I don't have an editor/compiler on this tablet, so apologies for any
 silly errors.

>>>  --
>>> --
>>> 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/groups/opt_out.
>>>
>>
>>  --
>> --
>> You received this message because you a

closing-buffer

[t x]

I am aware of:

  DroppingBuffer and SliddingBuffer

I would like to build a channel with different semantics:

  When I try to put an item on a full channel:

  * DroppingBuffer drops the new item
  * SliddingBuffer evicts the oldest item

  * ClosingBuffer should _close the channel_

(thus, the receiver eventually gets a nil, and realizes "ah, was
disconnected")

Now, I am looking at the github core.async code:

DroppingBuffer:
https://github.com/clojure/core.async/blob/76317035d386ce2a1d98c2c349da9b898b480c55/src/main/clojure/clojure/core/async/impl/buffers.clj#L33-L45

ManyToManyChannel:
https://github.com/clojure/core.async/blob/76317035d386ce2a1d98c2c349da9b898b480c55/src/main/clojure/clojure/core/async/impl/channels.clj#L31-L198

## Problem:

DroppingBuffer is easy to understand. However, I don't think I can
implement "ClosingBuffer" as Buffer.

I feel taht "ClosingBuffer" can only be implemneted at the Channel Level.

However, the Channel Code is complicated.

Is there a neat hack / trick to do what I described above?

Thanks!

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

ANN Langohr 2.2.1

[Michael Klishin]

Langohr [1] is a small, feature complete Clojure client for RabbitMQ.

Hot on the heels of 2.2.0, 2.2.1 is out with one bug fix.

Release notes:
http://blog.clojurewerkz.org/blog/2014/01/14/langohr-2-dot-2-1-is-released/

1. http://clojurerabbitmq.info
-- 
MK

http://github.com/michaelklishin
http://twitter.com/michaelklishin

-- 
-- 
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/groups/opt_out.

Re: go "kill infinite loop"

[Ben Mabey]

On Mon Jan 13 18:11:10 2014, t x wrote:

Consider the following code block:


(defn make-stupid []
  (go (loop []
(recur

(def x (make-stupid))

;; ... is there a way to kill this infinite go-loop ?


No, you can not kill the loop with the go channel that is bound to x.  
You need to return a stop, a.k.a. poison, channel that the go block 
checks before recurring. Something like:


(let [stop (chan)]
 (go
  (loop []
(when (alt! stop false :default :keep-going)
  ...
  (recur
 stop)

-Ben

--
--
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/groups/opt_out.

Re: go "kill infinite loop"

[t x]

Understood. Thanks for the clarification.


On Mon, Jan 13, 2014 at 9:28 PM, Ben Mabey  wrote:

> On Mon Jan 13 18:11:10 2014, t x wrote:
>
>> Consider the following code block:
>>
>>
>> (defn make-stupid []
>>   (go (loop []
>> (recur
>>
>> (def x (make-stupid))
>>
>> ;; ... is there a way to kill this infinite go-loop ?
>>
>
> No, you can not kill the loop with the go channel that is bound to x.  You
> need to return a stop, a.k.a. poison, channel that the go block checks
> before recurring. Something like:
>
> (let [stop (chan)]
>  (go
>   (loop []
> (when (alt! stop false :default :keep-going)
>   ...
>   (recur
>  stop)
>
> -Ben
>
> --
> --
> 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/groups/opt_out.
>

-- 
-- 
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/groups/opt_out.

Re: go "kill infinite loop"

[Mark Mandel]

I found this macro I wrote really useful for exactly this type of thing:
https://github.com/markmandel/while-let

As long as you are happy for your go loop to stop when nil comes through
(i.e. when it gets closed).

(go (while-let [data ( wrote:

> Understood. Thanks for the clarification.
>
>
> On Mon, Jan 13, 2014 at 9:28 PM, Ben Mabey  wrote:
>
>> On Mon Jan 13 18:11:10 2014, t x wrote:
>>
>>> Consider the following code block:
>>>
>>>
>>> (defn make-stupid []
>>>   (go (loop []
>>> (recur
>>>
>>> (def x (make-stupid))
>>>
>>> ;; ... is there a way to kill this infinite go-loop ?
>>>
>>
>> No, you can not kill the loop with the go channel that is bound to x.
>>  You need to return a stop, a.k.a. poison, channel that the go block checks
>> before recurring. Something like:
>>
>> (let [stop (chan)]
>>  (go
>>   (loop []
>> (when (alt! stop false :default :keep-going)
>>   ...
>>   (recur
>>  stop)
>>
>> -Ben
>>
>> --
>> --
>> 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/groups/opt_out.
>>
>
>  --
> --
> 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/groups/opt_out.
>



-- 
E: mark.man...@gmail.com
T: http://www.twitter.com/neurotic
W: www.compoundtheory.com

2 Devs from Down Under Podcast
http://www.2ddu.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/groups/opt_out.

Re: go "kill infinite loop"

[Kelker Ryan]

Maybe something like this?

(go-loop [c (chan)]
  (let [x (:
> On Mon Jan 13 18:11:10 2014, t x wrote:
>
>>  Consider the following code block:
>>
>>  (defn make-stupid []
>>    (go (loop []
>>  (recur
>>
>>  (def x (make-stupid))
>>
>>  ;; ... is there a way to kill this infinite go-loop ?
>
> No, you can not kill the loop with the go channel that is bound to x.
> You need to return a stop, a.k.a. poison, channel that the go block
> checks before recurring. Something like:
>
> (let [stop (chan)]
>   (go
>    (loop []
>  (when (alt! stop false :default :keep-going)
>    ...
>    (recur
>   stop)
>
> -Ben
>
> --
> --
> 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/groups/opt_out.

-- 
-- 
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/groups/opt_out.

Re: go "kill infinite loop"

[t x]

I really like Mark's while-let.

I've always felt loop ... recur slightly cubersome, but never got around to
writing a custom macro to just get around it.

while-let much elegant. wow.


On Mon, Jan 13, 2014 at 9:49 PM, Kelker Ryan  wrote:

> Maybe something like this?
>
> (go-loop [c (chan)]
>   (let [x ( (when-not (= :break x)
>   (doing some things x)
>   (recur c
>
> 14.01.2014, 14:28, "Ben Mabey" :
> > On Mon Jan 13 18:11:10 2014, t x wrote:
> >
> >>  Consider the following code block:
> >>
> >>  (defn make-stupid []
> >>(go (loop []
> >>  (recur
> >>
> >>  (def x (make-stupid))
> >>
> >>  ;; ... is there a way to kill this infinite go-loop ?
> >
> > No, you can not kill the loop with the go channel that is bound to x.
> > You need to return a stop, a.k.a. poison, channel that the go block
> > checks before recurring. Something like:
> >
> > (let [stop (chan)]
> >   (go
> >(loop []
> >  (when (alt! stop false :default :keep-going)
> >...
> >(recur
> >   stop)
> >
> > -Ben
> >
> > --
> > --
> > 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/groups/opt_out.
>
> --
> --
> 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/groups/opt_out.
>

-- 
-- 
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/groups/opt_out.

Re: Eastwood lint tools - some Qs

[Andy Fingerhut]

Nicola can answer more authoritatively, as I haven't checked that part of
tools.analyzer recently, but I am pretty sure that the :arglists with
things like doc-string? attr-map? are simply treated as if they were normal
positional arguments, with no 'guessing' that they are optional due their
symbols ending with a question mark.

A function with :arglists ([x & xs]) is checked that it takes 1 or more
args, so only warning if a call is made with 0 args.  That is why the
current release of Eastwood will give incorrect :wrong-arity warning
messages if one manually sets :arglists for a function to something other
than what defn would make it.

For macros, they are all expanded during Eastwood analysis, so any
incorrect number of arguments should cause an exception to be thrown during
analysis, much like it would if you attempted to compile such code.

Andy


On Mon, Jan 13, 2014 at 6:57 PM, Colin Fleming
wrote:

> This is an interesting discussion, I've been thinking about some of these
> problems as I move towards adding inspections in Cursive. arglist parsing
> is a real problem in Clojure. I'd like to be able to flag invocations of
> functions with bad arities in the editor, but it's very difficult. Even
> defn is complicated, given that its :arglists is:
>
> :arglists '([name doc-string? attr-map? [params*] prepost-map? body]
> [name doc-string? attr-map? ([params*] prepost-map? body)+
> attr-map?])
>
> and its actual args declaration is:
>
> [&form &env name & fdecl]
>
> There's really no way to parse either of them automatically well. Does
> Eastwood use the actual fn declaration or :arglists for linting? What would
> it do in the case above? It's impossible to tell if doc-string? is a
> boolean or if it's an optional arg.
>
> Oh, and I agree that invalid :arglists as documentation is probably a bad
> idea, since it'll inevitably make this sort of tooling more difficult than
> it already is.
>
>
> On 14 January 2014 14:03, Sean Corfield  wrote:
>
>> On Jan 13, 2014, at 3:09 PM, Nicola Mometto  wrote:
>> > To be honest I don't like the idea of libraries attaching not-valid
>> > :arglists meta to Vars at all since the doc[1] for `def` says that
>> :arglists
>> > will be "a list of vector(s) of argument forms, as were supplied to
>> > defn" and the clojure Compiler uses :arglists for type-hints handling.
>>
>> I agree with you in principle - and I'm happy to change java.jdbc to
>> avoid the issue.
>>
>> Could Eastwood (or j.t.a) flag invalid :arglists? The "example" ones in
>> both java.jdbc and congomongo are clearly "invalid" according the special
>> forms page (but they silently "work"). Perhaps if Eastwood finds invalid /
>> suspicious metadata in :arglists, it could use a different linter warning?
>>
>> Sean Corfield -- (904) 302-SEAN
>> An Architect's View -- http://corfield.org/
>>
>> "Perfection is the enemy of the good."
>> -- Gustave Flaubert, French realist novelist (1821-1880)
>>
>>
>>
>>
>  --
> --
> 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/groups/opt_out.
>

-- 
-- 
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/groups/opt_out.

Re: Eastwood lint tools - some Qs

[Cedric Greevey]

IMO, :eastwood-arglist (and a proliferation of other tool-specific
metadata) would be exactly the wrong approach; :arglists should be the real
defn-form arglists. Instead there should be an optional :pretty-arglists
for documentation generators to use in lieu of :arglists if it is present.
That would address the documentation need while being tool-agnostic and not
prone to grow like kudzu until sometime before 2020 we wind up usually
writing defn forms like

(defn ^{:foo-arglists [a b & xyz] :special-tooly-stuff-count 42
:another-thingy-base /etc/data :another-thingy-defs /etc/data/.defs-file
:miscellaneous-stuff-v1.1 :pure-function :miscellaneous-stuff-v2.0
#{:pure-function :noprims} :superduperoptionizer4 #{[a? b] [a? b jump?
speed] [a? b jump? speed direction]} bar
  "docstring"
  ([&thingys]
...))



On Tue, Jan 14, 2014 at 12:56 AM, Andy Fingerhut
wrote:

> Nicola can answer more authoritatively, as I haven't checked that part of
> tools.analyzer recently, but I am pretty sure that the :arglists with
> things like doc-string? attr-map? are simply treated as if they were normal
> positional arguments, with no 'guessing' that they are optional due their
> symbols ending with a question mark.
>
> A function with :arglists ([x & xs]) is checked that it takes 1 or more
> args, so only warning if a call is made with 0 args.  That is why the
> current release of Eastwood will give incorrect :wrong-arity warning
> messages if one manually sets :arglists for a function to something other
> than what defn would make it.
>
> For macros, they are all expanded during Eastwood analysis, so any
> incorrect number of arguments should cause an exception to be thrown during
> analysis, much like it would if you attempted to compile such code.
>
> Andy
>
>
> On Mon, Jan 13, 2014 at 6:57 PM, Colin Fleming <
> colin.mailingl...@gmail.com> wrote:
>
>> This is an interesting discussion, I've been thinking about some of these
>> problems as I move towards adding inspections in Cursive. arglist parsing
>> is a real problem in Clojure. I'd like to be able to flag invocations of
>> functions with bad arities in the editor, but it's very difficult. Even
>> defn is complicated, given that its :arglists is:
>>
>> :arglists '([name doc-string? attr-map? [params*] prepost-map? body]
>> [name doc-string? attr-map? ([params*] prepost-map? body)+
>> attr-map?])
>>
>> and its actual args declaration is:
>>
>> [&form &env name & fdecl]
>>
>> There's really no way to parse either of them automatically well. Does
>> Eastwood use the actual fn declaration or :arglists for linting? What would
>> it do in the case above? It's impossible to tell if doc-string? is a
>> boolean or if it's an optional arg.
>>
>> Oh, and I agree that invalid :arglists as documentation is probably a bad
>> idea, since it'll inevitably make this sort of tooling more difficult than
>> it already is.
>>
>>
>> On 14 January 2014 14:03, Sean Corfield  wrote:
>>
>>> On Jan 13, 2014, at 3:09 PM, Nicola Mometto  wrote:
>>> > To be honest I don't like the idea of libraries attaching not-valid
>>> > :arglists meta to Vars at all since the doc[1] for `def` says that
>>> :arglists
>>> > will be "a list of vector(s) of argument forms, as were supplied to
>>> > defn" and the clojure Compiler uses :arglists for type-hints handling.
>>>
>>> I agree with you in principle - and I'm happy to change java.jdbc to
>>> avoid the issue.
>>>
>>> Could Eastwood (or j.t.a) flag invalid :arglists? The "example" ones in
>>> both java.jdbc and congomongo are clearly "invalid" according the special
>>> forms page (but they silently "work"). Perhaps if Eastwood finds invalid /
>>> suspicious metadata in :arglists, it could use a different linter warning?
>>>
>>> Sean Corfield -- (904) 302-SEAN
>>> An Architect's View -- http://corfield.org/
>>>
>>> "Perfection is the enemy of the good."
>>> -- Gustave Flaubert, French realist novelist (1821-1880)
>>>
>>>
>>>
>>>
>>  --
>> --
>> 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/groups/opt_out.
>>
>
>  --
> --
> 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 

Re: Eastwood lint tools - some Qs

[Colin Fleming]

Interesting - but there must be some sort of magic there since otherwise
every call to defn would be flagged, since its :arglists implies it has 6
arguments. And in fact, there's nothing there indicating that the body is
in fact the body.


On 14 January 2014 18:56, Andy Fingerhut  wrote:

> Nicola can answer more authoritatively, as I haven't checked that part of
> tools.analyzer recently, but I am pretty sure that the :arglists with
> things like doc-string? attr-map? are simply treated as if they were normal
> positional arguments, with no 'guessing' that they are optional due their
> symbols ending with a question mark.
>
> A function with :arglists ([x & xs]) is checked that it takes 1 or more
> args, so only warning if a call is made with 0 args.  That is why the
> current release of Eastwood will give incorrect :wrong-arity warning
> messages if one manually sets :arglists for a function to something other
> than what defn would make it.
>
> For macros, they are all expanded during Eastwood analysis, so any
> incorrect number of arguments should cause an exception to be thrown during
> analysis, much like it would if you attempted to compile such code.
>
> Andy
>
>
> On Mon, Jan 13, 2014 at 6:57 PM, Colin Fleming <
> colin.mailingl...@gmail.com> wrote:
>
>> This is an interesting discussion, I've been thinking about some of these
>> problems as I move towards adding inspections in Cursive. arglist parsing
>> is a real problem in Clojure. I'd like to be able to flag invocations of
>> functions with bad arities in the editor, but it's very difficult. Even
>> defn is complicated, given that its :arglists is:
>>
>> :arglists '([name doc-string? attr-map? [params*] prepost-map? body]
>> [name doc-string? attr-map? ([params*] prepost-map? body)+
>> attr-map?])
>>
>> and its actual args declaration is:
>>
>> [&form &env name & fdecl]
>>
>> There's really no way to parse either of them automatically well. Does
>> Eastwood use the actual fn declaration or :arglists for linting? What would
>> it do in the case above? It's impossible to tell if doc-string? is a
>> boolean or if it's an optional arg.
>>
>> Oh, and I agree that invalid :arglists as documentation is probably a bad
>> idea, since it'll inevitably make this sort of tooling more difficult than
>> it already is.
>>
>>
>> On 14 January 2014 14:03, Sean Corfield  wrote:
>>
>>> On Jan 13, 2014, at 3:09 PM, Nicola Mometto  wrote:
>>> > To be honest I don't like the idea of libraries attaching not-valid
>>> > :arglists meta to Vars at all since the doc[1] for `def` says that
>>> :arglists
>>> > will be "a list of vector(s) of argument forms, as were supplied to
>>> > defn" and the clojure Compiler uses :arglists for type-hints handling.
>>>
>>> I agree with you in principle - and I'm happy to change java.jdbc to
>>> avoid the issue.
>>>
>>> Could Eastwood (or j.t.a) flag invalid :arglists? The "example" ones in
>>> both java.jdbc and congomongo are clearly "invalid" according the special
>>> forms page (but they silently "work"). Perhaps if Eastwood finds invalid /
>>> suspicious metadata in :arglists, it could use a different linter warning?
>>>
>>> Sean Corfield -- (904) 302-SEAN
>>> An Architect's View -- http://corfield.org/
>>>
>>> "Perfection is the enemy of the good."
>>> -- Gustave Flaubert, French realist novelist (1821-1880)
>>>
>>>
>>>
>>>
>>  --
>> --
>> 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/groups/opt_out.
>>
>
>  --
> --
> 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/groups/opt_out.
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to c

Re: closing-buffer

[Michał Marczyk]

Instead of actually implementing a new channel type, you could use the
regular MTMCs, but with your own factory function, custom buffers and
a sprinkle of mutability:

(defprotocol PBufferThatMightCloseAChannel
  (this-is-your-channel! [this c]
"Informs the buffer that c is the channel it might need to close"))

;; implement a buffer with an impl for the above protocol;
;; have it close the appropriate channel on overflow;
;; suppose closing-buffer is the factory function
;; producing such channels

(defn closing-channel [n]
  (let [b (closing-buffer n)
c (chan b)]
(this-is-your-channel! b c)
c))

Cheers,
Michał


On 14 January 2014 05:47, t x  wrote:
> I am aware of:
>
>   DroppingBuffer and SliddingBuffer
>
> I would like to build a channel with different semantics:
>
>   When I try to put an item on a full channel:
>
>   * DroppingBuffer drops the new item
>   * SliddingBuffer evicts the oldest item
>
>   * ClosingBuffer should _close the channel_
>
> (thus, the receiver eventually gets a nil, and realizes "ah, was
> disconnected")
>
> Now, I am looking at the github core.async code:
>
> DroppingBuffer:
> https://github.com/clojure/core.async/blob/76317035d386ce2a1d98c2c349da9b898b480c55/src/main/clojure/clojure/core/async/impl/buffers.clj#L33-L45
>
> ManyToManyChannel:
> https://github.com/clojure/core.async/blob/76317035d386ce2a1d98c2c349da9b898b480c55/src/main/clojure/clojure/core/async/impl/channels.clj#L31-L198
>
> ## Problem:
>
> DroppingBuffer is easy to understand. However, I don't think I can implement
> "ClosingBuffer" as Buffer.
>
> I feel taht "ClosingBuffer" can only be implemneted at the Channel Level.
>
> However, the Channel Code is complicated.
>
> Is there a neat hack / trick to do what I described above?
>
> Thanks!
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

-- 
-- 
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/groups/opt_out.

Re: closing-buffer

[t x]

If I understand your strategy correctly, it works as follows:

* write new buffer class
* extend buffer class with a field/atom that stores the channel that owns
the buffer

* on overflow, call (async/close!) on the owned channel

However, looking at :

*
https://github.com/clojure/core.async/blob/master/src/main/clojure/clojure/core/async/impl/channels.clj#L179
*
https://github.com/clojure/core.async/blob/master/src/main/clojure/clojure/core/async/impl/channels.clj#L55

isn't this a deadlock by acquiring the mutex while holding the mutex?


On Mon, Jan 13, 2014 at 10:27 PM, Michał Marczyk
wrote:

> Instead of actually implementing a new channel type, you could use the
> regular MTMCs, but with your own factory function, custom buffers and
> a sprinkle of mutability:
>
> (defprotocol PBufferThatMightCloseAChannel
>   (this-is-your-channel! [this c]
> "Informs the buffer that c is the channel it might need to close"))
>
> ;; implement a buffer with an impl for the above protocol;
> ;; have it close the appropriate channel on overflow;
> ;; suppose closing-buffer is the factory function
> ;; producing such channels
>
> (defn closing-channel [n]
>   (let [b (closing-buffer n)
> c (chan b)]
> (this-is-your-channel! b c)
> c))
>
> Cheers,
> Michał
>
>
> On 14 January 2014 05:47, t x  wrote:
> > I am aware of:
> >
> >   DroppingBuffer and SliddingBuffer
> >
> > I would like to build a channel with different semantics:
> >
> >   When I try to put an item on a full channel:
> >
> >   * DroppingBuffer drops the new item
> >   * SliddingBuffer evicts the oldest item
> >
> >   * ClosingBuffer should _close the channel_
> >
> > (thus, the receiver eventually gets a nil, and realizes "ah, was
> > disconnected")
> >
> > Now, I am looking at the github core.async code:
> >
> > DroppingBuffer:
> >
> https://github.com/clojure/core.async/blob/76317035d386ce2a1d98c2c349da9b898b480c55/src/main/clojure/clojure/core/async/impl/buffers.clj#L33-L45
> >
> > ManyToManyChannel:
> >
> https://github.com/clojure/core.async/blob/76317035d386ce2a1d98c2c349da9b898b480c55/src/main/clojure/clojure/core/async/impl/channels.clj#L31-L198
> >
> > ## Problem:
> >
> > DroppingBuffer is easy to understand. However, I don't think I can
> implement
> > "ClosingBuffer" as Buffer.
> >
> > I feel taht "ClosingBuffer" can only be implemneted at the Channel Level.
> >
> > However, the Channel Code is complicated.
> >
> > Is there a neat hack / trick to do what I described above?
> >
> > Thanks!
> >
> > --
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Clojure" group.
> > To post to this group, send email to clojure@googlegroups.com
> > Note that posts from new members are moderated - please be patient with
> your
> > first post.
> > To unsubscribe from this group, send email to
> > clojure+unsubscr...@googlegroups.com
> > For more options, visit this group at
> > http://groups.google.com/group/clojure?hl=en
> > ---
> > You received this message because you are subscribed to the Google Groups
> > "Clojure" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to clojure+unsubscr...@googlegroups.com.
> > For more options, visit https://groups.google.com/groups/opt_out.
>
> --
> --
> 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/groups/opt_out.
>

-- 
-- 
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/groups/opt_out.

Re: Eastwood lint tools - some Qs

[Andy Fingerhut]

defn is a macro, and thus macro-expanded during Eastwood analysis, I
believe ignoring the :arglists.  I think it is really only the :arglists of
functions that matter for Eastwood :wrong-arity warnings

Andy


On Mon, Jan 13, 2014 at 10:22 PM, Colin Fleming  wrote:

> Interesting - but there must be some sort of magic there since otherwise
> every call to defn would be flagged, since its :arglists implies it has 6
> arguments. And in fact, there's nothing there indicating that the body is
> in fact the body.
>
>
> On 14 January 2014 18:56, Andy Fingerhut  wrote:
>
>> Nicola can answer more authoritatively, as I haven't checked that part of
>> tools.analyzer recently, but I am pretty sure that the :arglists with
>> things like doc-string? attr-map? are simply treated as if they were normal
>> positional arguments, with no 'guessing' that they are optional due their
>> symbols ending with a question mark.
>>
>> A function with :arglists ([x & xs]) is checked that it takes 1 or more
>> args, so only warning if a call is made with 0 args.  That is why the
>> current release of Eastwood will give incorrect :wrong-arity warning
>> messages if one manually sets :arglists for a function to something other
>> than what defn would make it.
>>
>> For macros, they are all expanded during Eastwood analysis, so any
>> incorrect number of arguments should cause an exception to be thrown during
>> analysis, much like it would if you attempted to compile such code.
>>
>> Andy
>>
>>
>> On Mon, Jan 13, 2014 at 6:57 PM, Colin Fleming <
>> colin.mailingl...@gmail.com> wrote:
>>
>>> This is an interesting discussion, I've been thinking about some of
>>> these problems as I move towards adding inspections in Cursive. arglist
>>> parsing is a real problem in Clojure. I'd like to be able to flag
>>> invocations of functions with bad arities in the editor, but it's very
>>> difficult. Even defn is complicated, given that its :arglists is:
>>>
>>> :arglists '([name doc-string? attr-map? [params*] prepost-map? body]
>>> [name doc-string? attr-map? ([params*] prepost-map? body)+
>>> attr-map?])
>>>
>>> and its actual args declaration is:
>>>
>>> [&form &env name & fdecl]
>>>
>>> There's really no way to parse either of them automatically well. Does
>>> Eastwood use the actual fn declaration or :arglists for linting? What would
>>> it do in the case above? It's impossible to tell if doc-string? is a
>>> boolean or if it's an optional arg.
>>>
>>> Oh, and I agree that invalid :arglists as documentation is probably a
>>> bad idea, since it'll inevitably make this sort of tooling more difficult
>>> than it already is.
>>>
>>>
>>> On 14 January 2014 14:03, Sean Corfield  wrote:
>>>
 On Jan 13, 2014, at 3:09 PM, Nicola Mometto 
 wrote:
 > To be honest I don't like the idea of libraries attaching not-valid
 > :arglists meta to Vars at all since the doc[1] for `def` says that
 :arglists
 > will be "a list of vector(s) of argument forms, as were supplied to
 > defn" and the clojure Compiler uses :arglists for type-hints handling.

 I agree with you in principle - and I'm happy to change java.jdbc to
 avoid the issue.

 Could Eastwood (or j.t.a) flag invalid :arglists? The "example" ones in
 both java.jdbc and congomongo are clearly "invalid" according the special
 forms page (but they silently "work"). Perhaps if Eastwood finds invalid /
 suspicious metadata in :arglists, it could use a different linter warning?

 Sean Corfield -- (904) 302-SEAN
 An Architect's View -- http://corfield.org/

 "Perfection is the enemy of the good."
 -- Gustave Flaubert, French realist novelist (1821-1880)




>>>  --
>>> --
>>> 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/groups/opt_out.
>>>
>>
>>  --
>> --
>> 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

[ANN] incise 0.1.0 - An extensible static site generator

[Ryan McGowan]

Hi all!

After consuming quite a bit of my spare time for the past several months, I 
have finally released version 0.1.0  of incise. 
It is a static site generator written in Clojure (of course). I like it 
quite a bit and I think others might benefit from it too.  I am very open 
to contributions, suggestions or criticisms (just open an 
issue)
.

Necessary links:

   - https://clojars.org/incise
   - http://www.ryanmcg.com/incise/ - README generated into website using 
   itself (it's called being meta).
   - https://github.com/RyanMcG/incise
   - https://github.com/RyanMcG/lein-incise - Yes there is a plugin
   - http://www.ryanmcg.com/2014/1/13/static-website-generation-with-incise/ - 
   Very short post about it. Basically points to the README and makes the 
   disclaimer that it's not a big deal.
   - https://github.com/RyanMcG/incise-example-project - super simple 
   example project
   - http://www.ryanmcg.com/incise-example-project/ - and its generated 
   output
   
Thanks,

Ryan McGowan

-- 
-- 
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/groups/opt_out.