Re: [ANN] vectorz-clj 0.6.0

[Mikera]

On Monday, 25 February 2013 18:17:50 UTC+8, Mikera wrote:

> Hi All,
>
> Pleased to announce the latest release of vectorz-clj, a high performance 
> vector and matrix math implementation for Clojure.
>
> GitHub site: https://github.com/mikera/vectorz-clj
> Clojars: https://clojars.org/net.mikera/vectorz-clj
>
> Key features:
>
> a) 100% pure JVM code (no native libraries required)
> b) Supports a clean, functional, idiomatic style of vector and matrix 
> maths in Clojure
> c) Currently the most complete implementation of the "core.matrix" API for 
> Clojure numerics
> d) Very fast - designed for games, simulations, machine learning 
> applications etc.
>
> For an idea of performance, it is worth comparing with regular Clojure 
> vectors:
>
>   (let [a [1 2 3 4 5 6 7 8 9 10]
> b [1 2 3 4 5 6 7 8 9 10]]
> (c/quick-bench (dotimes [i 1000] (vec (map clojure.core/+ a b)  
>   ;; => Execution time mean per addition : 1221 ns
>
> Using vectorz-clj to do the same additions is about 15-20x faster:
>
>   (let [a (matrix :vectorz [1 2 3 4 5 6 7 8 9 10])
> b (matrix :vectorz [1 2 3 4 5 6 7 8 9 10])]
> (c/quick-bench (dotimes [i 1000] (+ a b
>   ;; => Execution time mean per addition: 68 ns
>
> If you are willing to abandon immutability and use mutable vectors, you 
> can go faster still:
>
>   (let [a (matrix :vectorz [1 2 3 4 5 6 7 8 9 10])
> b (matrix :vectorz [1 2 3 4 5 6 7 8 9 10])]
> (c/quick-bench (dotimes [i 1000] (add! a b
>   ;; => Execution time mean per addition: 31 ns
>
>
Incidentally, I found that if you call Vectorz methods directly using Java 
interop, you can go even faster again. I think the difference is mainly in 
the overhead of making a polymorphic call via a dynamically extended 
Clojure protocol, but I need to investigate a bit further to figure out 
what is really happening here:

  (let [a (Vectorz/create [1 2 3 4 5 6 7 8 9 10])
b (Vectorz/create [1 2 3 4 5 6 7 8 9 10])]
(c/quick-bench (dotimes [i 1000] (.add a b
  ;; => Execution time mean per addition: 11 ns
 

> This is all still very much in early development, so feedback / ideas / 
> code contributions all very welcome!
>
>   Mike.
>

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

[Marko Topolnik]

This is a great analysis, thanks for the link; shame it's so old.

On Sunday, February 24, 2013 10:45:33 PM UTC+1, Ben Mabey wrote:
>
>  
> Yeah, I wish the Benchmarks allowed for idiomatic submissions and finely 
> tuned submissions.  That would allow you to get some sort of an idea how 
> performant the dominant idiom is.  Along those lines this older post did an 
> interesting analysis on the benchmark solutions where it explored the 
> tension that exists between expressiveness and performance across the 
> various languages:
>
> http://blog.gmarceau.qc.ca/2009/05/speed-size-and-dependability-of.html
>
>
>
>  

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

Re: [ANN] clj-toml 0.2.0

[Luca Antiga]

Thanks Armando, I'm glad to hear this. Kern is impressive (and well 
documented too).
Please feel free to send suggestions if you find something awkward or 
inefficient.

Luca


On Monday, February 25, 2013 10:50:13 PM UTC+1, Armando Blancas wrote:
>
> Glad to see Kern being useful. Your parser uses those combinators quite 
> effectively.
>
> On Monday, February 25, 2013 1:26:26 AM UTC-8, Luca Antiga wrote:
>>
>> Quick announcement: clj-toml 0.2.0 is available on 
>> Clojars
>> .
>>
>> clj-toml  is a 
>> TOMLparser for Clojure. It was written on 
>> top of the 
>> Kern  library by Armando Blancas 
>> (kudos).
>>
>> TOML is a minimalistic, human-readable format that maps to a hash (like 
>> INI, but more evolved).
>>
>> Cheers,
>>
>> Luca
>>
>

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

[David Nolen]

Feel free to open a ticket in JIRA. More details would be helpful and a
patch would be nice. Thanks!

On Monday, February 25, 2013, Bobby Wang wrote:

> Update: this seems to only happen if I start the CLJS REPL inside a CLJ
> REPL. If I start straight from the command line (ie. lein trampoline
> cljsbuild repl-listen) it's fine.
>
> On Monday, 25 February 2013 19:22:06 UTC-5, Bobby Wang wrote:
>>
>> Hi,
>>
>> Sometimes when I start the CLJS browser REPL and evaluate something like
>> js/alert, the alert runs fine, but after a few seconds it goes into an
>> infinite loop while repeatedly printing "*ClojureScript:cljs.user>
>> java.io.IOException: Write end dead*".
>>
>> The same thing happens on ClojureScript One, which I think uses older
>> dependencies.
>>
>> Any idea what might be wrong?
>>
>> My setup:
>>
>> * clojure 1.4.0
>> * clojurescript 0.0-1586
>> * lein-cljsbuild 0.3.0
>> * Mac OS X 10.8.2
>> * Java 1.6.0_41 that came with OS X
>> * Also tried to install Oracle's Java 7, but it doesn't seem to work out
>> of box yet
>>
>> Much appreciated,
>>
>> Bobby
>>
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to 
> clojure@googlegroups.com 'clojure@googlegroups.com');>
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com  'clojure%2bunsubscr...@googlegroups.com');>
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com  'clojure%2bunsubscr...@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.

Securing Clojure + Clojurescript Web App

[Ari]

Hi,

I'd appreciate suggestions on how I can/should secure my 
clojure/clojurescript "single page web" app that relies heavily on 
shoreleave-remote. With other frameworks, upon authentication I've created 
a "roles" cookie that the clientside uses to determine access rights to 
views, while on the serverside I use a "roles" session variable to 
determine access rights to GET/POST data. But Shoreleave side-steps the 
serverside authentication/authorization (via friend), so I'm not sure how 
to proceed. 

Thanks.

-Ari

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

[Akhil Wali]

Checkout cemrick/friend . It handles
authentication as ring middleware.



On Tue, Feb 26, 2013 at 9:54 PM, Ari  wrote:

> Hi,
>
> I'd appreciate suggestions on how I can/should secure my
> clojure/clojurescript "single page web" app that relies heavily on
> shoreleave-remote. With other frameworks, upon authentication I've created
> a "roles" cookie that the clientside uses to determine access rights to
> views, while on the serverside I use a "roles" session variable to
> determine access rights to GET/POST data. But Shoreleave side-steps the
> serverside authentication/authorization (via friend), so I'm not sure how
> to proceed.
>
> Thanks.
>
> -Ari
>
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from 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.
>
>
>



-- 
Akhil Wali

# http://github.com/darth10 
# http://darth10.github.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: Securing Clojure + Clojurescript Web App

[Akhil Wali]

Here's a good 
screencastto
give you a quick tutorial.


On Tue, Feb 26, 2013 at 10:57 PM, Akhil Wali wrote:

> Checkout cemrick/friend . It handles
> authentication as ring middleware.
>
>
>
> On Tue, Feb 26, 2013 at 9:54 PM, Ari  wrote:
>
>> Hi,
>>
>> I'd appreciate suggestions on how I can/should secure my
>> clojure/clojurescript "single page web" app that relies heavily on
>> shoreleave-remote. With other frameworks, upon authentication I've created
>> a "roles" cookie that the clientside uses to determine access rights to
>> views, while on the serverside I use a "roles" session variable to
>> determine access rights to GET/POST data. But Shoreleave side-steps the
>> serverside authentication/authorization (via friend), so I'm not sure how
>> to proceed.
>>
>> Thanks.
>>
>> -Ari
>>
>>  --
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from 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.
>>
>>
>>
>
>
>
> --
> Akhil Wali
>
> # http://github.com/darth10 
> # http://darth10.github.com
>
>


-- 
Akhil Wali

# http://github.com/darth10 
# http://darth10.github.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: Clojure Performance For Expensive Algorithms

[Ben Mabey]

As Issac pointed out, here are some very recent graphs (including Clojure):

http://benchmarksgame.alioth.debian.org/u32/code-used-time-used-shapes.php

On 2/26/13 2:35 AM, Marko Topolnik wrote:

This is a great analysis, thanks for the link; shame it's so old.

On Sunday, February 24, 2013 10:45:33 PM UTC+1, Ben Mabey wrote:


Yeah, I wish the Benchmarks allowed for idiomatic submissions and
finely tuned submissions.  That would allow you to get some sort
of an idea how performant the dominant idiom is. Along those lines
this older post did an interesting analysis on the benchmark
solutions where it explored the tension that exists between
expressiveness and performance across the various languages:

http://blog.gmarceau.qc.ca/2009/05/speed-size-and-dependability-of.html




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

To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google 
Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to clojure+unsubscr...@googlegroups.com.

For more options, visit https://groups.google.com/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: Securing Clojure + Clojurescript Web App

[Paul deGrandis]

Friend + Shoreleave's CSRF protection gets you most of the way there.  The 
rest is up to you (iptables, ssh lock down, etc).

Paul

On Tuesday, February 26, 2013 9:30:18 AM UTC-8, Akhil Wali wrote:
>
> Here's a good 
> screencastto
>  give you a quick tutorial. 
>
>
> On Tue, Feb 26, 2013 at 10:57 PM, Akhil Wali 
> > wrote:
>
>> Checkout cemrick/friend . It handles 
>> authentication as ring middleware.
>>  
>>
>>
>> On Tue, Feb 26, 2013 at 9:54 PM, Ari 
>> > wrote:
>>
>>> Hi,
>>>
>>> I'd appreciate suggestions on how I can/should secure my 
>>> clojure/clojurescript "single page web" app that relies heavily on 
>>> shoreleave-remote. With other frameworks, upon authentication I've created 
>>> a "roles" cookie that the clientside uses to determine access rights to 
>>> views, while on the serverside I use a "roles" session variable to 
>>> determine access rights to GET/POST data. But Shoreleave side-steps the 
>>> serverside authentication/authorization (via friend), so I'm not sure how 
>>> to proceed. 
>>>
>>> Thanks.
>>>
>>> -Ari
>>>
>>>  -- 
>>> -- 
>>> 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.
>>>  
>>>  
>>>
>>
>>
>>
>> -- 
>> Akhil Wali 
>>
>> # http://github.com/darth10 
>> # http://darth10.github.com
>>
>>  
>
>
> -- 
> Akhil Wali 
>
> # http://github.com/darth10 
> # http://darth10.github.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.

ANN Elastisch 1.1.0-beta1 is released

[Michael Klishin]

Elastisch [1] is is a small but feature complete and well documented
Clojure client for ElasticSearch.

1.1.0-beta1 is a development release that introduces several new
features, most importantly a [mostly complete] native client
that has the same API Elastisch's REST one does.

Release notes:
http://blog.clojurewerkz.org/blog/2013/02/26/elastisch-1-dot-1-0-beta1-is-released/
1. http://clojureelasticsearch.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: Support for pmap?

[Alan Shaw]

Could parallel.js and web workers help?
On Feb 25, 2013 6:12 PM, "David Nolen"  wrote:

> Not sure how we could given JS is single threaded.
>
> On Monday, February 25, 2013, MC Andre wrote:
>
>> Does ClojureScript support pmap?
>>
>> --
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from 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: Support for pmap?

[David Nolen]

Maybe one day. Far as I know the current overhead is significant.


On Tue, Feb 26, 2013 at 2:05 PM, Alan Shaw  wrote:

> Could parallel.js and web workers help?
> On Feb 25, 2013 6:12 PM, "David Nolen"  wrote:
>
>> Not sure how we could given JS is single threaded.
>>
>> On Monday, February 25, 2013, MC Andre wrote:
>>
>>> Does ClojureScript support pmap?
>>>
>>> --
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To post to this group, send email to clojure@googlegroups.com
>>> Note that posts from new members are moderated - please be patient with
>>> your first post.
>>> To unsubscribe from this group, send email to
>>> clojure+unsubscr...@googlegroups.com
>>> For more options, visit this group at
>>> http://groups.google.com/group/clojure?hl=en
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To unsubscribe from 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.
>
>
>

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

Creating web app/site without routing [experiment]

[Yakovlev Roman]

Hello
Recently i was experimenting with Clojure and web stack and created kind of 
non-standart web app. It doesn't use routing there are no any urls there.
This app is mostly "One page apps". Instead of routes i used id's and 
classes.
Let me explain:
I used "Noir" and "fetch" libs and logic of interaction was something like 
this:


User clicks link with some id -> i bind this even to js/cljs function -> 
this function calls function on the server
 -> that returns appropriate HTML code -> cljs function inserts that code 
at right place in the page.

Function on the server calls controller function -> controller function 
gets data and insert that data into the template -> and returns HTML code 
as string


app.cljs file
-
(defn show-user-info [mid e]
  (prevent e)
  (let [a (attr ($ mid) :profile)]
(.dialog ($ "#user-info-box") "open")
(remote (show-user a) [result]
  (inner ($ "#user-info-box") result)))
  )

This method calls show-user function on the server and send it appropriate 
arguments.

main.clj file on the server
--
;Show user profile info

(defremote show-user [a]
  (pa/user-profile-pa a)
  )

This function returns HTML code as a string

partials.clj file
--
(defpartial user-profile-pa [uid]
  (map user-profile-box (mprof/get-profile uid))
)

This function joins data and template via *map* function. It is something 
like controller.

user-profile-box is a template like so:

(defpartial user-profile-box [{:keys [uname city site business profimg age 
f1]}]
  [:ul
[:li 
[:img {:src profimg }]]
[:li (str "Name: " uname)]
(if city [:li (str "City: " city)])
(if business [:li (str "Business: " business)])
(if site [:li (str "Site: " site)])
(if age [:li (str "Age: " age)])
  ]
)
This partial gets data from (mprof/get-profile uid) call


I found this approach pretty insteresting and simple though it's not mature 
and can be improved a lot. What you think about that ?

I've seen this approach in Lift - scala framework and something like this 
is implemented in Meteor.

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

[Chas Emerick]

On Feb 26, 2013, at 11:24 AM, Ari wrote:

> Hi,
> 
> I'd appreciate suggestions on how I can/should secure my 
> clojure/clojurescript "single page web" app that relies heavily on 
> shoreleave-remote. With other frameworks, upon authentication I've created a 
> "roles" cookie that the clientside uses to determine access rights to views, 
> while on the serverside I use a "roles" session variable to determine access 
> rights to GET/POST data. But Shoreleave side-steps the serverside 
> authentication/authorization (via friend), so I'm not sure how to proceed. 

What do you mean by "sidesteps the auth"?  If you're using 
shoreleave-remote-ring, then the handler produced by its wrap-rpc middleware is 
subject to whatever access controls you define via Friend.

- Chas

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

[Marko Topolnik]

I see; didn't notice that one. Again, only the fastest entries are shown. 
It appears that the same is the case with Marceau's graphs; he just didn't 
state that explicitly.

Things don't look very rosy for Clojure: it turns out to be about as 
verbose as Java and significantly slower (this confirms my experience; 
slightly slower than *regular* Java code, significantly slower than highly 
optimized Java). If idiomatic Clojure was used, it would move it to the 
left and upwards; Clojure would hang out with JRuby.

Anyway, it would be really great to see such a comparison chart, but only 
with idiomatic code involved. This way I don't have a clue what to make of 
Haskell, for example.


On Tuesday, February 26, 2013 6:30:55 PM UTC+1, Ben Mabey wrote:
>
>  As Issac pointed out, here are some very recent graphs (including 
> Clojure):
>
> http://benchmarksgame.alioth.debian.org/u32/code-used-time-used-shapes.php
>
> On 2/26/13 2:35 AM, Marko Topolnik wrote:
>  
> This is a great analysis, thanks for the link; shame it's so old.
>
> On Sunday, February 24, 2013 10:45:33 PM UTC+1, Ben Mabey wrote: 
>>
>>  
>>  Yeah, I wish the Benchmarks allowed for idiomatic submissions and finely 
>> tuned submissions.  That would allow you to get some sort of an idea how 
>> performant the dominant idiom is.  Along those lines this older post did an 
>> interesting analysis on the benchmark solutions where it explored the 
>> tension that exists between expressiveness and performance across the 
>> various languages:
>>
>> http://blog.gmarceau.qc.ca/2009/05/speed-size-and-dependability-of.html
>>
>>
>>
>>  -- 
> -- 
> 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.
>  
>  
>
>
>  

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

[Andy Fingerhut]

I've got a github repo with submissions for the Benchmarks Game web site for 
Java and Clojure, with several different Clojure programs for most problems:

https://github.com/jafingerhut/clojure-benchmarks

If people would like to submit what they consider idiomatic Clojure programs 
for any of these problems, feel free to send them to me, and I can include 
them, not only in the repo but also in some benchmark results that I am 
planning to publish at the link below some day when I have them ready, under 
"whole program benchmarks":


http://jafingerhut.github.com/clojure-benchmarks-results/Clojure-benchmarks.html

If you do submit a program, I'd ask you to consider submitting a version that 
you wrote first and got working correctly, before even looking at any kinds of 
optimizations at all, as well as one you consider to be a mild optimization 
pass over that first version, and yet still "idiomatic".

Andy

On Feb 26, 2013, at 12:50 PM, Marko Topolnik wrote:

> I see; didn't notice that one. Again, only the fastest entries are shown. It 
> appears that the same is the case with Marceau's graphs; he just didn't state 
> that explicitly.
> 
> Things don't look very rosy for Clojure: it turns out to be about as verbose 
> as Java and significantly slower (this confirms my experience; slightly 
> slower than regular Java code, significantly slower than highly optimized 
> Java). If idiomatic Clojure was used, it would move it to the left and 
> upwards; Clojure would hang out with JRuby.
> 
> Anyway, it would be really great to see such a comparison chart, but only 
> with idiomatic code involved. This way I don't have a clue what to make of 
> Haskell, for example.
> 
> 
> On Tuesday, February 26, 2013 6:30:55 PM UTC+1, Ben Mabey wrote:
> As Issac pointed out, here are some very recent graphs (including Clojure):
> 
> http://benchmarksgame.alioth.debian.org/u32/code-used-time-used-shapes.php
> 
> On 2/26/13 2:35 AM, Marko Topolnik wrote:
>> This is a great analysis, thanks for the link; shame it's so old.
>> 
>> On Sunday, February 24, 2013 10:45:33 PM UTC+1, Ben Mabey wrote:
>> 
>> Yeah, I wish the Benchmarks allowed for idiomatic submissions and finely 
>> tuned submissions.  That would allow you to get some sort of an idea how 
>> performant the dominant idiom is.  Along those lines this older post did an 
>> interesting analysis on the benchmark solutions where it explored the 
>> tension that exists between expressiveness and performance across the 
>> various languages:
>> 
>> http://blog.gmarceau.qc.ca/2009/05/speed-size-and-dependability-of.html
>> 
>> 
>> 
>> -- 
>> -- 
>> 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.
>>  
>>  
> 
> 
> -- 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from 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: Clojure Performance For Expensive Algorithms

[Jules]

Clojure code should in principle be possible to execute very fast when 
using the same data structures. Clojure is much better behaved than 
languages like Ruby and Javascript from a compiler perspective. See for 
example the Stalin scheme compiler. It runs well written Scheme at almost C 
speed (sometimes even faster), without type annotations.

On Tuesday, February 26, 2013 9:50:17 PM UTC+1, Marko Topolnik wrote:
>
> I see; didn't notice that one. Again, only the fastest entries are shown. 
> It appears that the same is the case with Marceau's graphs; he just didn't 
> state that explicitly.
>
> Things don't look very rosy for Clojure: it turns out to be about as 
> verbose as Java and significantly slower (this confirms my experience; 
> slightly slower than *regular* Java code, significantly slower than 
> highly optimized Java). If idiomatic Clojure was used, it would move it to 
> the left and upwards; Clojure would hang out with JRuby.
>
> Anyway, it would be really great to see such a comparison chart, but only 
> with idiomatic code involved. This way I don't have a clue what to make of 
> Haskell, for example.
>
>
> On Tuesday, February 26, 2013 6:30:55 PM UTC+1, Ben Mabey wrote:
>>
>>  As Issac pointed out, here are some very recent graphs (including 
>> Clojure):
>>
>> http://benchmarksgame.alioth.debian.org/u32/code-used-time-used-shapes.php
>>
>> On 2/26/13 2:35 AM, Marko Topolnik wrote:
>>  
>> This is a great analysis, thanks for the link; shame it's so old.
>>
>> On Sunday, February 24, 2013 10:45:33 PM UTC+1, Ben Mabey wrote: 
>>>
>>>  
>>>  Yeah, I wish the Benchmarks allowed for idiomatic submissions and 
>>> finely tuned submissions.  That would allow you to get some sort of an idea 
>>> how performant the dominant idiom is.  Along those lines this older post 
>>> did an interesting analysis on the benchmark solutions where it explored 
>>> the tension that exists between expressiveness and performance across the 
>>> various languages:
>>>
>>> http://blog.gmarceau.qc.ca/2009/05/speed-size-and-dependability-of.html
>>>
>>>
>>>
>>>  -- 
>> -- 
>> 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.
>>  
>>  
>>
>>
>>  

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from 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 can I ensure a dosync is finished?

[larry google groups]

I would like to connect to MongoDb with the following code, but I am
worried about the side-effecting code that comes right after the
dosync:


(def which-database-to-use (ref false))
(def which-collection-to-use (ref false))

(defn connect-to-server []
  (mg/connect!))

(defn set-database-to-use []
  (mg/set-db! (mg/get-db @which-database-to-use)))

(defn establish-database-connection [database-name-as-string
collection-name-as-string]
  (dosync
   (ref-set which-database-to-use database-name-as-string)
   (ref-set which-collection-to-use collection-name-as-string))
  (when @which-database-to-use
(connect-to-server)
(set-database-to-use)))


Is there a risk that set-database-to-use will be called before the
dosync is finished?


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

[David Nolen]

On Tue, Feb 26, 2013 at 3:50 PM, Marko Topolnik wrote:

> Things don't look very rosy for Clojure: it turns out to be about as
> verbose as Java and significantly slower (this confirms my experience;
> slightly slower than *regular* Java code, significantly slower than
> highly optimized Java). If idiomatic Clojure was used, it would move it to
> the left and upwards; Clojure would hang out with JRuby.
>

Hang out with JRuby? Seriously?
http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?test=all&lang=clojure&lang2=jruby

Having written two test.benchmark entries which compare quite favorably to
Java, I think the current crop of Alioth benchmarks could use a bit of
improvement both in terms of code quality and performance. There's no
reason that every single Clojure Alioth benchmark should not be near
competitive with the corresponding Java Alioth benchmark in terms of time,
memory, and code size except for lack of community interest.

Probably because none of these things will ever reveal Clojure performance
for non-trivial applications.

It's much more convincing for example when Prismatic engineers say they can
happily achieve Java performance without verbosity.
http://blog.getprismatic.com/blog/2012/4/5/software-engineering-at-prismatic.html

David

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

[Softaddicts]

I you attempt to mimic Java or C in some narrow linear
compute bound algorithm, I agree that the resulting code is quite ugly, not 
idiomatic
on top of having performance issues.

Lucky for us not all the problems are bounded like this.

I have been following this thread from the beginning and I cannot understand
why people are hammering at performance issues we were tackling using 
machine code directly in the 80s or by carefully inspecting compiler generated
code (by Fortran, C, ...) to avoid costly instructions. We would thunk down
to machine code when required.

There are no wins on all fronts at the same time. We are happy here to get
wall clock performance boosts without added complexity
because the nature of our business domain allows us to parallelize processing.

Why insist on getting Clojure to be at par with languages that may offer a 
performance
boost on narrow problems at the expense of making parallel processing and code
in general more complex everywhere else ?

I do not say that these benchmarks are futile, write idiomatic code, use 
available 
optimizations (type hints and cie) and start the baseline from there to improve 
the
compiler.

Improvements to the compiler will benefit everyone. Improvements to reach
similar perf levels with these benchmarks by twisting the code are pretty 
narrow goals
and not many can benefit from it.

100% cpu usage in the whole lifetime of your app ?
Without db or file persistence ? Without network I/O s ? All of which induce 
latencies ?

It's similar to me to weater simulations. These days they have enough data to
predict weather with a great accuracy... three days after the fact.
Why ? They have a compute bound problem that they cannot address other than 
sequentialy in some critical steps and too much data to process if they want to 
improve
the accuracy of their simulations.

Using Clojure in these critical steps would be futile until new parallel 
algorithms
appear. Parallel algorithms to some of their performance problems do not exist
yet. The maths to do so have not been invented yet. Oups...

If anyone uses these benchmarks as their main criteria to choose a language
without considering first their problem domain, well they need to get their 
brain fixed.

I considered my domain problem before embracing Clojure and pushed back the 
performance issues later because I knew I could always cheat with parallel 
processing
and lower the source code burden by getting more expressivenes.

The gains are in the sum of all parts not in a single narrowly defined one.


Luc P.

> I see; didn't notice that one. Again, only the fastest entries are shown. 
> It appears that the same is the case with Marceau's graphs; he just didn't 
> state that explicitly.
> 
> Things don't look very rosy for Clojure: it turns out to be about as 
> verbose as Java and significantly slower (this confirms my experience; 
> slightly slower than *regular* Java code, significantly slower than highly 
> optimized Java). If idiomatic Clojure was used, it would move it to the 
> left and upwards; Clojure would hang out with JRuby.
> 
> Anyway, it would be really great to see such a comparison chart, but only 
> with idiomatic code involved. This way I don't have a clue what to make of 
> Haskell, for example.
> 
> 
> On Tuesday, February 26, 2013 6:30:55 PM UTC+1, Ben Mabey wrote:
> >
> >  As Issac pointed out, here are some very recent graphs (including 
> > Clojure):
> >
> > http://benchmarksgame.alioth.debian.org/u32/code-used-time-used-shapes.php
> >
> > On 2/26/13 2:35 AM, Marko Topolnik wrote:
> >  
> > This is a great analysis, thanks for the link; shame it's so old.
> >
> > On Sunday, February 24, 2013 10:45:33 PM UTC+1, Ben Mabey wrote: 
> >>
> >>  
> >>  Yeah, I wish the Benchmarks allowed for idiomatic submissions and finely 
> >> tuned submissions.  That would allow you to get some sort of an idea how 
> >> performant the dominant idiom is.  Along those lines this older post did 
> >> an 
> >> interesting analysis on the benchmark solutions where it explored the 
> >> tension that exists between expressiveness and performance across the 
> >> various languages:
> >>
> >> http://blog.gmarceau.qc.ca/2009/05/speed-size-and-dependability-of.html
> >>
> >>
> >>
> >>  -- 
> > -- 
> > 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.g

Re: how can I ensure a dosync is finished?

[vemv]

Looks like refs are not particularly the best tool for the job in this case 
- those values aren't going to change a lot right? And they could be 
expressed as a single hashmap - removing the needs for transactionality.

Answering to your question, it is impossible to reach the (when...) without 
the two refs being succesfully set: dosync blocks, and throws an exception 
if something goes wrong.

On Wednesday, February 27, 2013 12:38:56 AM UTC+1, larry google groups 
wrote:
>
> I would like to connect to MongoDb with the following code, but I am 
> worried about the side-effecting code that comes right after the 
> dosync: 
>
>
> (def which-database-to-use (ref false)) 
> (def which-collection-to-use (ref false)) 
>
> (defn connect-to-server [] 
>   (mg/connect!)) 
>
> (defn set-database-to-use [] 
>   (mg/set-db! (mg/get-db @which-database-to-use))) 
>
> (defn establish-database-connection [database-name-as-string 
> collection-name-as-string] 
>   (dosync 
>(ref-set which-database-to-use database-name-as-string) 
>(ref-set which-collection-to-use collection-name-as-string)) 
>   (when @which-database-to-use 
> (connect-to-server) 
> (set-database-to-use))) 
>
>
> Is there a risk that set-database-to-use will be called before the 
> dosync is finished? 
>
>
>

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

[Ari]

On Tuesday, February 26, 2013 3:16:23 PM UTC-5, Chas Emerick wrote:
 

> What do you mean by "sidesteps the auth"?  If you're using 
> shoreleave-remote-ring, then the handler produced by its wrap-rpc 
> middleware is subject to whatever access controls you define via Friend.  
> - Chas


Friend, as I understand it, allows access to be controlled at the route 
level (see friend 
authorization) 
allowing for fine-grained access control definitions. However, since 
Shoreleave remote defines and relies on a single URI, which defaults to 
"_fetch", defining such fine-grained access controls is not possible. This 
is what I was referring to by "side-steps" the authentication/authorization 
flow and thus inhibits implementing the client-side/server-side security 
approach I described in my original post. 

Following up on my original post, is it possible to create a "roles" cookie 
upon initial authentication; if so, how? Thanks.

-Ari

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

wrapping multimethods?

[George Oliver]

hi, 

I'm interested in what techniques are useful for adding functionality to 
multimethods without modifying the defmethod itself. A while back I asked a 
similar question [1] and there are good answers there, but recently I've 
been looking at simple concepts like Ring middleware and wrapping functions 
with functions defining :pre and :post conditions,  and now wonder if there 
isn't a similar idea for multimethods. 

My code is a basic socket server with a defmulti that dispatches based on 
whether the socket is ready to accept, read, etcetera. I would like to add 
behavior to the defmethods in a simple and composable way and keep concerns 
separate (for example separating reading a socket from checking if it's 
actually closed). 

Here's a paste, https://www.refheap.com/paste/11861. 


thanks, George

[1] 
https://groups.google.com/forum/?fromgroups=#!searchin/clojure/george$20before$20after/clojure/beqWiVSn8ws/CihDwDumLDQJ

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

[Brent Millare]

On another note, I wonder if a leiningen2 wizard installer for windows 
would be in high-demand (does one already exist?). Anyone familiar with 
writing windows wizards?

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

[Isaac Gouy]

On Tuesday, February 26, 2013 12:50:17 PM UTC-8, Marko Topolnik wrote:
>
> Again, only the fastest entries are shown. 
>

True, except for the special-case included to show that programs can be 
made slower (and sometimes more concise) -- the shortest C++ programs.


If idiomatic Clojure was used...
>

The problem, of course, is that: the code one-person considers to be 
idiomatic; another person considers to be idiotic, naïve.

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

lack of :import causes Invalid method Code length

[AtKaaZ]

from here:
https://groups.google.com/d/msg/clojuredev-users/2RhOiM8b308/XESMfS48upgJ

the line is basically this:
*:open #(ccw.repl.REPLView/connect (format "nrepl://%s:%s" host port)
*
and without this* :import* clause*
[ccw.repl REPLView]
*
it will do the following (but with that import works just fine):*
*

Caused by: java.lang.ClassFormatError: *Invalid method Code length 93115 in
class* file ccw/editors/clojure/nrepl_
hyperlink_detector$detect_hyperlinks$fn__13522, compiling:(*ccw/editors/**
clojure/nrepl_hyperlink_**detector.clj:48:5*)
...
snip
...
Caused by: java.lang.ClassFormatError: Invalid method Code length 93115 in
class file
ccw/editors/clojure/nrepl_hyperlink_detector$detect_hyperlinks$fn__13522

at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClassCond(Unknown Source)
at java.lang.ClassLoader.defineClass(Unknown Source)
at java.lang.ClassLoader.defineClass(Unknown Source)
at
clojure.lang.DynamicClassLoader.defineClass(DynamicClassLoader.java:46)
at clojure.lang.Compiler$ObjExpr.getCompiledClass(Compiler.java:4663)
at clojure.lang.Compiler$FnExpr.parse(Compiler.java:3819)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:6558)
... 114 more

So why does it work with the import? Someone please explain something,
thank you!

-- 
Please correct me if I'm wrong or incomplete,
even if you think I'll subconsciously hate it.

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