date:20130115

is org.clojure/java.jdbc part of the official clojure

2013-01-15 Thread Josh Kamau

Hi there ,

I am a little confused here (no big deal though) .

Is org.clojure/java.jdbc an official clojure library? if yes, why is the
version still 0.2.3 and not 1.4.x as clojure ?

TIA
Josh

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

Re: pool-map - a more disciplined version of pmap on top of executors

2013-01-15 Thread Marko Topolnik

On Tuesday, January 15, 2013 12:36:04 AM UTC+1, Jim foo.bar wrote:

  On 14/01/13 22:15, Marko Topolnik wrote:
  
 But... you were quite clear in stating that your function isn't lazy, and 
 you were right to say that: *doall* will not return until *all* the tasks 
 have completed. Maybe you did want laziness, after all?


 I'm not entirely sure what you mean here...The only real reason I am using 
 'doall' is so that I can shutdown the ExecutorService, otherwise I wouldn't 
 mind returning a lazy-seq. In fact that is how I originally had it - I was 
 never shutting down the pool until recently! Inside the doall however I'm 
 polling the pool for answers and *it* looks for finished jobs...I'm not 
 deref-ing the futures in a serial manner which has higher chances of 
 bocking...Is my thinking not correct?  


The order in which you are polling is not very relevant given the fact that 
*doall* won't return until *all* futures are realized. It's just an 
internal detail. As for shutting down the executor service, it is safe to 
do so immediatly after all tasks have been submitted:

