Re: [ANN] Introducing Yagni, a Leiningen plugin for finding unused code

[Yehonathan Sharvit]

Does yagni work with cljs projects?

On Wednesday, 24 June 2015 02:27:46 UTC+3, Andrew Oberstar wrote:
>
> Haven't tried it yet, but looks good. Nice work!
>
> Andrew Oberstar
>
> On Tue, Jun 23, 2015 at 12:39 PM W. David Jarvis  > wrote:
>
>> Hello everyone. 
>>
>> I'm happy to announce the initial release of Yagni, a Leiningen plugin 
>> for finding unused code. 
>>
>> At a high level, Yagni works by identifying all of the interned vars in 
>> the namespaces findable within your :source-paths, and then walking the 
>> forms of those vars.
>>
>> As it walks the forms, it builds a graph of references to other vars. It 
>> then searches the graph from a set of entrypoints (by default your 
>> project's :main method), and emits warnings for any vars that it 
>> couldn't find in the graph's search.
>>
>> There's some other clever stuff going on there and some options for 
>> additional customization as well. I've written up a blog post, located 
>> here , that goes into considerably more 
>> detail on how the plugin works and what the project's roadmap looks like. 
>>
>> For those of you who want to look at the repository, it's on GitHub here: 
>> https://github.com/venantius/yagni
>>
>> And, of course, for those of you who just want to get started fiddling, 
>> you can add the following to your project's plugins map `[venantius/yagni 
>> "0.1.1"]` and type `lein yagni` to give it a whirl.
>>
>> Cheers!
>>
>>  - V
>>
>> -- 
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clo...@googlegroups.com 
>> 
>> Note that posts from new members are moderated - please be patient with 
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+u...@googlegroups.com 
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to clojure+u...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

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

Re: [ANN] Introducing Yo-yo, a protocol-less, function composition-based alternative to Component

[Atamert Ölçgen]

On Tue, Jun 23, 2015 at 11:47 PM, James Henderson 
wrote:

> Hi Atamert - thanks :)
>
> I thought it might be preferable to keep the call to (latch)explicit - it
> means that ylet can be used in nested calls, too - for example, to set up
> and compose groups of components/sub-systems: (contrived example, though!)
>
> ;; (docs for ylet at https://github.com/james-henderson/yoyo#introducing-ylet 
> )
>
> (require '[yoyo :refer [ylet]])
>
> (defn with-connections [config f]
>   (ylet [db-pool (with-db-pool (:db config))
>  es-conn (with-es-connection (:elasticsearch config))]
>
> (f {:db-pool db-pool
> :es-conn es-conn})))
>
> (defn make-system [latch]
>   (let [config ...]
> (ylet [connections (with-connections system)
>_ (with-webserver {:handler (make-handler (merge connections
> {:config config}))
>   :port 3000})]
>   (latch
>
>
> How would you see the with-* functions working, btw?
>

I think the general idea should be to provide a clean API to the consumer
(of your lib). Perhaps something that accepts a start function, a stop
function and some sort of main loop (f in your example).


>
> Cheers,
>
> James
>
> On Tuesday, 23 June 2015 09:57:16 UTC+1, Atamert Ölçgen wrote:
>>
>> Hi James,
>>
>> Interesting idea. Thanks for sharing.
>>
>> I think you can simplify this:
>>
>> (yoyo/run-system!
>>  (fn [latch]
>>(ylet [db-pool (with-db-pool {...})
>>   :let [server-opts {:handler (make-handler {:db-pool db-pool})
>>  :port 3000}]
>>   web-server (with-web-server server-opts)]
>>  (do-this web-server)
>>  (do-that db-pool web-server)
>>  (latch
>>
>>
>> to:
>>
>> (yoyo/foo! [db-pool (with-db-pool {...})
>> :let [server-opts {:handler (make-handler {:db-pool db-pool})
>>:port 3000}]
>> web-server (with-web-server server-opts)]
>>   (do-this web-server)
>>   (do-that db-pool web-server))
>>
>>
>> I believe with-* function can also be simplified further.
>>
>>
>> On Tue, Jun 23, 2015 at 1:18 AM, James Henderson 
>> wrote:
>>
>>> Hi all,
>>>
>>> I've just released an early version of 'Yo-yo', a protocol-less,
>>> function composition-based alternative to Component. It's still in its
>>> early stages, so feedback would be very much appreciated!
>>>
>>> https://github.com/james-henderson/yoyo
>>>
>>> Yo-yo was also an experiment to see what could be de-coupled from the
>>> concept of 'reloadable systems', so you won't find any configuration,
>>> dependency injection, etc - just a way to write a system that can be easily
>>> started, stopped, and reloaded.
>>>
>>> Fundamentally, we start by assuming there's a function available that
>>> only returns 'when the system stops' - a 'latch', say. If we had such a
>>> function, we could start our system, call that function, then stop the
>>> system (closing any necessary resources). A database pool, for example,
>>> might look like this:
>>>
>>> (defn with-db-pool [db-config f]
>>>   (let [db-pool (start-pool! db-config)]
>>> (try
>>>   (f db-pool)
>>>
>>>   (finally
>>> (stop-pool! db-pool)
>>>
>>> Here, we're assuming that we'll be passed 'f', the 'latch' function. A
>>> web server would be similar, and, because they're both functions, they're
>>> very simple to compose:
>>>
>>> (with-db-pool {...}
>>>   (fn [db-pool]
>>> (with-web-server {:handler (make-handler {:db-pool db-pool})
>>>   :port ...}
>>>   (fn [web-server]
>>> ;; TODO: Ah. We've run out of turtles. :(
>>> 
>>>
>>> This is where Yo-yo comes in - there’s a function called run-system!,
>>> which takes a function that accepts a latch:
>>>
>>> (:require [yoyo])
>>>
>>> (yoyo/run-system!
>>>   (fn [latch]
>>> (with-db-pool {...}
>>>   (fn [db-pool]
>>> (with-web-server {:handler (make-handler {:db-pool db-pool}) ; n.b. 
>>> we have access to the db-pool here - no need for global state!
>>>   :port ...}
>>>   (fn [web-server]
>>> (latch))) ; Aha!
>>>
>>> run-system! then returns a promise - deliver any value to it, and it'll
>>> stop the system.
>>>
>>> And that's pretty much it! There are a few more functions - mostly to do
>>> with easily starting/stopping/reloading a system through the REPL, and a
>>> macro to simplify the 'function staircase' - these are covered in more
>>> detail in the README. There are some also common components - a database
>>> pool, a web server, and a simple integration for existing Component systems.
>>>
>>> It'd be great to hear your thoughts/ideas, whatever they may be - either
>>> through here, e-mail, Github, or Twitter - thanks!
>>>
>>> James
>>>
>>>  --
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To post to this group, send email to clo...

Re: Writing REST api the right way

[Tommi Reiman]

Hi.

About the documentation - at least ring-swagger[1] doesn't force you to use 
Schema as the runtime validation library, it just expects the route (and 
parameter) definitions to be presented to it as Schemas. So, you could 
validate the routes using bouncer and extract the ring-swagger schemas out 
of those just for documentation purposes [2,3]. Another option would be to 
write directly bouncer -> swagger json schema mappings. Or ring-swagger 
could be made to support different parameter formats (native swagger, json 
schema, bouncer) via protocol extensions.

[1] https://github.com/metosin/ring-swagger
[2] 
https://github.com/metosin/ring-swagger/blob/master/src/ring/swagger/swagger2_schema.clj
[3] 
https://github.com/metosin/ring-swagger/blob/master/test/ring/swagger/swagger2_test.clj

tiistai 23. kesäkuuta 2015 11.33.50 UTC+2 Mike Grabowski kirjoitti:
>
> Hey guys,
>
> I am so excited to join Clojure bandwagon, last weeks have been super 
> exciting, pretty much in love with Clojure syntax. As we are currently 
> building an application broken into smaller micro services, I thought I am 
> gonna make one or two Clojure based modules. Although the initial purpose 
> of picking the language was to do some CPU demand calculations and data 
> processing, I found it really simple yet enjoyable to write REST api as 
> well (we also use Node.js and Elixir for that purpose and it works pretty 
> well - especially with Elixir thanks to awesome yet simple Erlang model 
> where you can `spawn&block` and be happy).
>
> I've seen lots of benchmarks already featuring Aleph, Jetty, Vert.x and 
> other HTTP servers and I am currently with `Aleph` thanks to its ability to 
> handle channels and futures out of the box. Unfortunately, because I spent 
> so many years with Node.js and stopped using Java ages ago, I just can't 
> stop thinking about non-blocking evented IO interactions. It just does not 
> feel right to me to block the thread when e.g. logging in an user. 
> Unfortunately, there are no NIO drivers for the database engines I am 
> interested in (Neo4J, Mongo) so async channels are not the way to go.
>
> Any advices or interesting thoughts? Maybe I am missing something as I am 
> not entirely sure if evented IO is always speeding up the overall 
> performance. Any performance optimisations are welcome. I am especially 
> unhappy with one Neo4J request that takes 1.5 second to finish (it's only 
> because the database is hosted on free Heroku plan and this is not going to 
> happen in production but I find it quite a good place to tweak the 
> optimisations and concurrency).
>
> Another question is - is there any documentation generator that can parse 
> your comments, take keywords like `:params` or `:returns` (just the idea) 
> and generate beautiful API docs out of the box? Swagger is not a way to go 
> as it requires me to use `Schema` plugin - I am currently with `bouncer` 
> thanks to more real-life validators as well as user friendly messages that 
> I can just print to users out of the box (maybe it's worth building as an 
> open source module then)
>
> Thanks 
>
>

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

Compojure character encoding

[Jonathon McKitrick]

I have a web app that apparently cannot consume UTF-8 encoding.  Can 
compojure generate responses in latin-1 encoding?

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

Re: Compojure character encoding

[James Reeves]

Yes, you can return a full response map with the desired encoding:

  (GET "/" []
{:status 200
 :headers {"Content-Type" "text/html; charset=ISO-8859-1"}
 :body "Hello World"})

Or use the ring.util.response namespace:

  (GET "/" []
(-> (resp/response "Hello World")
(resp/charset "ISO-8859-1")))

Or write some middleware to change the charset globally:

  (defn text-response? [response]
(some-> (resp/get-header response "Content-Type")
(.startsWith "text/")))

  (defn wrap-charset [handler charset]
(fn [request]
  (let [response (handler request)]
(if (text-response? response)
  (resp/charset response "ISO-8859-1")
  response

However, it's odd that you "can't consume UTF-8 encoding". Are you sure
that's the problem?

- James


On 24 June 2015 at 14:47, Jonathon McKitrick  wrote:

> I have a web app that apparently cannot consume UTF-8 encoding.  Can
> compojure generate responses in latin-1 encoding?
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Compojure character encoding

[Jonathon McKitrick]

Thanks, James.

To clarify, Compojure has no problems serving the JSON content.  But the 
SBCL common lisp app and a third-party app (Klipfolio) both are choking on 
the output.  I was able to fix the SBCL app by telling Babel to use latin-1 
encoding, but I need another solution for the output to Klipfolio.  It's 
probably a knowledge gap on my part of correct use of encodings, and I just 
haven't found the 'correct' solution yet.

On Wednesday, June 24, 2015 at 9:23:36 AM UTC-4, James Reeves wrote:
>
> Yes, you can return a full response map with the desired encoding:
>
>   (GET "/" []
> {:status 200
>  :headers {"Content-Type" "text/html; charset=ISO-8859-1"}
>  :body "Hello World"})
>
> Or use the ring.util.response namespace:
>
>   (GET "/" []
> (-> (resp/response "Hello World")
> (resp/charset "ISO-8859-1")))
>
> Or write some middleware to change the charset globally:
>
>   (defn text-response? [response]
> (some-> (resp/get-header response "Content-Type")
> (.startsWith "text/")))
>
>   (defn wrap-charset [handler charset]
> (fn [request]
>   (let [response (handler request)]
> (if (text-response? response)
>   (resp/charset response "ISO-8859-1")
>   response
>
> However, it's odd that you "can't consume UTF-8 encoding". Are you sure 
> that's the problem?
>
> - James
>
>
> On 24 June 2015 at 14:47, Jonathon McKitrick  > wrote:
>
>> I have a web app that apparently cannot consume UTF-8 encoding.  Can 
>> compojure generate responses in latin-1 encoding?
>>
>> -- 
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clo...@googlegroups.com 
>> 
>> Note that posts from new members are moderated - please be patient with 
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+u...@googlegroups.com 
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to clojure+u...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

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

Online hacktahon on June 27 - Clojure available

[Maria Martin]

Hi everyone,

Just to let you know about an online hackathon that may be of interest to 
you: http://www.codingame.com/challenge/code-of-the-rings
The concept is: 24 hours to code and optimize a solution to a problem. It's 
free and open to all.
There are other games to train on the platform (page games)

Don't hesitate to tell us what you think,

Maria

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

Re: Compojure character encoding

[James Reeves]

Well, JSON should be encoded in unicode (either UTF-8, UTF-16 or UTF-32,
with UTF-8 as the default), so the clients shouldn't be having a problem if
their JSON parsers are correct.

However, you may want to try the :escape-non-ascii option that Cheshire and
Ring-JSON have. e.g.

(wrap-json-response app {:escape-non-ascii true})

This will ensure all strings in the JSON are ASCII-encoded, which may be
easier for the clients you're trying to support.

- James

On 24 June 2015 at 15:29, Jonathon McKitrick  wrote:

> Thanks, James.
>
> To clarify, Compojure has no problems serving the JSON content.  But the
> SBCL common lisp app and a third-party app (Klipfolio) both are choking on
> the output.  I was able to fix the SBCL app by telling Babel to use latin-1
> encoding, but I need another solution for the output to Klipfolio.  It's
> probably a knowledge gap on my part of correct use of encodings, and I just
> haven't found the 'correct' solution yet.
>
> On Wednesday, June 24, 2015 at 9:23:36 AM UTC-4, James Reeves wrote:
>>
>> Yes, you can return a full response map with the desired encoding:
>>
>>   (GET "/" []
>> {:status 200
>>  :headers {"Content-Type" "text/html; charset=ISO-8859-1"}
>>  :body "Hello World"})
>>
>> Or use the ring.util.response namespace:
>>
>>   (GET "/" []
>> (-> (resp/response "Hello World")
>> (resp/charset "ISO-8859-1")))
>>
>> Or write some middleware to change the charset globally:
>>
>>   (defn text-response? [response]
>> (some-> (resp/get-header response "Content-Type")
>> (.startsWith "text/")))
>>
>>   (defn wrap-charset [handler charset]
>> (fn [request]
>>   (let [response (handler request)]
>> (if (text-response? response)
>>   (resp/charset response "ISO-8859-1")
>>   response
>>
>> However, it's odd that you "can't consume UTF-8 encoding". Are you sure
>> that's the problem?
>>
>> - James
>>
>>
>> On 24 June 2015 at 14:47, Jonathon McKitrick  wrote:
>>
>>> I have a web app that apparently cannot consume UTF-8 encoding.  Can
>>> compojure generate responses in latin-1 encoding?
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To post to this group, send email to clo...@googlegroups.com
>>> Note that posts from new members are moderated - please be patient with
>>> your first post.
>>> To unsubscribe from this group, send email to
>>> clojure+u...@googlegroups.com
>>> For more options, visit this group at
>>> http://groups.google.com/group/clojure?hl=en
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to clojure+u...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>

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

[ANN] CIDER 0.9.1

[Bozhidar Batsov]

Hi everyone,

CIDER 0.9.1 (codename “EuroCIDER”) is out! The release notes are here
https://github.com/clojure-emacs/cider/releases/tag/v0.9.1

This release fixes pretty much all serious issues that were discovered
shortly after 0.9.0 went
live and (as you probably have guessed by now) is dedicated to EuroClojure.
Enjoy EuroClojure and EuroCIDER!

For me it's time to start packing for my flight. See you at Barcelona!

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

[ANN] aleph-middleware: Ring middleware that support deferred responses.

[Atamert Ölçgen]

Hi,

https://github.com/muhuk/aleph-middleware

This is library that provides deferred-friendly versions of some of the
middleware that's shipped with ring-core. Specifically ones that modify
responses. They were choking on deferred's so I had to modify them a bit.

Let me know if it's useful.


-- 
Kind Regards,
Atamert Ölçgen

◻◼◻
◻◻◼
◼◼◼

www.muhuk.com

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

Re: transducer (+ closures) efficiency question

[Herwig Hochleitner]

2015-06-24 1:25 GMT+02:00 Ben Wolfson :

> On Tue, Jun 23, 2015 at 4:17 PM, Ghadi Shayban  wrote:
>
>>
>> Tangentially:
>> (remove even?)
>> Will be faster than
>> (remove (fn [i] (even? i)))
>> because in the first case the dereference of the var 'even?' happens only
>> once and the value inside the var will be passed to `remove` at the
>> outset.  In the second example the var dereference happens for every single
>> item (though it's very cheap).  The second example is equivalent to writing 
>> (remove
>> #'even?)
>>
>
> I can't seem to observe a difference between the two cases.
>

A simple var reference like even? compiles to a fetch of its root val:
@#'even?
In the first case, that happens only once, passing the resulting fn object
to remove. In the second case, the deref happens every time the fn is
called, thus allowing for redefinition of even?.

Have you ever passed passed #'handler to a server-start function (e.g. in a
ring app), so that you might redefine the handler fn during run time of the
server?

Ad. thread topic: As detailed, clojure's evaluation semantics already help
with transducers. Even better: Built transducer stacks should be pretty
accessible to the JIT, since they contain no more var references (in the
wiring). Also, since transducers are a kind of lexically closed pipe from
input effect to output effect, hotspot's escape analysis should also kick
in nicely.

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

Re: transducer (+ closures) efficiency question

[Ben Wolfson]

On Wed, Jun 24, 2015 at 8:29 AM, Herwig Hochleitner 
wrote:

>
>
> 2015-06-24 1:25 GMT+02:00 Ben Wolfson :
>
>> On Tue, Jun 23, 2015 at 4:17 PM, Ghadi Shayban 
>> wrote:
>>
>>>
>>> Tangentially:
>>> (remove even?)
>>> Will be faster than
>>> (remove (fn [i] (even? i)))
>>> because in the first case the dereference of the var 'even?' happens
>>> only once and the value inside the var will be passed to `remove` at the
>>> outset.  In the second example the var dereference happens for every single
>>> item (though it's very cheap).  The second example is equivalent to writing 
>>> (remove
>>> #'even?)
>>>
>>
>> I can't seem to observe a difference between the two cases.
>>
>
> A simple var reference like even? compiles to a fetch of its root val:
> @#'even?
> In the first case, that happens only once, passing the resulting fn object
> to remove. In the second case, the deref happens every time the fn is
> called, thus allowing for redefinition of even?.
>

I meant a difference in speed.

-- 
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/d/optout.

Re: transducer (+ closures) efficiency question

[Leon Grapenthin]

Using a set as filter predicate is idiomatic Clojure.

If you don't know whether your filter coll is a set, you can write your 
filter-contains as

(def filter-contains (comp filter set))

E. g. use as

(into [] (filter-contains [1 2 3]) [1 2 3 4]) 
;-> [4]

I am not up to date about optimizations in the PersistentHashSet world, but 
I'd assume for very small filter colls you can gain speed with a linear 
scan instead of contains?.

If you are ok with input, output and filter being a set, I'd recommend 
looking at clojure.set/intersection for that task. It optimizes by reducing 
the smaller set. Depending on the sizes of the collections you are dealing 
with, the set conversion cost may be worth the speed up you can gain. 


On Wednesday, June 24, 2015 at 12:07:06 AM UTC+2, Sam Raker wrote:
>
> Let's say that, as part of an xf, I want to filter out everything in a 
> sequence that's also in some other sequence. Here are some ways of doing 
> that:
>
> (defn filter-contains1 [edn-file] (remove (partial contains? (set (read-
> edn-file edn-file)
>
> (defn filter-contains2 [coll] (remove (partial contains? (set coll
>
> (def filter-contains3 [coll] (let [coll-as-set (set coll)] (remove (
> partial contains? (set coll)
>
> I have the strong suspicion that `filter-contains3` is the best of the 3, 
> and `filter-contains1` the worst. The internal mechanics of transduce are a 
> bit of a mystery to me, however: if `filter-contains2` were to be used on a 
> collection of, say, a million items, would `coll` be cast to a set a 
> million times, or is Clojure/the JVM smarter than that? I'm also wondering 
> if anyone has any "best practices" (or whatever) they can share relating to 
> this kind of intersection of transducers/xfs and closures. It seems to me, 
> for example, that something like
>
> (defn my-thing [coll & stuff]
>   (let [s (set coll)]
>   ...
>   (comp
> ...
>(map foo)
>(filter bar)
>(remove (partial contains? s))
>...
>
> is awkward, but that a lot of limited-use transducer factory functions 
> (like the ones above) aren't exactly optimal, either.
>

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

Re: transducer (+ closures) efficiency question

[Leon Grapenthin]

Correction: The result in the example should be [1 2 3] of course.

On Wednesday, June 24, 2015 at 6:34:20 PM UTC+2, Leon Grapenthin wrote:
>
> Using a set as filter predicate is idiomatic Clojure.
>
> If you don't know whether your filter coll is a set, you can write your 
> filter-contains as
>
> (def filter-contains (comp filter set))
>
> E. g. use as
>
> (into [] (filter-contains [1 2 3]) [1 2 3 4]) 
> ;-> [4]
>
> I am not up to date about optimizations in the PersistentHashSet world, 
> but I'd assume for very small filter colls you can gain speed with a linear 
> scan instead of contains?.
>
> If you are ok with input, output and filter being a set, I'd recommend 
> looking at clojure.set/intersection for that task. It optimizes by reducing 
> the smaller set. Depending on the sizes of the collections you are dealing 
> with, the set conversion cost may be worth the speed up you can gain. 
>
>
> On Wednesday, June 24, 2015 at 12:07:06 AM UTC+2, Sam Raker wrote:
>>
>> Let's say that, as part of an xf, I want to filter out everything in a 
>> sequence that's also in some other sequence. Here are some ways of doing 
>> that:
>>
>> (defn filter-contains1 [edn-file] (remove (partial contains? (set (read-
>> edn-file edn-file)
>>
>> (defn filter-contains2 [coll] (remove (partial contains? (set coll
>>
>> (def filter-contains3 [coll] (let [coll-as-set (set coll)] (remove (
>> partial contains? (set coll)
>>
>> I have the strong suspicion that `filter-contains3` is the best of the 3, 
>> and `filter-contains1` the worst. The internal mechanics of transduce are a 
>> bit of a mystery to me, however: if `filter-contains2` were to be used on a 
>> collection of, say, a million items, would `coll` be cast to a set a 
>> million times, or is Clojure/the JVM smarter than that? I'm also wondering 
>> if anyone has any "best practices" (or whatever) they can share relating to 
>> this kind of intersection of transducers/xfs and closures. It seems to me, 
>> for example, that something like
>>
>> (defn my-thing [coll & stuff]
>>   (let [s (set coll)]
>>   ...
>>   (comp
>> ...
>>(map foo)
>>(filter bar)
>>(remove (partial contains? s))
>>...
>>
>> is awkward, but that a lot of limited-use transducer factory functions 
>> (like the ones above) aren't exactly optimal, either.
>>
>

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

Re: transducer (+ closures) efficiency question

[Herwig Hochleitner]

2015-06-24 18:19 GMT+02:00 Ben Wolfson :

>
> I meant a difference in speed.
>
>
A var-root fetch is a volatile read, which can have several adverse
performance effects. Most importantly, it hinders inlining, since the JIT
has to place a guard for every inlining site of a volatile read, thus it
won't so readily inline.
Even when inlined, there must be a memory barrier for the guard, which can
lead to pipeline flushes, bus communication and other stalls in execution.

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

Re: [ANN] Introducing Yagni, a Leiningen plugin for finding unused code

[juan.facorro]

Yehonathan Sharvit,

I think Google's Closure compiler already has dead code elimination, so 
it's available for ClojureScript even if Yagni doesn't provide it :).

Cheers,

Juan

On Wednesday, June 24, 2015 at 5:11:01 AM UTC-3, Yehonathan Sharvit wrote:
>
> Does yagni work with cljs projects?
>
> On Wednesday, 24 June 2015 02:27:46 UTC+3, Andrew Oberstar wrote:
>>
>> Haven't tried it yet, but looks good. Nice work!
>>
>> Andrew Oberstar
>>
>> On Tue, Jun 23, 2015 at 12:39 PM W. David Jarvis  
>> wrote:
>>
>>> Hello everyone. 
>>>
>>> I'm happy to announce the initial release of Yagni, a Leiningen plugin 
>>> for finding unused code. 
>>>
>>> At a high level, Yagni works by identifying all of the interned vars in 
>>> the namespaces findable within your :source-paths, and then walking the 
>>> forms of those vars.
>>>
>>> As it walks the forms, it builds a graph of references to other vars. It 
>>> then searches the graph from a set of entrypoints (by default your 
>>> project's :main method), and emits warnings for any vars that it 
>>> couldn't find in the graph's search.
>>>
>>> There's some other clever stuff going on there and some options for 
>>> additional customization as well. I've written up a blog post, located 
>>> here , that goes into considerably more 
>>> detail on how the plugin works and what the project's roadmap looks like. 
>>>
>>> For those of you who want to look at the repository, it's on GitHub 
>>> here: https://github.com/venantius/yagni
>>>
>>> And, of course, for those of you who just want to get started fiddling, 
>>> you can add the following to your project's plugins map `[venantius/yagni 
>>> "0.1.1"]` and type `lein yagni` to give it a whirl.
>>>
>>> Cheers!
>>>
>>>  - V
>>>
>>> -- 
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To post to this group, send email to clo...@googlegroups.com
>>> Note that posts from new members are moderated - please be patient with 
>>> your first post.
>>> To unsubscribe from this group, send email to
>>> clojure+u...@googlegroups.com
>>> For more options, visit this group at
>>> http://groups.google.com/group/clojure?hl=en
>>> --- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "Clojure" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to clojure+u...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>

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

Re: Writing REST api the right way

[Stuart Sierra]

On Tuesday, June 23, 2015, Mike Grabowski wrote:
> ... I just can't stop thinking about non-blocking evented
> IO interactions. It just does not feel right to me to
> block the thread when e.g. logging in an user.
> Unfortunately, there are no NIO drivers for the database
> engines I am interested in (Neo4J, Mongo) so async
> channels are not the way to go.

This is pretty much unavoidable on the JVM. Java started
with a multi-threaded blocking I/O model, and that's still
how most Java code is written despite the availability of
non-blocking I/O.

The typical way to mitigate this in Java is with thread
pools. The JVM is capable of handling hundreds of threads,
and modern operating systems are pretty good at
context-switching.

For an extreme example, look at Netflix's [Hystrix], which
isolates *every* library in its own thread pool, so they can
guarantee timeouts and other bounded behaviors. Netflix
reports that the overhead of extra threads is worth the
more-predictable behavior.

[Hystrix]: https://github.com/Netflix/Hystrix

-S

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

Re: transducer (+ closures) efficiency question

[Alan Shaw]

As with all discussions involving interoperability, I'd love to see the
same questions answered for the JS target too. (This would of course apply
to books such as the new Clojure Applied. )
On Jun 24, 2015 9:48 AM, "Herwig Hochleitner" 
wrote:

>
>
> 2015-06-24 18:19 GMT+02:00 Ben Wolfson :
>
>>
>> I meant a difference in speed.
>>
>>
> A var-root fetch is a volatile read, which can have several adverse
> performance effects. Most importantly, it hinders inlining, since the JIT
> has to place a guard for every inlining site of a volatile read, thus it
> won't so readily inline.
> Even when inlined, there must be a memory barrier for the guard, which can
> lead to pipeline flushes, bus communication and other stalls in execution.
>
>  --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Writing REST api the right way

[Mike Grabowski]

Thanks for the reference, I've seen it before and it looks interesting, 
especially thanks to the failover built-in. It also greatly shows how 
Clojure can reduce the `Java boilerplate`. 

Speaking on the performance note, I am not entirely sure what's causing my 
REST API to be slower than `Node.js` one, I have two the same auth logic 
implemented in both Node/Clojure. The Node.js version is running on Heroku 
(London) with MongoLab hosted in (US-east-1) which can handle login in 
140ms. On the other hand, the Clojure Aleph/Compojure hosted in London on 
DigitalOcean with MongoHQ database hosted in the same DigitalOcean region 
handles the same thing in 350ms in the best case. This is really weird as 
the `non-database` request is 40ms faster than Node.js one. I need to 
investigate, but apart from that, all good so far.

On Wednesday, 24 June 2015 20:49:40 UTC+2, Stuart Sierra wrote:
>
> On Tuesday, June 23, 2015, Mike Grabowski wrote:
> > ... I just can't stop thinking about non-blocking evented
> > IO interactions. It just does not feel right to me to
> > block the thread when e.g. logging in an user.
> > Unfortunately, there are no NIO drivers for the database
> > engines I am interested in (Neo4J, Mongo) so async
> > channels are not the way to go.
>
> This is pretty much unavoidable on the JVM. Java started
> with a multi-threaded blocking I/O model, and that's still
> how most Java code is written despite the availability of
> non-blocking I/O.
>
> The typical way to mitigate this in Java is with thread
> pools. The JVM is capable of handling hundreds of threads,
> and modern operating systems are pretty good at
> context-switching.
>
> For an extreme example, look at Netflix's [Hystrix], which
> isolates *every* library in its own thread pool, so they can
> guarantee timeouts and other bounded behaviors. Netflix
> reports that the overhead of extra threads is worth the
> more-predictable behavior.
>
> [Hystrix]: https://github.com/Netflix/Hystrix
>
> -S
>

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

pr-str and safe serialization

[Ignacio Thayer]

I think this might be rehashing some old stuff, but I haven't seen 
discussion on it recently and I see this behavior is still present in 1.7 
so I thought I'd ask. It's the same underlying issue as 
this: 
http://dev.clojure.org/jira/browse/CLJ-1532?page=com.atlassian.jira.plugin.system.issuetabpanels:changehistory-tabpanel#issue-tabs

Having pr-str binding to the same *out* that's used by printing seems 
dangerous - is there a more commonly accepted standard way to serialize for 
edn?  

We've been using Clojure in production at ReadyForZero for 4 years and 
haven't encountered this, but began using a lib that uses edn, and stumbled 
on unexpected behavior (described below).

Thanks guys.

ignacio



Just for other's sake, here is simplified code that demonstrates the 
surprising behavior we encountered. The real code is nested several levels 
and so was not as easy to spot.

EXPECTED: 

app.core.redirect-service> (def _xs (map #(lg/warn (pr-str {:x "test" :y 
%})) [1 2 3]))
#'app.core.redirect-service/_xs
app.core.redirect-service> _xs ;; Force evaluation
(nil nil nil)

output on log:

WARN  nREPL-worker-69 20150623 220028,098 
app.core.redirect-service ] {:x "test", :y 1} ;; "test" correctly printed 
w/ quotes, serialized as string
WARN  nREPL-worker-69 20150623 220028,099 
app.core.redirect-service ] {:x "test", :y 2}
WARN  nREPL-worker-69 20150623 220028,099 
app.core.redirect-service ] {:x "test", :y 3}


UNEXPECTED:

app.core.redirect-service> (def _xs (map #(lg/warn (pr-str {:x "test" :y 
%})) [1 2 3]))
#'app.core.redirect-service/_xs
app.core.redirect-service> (lg/warn _xs) ;; Force evaluation, but bind to 
*out*
nil

output on log:

WARN  nREPL-worker-69 20150623 220044,748 
app.core.redirect-service ] {:x test, :y 1} ;; "test" incorrectly printed 
w/out quotes, serialized as symbol
WARN  nREPL-worker-69 20150623 220044,749 
app.core.redirect-service ] {:x test, :y 2}
WARN  nREPL-worker-69 20150623 220044,749 
app.core.redirect-service ] {:x test, :y 3}
WARN  nREPL-worker-69 20150623 220044,750 
app.core.redirect-service ] (nil nil nil)

>>>

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

Re: [ANN] Introducing Yagni, a Leiningen plugin for finding unused code

[Fluid Dynamics]

 FMIIW, but I think they serve orthogonal purposes. Google Closure finds 
code (mostly library parts your program doesn't use) that your particular 
program doesn't need and omits it from the build to save disk and 
bandwidth. Yagni finds obsolete code that is no longer reached in your 
program or from *any* public entry point to your library (whether a 
particular program uses that entry point or not) and issues warnings, so 
you know that either something is maintenance deadweight or you have a bug 
because you *meant* to call it somewhere but forgot, or it's become 
accidentally shadowed or something.

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

Re: [ANN] Introducing Yagni, a Leiningen plugin for finding unused code

[juan.facorro]

That's a good point.

On Wednesday, June 24, 2015 at 6:53:43 PM UTC-3, Fluid Dynamics wrote:
>
>  FMIIW, but I think they serve orthogonal purposes. Google Closure finds 
> code (mostly library parts your program doesn't use) that your particular 
> program doesn't need and omits it from the build to save disk and 
> bandwidth. Yagni finds obsolete code that is no longer reached in your 
> program or from *any* public entry point to your library (whether a 
> particular program uses that entry point or not) and issues warnings, so 
> you know that either something is maintenance deadweight or you have a bug 
> because you *meant* to call it somewhere but forgot, or it's become 
> accidentally shadowed or something.
>

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

Re: Writing REST api the right way

[Fluid Dynamics]

On Wednesday, June 24, 2015 at 4:03:39 PM UTC-4, Mike Grabowski wrote:
>
> Thanks for the reference, I've seen it before and it looks interesting, 
> especially thanks to the failover built-in. It also greatly shows how 
> Clojure can reduce the `Java boilerplate`. 
>
> Speaking on the performance note, I am not entirely sure what's causing my 
> REST API to be slower than `Node.js` one, I have two the same auth logic 
> implemented in both Node/Clojure. The Node.js version is running on Heroku 
> (London) with MongoLab hosted in (US-east-1) which can handle login in 
> 140ms. On the other hand, the Clojure Aleph/Compojure hosted in London on 
> DigitalOcean with MongoHQ database hosted in the same DigitalOcean region 
> handles the same thing in 350ms in the best case. This is really weird as 
> the `non-database` request is 40ms faster than Node.js one. I need to 
> investigate, but apart from that, all good so far. 
>

350ms sounds fast enough for a low-frequency user interaction. In fact, 
once login is fast enough not to annoy your users, you don't *want* any 
more speed from it, as further speedup then only benefits blackhats trying 
to brute-force one of your users' accounts. So, it might be a feature, not 
a bug.

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

Re: Writing REST api the right way

[Raoul Duke]

> 350ms sounds fast enough for a low-frequency user interaction. In fact, once
> login is fast enough not to annoy your users, you don't *want* any more
> speed from it, as further speedup then only benefits blackhats trying to
> brute-force one of your users' accounts. So, it might be a feature, not a
> bug.

Those seem like really weird statements to me. :-)

a) I thought it was 250 msec as the upper abound for things feeling
snappy. Tho others apparently say 100 msec or less.
http://stackoverflow.com/questions/536300/what-is-the-shortest-perceivable-application-response-delay

b) If anybody is relying on 350 msec vs. e.g. 100 msec as some grand
solution to black hats brute forcing logins, I strongly suspect they
are doing it very wrong.

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

Re: pr-str and safe serialization

[Fluid Dynamics]

On Wednesday, June 24, 2015 at 4:56:06 PM UTC-4, Ignacio Thayer wrote:
>
> I think this might be rehashing some old stuff, but I haven't seen 
> discussion on it recently and I see this behavior is still present in 1.7 
> so I thought I'd ask. It's the same underlying issue as this: 
> http://dev.clojure.org/jira/browse/CLJ-1532?page=com.atlassian.jira.plugin.system.issuetabpanels:changehistory-tabpanel#issue-tabs
>
> Having pr-str binding to the same *out* that's used by printing seems 
> dangerous - is there a more commonly accepted standard way to serialize for 
> edn?
>

It's not hard to make a wrapper. Binding *out* io/writer my-output-stream), 
binding *print-dup* true, pr-str foo, close parenthesis, close parenthesis. 
Maybe it should be under clojure.edn as edn/write or something, but at 
least it's nigh trivial to write. My main complaint with edn is that 
*reading* isn't platform independent because you need to wrap io/reader in 
a PushbackReader on JVM. There's nothing in the io or edn libraries to make 
a reader that read-string and edn/read will accept, so you have to juggle 
platforms in your own code, and even with cljc that's a nuisance that might 
have been avoided if there's nothing else platform-varying that you need 
that isn't abstracted behind some multi-platform library.

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

Re: [ANN] Introducing Yagni, a Leiningen plugin for finding unused code

[W. David Jarvis]

Indeed. I'd argue it's better not to have unused code in the codebase in 
the first place, regardless of what the Closure compiler does to help when 
it comes to compiling assets. 

I haven't tested this with cljs projects, but on the face of it I don't see 
why Yagni's methodology wouldn't work. If you get a chance to give it a try 
I'd love the feedback :)

On Wednesday, June 24, 2015 at 2:58:14 PM UTC-7, juan.facorro wrote:
>
> That's a good point.
>
> On Wednesday, June 24, 2015 at 6:53:43 PM UTC-3, Fluid Dynamics wrote:
>>
>>  FMIIW, but I think they serve orthogonal purposes. Google Closure finds 
>> code (mostly library parts your program doesn't use) that your particular 
>> program doesn't need and omits it from the build to save disk and 
>> bandwidth. Yagni finds obsolete code that is no longer reached in your 
>> program or from *any* public entry point to your library (whether a 
>> particular program uses that entry point or not) and issues warnings, so 
>> you know that either something is maintenance deadweight or you have a bug 
>> because you *meant* to call it somewhere but forgot, or it's become 
>> accidentally shadowed or something.
>>
>

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

Re: Writing REST api the right way

[Fluid Dynamics]

On Wednesday, June 24, 2015 at 6:37:14 PM UTC-4, raould wrote:
>
> > 350ms sounds fast enough for a low-frequency user interaction. In fact, 
> once 
> > login is fast enough not to annoy your users, you don't *want* any more 
> > speed from it, as further speedup then only benefits blackhats trying to 
> > brute-force one of your users' accounts. So, it might be a feature, not 
> a 
> > bug. 
>
> Those seem like really weird statements to me. :-) 
>
> a) I thought it was 250 msec as the upper abound for things feeling 
> snappy. Tho others apparently say 100 msec or less. 
>
> http://stackoverflow.com/questions/536300/what-is-the-shortest-perceivable-application-response-delay
>  
>

That would apply to common actions like typing and entering. Login being 
slower than that isn't likely to be as much of a bother as you likely only 
do it infrequently, maybe as much as once a day if you're paranoid and 
clear cookies nightly.
 

> b) If anybody is relying on 350 msec vs. e.g. 100 msec as some grand 
> solution to black hats brute forcing logins, I strongly suspect they 
> are doing it very wrong.
>

Relying on? No. But every little bit helps, and making it less economical 
to do bad things can have big breakpoints where an incremental additional 
difference turns mild badguy profits into mild losses.

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

Re: Writing REST api the right way

[Raoul Duke]

> That would apply to common actions like typing and entering. Login being
> slower than that isn't likely to be as much of a bother as you likely only
> do it infrequently, maybe as much as once a day if you're paranoid and clear
> cookies nightly.

Yeah, to me that is the sort of reasoning that leads in the long run
to the kind of experiences we regularly have with the web: slow. Death
of a thousand overheads of 250 msec cuts. $0.02. I know, I know, there
are more important things for the engineers to fix right now, and for
the forseeable future, I know! :-)

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

Re: pr-str and safe serialization

[Matching Socks]

There are currently no votes for either Jira issue!

 - No.1532, "pr-str captures stdout from printing side-effects of lazily 
evaluated expressions"

 - No.1611, "clojure.java.io/pushback-reader"

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

Re: Writing REST api the right way

[Alan Moore]

Mike,

I think you might be better off keeping as much as you can the same between 
the two test scenarios so that you are only comparing the differences 
between nodejs and clojure -- and not all kinds of other variables like 
co-located services/cpu-load on your various hosts, network latency 
differences, JVM/nodejs cache warm-up behaviors, memory pressure 
differences, backing store performance, etc. Consider running both apps 
separately on the same host (warmed up), against the same db, across the 
same network and so on. Also, I don't think heroku guarantees like-kind 
performance from launching dynos run to run given that your app may end up 
on different hosts with each test.

Good luck with your project.

Alan

On Wednesday, June 24, 2015 at 1:03:39 PM UTC-7, Mike Grabowski wrote:
>
> Thanks for the reference, I've seen it before and it looks interesting, 
> especially thanks to the failover built-in. It also greatly shows how 
> Clojure can reduce the `Java boilerplate`. 
>
> Speaking on the performance note, I am not entirely sure what's causing my 
> REST API to be slower than `Node.js` one, I have two the same auth logic 
> implemented in both Node/Clojure. The Node.js version is running on Heroku 
> (London) with MongoLab hosted in (US-east-1) which can handle login in 
> 140ms. On the other hand, the Clojure Aleph/Compojure hosted in London on 
> DigitalOcean with MongoHQ database hosted in the same DigitalOcean region 
> handles the same thing in 350ms in the best case. This is really weird as 
> the `non-database` request is 40ms faster than Node.js one. I need to 
> investigate, but apart from that, all good so far.
>
> On Wednesday, 24 June 2015 20:49:40 UTC+2, Stuart Sierra wrote:
>>
>> On Tuesday, June 23, 2015, Mike Grabowski wrote:
>> > ... I just can't stop thinking about non-blocking evented
>> > IO interactions. It just does not feel right to me to
>> > block the thread when e.g. logging in an user.
>> > Unfortunately, there are no NIO drivers for the database
>> > engines I am interested in (Neo4J, Mongo) so async
>> > channels are not the way to go.
>>
>> This is pretty much unavoidable on the JVM. Java started
>> with a multi-threaded blocking I/O model, and that's still
>> how most Java code is written despite the availability of
>> non-blocking I/O.
>>
>> The typical way to mitigate this in Java is with thread
>> pools. The JVM is capable of handling hundreds of threads,
>> and modern operating systems are pretty good at
>> context-switching.
>>
>> For an extreme example, look at Netflix's [Hystrix], which
>> isolates *every* library in its own thread pool, so they can
>> guarantee timeouts and other bounded behaviors. Netflix
>> reports that the overhead of extra threads is worth the
>> more-predictable behavior.
>>
>> [Hystrix]: https://github.com/Netflix/Hystrix
>>
>> -S
>>
>

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