(defn pool-map [f coll]
  (let [exec (Executors/newFixedThreadPool (.availableProcessors 
(Runtime/getRuntime)))]
(- (try (.invokeAll exec (for [x coll] #(f x))) (finally (.shutdown 
exec)))
 (map #(.get ^FutureTask %)
 

 Yet another issue with your function is that it doesn't submit all the 
 tasks up front so it clearly won't prevent longer tasks from delaying the 
 shorter ones. But, even if they are submitted all at once, like in my 
 version, the executor service will still enqueue them internally, with the 
 same end result. You'd need an unbounded thread pool, and that would 
 obviously bring in other issues.


 You're quite right here...Again using 'for' was a remnant from the old 
 version...Perhaps 'mapv' would be a better choice for submitting the 
 jobs...In any case, is this  executor-based approach (with or without the 
 completion service) encouraged? Would you care if tomorrow pmap started 
 using this approach?


Using *mapv* (or simply *doall*, same thing) won't solve the root problem 
of tasks waiting in executor's own queue.

Taking into account all that was said, *pool-map* can't offer much more 
than *pmap*. You can't know which tasks will take less time until they are 
already done. It is theoretically impossible to pre-order them according to 
execution time, thereby harvesting the results of the fastest ones earlier, 
eventually promoting total concurrency. The way to go is grinding the tasks 
down to chunks of predictable runtime and submitting them to a fork/join 
solver, which will optimize concurrency through work-stealing.
 

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

Re: is org.clojure/java.jdbc part of the official clojure

2013-01-15 Thread Andy Fingerhut

java.jdbc is one of several Clojure contrib libraries, others of which you can 
see listed in the two places below:

https://github.com/clojure
http://dev.clojure.org/display/design/Where+Did+Clojure.Contrib+Go

They are like Clojure in that they are released under the same Eclipse Public 
License, and to contribute code to them you must sign a Clojure Contributor's 
Agreement (CA):

http://clojure.org/contributing

They are unlike Clojure in that their releases occur independently of Clojure, 
and their version numbers advance independently of Clojure.

I believe all of the latest contrib libraries are compatible with Clojure 
1.3.0, 1.4.0, and most likely the forthcoming 1.5.0, and some are still 
compatible with Clojure 1.2.1.

Andy

On Jan 15, 2013, at 1:10 AM, Josh Kamau wrote:

 Hi there ,
 
 I am a little confused here (no big deal though) . 
 
 Is org.clojure/java.jdbc an official clojure library? if yes, why is the 
 version still 0.2.3 and not 1.4.x as clojure ? 
 
 TIA
 Josh

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

Re: is org.clojure/java.jdbc part of the official clojure

2013-01-15 Thread Josh Kamau

Andy;

Thanks for the clarification.

Josh.


On Tue, Jan 15, 2013 at 1:20 PM, Andy Fingerhut andy.finger...@gmail.comwrote:

 java.jdbc is one of several Clojure contrib libraries, others of which you
 can see listed in the two places below:

 https://github.com/clojure
 http://dev.clojure.org/display/design/Where+Did+Clojure.Contrib+Go

 They are like Clojure in that they are released under the same Eclipse
 Public License, and to contribute code to them you must sign a Clojure
 Contributor's Agreement (CA):

 http://clojure.org/contributing

 They are unlike Clojure in that their releases occur independently of
 Clojure, and their version numbers advance independently of Clojure.

 I believe all of the latest contrib libraries are compatible with Clojure
 1.3.0, 1.4.0, and most likely the forthcoming 1.5.0, and some are still
 compatible with Clojure 1.2.1.

 Andy

 On Jan 15, 2013, at 1:10 AM, Josh Kamau wrote:

  Hi there ,
 
  I am a little confused here (no big deal though) .
 
  Is org.clojure/java.jdbc an official clojure library? if yes, why is
 the version still 0.2.3 and not 1.4.x as clojure ?
 
  TIA
  Josh

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


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

Re: pool-map - a more disciplined version of pmap on top of executors

2013-01-15 Thread Jim foo.bar


On 15/01/13 09:25, Marko Topolnik wrote:
The order in which you are polling is not very relevant given the fact 
that /doall/ won't return until *all* futures are realized. It's just 
an internal detail.


I finally fully grasped what you were saying...So yes you're right - as 
long as I'm forcing realisation at the end there is nothing to be 
gained...However, what if I submit jobs eagerly and poll for results 
lazily? Then there must be some some gain from using the completion 
service which will bring back the results in the order they finished 
some basic testing:


(defn pool-map
A saner, more disciplined version of pmap. Submits jobs eagerly but 
polls for results lazily.

 Don't use if original ordering of 'coll' matters.
[f coll]
 (let [cpu-no (.. Runtime getRuntime availableProcessors)
   exec (java.util.concurrent.Executors/newFixedThreadPool cpu-no)
   pool (java.util.concurrent.ExecutorCompletionService. exec)
   futures (doall (for [x coll] (.submit pool #(f x] ;;submit 
everything up front

(try
 (for [_ futures]  (.. pool take get))
(finally (.shutdown exec)

;;your version is 'pool-map1'
;;weirdly enough 'pool-map1' doesn't behave lazily (even though it has a 
call to 'map'!)!!!



user= (def dummy-times [3000 10 9 8 7 6 5 4 3 2 1])
#'user/dummy-times
user= (time  (pmap #(do (Thread/sleep %) %) dummy-times))
Elapsed time: 16.213366 msecs
(3000 10 9 8 7 6 5 4 3 2 1);;here you waited 3s before sleeping for 
0.01 s

user= (time  (pool-map #(do (Thread/sleep %) %) dummy-times))
Elapsed time: 21.004979 msecs
(10 9 8 7 6 5 4 3 2 1 3000)  ;;here you've not waited at all - sleeping 
for 3s finished last and is last

user= (time  (pool-map1 #(do (Thread/sleep %) %) dummy-times))
Elapsed time: 3008.174631 msecs  ;;non-lazy?
(3000 10 9 8 7 6 5 4 3 2 1)  ;;again your version will wait for the 
first item to finish before proceeding


I think what you trying to get across  is that the overall timings (if 
we do realise the result) will not differ much as all jobs have to 
finish eventually. In other words,  sleeping for 3 s first and for 1 
later is the same thing as sleeping for 1 s and then for 3 
seconds!...and of course this is generally true! However, there is no 
real benefit waiting for the 1st task  to finish when we don't mind 
about ordering. You 'll get the first item whenever it finishes in 
whatever position...This MUST be good but perhaps it needs to be paired 
with laziness to witness any effect?


aking into account all that was said, /pool-map/ can't offer much more 
than /pmap/. You can't know which tasks will take less time until they 
are already done. It is theoretically impossible to pre-order them 
according to execution time, thereby harvesting the results of the 
fastest ones earlier, eventually promoting total concurrency.


hmmm...so the completion service is useless? It can't be... You say 
that'You can't know which tasks will take less time until they are 
already done' but the way I see it you don't  need to...all you need to 
know at any given time is whether a or some  futures have completed. If 
one has indeed completed you invoke .get for the result. If it hasn't 
finished and you do .get it will block until it finishes just like 
deref-ing in Clojure... I honestly don't see why harvesting the results 
of the fastest ones earlier requires to know the execution times up 
front! As you go along you can ask the futures whether they finished or 
not, can't you?


I am in no way trying to contradict you ,I'm just trying to set things 
straight so we are all on the same page...again thanks for your time and 
comments! :)



Jim


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

Re: pool-map - a more disciplined version of pmap on top of executors

2013-01-15 Thread Marko Topolnik

user= (def dummy-times [3000 10 9 8 7 6 5 4 3 2 1])

 #'user/dummy-times
 user= (time  (pmap #(do (Thread/sleep %) %) dummy-times)) 
 Elapsed time: 16.213366 msecs
 (3000 10 9 8 7 6 5 4 3 2 1);;here you waited 3s before sleeping for 
 0.01 s
 user= (time  (pool-map #(do (Thread/sleep %) %) dummy-times))
 Elapsed time: 21.004979 msecs
 (10 9 8 7 6 5 4 3 2 1 3000)  ;;here you've not waited at all - sleeping 
 for 3s finished last and is last
 user= (time  (pool-map1 #(do (Thread/sleep %) %) dummy-times))
 Elapsed time: 3008.174631 msecs  ;;non-lazy?
 (3000 10 9 8 7 6 5 4 3 2 1)  ;;again your version will wait for the first 
 item to finish before proceeding


This only demonstrates a special case where there is an advantage. What 
about the scenario with 

(def dummy-times [3000 3000 3000 3000 3000 3000 3000 10 9 8 7 6 5 4 3 2 1])

Now all your threads are busy processing the long tasks, the shorter ones 
waiting patiently at the end of the queue. Nothing gained.
 

 hmmm...so the completion service is useless? It can't be... You say 
 that'You can't know which tasks will take less time until they are already 
 done' but the way I see it you don't  need to...all you need to know at any 
 given time is whether a or some  futures have completed. 


The tasks are waiting in the queue, they are not being executed at all. And 
the time they spend waiting cannot theoretically be a function of the time 
they will take to execute, once they get their chance.


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

Re: a join function that can be used in a reduce

2013-01-15 Thread JM Ibanez

Hi Andrew, 

On Tuesday, January 15, 2013 at 10:23 AM, Andrew Xue wrote: 
 Hi --
 
 Building some generic joining functionality on top of cascalog, the clojure 
 package for big data. 
 
 I have a join function that is defined like this:
 
 (defn join [lhs rhs join-ons] ..implementation ...)
 
 lhs and rhs are subqueries. the join returns then another query that is a 
 join of the two.
 
 join-ons in this case would look something like this [{lhs: user_id_lhs 
 :rhs user_id_rhs :as user_id}]
 
 each map in the vector corresponds to a join condition (in sql, the above 
 would be like lhs join rhs on lhs.user_id_lhs=rhs.user_id_rhs) .. the :as 
 keyword renames the join variable in the result of the join. join-ons is a 
 vector of these join conditions. 
 
 this works ok and its basically modeled after joins in sql.
 
 however it would be nice to able to do something maybe like this
 
 (reduce join [query1 query2 query3 ... queryN])
 
 i am having trouble picturing how the join-ons would work in this case though 
 ...

The simplest way to do this is to define a function generator:

   (defn generate-join-fn [join-ons]
(fn [lhs rhs]
  (let [join-on-cond (join-ons [lhs rhs])]
(join lhs rhs join-on-cond

This will then be used as such:
  
  (reduce 
   (generate-join-fn {[my-left my-right] {:lhs myleft :rhs myright}
 [my-right my-final] {:lhs myright :rhs myfinal}})
   [my-left my-right my-final])

Having the function that returns the actual reducer function is what is key.


HTH,
-- 
JM Ibanez
jmiba...@gmail.com
http://jmibanez.com/

Sent with Sparrow (http://www.sparrowmailapp.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

Re: pool-map - a more disciplined version of pmap on top of executors

2013-01-15 Thread Jim foo.bar


On 15/01/13 12:57, Marko Topolnik wrote:
The tasks are waiting in the queue, they are not being executed at 
all. And the time they spend waiting cannot theoretically be a 
function of the time they will take to execute, once they get their 
chance.


a so Java Futures are not the same as Clojure futures then! A 
Clojure future will fire up as soon as you define it yes? If what you 
say is true, then Java Future objects are not the same! I was under the 
impression that as soon as you submit the job and get the Future Object 
back , the actual computation has started already! I was wrong then...


Hmmm... now everything you've said so far makes sense! So we can't have 
our cake and eat it too? What if I grew the size of the pool to (count 
coll) instead of cpu-no? Then there would be no futures waiting for 
their turn but it could have a bad impact on thread-coordination. 
However it seems to work as I previously described and a lot faster!


user= (time (doall (pool-map #(do (Thread/sleep %) %) dummy-times))) 
;;pool of size: (count coll)

Elapsed time: 3005.827802 msecs
(1 2 3 4 6 5 7 8 9 10 3000 3000 3000 3000 3000 3000 3000)


user= (time (doall (pool-map #(do (Thread/sleep %) %) dummy-times))) 
;;pool of size: cpu-no -4

Elapsed time: 12003.958141 msecs
(3000 3000 3000 3000 3000 3000 10 9 8 7 6 5 4 3 2 1 3000)


Your version of pool-map behaves the same! It takes 4 times less!!! I 
wasn't expecting that improvement at all!




Jim



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

Re: [ANN] nrepl-transcript

2013-01-15 Thread Bob Hutchison


On 2013-01-14, at 3:58 PM, Jonas jonas.enl...@gmail.com wrote:

 Hi
 
 I created a middleware for nrepl that saves a transcript of your repl 
 interactions so you can go back and see what you did. 
 
 https://github.com/jonase/nrepl-transcript
 
 Feedback welcome!

Oh! Thank you!

Bob

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

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

Re: CLJS: undefined and nil are equally nil?

2013-01-15 Thread David Nolen

This is an unrelated issue. We could probably simulate this by creating a
Unbound type and initializing def'ed vars without init expressions to
instances of it.

David


On Tue, Jan 15, 2013 at 1:08 AM, Frank Siebenlist 
frank.siebenl...@gmail.com wrote:

 ClojureScript:cljs.user (def a nil)
 nil
 ClojureScript:cljs.user (def b)

 ClojureScript:cljs.user (= a b)
 true
 
 user= (def a nil)
 #'user/a
 user= (def b)
 #'user/b
 user= (= a b)
 false
 

 I didn't realize that the above is dark cave material ;-)

 Could you elaborate a little on the desirable aspect?
 (I'm not arguing - only trying to understand as I have just been bitten by
 this behavior)

 Thanks, FrankS.




 On Jan 14, 2013, at 9:25 PM, David Nolen dnolen.li...@gmail.com wrote:

  This behavior is desirable. Unless you are in some dark cave of interop
 you shouldn't care.
 
  On Tuesday, January 15, 2013, Frank Siebenlist wrote:
  ClojureScript:cljs.user (def a nil)
  nil
  ClojureScript:cljs.user (def b)
 
  ClojureScript:cljs.user (undefined? a)
  false
  ClojureScript:cljs.user (undefined? b)
  true
  ClojureScript:cljs.user (nil? a)
  true
  ClojureScript:cljs.user (nil? b)
  true
  ClojureScript:cljs.user (type a)
  nil
  ClojureScript:cljs.user (type b)
  nil
  ClojureScript:cljs.user (goog.typeOf a)
  null
  ClojureScript:cljs.user (goog.typeOf b)
  undefined
  ClojureScript:cljs.user (= a b)
  true
 
 
  That doesn't feel right… does it?
 
  Definitely different from clojure… although it's difficult to compare
 without vars in cljs.
 
  -FrankS.
 
 
 
  --
  You received this message because you are subscribed to the Google
  Groups Clojure group.
  To post to this group, send email to clojure@googlegroups.com
  Note that posts from new members are moderated - please be patient with
 your first post.
  To unsubscribe from this group, send email to
  clojure+unsubscr...@googlegroups.com
  For more options, visit this group at
  http://groups.google.com/group/clojure?hl=en
 
  --
  You received this message because you are subscribed to the Google
  Groups Clojure group.
  To post to this group, send email to clojure@googlegroups.com
  Note that posts from new members are moderated - please be patient with
 your first post.
  To unsubscribe from this group, send email to
  clojure+unsubscr...@googlegroups.com
  For more options, visit this group at
  http://groups.google.com/group/clojure?hl=en

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


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

Re: pool-map - a more disciplined version of pmap on top of executors

2013-01-15 Thread Marko Topolnik



 so Java Futures are not the same as Clojure futures then! A 
 Clojure future will fire up as soon as you define it yes? If what you 
 say is true, then Java Future objects are not the same! I was under the 
 impression that as soon as you submit the job and get the Future Object 
 back , the actual computation has started already! I was wrong then... 


It's not about futures, but about the way the ExecutorService is 
configured. Clojure's *future-call* apparently uses the *agent send-off pool
*, which is an unbounded thread pool executor. So you can use the same 
thing with *Executors/newCachedThreadPool* or instantiate one directly with 
a constructor, which gives finer-grained control over the behavior.
 

 What if I grew the size of the pool to (count 
 coll) instead of cpu-no? Then there would be no futures waiting for 
 their turn but it could have a bad impact on thread-coordination. 


Yes, the impact could be dreadful, possibly even resulting in *OutOfMemory* and 
the total time of execution would definitely deteriorate. This is not the 
smart way to go.

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

Re: pool-map - a more disciplined version of pmap on top of executors

2013-01-15 Thread Jim foo.bar


On 15/01/13 13:49, Marko Topolnik wrote:
It's not about futures, but about the way the ExecutorService is 
configured. Clojure's /future-call/ apparently uses the /agent 
send-off pool/, which is an unbounded thread pool executor. So you can 
use the same thing with /Executors/newCachedThreadPool/ or instantiate 
one directly with a constructor, which gives finer-grained control 
over the behavior.


That's more like it!!! /Executors/newCachedThreadPool/ works exactly as 
I 'd want without the risk of overwhelming the system with threads 
(which the fixed-size pool will if I initialize it with (count coll))...


I have used this thread pool before - I can't believe my mind completely 
forgot it! I think this  is the best version of pool-map so far:


(defn pool-map
A saner, more disciplined version of pmap.
 Submits jobs eagerly but polls for results lazily.
 Don't use if original ordering of 'coll' matters.
[f coll]
 (let [exec (Executors/newCachedThreadPool)
   pool (ExecutorCompletionService. exec)
   futures (doall (for [x coll] (.submit pool #(f x]
(try
 (for [_ futures]  (.. pool take get))
(finally (.shutdown exec)


1. it keeps its semi-lazy nature which is good from memory-allocation
   standpoint
2. will not block small tasks from finishing first (that is the whole
   purpose of this pool)
3. completion service does what its supposed to do
4. the system will recycle threads accordingly

I'm feeling a lot more confident now... :)
Thanks a million Marko!

Jim



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

Re: pool-map - a more disciplined version of pmap on top of executors

2013-01-15 Thread Marko Topolnik



 (defn pool-map 
 A saner, more disciplined version of pmap. 
  Submits jobs eagerly but polls for results lazily. 
  Don't use if original ordering of 'coll' matters. 
 [f coll]
  (let [exec (Executors/newCachedThreadPool)
pool (ExecutorCompletionService. exec)
futures (doall (for [x coll] (.submit pool #(f x] 
 (try 
  (for [_ futures]  (.. pool take get))
 (finally (.shutdown exec)


It would be simpler (and possibly just a tad more performant) to use 
.invokeAll instead of (doall (for ... .submit)).

Also, your try-finally block doesn't make much sense when you consider that 
(for ...) returns *immediately*, without evaluating anything. The 
try-finally belongs to the place where you submit your tasks. There is no 
reason to delay shutting down the executor service after having submitted 
all tasks.

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

Re: pool-map - a more disciplined version of pmap on top of executors

2013-01-15 Thread Marko Topolnik



  *Executors/newCachedThreadPool* works exactly as I 'd want without the 
 risk of overwhelming the system with threads (which the fixed-size pool 
 will if I initialize it with (count coll))...


You will either ovewhelm the system with threads or have the tasks waiting 
in the queue, there is no escaping it. For example:

(pool-map #(do (Thread/sleep %) %)
   (concat (repeat 1000 100) (repeat 100 1)))

prints

(100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 
100 100 ...)

meaning none of the fast tasks got to execute before at least some of the 
long tasks had already completed.

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

Re: ANN: bouncer, validation library for clojure

2013-01-15 Thread Gary Johnson

Right, I was testing against 1.5.0-RC1 and 1.5.0-RC2. Same problem occurred 
both times. I should have reported that in my initial bug report. Sorry 
about that. Also, thanks for the quick turnaround. I'll pull it and test it 
out.

  ~Gary

On Monday, January 14, 2013 7:16:29 PM UTC-5, Leonardo Borges wrote:

 Sean pointed me to it in the other thread. I read the ticket and 
 discussion - I personally don't feel it's abuse. To me it feels as natural 
 a use of destructuring as any other.

 just my 2c.

 Leonardo Borges
 www.leonardoborges.com


 On Tue, Jan 15, 2013 at 11:14 AM, Toby Crawley 
 to...@tcrawley.orgjavascript:
  wrote:

 This issue has already been reported and filed:
 http://dev.clojure.org/jira/browse/CLJ-1140

 There's been some discussion around that issue on clojure-dev@ as to
 whether this is a regression or an abuse of destructuring.

 Leonardo Borges writes:

  Alright so the bug appears in Clojure 1.5.0-RC1 - I'm not sure whether 
 this
  is a regression or intended behaviour so I'll send a separate email to 
 the
  list about that.
 


 --
 Toby Crawley
 http://immutant.org | http://torquebox.org

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




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

Re: CLJS: undefined and nil are equally nil?

2013-01-15 Thread Frank Siebenlist

I opened issue CLJS-457 for this enhancement/bug.

As a workaround, one can test for undefined?, although that is not really the 
same and cljs-specific, but for my use case that will do.

Thanks, Frank.


On Jan 15, 2013, at 5:32 AM, David Nolen dnolen.li...@gmail.com wrote:

 This is an unrelated issue. We could probably simulate this by creating a 
 Unbound type and initializing def'ed vars without init expressions to 
 instances of it.
 
 David
 
 
 On Tue, Jan 15, 2013 at 1:08 AM, Frank Siebenlist 
 frank.siebenl...@gmail.com wrote:
 ClojureScript:cljs.user (def a nil)
 nil
 ClojureScript:cljs.user (def b)
 
 ClojureScript:cljs.user (= a b)
 true
 
 user= (def a nil)
 #'user/a
 user= (def b)
 #'user/b
 user= (= a b)
 false
 
 
 I didn't realize that the above is dark cave material ;-)
 
 Could you elaborate a little on the desirable aspect?
 (I'm not arguing - only trying to understand as I have just been bitten by 
 this behavior)
 
 Thanks, FrankS.
 
 
 
 
 On Jan 14, 2013, at 9:25 PM, David Nolen dnolen.li...@gmail.com wrote:
 
  This behavior is desirable. Unless you are in some dark cave of interop you 
  shouldn't care.
 
  On Tuesday, January 15, 2013, Frank Siebenlist wrote:
  ClojureScript:cljs.user (def a nil)
  nil
  ClojureScript:cljs.user (def b)
 
  ClojureScript:cljs.user (undefined? a)
  false
  ClojureScript:cljs.user (undefined? b)
  true
  ClojureScript:cljs.user (nil? a)
  true
  ClojureScript:cljs.user (nil? b)
  true
  ClojureScript:cljs.user (type a)
  nil
  ClojureScript:cljs.user (type b)
  nil
  ClojureScript:cljs.user (goog.typeOf a)
  null
  ClojureScript:cljs.user (goog.typeOf b)
  undefined
  ClojureScript:cljs.user (= a b)
  true
 
 
  That doesn't feel right… does it?
 
  Definitely different from clojure… although it's difficult to compare 
  without vars in cljs.
 
  -FrankS.
 
 
 
  --
  You received this message because you are subscribed to the Google
  Groups Clojure group.
  To post to this group, send email to clojure@googlegroups.com
  Note that posts from new members are moderated - please be patient with 
  your first post.
  To unsubscribe from this group, send email to
  clojure+unsubscr...@googlegroups.com
  For more options, visit this group at
  http://groups.google.com/group/clojure?hl=en
 
  --
  You received this message because you are subscribed to the Google
  Groups Clojure group.
  To post to this group, send email to clojure@googlegroups.com
  Note that posts from new members are moderated - please be patient with 
  your first post.
  To unsubscribe from this group, send email to
  clojure+unsubscr...@googlegroups.com
  For more options, visit this group at
  http://groups.google.com/group/clojure?hl=en
 
 --
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clojure@googlegroups.com
 Note that posts from new members are moderated - please be patient with your 
 first post.
 To unsubscribe from this group, send email to
 clojure+unsubscr...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en
 
 
 -- 
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clojure@googlegroups.com
 Note that posts from new members are moderated - please be patient with your 
 first post.
 To unsubscribe from this group, send email to
 clojure+unsubscr...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en

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

Re: ANN: bouncer, validation library for clojure

2013-01-15 Thread Gary Johnson

Worked like a charm. Thanks.

On Tuesday, January 15, 2013 12:33:26 PM UTC-5, Gary Johnson wrote:

 Right, I was testing against 1.5.0-RC1 and 1.5.0-RC2. Same problem 
 occurred both times. I should have reported that in my initial bug report. 
 Sorry about that. Also, thanks for the quick turnaround. I'll pull it and 
 test it out.

   ~Gary

 On Monday, January 14, 2013 7:16:29 PM UTC-5, Leonardo Borges wrote:

 Sean pointed me to it in the other thread. I read the ticket and 
 discussion - I personally don't feel it's abuse. To me it feels as natural 
 a use of destructuring as any other.

 just my 2c.

 Leonardo Borges
 www.leonardoborges.com


 On Tue, Jan 15, 2013 at 11:14 AM, Toby Crawley to...@tcrawley.orgwrote:

 This issue has already been reported and filed:
 http://dev.clojure.org/jira/browse/CLJ-1140

 There's been some discussion around that issue on clojure-dev@ as to
 whether this is a regression or an abuse of destructuring.

 Leonardo Borges writes:

  Alright so the bug appears in Clojure 1.5.0-RC1 - I'm not sure whether 
 this
  is a regression or intended behaviour so I'll send a separate email to 
 the
  list about that.
 


 --
 Toby Crawley
 http://immutant.org | http://torquebox.org

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

[ANN] Leiningen 2.0.0-RC2

2013-01-15 Thread Phil Hagelberg


Hello good people of Clojure.

This weekend we had the pleasure of releasing the second release
candidate for Leiningen 2.0.0. There was an RC1 release a bit before
that which contained a number of bugs that have been fixed too, but if
you're currently using a preview release of Leiningen it would be great
if you could test with the latest release candidate so we can be sure
there are no show-stoppers for a final 2.0.0 release, which we hope to
have out by the end of the week.

$ lein upgrade 2.0.0-RC2

Highlights in the release candidates include:

* Reduce redundant output during dependency resolution. (Nelson Morris)
* Honor per-project REPL history. (Michael Klishin, Colin Jones)
* Read environment variables from project.clj. (Justin Balthrop)
* Allow searching over fields other than artifact id. (Michael Klishin)
* Don't AOT the `:main` namespace outside of uberjar task.
* Allow hooks from profiles to apply with limited scope. (Hugo Duncan)
* Support reading from stdin inside project process.
* Add `:only` test selector. (Anthony Grimes)
* Support partial application for test selectors. (Anthony Grimes)
* Un-deprecate `:auth` profile for full-disk-encryption users.

...along with a number of bug fixes. Thanks to all the contributors and
bug reporters who helped out with this release.

https://github.com/technomancy/leiningen/blob/master/NEWS.md

If you've been tracking the development plans for Leiningen 2, you may
be curious to note that the above does not include a switch to the
Clojars releases repository. We ran into a number of unforeseen
technical problems with the promotion process to the releases repository
and want to give library authors more time to get their artifacts
promoted; I hope to follow up on that once we're able to deploy some
Clojars changes to help address those issues. For the time being
Leiningen's behaviour regarding Clojars remains unchanged.

-Phil


pgprwf21cH0eb.pgp
Description: PGP signature

Re: CLJS: undefined and nil are equally nil?

2013-01-15 Thread David Nolen

Thanks, will look into it.


On Tue, Jan 15, 2013 at 12:33 PM, Frank Siebenlist 
frank.siebenl...@gmail.com wrote:

 I opened issue CLJS-457 for this enhancement/bug.

 As a workaround, one can test for undefined?, although that is not really
 the same and cljs-specific, but for my use case that will do.

 Thanks, Frank.


 On Jan 15, 2013, at 5:32 AM, David Nolen dnolen.li...@gmail.com wrote:

  This is an unrelated issue. We could probably simulate this by creating
 a Unbound type and initializing def'ed vars without init expressions to
 instances of it.
 
  David
 
 
  On Tue, Jan 15, 2013 at 1:08 AM, Frank Siebenlist 
 frank.siebenl...@gmail.com wrote:
  ClojureScript:cljs.user (def a nil)
  nil
  ClojureScript:cljs.user (def b)
 
  ClojureScript:cljs.user (= a b)
  true
  
  user= (def a nil)
  #'user/a
  user= (def b)
  #'user/b
  user= (= a b)
  false
  
 
  I didn't realize that the above is dark cave material ;-)
 
  Could you elaborate a little on the desirable aspect?
  (I'm not arguing - only trying to understand as I have just been bitten
 by this behavior)
 
  Thanks, FrankS.
 
 
 
 
  On Jan 14, 2013, at 9:25 PM, David Nolen dnolen.li...@gmail.com wrote:
 
   This behavior is desirable. Unless you are in some dark cave of
 interop you shouldn't care.
  
   On Tuesday, January 15, 2013, Frank Siebenlist wrote:
   ClojureScript:cljs.user (def a nil)
   nil
   ClojureScript:cljs.user (def b)
  
   ClojureScript:cljs.user (undefined? a)
   false
   ClojureScript:cljs.user (undefined? b)
   true
   ClojureScript:cljs.user (nil? a)
   true
   ClojureScript:cljs.user (nil? b)
   true
   ClojureScript:cljs.user (type a)
   nil
   ClojureScript:cljs.user (type b)
   nil
   ClojureScript:cljs.user (goog.typeOf a)
   null
   ClojureScript:cljs.user (goog.typeOf b)
   undefined
   ClojureScript:cljs.user (= a b)
   true
  
  
   That doesn't feel right… does it?
  
   Definitely different from clojure… although it's difficult to compare
 without vars in cljs.
  
   -FrankS.
  
  
  
   --
   You received this message because you are subscribed to the Google
   Groups Clojure group.
   To post to this group, send email to clojure@googlegroups.com
   Note that posts from new members are moderated - please be patient
 with your first post.
   To unsubscribe from this group, send email to
   clojure+unsubscr...@googlegroups.com
   For more options, visit this group at
   http://groups.google.com/group/clojure?hl=en
  
   --
   You received this message because you are subscribed to the Google
   Groups Clojure group.
   To post to this group, send email to clojure@googlegroups.com
   Note that posts from new members are moderated - please be patient
 with your first post.
   To unsubscribe from this group, send email to
   clojure+unsubscr...@googlegroups.com
   For more options, visit this group at
   http://groups.google.com/group/clojure?hl=en
 
  --
  You received this message because you are subscribed to the Google
  Groups Clojure group.
  To post to this group, send email to clojure@googlegroups.com
  Note that posts from new members are moderated - please be patient with
 your first post.
  To unsubscribe from this group, send email to
  clojure+unsubscr...@googlegroups.com
  For more options, visit this group at
  http://groups.google.com/group/clojure?hl=en
 
 
  --
  You received this message because you are subscribed to the Google
  Groups Clojure group.
  To post to this group, send email to clojure@googlegroups.com
  Note that posts from new members are moderated - please be patient with
 your first post.
  To unsubscribe from this group, send email to
  clojure+unsubscr...@googlegroups.com
  For more options, visit this group at
  http://groups.google.com/group/clojure?hl=en

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


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

Re: Standardized value for no-value?

2013-01-15 Thread Herwig Hochleitner

There actually is a standardized value for no value in clojure: nil
The reason it's not useable as such in some places, is exactly it being
standardized.
Were we to introduce another such non-value, e.g. #blackhole, I think the
following would happen:

- people would be horribly confused on whether to use nil or #blackhole,
and rightfully so
- additional interop issues would be created, since you never know if you
have to expect nil, #blackhole or both
- it would help no one, since you still have to create custom values for
domain-specific nils, that have to be distinguishable from nil or
#blackhole

Effectively you are proposing a third 'falsey' value apart from false and
nil which would get us into the same mess as js with undefined vs null.
Except the stereotypical clojure dev would pull her hair out over this,
while the stereotypical js dev doesn't care and can't afford to, they even
have 0 == false and  == false.

So the way to do it in clojure: ::undefined or a sentinel (Object.), if you
conceivably could get ::undefined in the data, like when processing your
own source code.

Remaining cases:

(f x) behaving differently from (f x nil): Just don't, even if it can be
done with arity overloading
(get {} :x) vs (get {:x nil} :x): to most code it should make no
difference. when it does, there is contains? or the not-found arg of get

That said, in CLJS we have adopted undefined as a third falsey value,
distinguishable from false and nil. I have no experience with problems
caused by reusing undefined as a domain specific nil, since I always treat
nil and undefined indifferently, so YMMV

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

can not get session with Ring and Compojure

2013-01-15 Thread larry google groups


I am not sure if this is a Ring problem or a Compojure problem. I set
up my app as you see below. However, when I go to /, I have the
function do this:

(prn (apply str request))

and I see a great deal of information printed out at the terminal, but
no session is set. What am I doing wrong? How do I initiate the
session?

(defroutes app-routes
  (GET / request (index request))
  (GET /search-results request (search-results request))
  (GET /account request (friend/authorize #{::user} (enlive/emit*
(enlive/html-resource templates/account.html
  (GET /admin request (friend/authorize #{::admin} (enlive/emit*
(enlive/html-resource templates/admin.html
  (friend/logout (ANY /logout request (ring.util.response/redirect
/
(GET /login request Login page.)
(GET /schema request (apply str (yaml/generate-string
@interactions))
 (route/not-found Page not found))

(def app
  (- app-routes
  (friend/authenticate {:credential-fn (partial creds/bcrypt-
credential-fn (:users interactions))
:workflows [(workflows/interactive-
form)]})
  (wrap-resource public)
  (wrap-params)
  (wrap-session {:cookie-name timeout-discovery-session :store
(cookie-store) :cookie-attrs {:max-age 1000 }})))

(defn -main [ args]
  (let [port (Integer/parseInt (first args))]
(try
  (run-jetty #'app {:port (or port 8080) :join? false})
  (catch Exception e (debug/print-error-info e)

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

Re: Standardized value for no-value?

2013-01-15 Thread David Nolen

Using `undefined?` for anything other than JS interop is not recommended. I
don't see any issues with:

(def foo (atom ::uninitialized))

For your watcher case.


On Mon, Jan 14, 2013 at 11:25 PM, Frank Siebenlist 
frank.siebenl...@gmail.com wrote:

 Ok - ClojureScript has an undefined? function that works like:


 ClojureScript:cljs.user (def v)

 ClojureScript:cljs.user (undefined? v)
 true
 ClojureScript:cljs.user (def w nil)
 nil
 ClojureScript:cljs.user (undefined? w)
 false
 ClojureScript:cljs.user (defn f [v] (if (undefined? v) :no-value v))
 #function f(v){
 if((void 0 === v))
 {return \uFDD0:no-value;
 } else
 {return v;
 }
 }
 ClojureScript:cljs.user (f z)
 :no-value
 ClojureScript:cljs.user (f 1)
 1
 ClojureScript:cljs.user (f y)
 nil


 which indicates that I can use that scheme to pass and detect no-value
 arguments in cljs.

 Isn't it great to answer your own Qs ;-)

 -FS.



 On Jan 14, 2013, at 7:47 PM, Frank Siebenlist frank.siebenl...@gmail.com
 wrote:

  For clojure I came up with the following alternative using an unbound
 var:
 
  user= (def v)
  #'user/v
  user= (defn f [x] (if (var? x) (if (bound? x) x :no-value) x))
  #'user/f
  user= (f v)
  #Unbound Unbound: #'user/v
  user= (f #'v)
  :no-value
  user= (f #'map)
  #'clojure.core/map
  user= (type (f v))
  clojure.lang.Var$Unbound
  user=
 
  which would indicate that I could pass an unbound var as the argument to
 indicate a no-value value, which I can either detect thru the type or the
 bound? test.
 
  However, next issue is how to do this in ClojureScript as we do not have
 any vars and therefor no unbound vars…?
 
  -FS.
 
 
  On Jan 14, 2013, at 7:07 PM, Frank Siebenlist 
 frank.siebenl...@gmail.com wrote:
 
  Understood.
 
  … but shouldn't it be a standardized constant for the whole community
 to use to avoid any interoperability issues and many reinvented wheels?
 
  The concept of no-value versus nil is a pretty basic one - there must
 be better solutions (re)invented many times over ;-)
 
  -FS.
 
 
  On Jan 14, 2013, at 5:23 PM, Timothy Baldridge tbaldri...@gmail.com
 wrote:
 
  It's fairly common in situations like this to use a namespaced
 keyword. For instance ::unknown (which is short for my.namespace/unknown).
 
 
  On Mon, Jan 14, 2013 at 6:06 PM, Frank Siebenlist 
 frank.siebenl...@gmail.com wrote:
  I'm using those watcher-fns that get called when the watched ref
 changes, and the watcher-fn gets passed the old-value and the new-value.
 
  Now, nil is a proper value for a key-value and well as a val-value in
 a map, so passing nil does not give you the info whether or not an
 old-value existed or not, or whether a new-value is nil or no-value.
 
  With the getter fn: (get m k no-value-here), you have the option to
 pass this no-value-here argument which gets returned if there was no value
 - this allows you to distinguish nil from no-value. However, in the
 watcher-fn you cannot pass such a no-value argument.
 
  One possible solution would be to define a well-know URI for the value
 of no-value - something like for example: uri:
 http://clojure.org/uri/no-value;, or some other standardized constant.
 
  Any other/better suggestions?
 
  Thanks, FrankS.
 
  --
  You received this message because you are subscribed to the Google
  Groups Clojure group.
  To post to this group, send email to clojure@googlegroups.com
  Note that posts from new members are moderated - please be patient
 with your first post.
  To unsubscribe from this group, send email to
  clojure+unsubscr...@googlegroups.com
  For more options, visit this group at
  http://groups.google.com/group/clojure?hl=en
 
 
 
  --
  “One of the main causes of the fall of the Roman Empire was
 that–lacking zero–they had no way to indicate successful termination of
 their C programs.”
  (Robert Firth)
 
  --
  You received this message because you are subscribed to the Google
  Groups Clojure group.
  To post to this group, send email to clojure@googlegroups.com
  Note that posts from new members are moderated - please be patient
 with your first post.
  To unsubscribe from this group, send email to
  clojure+unsubscr...@googlegroups.com
  For more options, visit this group at
  http://groups.google.com/group/clojure?hl=en
 
 

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


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

Re: Standardized value for no-value?

2013-01-15 Thread Stan Dyck

On 01/15/2013 11:48 AM, Herwig Hochleitner wrote:

There actually is a standardized value for no value in clojure: nil
The reason it's not useable as such in some places, is exactly it being
standardized.
Were we to introduce another such non-value, e.g. #blackhole, I think the
following would happen:

- people would be horribly confused on whether to use nil or #blackhole, and
rightfully so
- additional interop issues would be created, since you never know if you have to
expect nil, #blackhole or both
- it would help no one, since you still have to create custom values for
domain-specific nils, that have to be
distinguishable from nil or #blackhole

Effectively you are proposing a third 'falsey' value apart from false and nil
which would get us into the same mess as
js with undefined vs null.
Except the stereotypical clojure dev would pull her hair out over this, while
the stereotypical js dev doesn't care and
can't afford to, they even have 0 == false and == false.

This point it well taken. You should be thankful if you don't have to deal in the world of health care records where
there are something like a dozen different null flavors. Behold!

http://phinvads.cdc.gov/vads/ViewValueSet.action?id=A0D34BBC-617F-DD11-B38D-00188B398520

KISS

StanD.

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

blank? implementation

2013-01-15 Thread Thomas

Hi all,

In Stuart Halloway's book (Programming Clojure) is a wonderful example of
the succinctness of Clojure where he compares the Apache Commons
implementation of the isBlank method (
http://commons.apache.org/lang/api-2.5/src-html/org/apache/commons/lang/StringUtils.html#line.227)

with a Clojure equivalent which is a single line:

(defn blank? [s] (every? #(Character/isWhitespace %) s))

I have used this example a few times to show colleagues the difference
between Java and Clojure and why (IMHO) the Clojure solution is so much
nicer. Earlier today I looked at clojure.string and noticed that it had
blank? in it and looking at the source (
https://github.com/clojure/clojure/blob/f30995c86056959abca53d0ca35dcb9cfa73e6e6/src/clj/clojure/string.clj#L225)

I noticed that the actual implementation in Clojure is surprisingly similar
to the Java one (verbose, several if's, a loop etc.)

Is there any particular reason for this? It is performance? What is wrong
with Stuarts example? (I just checked it and it correct as far as I can
tell).

And a second question: What other examples are people using to demonstrate
the advantages of Clojure (in an elevator pitch style equivalent)

TIA,

Thomas

Re: blank? implementation

2013-01-15 Thread Thomas

I think I just answered my own question...

user= (time (dotimes [n 2] (s-blank? asdf)))
Elapsed time: 2481.018 msecs
nil
user= (time (dotimes [n 2] (blank? asdf)))
Elapsed time: 14.347 msecs
nil
user= 

Quite a difference I have to say. 

Thomas

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

Re: blank? implementation

2013-01-15 Thread Herwig Hochleitner

When you find non-idiomatic code in clojure's impl, the reason is almost
always performance.
In this case the clojure.string version is more performant since it saves:
1) the allocation of a lazy seq over the characters of the string
2) the allocation of a java.lang.Character for every char in the string,
thanks to clojure's ability to generate code for unboxed primitives

2013/1/15 Thomas th.vanderv...@gmail.com

Hi all,

(defn blank? [s] (every? #(Character/isWhitespace %) s))

Is there any particular reason for this? It is performance? What is wrong
with Stuarts example? (I just checked it and it correct as far as I can
tell).

And a second question: What other examples are people using to demonstrate
the advantages of Clojure (in an elevator pitch style equivalent)

TIA,

Thomas

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

Re: blank? implementation

2013-01-15 Thread Raoul Duke

 Quite a difference I have to say.

well, you can still be happy that first, get it right. then, make it
fast is still easier in clojure than in java! (of course if, like me,
you are a static typing bigot, there's more to be said on that :-)

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

Re: blank? implementation

2013-01-15 Thread Marko Topolnik



On Tuesday, January 15, 2013 9:35:07 PM UTC+1, Thomas wrote:

 I think I just answered my own question...

 user= (time (dotimes [n 2] (s-blank? asdf)))
 Elapsed time: 2481.018 msecs
 nil
 user= (time (dotimes [n 2] (blank? asdf)))
 Elapsed time: 14.347 msecs
 nil
 user= 

 Quite a difference I have to say. 


Yes; moreover, I find it misleading and almost a case of false advertising 
when such succint code is demonstrated without so much as a footnote 
mentioning the enormous performance penalty of converting a String into a 
sequence of Characters and then calling a higher-order function on it. The 
proper way to advertise Clojure is this: in Java you have little choice but 
write verbose, performant code; in Clojure you can go both ways and for 
most cases the overhead won't be the main bottleneck. But, at all times, do 
keep in mind the consequences of your choice of idiom.

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

Re: blank? implementation

2013-01-15 Thread Ben Wolfson

Note that the two functions aren't actually equivalent, since the
blank? that uses every? will accept anything that can be made a seq,
while the blank? in clojure.string does not.

Given an annotation like this, and assuming that every? is clojure.core/every?

(defn blank? [^CharSequence s] (every? #(Character/isWhitespace %) s))

it seems as if it should be possible for the compiler to generate the
faster code.

On Tue, Jan 15, 2013 at 12:42 PM, Marko Topolnik
marko.topol...@gmail.com wrote:


 On Tuesday, January 15, 2013 9:35:07 PM UTC+1, Thomas wrote:

 I think I just answered my own question...

 user= (time (dotimes [n 2] (s-blank? asdf)))
 Elapsed time: 2481.018 msecs
 nil
 user= (time (dotimes [n 2] (blank? asdf)))
 Elapsed time: 14.347 msecs
 nil
 user=

 Quite a difference I have to say.


 Yes; moreover, I find it misleading and almost a case of false advertising
 when such succint code is demonstrated without so much as a footnote
 mentioning the enormous performance penalty of converting a String into a
 sequence of Characters and then calling a higher-order function on it. The
 proper way to advertise Clojure is this: in Java you have little choice but
 write verbose, performant code; in Clojure you can go both ways and for most
 cases the overhead won't be the main bottleneck. But, at all times, do keep
 in mind the consequences of your choice of idiom.

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



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

Re: blank? implementation

2013-01-15 Thread Marko Topolnik



 Given an annotation like this, and assuming that every? is 
 clojure.core/every? 

 (defn blank? [^CharSequence s] (every? #(Character/isWhitespace %) s)) 

 it seems as if it should be possible for the compiler to generate the 
 faster code. 


Yes, there is enough information for a compiler that is prepared in advance 
to handle such a special case. In a future version this may become true for 
this one case; however, I don't expect *predictably* good performance of 
HOFs/lazy seqs in the foreseeable future. If Clojure will still be a 
relevant language at the time of my retirement, by then it really could 
become a rock-solid performer :)

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

[ANN] Formative - render, parse, and validate web forms

2013-01-15 Thread Justin Kramer

Formative is a library for dealing with web forms. Features:

   - Describe forms using simple data
   - Render forms via pluggable renderers (comes with Bootstrap and other 
   renderers built-in)
   - Parse submitted form data from Ring params
   - Validate parsed data using Verily https://github.com/jkk/verily(another 
new but less interesting lib)

A live demo can be seen at http://formative-demo.herokuapp.com/. Demo 
source: https://github.com/jkk/formative-demo

See the README for a usage guide and quick reference:

https://github.com/jkk/formative

It has seem some real-world usage, and I consider the API stable.

Feedback and contributions welcome.

Justin

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

Re: ANN: bouncer, validation library for clojure

2013-01-15 Thread Leonardo Borges

Excellent.

I'll push 0.2.2 final to clojars soon - as soon as I get the ANN email out.

Thanks for the help.

Cheers

Leonardo Borges
www.leonardoborges.com

On Wed, Jan 16, 2013 at 4:37 AM, Gary Johnson gwjoh...@uvm.edu wrote:

Worked like a charm. Thanks.

On Tuesday, January 15, 2013 12:33:26 PM UTC-5, Gary Johnson wrote:

Right, I was testing against 1.5.0-RC1 and 1.5.0-RC2. Same problem
occurred both times. I should have reported that in my initial bug report.
Sorry about that. Also, thanks for the quick turnaround. I'll pull it and
test it out.

~Gary

On Monday, January 14, 2013 7:16:29 PM UTC-5, Leonardo Borges wrote:

Sean pointed me to it in the other thread. I read the ticket and
discussion - I personally don't feel it's abuse. To me it feels as natural
a use of destructuring as any other.

just my 2c.

Leonardo Borges
www.leonardoborges.com

On Tue, Jan 15, 2013 at 11:14 AM, Toby Crawley to...@tcrawley.orgwrote:

This issue has already been reported and filed:
http://dev.clojure.org/jira/**browse/CLJ-1140http://dev.clojure.org/jira/browse/CLJ-1140

There's been some discussion around that issue on clojure-dev@ as to
whether this is a regression or an abuse of destructuring.

Leonardo Borges writes:

Alright so the bug appears in Clojure 1.5.0-RC1 - I'm not sure
whether this
is a regression or intended behaviour so I'll send a separate email
to the
list about that.

--
Toby Crawley
http://immutant.org | http://torquebox.org

--
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=enhttp://groups.google.com/group/clojure?hl=en

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

[ANN] bouncer 0.2.2 released

2013-01-15 Thread Leonardo Borges

bouncer is a validation DSL for Clojure apps

Github: https://github.com/leonardoborges/bouncer
Clojars: https://clojars.org/bouncer

Highlights of version 0.2.2:

- Use of a qualified keyword for storing the validation results
- The defvalidator macro allows defining validators with an arbitrary
number of arguments
- New validators
- Better docs
- minor bug fixes
- more...

Please have a look at the
CHANGELOGhttps://github.com/leonardoborges/bouncer/blob/master/CHANGELOG.md
for
details.

As always, feedback is welcome.

Cheers,
Leonardo Borges
www.leonardoborges.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

Re: blank? implementation

2013-01-15 Thread Leonardo Borges

This is interesting. We can get quite a huge performance boos by type 
hinting that impl.

Times on my system running Clojure 1.4.0:

user= (defn s-blank? [s] (every? #(Character/isWhitespace %) s))
user= (time (dotimes [n 2] (s-blank? asdf)))
Elapsed time: 247.252 msecs

Now if we type hint s-blank, here's what I get:

(defn s-blank? [^CharSequence s] (every? (fn [^Character c] 
(Character/isWhitespace c)) s))

user= (time (dotimes [n 2] (s-blank? asdf)))
Elapsed time: 9.122 msecs

Not bad :) Especially when compared to clojure's blank? :

user= (time (dotimes [n 2] (clojure.string/blank? asdf)))
Elapsed time: 2.62 msecs

Is it still slower? Absolutely! But we didn't have to give up the 
functional approach to boost performance - a little type hinting in this 
case provided a huge benefit.

On Wednesday, January 16, 2013 7:35:07 AM UTC+11, Thomas wrote:

 I think I just answered my own question...

 user= (time (dotimes [n 2] (s-blank? asdf)))
 Elapsed time: 2481.018 msecs
 nil
 user= (time (dotimes [n 2] (blank? asdf)))
 Elapsed time: 14.347 msecs
 nil
 user= 

 Quite a difference I have to say. 

 Thomas


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

Re: Better ways of documenting functions with type information?

2013-01-15 Thread Stephen Compall

On Sun, 2013-01-13 at 19:03 +0100, Marcel Möhring wrote:
 Currently I am using this approach but it feels rather clumsy:
 
 Takes a screen and a pixel coordinate and returns
 a map of maps with pixel colors
 and adjusted pixel coordinates around the pixel.
 Directions are degree numbers from 0 to 315.
 in: screen (BufferedImage), x (Number), y (Number)
 out: map of maps ({direction (Number) {:color (Number) :x (Number) 
 :y (Number)}})
 
 Are there any better ways?

Using your argument names in prose is superior to saying the order,
because you can read the order from other places.

Return a map of maps of pixel colors and coordinates on
BUFFERED-IMAGE surrounding (X, Y).
Directions are degree numbers from 0 to 315.
out: map of maps ({direction (Number) {:color (Number) :x (Number) 
   :y (Number)}})
  ;; hey you have a lambda list saying where the args go
  [buffered-image x y]

Also, here is a type annotation that documents your argument/return
types and registers them with Typed Clojure[1] for type checking:

(ann my-function [BufferedImage Number Number]
 - (Option (Seqable ...)))

Here is a version of that annotation that doesn't require Typed Clojure,
or anything at all really, although you don't get the type checking:

'(ann my-function [BufferedImage Number Number]
  - (Option (Seqable ...)))

[1] https://github.com/frenchy64/typed-clojure/wiki

-- 
Stephen Compall
^aCollection allSatisfy: [:each|aCondition]: less is better

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

[ANN] tracer, trace your clojure function call stack

2013-01-15 Thread James Xu

https://github.com/xumingming/tracer

tracer

trace clojure call stack.

When I read some open source clojure source code, I find that some 
function/logic are so complex that it is not so easy to understand the 
whole logic, I think it will help me a lot if I can see the real function 
call stack with the provided paremeters, so I developed this simple tool to 
facilitate reading of clojure source code.
https://github.com/xumingming/tracer#usageUsage
   
   - Include tracer in your project.clj

[tracer 1.0.0-SNAPSHOT]


   - Go into your project home and start the repl:

lein repl


   - use the tracer.core namespace

(use 'tracer.core)


   - Tell tracer which namespace you want to trace:

;; CHANGE 'blind.reader TO YOUR OWN namespace(trace 'blind.reader)


   - Invoke your function to see what happens( *you get a call tree  with 
   the parameter value!* ):

user= (read-string \hello\)|--blind.reader$read-string (hello)
  |--blind.reader$string-push-back-reader (hello)
|--blind.reader$string-push-back-reader (hello 1)
  |--blind.reader$string-reader (hello)
  |--blind.reader$read (#PushbackReader blind.reader.PushbackReader@3eae3da8 
true nil false)
|--blind.reader$char ()|--blind.reader$whitespace? ()
|--blind.reader$number-literal? (#PushbackReader 
blind.reader.PushbackReader@3eae3da8 )  |--blind.reader$numeric? ()
|--blind.reader$comment-prefix? ()|--blind.reader$macros ()
|--blind.reader$read-string* (#PushbackReader 
blind.reader.PushbackReader@3eae3da8 )  |--blind.reader$char (h)  
|--blind.reader$char (e)  |--blind.reader$char (l)  
|--blind.reader$char (l)  |--blind.reader$char (o)  
|--blind.reader$char ()hello

https://github.com/xumingming/tracer#license

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

Error on redirect when attempting unauthorized entry to Friend route

2013-01-15 Thread larry google groups


I have the following setting up an app where some pages will be
protected by Friend.


(defroutes app-routes
  (GET / request (index request))
  (GET /search-results request (search-results request))
  (GET /account request (friend/authorize #{::user} (account
request)))
  (GET /admin request (friend/authorize #{::admin} (admin request)))
  (friend/logout (ANY /logout request (ring.util.response/redirect
/)))
  (GET /login request (login request))
  (route/not-found Page not found))

(def app
(- app-routes
(friend/authenticate {:credential-fn (partial creds/bcrypt-
credential-fn (:users @interactions))
  :workflows [(workflows/interactive-
form)]})
(wrap-resource public)
(wrap-session {:cookie-name discovery-session :cookie-attrs
{:max-age 1 }})
(wrap-cookies)
(wrap-params)))

(defn -main [ args]
  (let [port (Integer/parseInt (first args))]
(try
  (run-jetty #'app {:port (or port 8080) :join? false})
  (catch Exception e (debug/print-error-info e)




 If I try to go to /admin without being logged in, I should get
redirected to /login, but instead I get:

java.lang.ClassCastException: java.lang.String cannot be cast to
clojure.lang.Associative
at clojure.lang.RT.assoc(RT.java:691)
at clojure.core$assoc.invoke(core.clj:187)
at clojure.core$assoc_in.invoke(core.clj:5459)
at clojure.core$assoc_in.invoke(core.clj:5458)
at cemerick.friend
$default_unauthenticated_handler.invoke(friend.clj:164)
at clojure.lang.Var.invoke(Var.java:415)
at cemerick.friend$authenticate_STAR_.invoke(friend.clj:202)
at cemerick.friend$authenticate$fn__1341.invoke(friend.clj:
207)
at ring.middleware.resource$wrap_resource
$fn__2730.invoke(resource.clj:17)
at ring.middleware.session$wrap_session
$fn__2651.invoke(session.clj:43)
at ring.middleware.cookies$wrap_cookies
$fn__2588.invoke(cookies.clj:160)
at ring.middleware.cookies$wrap_cookies
$fn__2588.invoke(cookies.clj:160)
at ring.middleware.params$wrap_params
$fn__2400.invoke(params.clj:55)
at clojure.lang.Var.invoke(Var.java:415)
at ring.adapter.jetty$proxy_handler$fn__2809.invoke(jetty.clj:
18)
at ring.adapter.jetty.proxy
$org.eclipse.jetty.server.handler.AbstractHandler$0.handle(Unknown
Source)
at
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:
111)
at org.eclipse.jetty.server.Server.handle(Server.java:349)
at
org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:
452)
at
org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:
884)
at org.eclipse.jetty.server.AbstractHttpConnection
$RequestHandler.headerComplete(AbstractHttpConnection.java:938)
at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:
634)
at
org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:230)
at
org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:
76)
at
org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:
609)
at org.eclipse.jetty.io.nio.SelectChannelEndPoint
$1.run(SelectChannelEndPoint.java:45)
at
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:
599)
at org.eclipse.jetty.util.thread.QueuedThreadPool
$3.run(QueuedThreadPool.java:534)
at java.lang.Thread.run(Thread.java:722)


Has anyone seen this error before?

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

Re: Error on redirect when attempting unauthorized entry to Friend route

2013-01-15 Thread larry google groups

Reading here:

https://github.com/cemerick/friend

I see this:

(Note that Friend itself requires some core Ring middlewares: params,
keyword-params and nested-params.

I did not have nested-params so I will add this.

This might be a stupid question, but why doesn't Friend include the
Ring middlewares that it depends on? Why do I have to manually hook
these in when writing my app?



On Jan 16, 1:00 am, larry google groups lawrencecloj...@gmail.com
wrote:
 I have the following setting up an app where some pages will be
 protected by Friend.

 (defroutes app-routes
   (GET / request (index request))
   (GET /search-results request (search-results request))
   (GET /account request (friend/authorize #{::user} (account
 request)))
   (GET /admin request (friend/authorize #{::admin} (admin request)))
   (friend/logout (ANY /logout request (ring.util.response/redirect
 /)))
   (GET /login request (login request))
   (route/not-found Page not found))

 (def app
     (- app-routes
         (friend/authenticate {:credential-fn (partial creds/bcrypt-
 credential-fn (:users @interactions))
                               :workflows [(workflows/interactive-
 form)]})
         (wrap-resource public)
         (wrap-session {:cookie-name discovery-session :cookie-attrs
 {:max-age 1 }})
         (wrap-cookies)
         (wrap-params)))

 (defn -main [ args]
   (let [port (Integer/parseInt (first args))]
     (try
       (run-jetty #'app {:port (or port 8080) :join? false})
       (catch Exception e (debug/print-error-info e)

  If I try to go to /admin without being logged in, I should get
 redirected to /login, but instead I get:

 java.lang.ClassCastException: java.lang.String cannot be cast to
 clojure.lang.Associative
         at clojure.lang.RT.assoc(RT.java:691)
         at clojure.core$assoc.invoke(core.clj:187)
         at clojure.core$assoc_in.invoke(core.clj:5459)
         at clojure.core$assoc_in.invoke(core.clj:5458)
         at cemerick.friend
 $default_unauthenticated_handler.invoke(friend.clj:164)
         at clojure.lang.Var.invoke(Var.java:415)
         at cemerick.friend$authenticate_STAR_.invoke(friend.clj:202)
         at cemerick.friend$authenticate$fn__1341.invoke(friend.clj:
 207)
         at ring.middleware.resource$wrap_resource
 $fn__2730.invoke(resource.clj:17)
         at ring.middleware.session$wrap_session
 $fn__2651.invoke(session.clj:43)
         at ring.middleware.cookies$wrap_cookies
 $fn__2588.invoke(cookies.clj:160)
         at ring.middleware.cookies$wrap_cookies
 $fn__2588.invoke(cookies.clj:160)
         at ring.middleware.params$wrap_params
 $fn__2400.invoke(params.clj:55)
         at clojure.lang.Var.invoke(Var.java:415)
         at ring.adapter.jetty$proxy_handler$fn__2809.invoke(jetty.clj:
 18)
         at ring.adapter.jetty.proxy
 $org.eclipse.jetty.server.handler.AbstractHandler$0.handle(Unknown
 Source)
         at
 org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:
 111)
         at org.eclipse.jetty.server.Server.handle(Server.java:349)
         at
 org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpC 
 onnection.java:
 452)
         at
 org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttp 
 Connection.java:
 884)
         at org.eclipse.jetty.server.AbstractHttpConnection
 $RequestHandler.headerComplete(AbstractHttpConnection.java:938)
         at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:
 634)
         at
 org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:230)
         at
 org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.jav a:
 76)
         at
 org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint 
 .java:
 609)
         at org.eclipse.jetty.io.nio.SelectChannelEndPoint
 $1.run(SelectChannelEndPoint.java:45)
         at
 org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java :
 599)
         at org.eclipse.jetty.util.thread.QueuedThreadPool
 $3.run(QueuedThreadPool.java:534)
         at java.lang.Thread.run(Thread.java:722)

 Has anyone seen this error before?

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

Re: Error on redirect when attempting unauthorized entry to Friend route

2013-01-15 Thread larry google groups

Looking here:

https://github.com/cemerick/friend/blob/master/src/cemerick/friend.clj

I see in the stacktrace that the problem seems to be with the last
line of this function:


(defn default-unauthenticated-handler
  [request]
  (- request
::auth-config
:login-uri
(util/resolve-absolute-uri request)
ring.util.response/redirect
(assoc :session (:session request))
(assoc-in [:session ::unauthorized-uri] (:uri request


I guess I've turned the request into a string by this point? I can get
to the unauthenticated routes in my app without a problem. They work
great. It is only the authenticated routes that blow up.

I am a bit confused about what is going on.





On Jan 16, 1:26 am, larry google groups lawrencecloj...@gmail.com
wrote:
 Reading here:

 https://github.com/cemerick/friend

 I see this:

 (Note that Friend itself requires some core Ring middlewares: params,
 keyword-params and nested-params.

 I did not have nested-params so I will add this.

 This might be a stupid question, but why doesn't Friend include the
 Ring middlewares that it depends on? Why do I have to manually hook
 these in when writing my app?

 On Jan 16, 1:00 am, larry google groups lawrencecloj...@gmail.com
 wrote:







  I have the following setting up an app where some pages will be
  protected by Friend.

  (defroutes app-routes
    (GET / request (index request))
    (GET /search-results request (search-results request))
    (GET /account request (friend/authorize #{::user} (account
  request)))
    (GET /admin request (friend/authorize #{::admin} (admin request)))
    (friend/logout (ANY /logout request (ring.util.response/redirect
  /)))
    (GET /login request (login request))
    (route/not-found Page not found))

  (def app
      (- app-routes
          (friend/authenticate {:credential-fn (partial creds/bcrypt-
  credential-fn (:users @interactions))
                                :workflows [(workflows/interactive-
  form)]})
          (wrap-resource public)
          (wrap-session {:cookie-name discovery-session :cookie-attrs
  {:max-age 1 }})
          (wrap-cookies)
          (wrap-params)))

  (defn -main [ args]
    (let [port (Integer/parseInt (first args))]
      (try
        (run-jetty #'app {:port (or port 8080) :join? false})
        (catch Exception e (debug/print-error-info e)

   If I try to go to /admin without being logged in, I should get
  redirected to /login, but instead I get:

  java.lang.ClassCastException: java.lang.String cannot be cast to
  clojure.lang.Associative
          at clojure.lang.RT.assoc(RT.java:691)
          at clojure.core$assoc.invoke(core.clj:187)
          at clojure.core$assoc_in.invoke(core.clj:5459)
          at clojure.core$assoc_in.invoke(core.clj:5458)
          at cemerick.friend
  $default_unauthenticated_handler.invoke(friend.clj:164)
          at clojure.lang.Var.invoke(Var.java:415)
          at cemerick.friend$authenticate_STAR_.invoke(friend.clj:202)
          at cemerick.friend$authenticate$fn__1341.invoke(friend.clj:
  207)
          at ring.middleware.resource$wrap_resource
  $fn__2730.invoke(resource.clj:17)
          at ring.middleware.session$wrap_session
  $fn__2651.invoke(session.clj:43)
          at ring.middleware.cookies$wrap_cookies
  $fn__2588.invoke(cookies.clj:160)
          at ring.middleware.cookies$wrap_cookies
  $fn__2588.invoke(cookies.clj:160)
          at ring.middleware.params$wrap_params
  $fn__2400.invoke(params.clj:55)
          at clojure.lang.Var.invoke(Var.java:415)
          at ring.adapter.jetty$proxy_handler$fn__2809.invoke(jetty.clj:
  18)
          at ring.adapter.jetty.proxy
  $org.eclipse.jetty.server.handler.AbstractHandler$0.handle(Unknown
  Source)
          at
  org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:
  111)
          at org.eclipse.jetty.server.Server.handle(Server.java:349)
          at
  org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpC 
  onnection.java:
  452)
          at
  org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttp 
  Connection.java:
  884)
          at org.eclipse.jetty.server.AbstractHttpConnection
  $RequestHandler.headerComplete(AbstractHttpConnection.java:938)
          at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:
  634)
          at
  org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:230)
          at
  org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.jav 
  a:
  76)
          at
  org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint 
  .java:
  609)
          at org.eclipse.jetty.io.nio.SelectChannelEndPoint
  $1.run(SelectChannelEndPoint.java:45)
          at
  org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java 
  :
  599)
          at org.eclipse.jetty.util.thread.QueuedThreadPool
  $3.run(QueuedThreadPool.java:534)
          at java.lang.Thread.run(Thread.java:722)

Re: Error on redirect when attempting unauthorized entry to Friend route

2013-01-15 Thread larry google groups

For anyone else who might make the same mistake I did, I changed this:

  (GET /admin request (friend/authorize #{::admin}  (admin
request)))

to this:

  (GET /admin request (friend/authorize #{::admin} {} (admin
request)))

adding an empty map before the string that is my actual HTML page.
That resolved the error in the stack trace.

However, my login still fails. I copy and paste both the username and
password, very carefully, into the login form, and hit submit, only to
get redirected to:

http://localhost:3/login?login_failed=Yusername=

I have not idea why this fails. I thought I had followed the
documentation carefully, but I suppose there is always something that
I miss.





On Jan 16, 1:30 am, larry google groups lawrencecloj...@gmail.com
wrote:
 Looking here:

 https://github.com/cemerick/friend/blob/master/src/cemerick/friend.clj

 I see in the stacktrace that the problem seems to be with the last
 line of this function:

 (defn default-unauthenticated-handler
   [request]
   (- request
     ::auth-config
     :login-uri
     (util/resolve-absolute-uri request)
     ring.util.response/redirect
     (assoc :session (:session request))
     (assoc-in [:session ::unauthorized-uri] (:uri request

 I guess I've turned the request into a string by this point? I can get
 to the unauthenticated routes in my app without a problem. They work
 great. It is only the authenticated routes that blow up.

 I am a bit confused about what is going on.

 On Jan 16, 1:26 am, larry google groups lawrencecloj...@gmail.com
 wrote:







  Reading here:

 https://github.com/cemerick/friend

  I see this:

  (Note that Friend itself requires some core Ring middlewares: params,
  keyword-params and nested-params.

  I did not have nested-params so I will add this.

  This might be a stupid question, but why doesn't Friend include the
  Ring middlewares that it depends on? Why do I have to manually hook
  these in when writing my app?

  On Jan 16, 1:00 am, larry google groups lawrencecloj...@gmail.com
  wrote:

   I have the following setting up an app where some pages will be
   protected by Friend.

   (defroutes app-routes
     (GET / request (index request))
     (GET /search-results request (search-results request))
     (GET /account request (friend/authorize #{::user} (account
   request)))
     (GET /admin request (friend/authorize #{::admin} (admin request)))
     (friend/logout (ANY /logout request (ring.util.response/redirect
   /)))
     (GET /login request (login request))
     (route/not-found Page not found))

   (def app
       (- app-routes
           (friend/authenticate {:credential-fn (partial creds/bcrypt-
   credential-fn (:users @interactions))
                                 :workflows [(workflows/interactive-
   form)]})
           (wrap-resource public)
           (wrap-session {:cookie-name discovery-session :cookie-attrs
   {:max-age 1 }})
           (wrap-cookies)
           (wrap-params)))

   (defn -main [ args]
     (let [port (Integer/parseInt (first args))]
       (try
         (run-jetty #'app {:port (or port 8080) :join? false})
         (catch Exception e (debug/print-error-info e)

    If I try to go to /admin without being logged in, I should get
   redirected to /login, but instead I get:

   java.lang.ClassCastException: java.lang.String cannot be cast to
   clojure.lang.Associative
           at clojure.lang.RT.assoc(RT.java:691)
           at clojure.core$assoc.invoke(core.clj:187)
           at clojure.core$assoc_in.invoke(core.clj:5459)
           at clojure.core$assoc_in.invoke(core.clj:5458)
           at cemerick.friend
   $default_unauthenticated_handler.invoke(friend.clj:164)
           at clojure.lang.Var.invoke(Var.java:415)
           at cemerick.friend$authenticate_STAR_.invoke(friend.clj:202)
           at cemerick.friend$authenticate$fn__1341.invoke(friend.clj:
   207)
           at ring.middleware.resource$wrap_resource
   $fn__2730.invoke(resource.clj:17)
           at ring.middleware.session$wrap_session
   $fn__2651.invoke(session.clj:43)
           at ring.middleware.cookies$wrap_cookies
   $fn__2588.invoke(cookies.clj:160)
           at ring.middleware.cookies$wrap_cookies
   $fn__2588.invoke(cookies.clj:160)
           at ring.middleware.params$wrap_params
   $fn__2400.invoke(params.clj:55)
           at clojure.lang.Var.invoke(Var.java:415)
           at ring.adapter.jetty$proxy_handler$fn__2809.invoke(jetty.clj:
   18)
           at ring.adapter.jetty.proxy
   $org.eclipse.jetty.server.handler.AbstractHandler$0.handle(Unknown
   Source)
           at
   org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:
   111)
           at org.eclipse.jetty.server.Server.handle(Server.java:349)
           at
   org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpC
onnection.java:
   452)
           at
   org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttp
Connection.java:

Re: Clojure web server benchmarks

2013-01-15 Thread Peter Taoussanis



 This is very interesting. Have you tried running the Ring Jetty adapter 
 with a larger thread pool? It's set lower than the default so as not to 
 overload cloud hosts like Heroku.


Okay, bumped the :max-threads from 50 to 100 without seeing much change to 
the results at these relatively low concurrency levels. May well make a 
difference at higher concurrency /or with better hardware (both on the 
cards for later).

Anecdotally, I've seen http-kit happily running dozens of thousands of 
concurrent connections in a high-load testing environment. Would like to 
see how far I can push it on a 16 logical core box.

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

Re: [ANN] tracer, trace your clojure function call stack

2013-01-15 Thread Alex Baranosky

Curious: how's this different from tools.trace?

On Tue, Jan 15, 2013 at 8:29 PM, James Xu xumingming64398...@gmail.comwrote:

 https://github.com/xumingming/tracer

 tracer

 trace clojure call stack.

 When I read some open source clojure source code, I find that some
 function/logic are so complex that it is not so easy to understand the
 whole logic, I think it will help me a lot if I can see the real function
 call stack with the provided paremeters, so I developed this simple tool to
 facilitate reading of clojure source code.
 https://github.com/xumingming/tracer#usageUsage

- Include tracer in your project.clj

 [tracer 1.0.0-SNAPSHOT]


- Go into your project home and start the repl:

 lein repl


- use the tracer.core namespace

 (use 'tracer.core)


- Tell tracer which namespace you want to trace:

 ;; CHANGE 'blind.reader TO YOUR OWN namespace(trace 'blind.reader)


- Invoke your function to see what happens( *you get a call tree 
with the parameter value!* ):

 user= (read-string \hello\)|--blind.reader$read-string (hello)
   |--blind.reader$string-push-back-reader (hello)
 |--blind.reader$string-push-back-reader (hello 1)
   |--blind.reader$string-reader (hello)
   |--blind.reader$read (#PushbackReader 
 blind.reader.PushbackReader@3eae3da8 true nil false)
 |--blind.reader$char ()|--blind.reader$whitespace? ()
 |--blind.reader$number-literal? (#PushbackReader 
 blind.reader.PushbackReader@3eae3da8 )  |--blind.reader$numeric? ()
 |--blind.reader$comment-prefix? ()|--blind.reader$macros ()
 |--blind.reader$read-string* (#PushbackReader 
 blind.reader.PushbackReader@3eae3da8 )  |--blind.reader$char (h)  
 |--blind.reader$char (e)  |--blind.reader$char (l)  
 |--blind.reader$char (l)  |--blind.reader$char (o)  
 |--blind.reader$char ()hello

 https://github.com/xumingming/tracer#license

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

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

Re: [ANN] tracer, trace your clojure function call stack

2013-01-15 Thread James Xu

Actually the same purpose, don't know there is such a tool before I wrote
itŠ |o|

From:  Alex Baranosky alexander.barano...@gmail.com
Reply-To:  clojure@googlegroups.com
Date:  Tue, 15 Jan 2013 22:58:42 -0800
To:  clojure@googlegroups.com
Subject:  Re: [ANN] tracer, trace your clojure function call stack

Curious: how's this different from tools.trace?

On Tue, Jan 15, 2013 at 8:29 PM, James Xu xumingming64398...@gmail.com
wrote:
 https://github.com/xumingming/tracer
 
 tracer
 trace clojure call stack.
 When I read some open source clojure source code, I find that some
 function/logic are so complex that it is not so easy to understand the whole
 logic, I think it will help me a lot if I can see the real function call stack
 with the provided paremeters, so I developed this simple tool to facilitate
 reading of clojure source code.
  https://github.com/xumingming/tracer#usage Usage
 * Include tracer in your project.clj
 [tracer 1.0.0-SNAPSHOT]
 * Go into your project home and start the repl:
 lein repl
 * use the tracer.core namespace
 (use 'tracer.core)
 * Tell tracer which namespace you want to trace:
 ;; CHANGE 'blind.reader TO YOUR OWN namespace(trace 'blind.reader)
 * Invoke your function to see what happens( you get a call tree  with the
 parameter value! ):
 user= (read-string \hello\)|--blind.reader$read-string (hello)
   |--blind.reader$string-push-back-reader (hello)
 |--blind.reader$string-push-back-reader (hello 1)
   |--blind.reader$string-reader (hello)
   |--blind.reader$read (#PushbackReader blind.reader.PushbackReader@3eae3da8
 true nil false)
 |--blind.reader$char ()|--blind.reader$whitespace? ()
 |--blind.reader$number-literal? (#PushbackReader
 blind.reader.PushbackReader@3eae3da8 )  |--blind.reader$numeric? ()
 |--blind.reader$comment-prefix? ()|--blind.reader$macros ()
 |--blind.reader$read-string* (#PushbackReader
 blind.reader.PushbackReader@3eae3da8 )  |--blind.reader$char (h)
 |--blind.reader$char (e)  |--blind.reader$char (l)
 |--blind.reader$char (l)  |--blind.reader$char (o)
 |--blind.reader$char ()hello
  https://github.com/xumingming/tracer#license
 -- 
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clojure@googlegroups.com
 Note that posts from new members are moderated - please be patient with your
 first post.
 To unsubscribe from this group, send email to
 clojure+unsubscr...@googlegroups.com
 mailto:clojure%2bunsubscr...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en


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

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

43 matches

Mail list logo