Re: [ANN] Nginx-Clojure v0.2.2 released

[Toni Helenius]

Out of interest, how do people use these multiprocess server thingies like 
nginx-clojure or vert.x with datomic?

On Saturday, May 31, 2014 7:57:54 PM UTC+3, Xfeep Zhang wrote:
>
> Nginx-Clojure is a Nginx  module for embedding Clojure 
> or Java programs, typically those Ring 
>  based handlers.
>
> Release 0.2.2 contains two updates
>
> 1. Fix bug of with Compojure 1.1.5 + Apache Solrj 4.3.0 + httpclient 4.3.2 
> NPE happens first time then everything is OK (issue #22)
> 2. Verifying option for auto generated waving configurations needed by 
> coroutine based socket (issue #23)
>
>
> The binary release can be found from 
> https://sourceforge.net/projects/nginx-clojure/files/
> The source files and guide can be found from 
> https://github.com/nginx-clojure/nginx-clojure/blob/master/README.md
> The index page for guide can be found from 
> https://github.com/nginx-clojure/nginx-clojure/wiki
>
> There are some core features of Nginx-Clojure:
>
>1. Compatible with Ring 
> and obviously 
>supports those Ring based frameworks, such as Compojure etc.
>2. Use Java/Clojure code to write a simple nginx rewrite handler to 
>set var before proxy pass
>3. Non-blocking coroutine based socket which is Compatible with Java 
>Socket API and works well with largely existing java library such as 
> apache 
>http client, mysql jdbc drivers. With this feature one java main thread 
> can 
>handle thousands of connections.
>4. Handle multiple sockets parallel in sub coroutines, e.g. we can 
>invoke two remote services at the same time feature
>5. Asynchronous callback API of socket for some advanced usage
>6. Run initialization clojure code when nginx worker starting
>7. Compatible with the Nginx lastest stable version 1.6.0. (Nginx 
>1.4.x is also ok, older version is not tested and maybe works.)
>8. One of benifits of Nginx  is worker processes 
>are automatically restarted by a master process if they crash
>9. Utilizes lazy headers and direct memory operation between Nginx 
> and JVM to fast handle dynamic contents from 
>Clojure or Java code.
>10. Utilizes Nginx  zero copy file sending 
>mechanism to fast handle static contents controlled by Clojure or Java 
> code.
>11. Supports Linux x64, Linux x86 32bit, Win32 and Mac OS X. Win64 
>users can also run it with a 32bit JRE/JDK.
>
>

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

protocol order

[Phillip Lord]

How does Clojure decide which Protocol implementation to call.

I ask because I have tried this code:


(defprotocol Fred
  (fred [item]))

(extend-type CharSequence
  Fred
  (fred [item] "charseq"))

(extend-type Comparable
  Fred
  (fred [item] "comparable"))

(extend-type java.io.Serializable
  Fred
  (fred [item] "serializable"))


(fred "hello")


With lein repl it seems to return charseq everytime. With CIDER it gives
different results. With lein repl on windows, again, different results
with different JVM invocations.

Should this not be consistent?

Phil

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

Re: protocol order

[Timothy Baldridge]

>From clojure.org/protocols : "

if one interface is derived from the other, the more derived is used, else
which one is used is unspecified."


Since multi-methods use "isa?" and not "=" perhaps use multi-methods and
specify order via "prefer-method"?

Timothy


On Mon, Jun 2, 2014 at 6:57 AM, Phillip Lord 
wrote:

>
>
> How does Clojure decide which Protocol implementation to call.
>
> I ask because I have tried this code:
>
>
> (defprotocol Fred
>   (fred [item]))
>
> (extend-type CharSequence
>   Fred
>   (fred [item] "charseq"))
>
> (extend-type Comparable
>   Fred
>   (fred [item] "comparable"))
>
> (extend-type java.io.Serializable
>   Fred
>   (fred [item] "serializable"))
>
>
> (fred "hello")
>
>
> With lein repl it seems to return charseq everytime. With CIDER it gives
> different results. With lein repl on windows, again, different results
> with different JVM invocations.
>
> Should this not be consistent?
>
> Phil
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
“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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ANN] Clojure cheatsheet with search capability

[John Gabriele]

On Sunday, June 1, 2014 5:15:52 PM UTC-4, Andy Fingerhut wrote:
>
> Thanks to Francois du Toit, the versions of the Clojure cheatsheet 
> available at the link below now have the ability to let you search for all 
> symbols beginning with a string you type in, with color highlighting of 
> matches.
>
> http://jafingerhut.github.io
>
>
Oooh, that's nifty. Removes blocks with no results too. And I see that it 
actually searches for string anywhere in the function name (not just at the 
beginning). Thanks Francois and Andy!

One minor thing: if a search string doesn't turn up any results at all, it 
would be nice if it turned red in the search field to indicate so.

-- John

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

Re: [ANN] Clojure cheatsheet with search capability

[Andy Fingerhut]

I'm open to a change like that.  If anyone has a code change that would
implement that, please let me know.

Andy


On Mon, Jun 2, 2014 at 6:54 AM, John Gabriele  wrote:

> On Sunday, June 1, 2014 5:15:52 PM UTC-4, Andy Fingerhut wrote:
>>
>> Thanks to Francois du Toit, the versions of the Clojure cheatsheet
>> available at the link below now have the ability to let you search for all
>> symbols beginning with a string you type in, with color highlighting of
>> matches.
>>
>> http://jafingerhut.github.io
>>
>>
> Oooh, that's nifty. Removes blocks with no results too. And I see that it
> actually searches for string anywhere in the function name (not just at the
> beginning). Thanks Francois and Andy!
>
> One minor thing: if a search string doesn't turn up any results at all, it
> would be nice if it turned red in the search field to indicate so.
>
> -- John
>
>  --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: protocol order

[Phillip Lord]

Timothy Baldridge  writes:

>>From clojure.org/protocols : "
>
> if one interface is derived from the other, the more derived is used, else
> which one is used is unspecified."

Oh dear, that's not so hot. I guess it's the first that gets tested, and
that this is undefined.


> Since multi-methods use "isa?" and not "=" perhaps use multi-methods and
> specify order via "prefer-method"?

I used simple multi-methods (with a "class" based dispatch function).
But then, my tests suite moved from taking 30seconds to taking 5minutes,
when a downstream API introduced some new interfaces (with no other
functional changes AFAICT). I am still using multimethods but in a
way which subverts the (unreplaceable) isa? call, and my tests suite is
taking 15 seconds.

I was investigating protocols as an alternative.

Phil

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

Re: help with the lawyers?

[gla]

Tempest in a teapot.  

The Federal Government is rarely held to state laws under diversity under 
the Erie Doctrine.  The probability of the Fed being held to NYS law is 
minimal to nil.
 
Second the Arbitration clause is permitted under the Administrative Dispute 
Resolution Act.  Under that act every Federal Govt entity was required to 
adopt a policy for ADR.  


On Thursday, May 29, 2014 11:31:36 PM UTC-4, rcg wrote:
>
> Hello;
>
> Developing web site for government using Clojure on back end- lawyers 
> reviewing EPL had objections. Would appreciate any advice on how to deal 
> with them.
>
> Again- web site, not distributing or modifying Clojure. I have no 
> expertise with Open Source Licenses or lawyer-ese jargon.
>
> These are the specific objections- do they even apply in the context of 
> web services?
>
> 1. "This Agreement is governed by the laws of the State of New York". Not 
> acceptable: The federal government cannot agree to be bound by state law.
>
> 2. "Each party waives its rights to a jury trial in any 
> resulting litigation". Not acceptable: Only DOJ can control litigation.
>
>
> THANKS!!
>

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

Re: REPL using Emacs Cider

[Erlis Vidal]

Hi Timur,

I've seen weird errors when not using lein2. What version of lein are you
using?


On Sun, Jun 1, 2014 at 11:52 AM, Timur  wrote:

> hi everyone, I have a question about using nREPL (cider) in Emacs.
>
> In my clojurescript project, I start the repl server using cider-jack-in
> command. However, whenever I try to execute a function from the clojure
> file, a CompilerException is thrown with the message unable to resolve
> symbol... What could be the problem? Does cider load all dependencies
> automatically?
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Top-down code in namspaces

[Sean Corfield]

On Jun 1, 2014, at 11:53 PM, u1204  wrote:
> Instead of calling load to read the file, call your tangle function.

Whilst that might work from the REPL, it's not going to work with normal 
Clojure tooling and it would mean you couldn't just :require files written that 
way in the file's ns either.

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

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





signature.asc
Description: Message signed with OpenPGP using GPGMail

Code Mesh London 4-5 Nov - VEB opens

[Andra Dinu]

Hi all,

For the third year in a row, Code Mesh London will be the best place in 
Europe to meet over 50 inventors and commercial users of innovative tech 
and non-mainstream languages. Among the first speakers on the website: 
Data-Centric Functional Programmer and O'Reilly Author Dean Whampler, 
Author of '7 Languages in 7 Weeks' Bruce Tate, Creator of the Catnip IDE 
Bodil Stokke, Developer Advocate for Google+ Ian Barber, Scala Hacker 
Jessica Kerr.  

http://www.codemesh.io

Due to a large number of requests, this year we're opening the Very Early 
Bird on Thursday, 5 June. Offer closes on 28 June!

Best, 
Andra

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

Re: What's clojure killer app? I don't see any.

[douglas smith]

I would like to revisit this thread on 'killer-apps' for clojure. Hope you 
don't mind.

For quite some time I have been trying  to teach myself to code. -even 
before clojure was 'born'. (slow learner?...   probably)

I have read many books and spent many hours 'dinking' as my wife says.  I 
find it very very interesting and fun.
 
MOOC's  and in particular Udacity.com  have wet my appetite for learning 
again.  

I am taking several courses and enjoying the interactive  format.  I am 
even doing some screen-casting of the homework.  

I enjoy following your community and have learned a lot.

I have installed emacs, light table, cider,org-mode, session, om -you name 
and enjoy going the different tutorials.

I am really finding the simplicity of 'code as data' and 'immutability' to 
be very helpful.

Anyway   I may need to switch to decaf!   NAAh

Here it is:

A killer app for me and I think MANY others like me would be something very 
similar to a Kovas' 'Session' 'pretty like Light Table'  and beefy like 
IPythons Notebooks. 

I see a great opportunity for clojure to provide a pathway to learning to 
program the 'right way' from the start.  It seems you have all come to 
clojure after realizing that yourself.

I can't help but think many of the current students just starting out are 
going down the same path many of you did.

Lets teach people eager to learn using the best 'hand-tools' available. 
i told you i have been watching...
 
Anyway thanks for sharing all the cool stuff you folks do.

I would love to help any way I could 

Doug









On Saturday, April 19, 2014 12:15:38 PM UTC-4, Paulo Suzart wrote:
>
> Hi all, (warning, this is kinda confusing email) 
>
> Been following the list for some time and specially paying attention to 
> what could be the killer clojure app as Akka is for Scala. 
>
> I keep seeing small libs (I like libs) popping up like ants, but I don't 
> believe none of them (alone at least)  can make clojure explode and become 
> main technology in a old school /ordinary company.
>
> People say clojure is good for data. But where are the cases? And more 
> specifically, where are the frameworks and libs to support it? Are they 
> talking about wrappers around java for Hadoop? Sigh... 
>
> Pulsar is quite dead, core async isn't clear regarding remoting, and 
> avout? And lamina? And aleph? Where are the tools that can make clojure to 
> cover from Web to big data and batch? 
>
> Luminous,  caribou, etc, are they going to become the next grails? Huumm.. 
> Will take lot of time. Clojure Script alone will not go any further than 
> the current server side. 
>
> What made me give up scala was Scalaz, and I hope the "create thousand 
> disconnected libs and publish a post with ANN sufix" approach doesn't make 
> me give up clojure. 
>
> Sorry guys, I've been posting about Clojure since 2009, and still can't 
> see it becoming the main technology even being the CTO of the company. 
>
> What is the killer app for you? Or how do you think we can make clojure 
> supporting apps like Facebook or something big like 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
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

stack backtraces for exceptions in agents?

[Lee Spector]

In my single-threaded code, exceptions stop execution and print a stack 
backtrace. This is less informative than I would like [1], but sometimes it 
provides crucial clues.

My multi-threaded code generally uses agents (just because that's the best way 
I've found to get something that behaves like pmap but with better multicore 
processor utilization [2]). By default, exceptions in agents are silent, which 
is a default that I've always found to be perplexing. But if I pass an 
:error-handler argument to agent (as in [2] below) then I can at least see the 
exception... but execution doesn't halt and I don't get a backtrace. That means 
that if I'm running in a multi-core mode (as I usually am) then the first 
unfortunate thing is that I have to notice the printed exception (because 
execution continues past it if I don't). But the even more unfortunate thing is 
that I then get no backtrace. In order to get a backtrace I have to re-run my 
whole system in single-threaded mode, and then hope that I hit the same error 
(since my systems almost always involve a lot of randomness).

I figure it would be easy to put an exit in the :error-handler that would quit 
the whole program, but I don't know how I could get the stack backtrace for the 
triggering exception.

Does anyone know how to get this?

Thanks,

 -Lee 


[1] Oh, how I long to see the values of locals up the stack in these 
backtraces. I understand there are ways to get this but that they require 
particular tool chains (emacs w/ritz?); my longing is for this kind of 
functionality no matter how I launch my code, or at least when I launch it via 
"lein run". The lack of this feature is the #1 thing I miss in Clojure relative 
to Common Lisp.

[2] Specifically, pmap won't keep all cores busy if a thread that starts later 
finishes earlier than one that starts earlier. Here's the code that I use 
instead of pmap, which assumes there's a boolean-valued var called 
single-thread-mode:
(defn pmapall
  "Like pmap but: 1) coll should be finite, 2) the returned sequence
   will not be lazy, 3) calls to f may occur in any order, to maximize
   multicore processor utilization, and 4) takes only one coll so far."
  [f coll]
  (if single-thread-mode
(doall (map f coll))
(let [agents (map #(agent % :error-handler (fn [agnt except] (println 
except))) coll)]
  (dorun (map #(send % f) agents))
  (apply await agents)
  (doall (map deref agents)

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

Re: stack backtraces for exceptions in agents?

[Sean Corfield]

The exception object should have a full stack trace in it - how are you 
printing your exceptions?

Sean

On Jun 2, 2014, at 12:28 PM, Lee Spector  wrote:
> In my single-threaded code, exceptions stop execution and print a stack 
> backtrace. This is less informative than I would like [1], but sometimes it 
> provides crucial clues.
> 
> My multi-threaded code generally uses agents (just because that's the best 
> way I've found to get something that behaves like pmap but with better 
> multicore processor utilization [2]). By default, exceptions in agents are 
> silent, which is a default that I've always found to be perplexing. But if I 
> pass an :error-handler argument to agent (as in [2] below) then I can at 
> least see the exception... but execution doesn't halt and I don't get a 
> backtrace. That means that if I'm running in a multi-core mode (as I usually 
> am) then the first unfortunate thing is that I have to notice the printed 
> exception (because execution continues past it if I don't). But the even more 
> unfortunate thing is that I then get no backtrace. In order to get a 
> backtrace I have to re-run my whole system in single-threaded mode, and then 
> hope that I hit the same error (since my systems almost always involve a lot 
> of randomness).
> 
> I figure it would be easy to put an exit in the :error-handler that would 
> quit the whole program, but I don't know how I could get the stack backtrace 
> for the triggering exception.
> 
> Does anyone know how to get this?
> 
> Thanks,
> 
> -Lee 
> 
> 
> [1] Oh, how I long to see the values of locals up the stack in these 
> backtraces. I understand there are ways to get this but that they require 
> particular tool chains (emacs w/ritz?); my longing is for this kind of 
> functionality no matter how I launch my code, or at least when I launch it 
> via "lein run". The lack of this feature is the #1 thing I miss in Clojure 
> relative to Common Lisp.
> 
> [2] Specifically, pmap won't keep all cores busy if a thread that starts 
> later finishes earlier than one that starts earlier. Here's the code that I 
> use instead of pmap, which assumes there's a boolean-valued var called 
> single-thread-mode:
> (defn pmapall
>  "Like pmap but: 1) coll should be finite, 2) the returned sequence
>   will not be lazy, 3) calls to f may occur in any order, to maximize
>   multicore processor utilization, and 4) takes only one coll so far."
>  [f coll]
>  (if single-thread-mode
>(doall (map f coll))
>(let [agents (map #(agent % :error-handler (fn [agnt except] (println 
> except))) coll)]
>  (dorun (map #(send % f) agents))
>  (apply await agents)
>  (doall (map deref agents)



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: stack backtraces for exceptions in agents?

[Lee Spector]

(fn [agnt except] (println except))

 -Lee


On Jun 2, 2014, at 3:38 PM, Sean Corfield  wrote:

> The exception object should have a full stack trace in it - how are you 
> printing your exceptions?
> 
> Sean
> 
> On Jun 2, 2014, at 12:28 PM, Lee Spector  wrote:
>> In my single-threaded code, exceptions stop execution and print a stack 
>> backtrace. This is less informative than I would like [1], but sometimes it 
>> provides crucial clues.
>> 
>> My multi-threaded code generally uses agents (just because that's the best 
>> way I've found to get something that behaves like pmap but with better 
>> multicore processor utilization [2]). By default, exceptions in agents are 
>> silent, which is a default that I've always found to be perplexing. But if I 
>> pass an :error-handler argument to agent (as in [2] below) then I can at 
>> least see the exception... but execution doesn't halt and I don't get a 
>> backtrace. That means that if I'm running in a multi-core mode (as I usually 
>> am) then the first unfortunate thing is that I have to notice the printed 
>> exception (because execution continues past it if I don't). But the even 
>> more unfortunate thing is that I then get no backtrace. In order to get a 
>> backtrace I have to re-run my whole system in single-threaded mode, and then 
>> hope that I hit the same error (since my systems almost always involve a lot 
>> of randomness).
>> 
>> I figure it would be easy to put an exit in the :error-handler that would 
>> quit the whole program, but I don't know how I could get the stack backtrace 
>> for the triggering exception.
>> 
>> Does anyone know how to get this?
>> 
>> Thanks,
>> 
>> -Lee 
>> 
>> 
>> [1] Oh, how I long to see the values of locals up the stack in these 
>> backtraces. I understand there are ways to get this but that they require 
>> particular tool chains (emacs w/ritz?); my longing is for this kind of 
>> functionality no matter how I launch my code, or at least when I launch it 
>> via "lein run". The lack of this feature is the #1 thing I miss in Clojure 
>> relative to Common Lisp.
>> 
>> [2] Specifically, pmap won't keep all cores busy if a thread that starts 
>> later finishes earlier than one that starts earlier. Here's the code that I 
>> use instead of pmap, which assumes there's a boolean-valued var called 
>> single-thread-mode:
>> (defn pmapall
>> "Like pmap but: 1) coll should be finite, 2) the returned sequence
>>  will not be lazy, 3) calls to f may occur in any order, to maximize
>>  multicore processor utilization, and 4) takes only one coll so far."
>> [f coll]
>> (if single-thread-mode
>>   (doall (map f coll))
>>   (let [agents (map #(agent % :error-handler (fn [agnt except] (println 
>> except))) coll)]
>> (dorun (map #(send % f) agents))
>> (apply await agents)
>> (doall (map deref agents)
> 

--
Lee Spector, Professor of Computer Science
Cognitive Science, Hampshire College
893 West Street, Amherst, MA 01002-3359
lspec...@hampshire.edu, http://hampshire.edu/lspector/
Phone: 413-559-5352, Fax: 413-559-5438

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

Re: stack backtraces for exceptions in agents?

[Andy Fingerhut]

Try out (clojure.repl/pst e 1000), where e is the exception you have caught.

Andy


On Mon, Jun 2, 2014 at 12:28 PM, Lee Spector  wrote:

>
> In my single-threaded code, exceptions stop execution and print a stack
> backtrace. This is less informative than I would like [1], but sometimes it
> provides crucial clues.
>
> My multi-threaded code generally uses agents (just because that's the best
> way I've found to get something that behaves like pmap but with better
> multicore processor utilization [2]). By default, exceptions in agents are
> silent, which is a default that I've always found to be perplexing. But if
> I pass an :error-handler argument to agent (as in [2] below) then I can at
> least see the exception... but execution doesn't halt and I don't get a
> backtrace. That means that if I'm running in a multi-core mode (as I
> usually am) then the first unfortunate thing is that I have to notice the
> printed exception (because execution continues past it if I don't). But the
> even more unfortunate thing is that I then get no backtrace. In order to
> get a backtrace I have to re-run my whole system in single-threaded mode,
> and then hope that I hit the same error (since my systems almost always
> involve a lot of randomness).
>
> I figure it would be easy to put an exit in the :error-handler that would
> quit the whole program, but I don't know how I could get the stack
> backtrace for the triggering exception.
>
> Does anyone know how to get this?
>
> Thanks,
>
>  -Lee
>
>
> [1] Oh, how I long to see the values of locals up the stack in these
> backtraces. I understand there are ways to get this but that they require
> particular tool chains (emacs w/ritz?); my longing is for this kind of
> functionality no matter how I launch my code, or at least when I launch it
> via "lein run". The lack of this feature is the #1 thing I miss in Clojure
> relative to Common Lisp.
>
> [2] Specifically, pmap won't keep all cores busy if a thread that starts
> later finishes earlier than one that starts earlier. Here's the code that I
> use instead of pmap, which assumes there's a boolean-valued var called
> single-thread-mode:
> (defn pmapall
>   "Like pmap but: 1) coll should be finite, 2) the returned sequence
>will not be lazy, 3) calls to f may occur in any order, to maximize
>multicore processor utilization, and 4) takes only one coll so far."
>   [f coll]
>   (if single-thread-mode
> (doall (map f coll))
> (let [agents (map #(agent % :error-handler (fn [agnt except] (println
> except))) coll)]
>   (dorun (map #(send % f) agents))
>   (apply await agents)
>   (doall (map deref agents)
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: stack backtraces for exceptions in agents?

[Lee Spector]

Beautiful.

In fact, if I specify an :error-handler of:

(fn [agnt except] (clojure.repl/pst except 1000) (System/exit 0))

Then it prints the backtrace and also terminates execution.

FWIW that would seem to me to be a better default than the current "fail 
silently."

 -Lee


On Jun 2, 2014, at 3:39 PM, Andy Fingerhut  wrote:

> Try out (clojure.repl/pst e 1000), where e is the exception you have caught.
> 
> Andy
> 
> 
> On Mon, Jun 2, 2014 at 12:28 PM, Lee Spector  wrote:
> 
> In my single-threaded code, exceptions stop execution and print a stack 
> backtrace. This is less informative than I would like [1], but sometimes it 
> provides crucial clues.
> 
> My multi-threaded code generally uses agents (just because that's the best 
> way I've found to get something that behaves like pmap but with better 
> multicore processor utilization [2]). By default, exceptions in agents are 
> silent, which is a default that I've always found to be perplexing. But if I 
> pass an :error-handler argument to agent (as in [2] below) then I can at 
> least see the exception... but execution doesn't halt and I don't get a 
> backtrace. That means that if I'm running in a multi-core mode (as I usually 
> am) then the first unfortunate thing is that I have to notice the printed 
> exception (because execution continues past it if I don't). But the even more 
> unfortunate thing is that I then get no backtrace. In order to get a 
> backtrace I have to re-run my whole system in single-threaded mode, and then 
> hope that I hit the same error (since my systems almost always involve a lot 
> of randomness).
> 
> I figure it would be easy to put an exit in the :error-handler that would 
> quit the whole program, but I don't know how I could get the stack backtrace 
> for the triggering exception.
> 
> Does anyone know how to get this?
> 
> Thanks,
> 
>  -Lee
> 
> 
> [1] Oh, how I long to see the values of locals up the stack in these 
> backtraces. I understand there are ways to get this but that they require 
> particular tool chains (emacs w/ritz?); my longing is for this kind of 
> functionality no matter how I launch my code, or at least when I launch it 
> via "lein run". The lack of this feature is the #1 thing I miss in Clojure 
> relative to Common Lisp.
> 
> [2] Specifically, pmap won't keep all cores busy if a thread that starts 
> later finishes earlier than one that starts earlier. Here's the code that I 
> use instead of pmap, which assumes there's a boolean-valued var called 
> single-thread-mode:
> (defn pmapall
>   "Like pmap but: 1) coll should be finite, 2) the returned sequence
>will not be lazy, 3) calls to f may occur in any order, to maximize
>multicore processor utilization, and 4) takes only one coll so far."
>   [f coll]
>   (if single-thread-mode
> (doall (map f coll))
> (let [agents (map #(agent % :error-handler (fn [agnt except] (println 
> except))) coll)]
>   (dorun (map #(send % f) agents))
>   (apply await agents)
>   (doall (map deref agents)
> 

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

Re: stack backtraces for exceptions in agents?

[Lee Spector]

PS I should have said "thanks!".

 -Lee

On Jun 2, 2014, at 3:52 PM, Lee Spector  wrote:

> 
> Beautiful.
> 
> In fact, if I specify an :error-handler of:
> 
> (fn [agnt except] (clojure.repl/pst except 1000) (System/exit 0))
> 
> Then it prints the backtrace and also terminates execution.
> 
> FWIW that would seem to me to be a better default than the current "fail 
> silently."
> 
> -Lee
> 

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

non-lazy clojure?

[Lee Spector]

I've generally liked Clojure's pervasive laziness. It's cute and it sometimes 
permits lovely, elegant approaches to particular programming problems. And 
although I've long known that it can get you into trouble in a few unusual 
cases -- I think I recall seeing a nice blog post on issues related to 
"binding" and laziness by Chas Emerick several years ago -- it has generally 
seemed safe enough for most purposes. I figured that while it may not always 
provide benefits it should at least be mostly harmless.

However, after spending a couple of days tracking down a particularly confusing 
bug, and finding once again (this has happened to me at least a few times) that 
the bug was due to laziness that I never really wanted in the first place, I'm 
reconsidering.

I don't have a pared-down version of the bug that I was just dealing with (see 
below for a pointer to the non-pared-down version), but it goes away when I 
wring out all of the laziness. In this particular case I do so by calling vec 
or doall on the results of all of my calls to map and other functions function 
that produce lazy sequences (none of which I actually want to be lazy in this 
application). I was getting StackOverflowErrors and I have a half-baked 
half-theory that it was due to some bad interaction between laziness and 
garbage collection, with the JVM not realizing that it could reclaim lazy 
things that weren't yet fully evaluated. That doesn't make complete sense to 
me, and maybe that kind of bad interaction is not even possible -- I don't 
know. But I do know that all is well when I wring out all of the laziness.

One possible lesson from this experience (which was particularly frustrating, 
BTW, because the stack backtraces were particularly uninformative [1]) is that 
I should just be careful to surround any call to any function that produces a 
lazy sequence with something like vec that ensures that the laziness will be 
eliminated as soon as it is created -- except in those relatively rare cases 
where I really want the laziness. But this would be a pain, and ugly. I rely 
heavily on Clojure's sequence processing functions and I would hate to clutter 
up every call to every one of them or to have to reimplement my own non-lazy 
versions of everything.

Is there a more elegant way? Maybe somebody has already made non-lazy clones of 
all of the core functions that normally produce lazy sequences? And if so, 
maybe there's some clean way to cause my code to use the non-lazy versions 
unless specifically directed to use the lazy versions?

I realize that this is fighting with a core feature of Clojure, and that the 
idea will probably rub lots of folks the wrong way. But I've now been down this 
road a couple of times and I'm beginning to think that I'd spend less time 
tracking down mysterious bugs if I could avoid laziness more easily.

In case anybody is motivated to look into the specific bug that I was just 
dealing with, I've put the project at 
http://hampshire.edu/lspector/temp/world2D.zip. If you do "lein run" in its 
present state it will run fine, making little balls bounce around. (This is a 
very early version of some code that I plan to use both for teaching an AI 
class and for some ALife experiments...) But if you edit src/world2D/vec2D.clj, 
commenting out the definitions of *v, +v, and -v, and uncommenting the 
alternatives (which are the same except that they lack the calls to vec) then 
after running for a few seconds or a minute or so you'll get the stack overflow.

Thanks for any suggestions,

 -Lee


[1] The stack traces I was getting provide no information about where/what the 
offending lazy sequences are, since they don't show locals etc. I see no 
references to any of my own code, just a repeating sequence that starts:

StackOverflowError 
clojure.core/seq (core.clj:133)
clojure.core/map/fn--4211 (core.clj:2490)
clojure.lang.LazySeq.sval (LazySeq.java:42)
clojure.lang.LazySeq.seq (LazySeq.java:60)
clojure.lang.RT.seq (RT.java:484)
clojure.core/seq (core.clj:133)
clojure.core/map/fn--4211 (core.clj:2490)
clojure.lang.LazySeq.sval (LazySeq.java:42)
clojure.lang.LazySeq.seq (LazySeq.java:60)
clojure.lang.RT.seq (RT.java:484)
[etc]

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

Re: non-lazy clojure?

[Softaddicts]

mapv

a bit shorter :)

Luc P.

> 
> I've generally liked Clojure's pervasive laziness. It's cute and it sometimes 
> permits lovely, elegant approaches to particular programming problems. And 
> although I've long known that it can get you into trouble in a few unusual 
> cases -- I think I recall seeing a nice blog post on issues related to 
> "binding" and laziness by Chas Emerick several years ago -- it has generally 
> seemed safe enough for most purposes. I figured that while it may not always 
> provide benefits it should at least be mostly harmless.
> 
> However, after spending a couple of days tracking down a particularly 
> confusing bug, and finding once again (this has happened to me at least a few 
> times) that the bug was due to laziness that I never really wanted in the 
> first place, I'm reconsidering.
> 
> I don't have a pared-down version of the bug that I was just dealing with 
> (see below for a pointer to the non-pared-down version), but it goes away 
> when I wring out all of the laziness. In this particular case I do so by 
> calling vec or doall on the results of all of my calls to map and other 
> functions function that produce lazy sequences (none of which I actually want 
> to be lazy in this application). I was getting StackOverflowErrors and I have 
> a half-baked half-theory that it was due to some bad interaction between 
> laziness and garbage collection, with the JVM not realizing that it could 
> reclaim lazy things that weren't yet fully evaluated. That doesn't make 
> complete sense to me, and maybe that kind of bad interaction is not even 
> possible -- I don't know. But I do know that all is well when I wring out all 
> of the laziness.
> 
> One possible lesson from this experience (which was particularly frustrating, 
> BTW, because the stack backtraces were particularly uninformative [1]) is 
> that I should just be careful to surround any call to any function that 
> produces a lazy sequence with something like vec that ensures that the 
> laziness will be eliminated as soon as it is created -- except in those 
> relatively rare cases where I really want the laziness. But this would be a 
> pain, and ugly. I rely heavily on Clojure's sequence processing functions and 
> I would hate to clutter up every call to every one of them or to have to 
> reimplement my own non-lazy versions of everything.
> 
> Is there a more elegant way? Maybe somebody has already made non-lazy clones 
> of all of the core functions that normally produce lazy sequences? And if so, 
> maybe there's some clean way to cause my code to use the non-lazy versions 
> unless specifically directed to use the lazy versions?
> 
> I realize that this is fighting with a core feature of Clojure, and that the 
> idea will probably rub lots of folks the wrong way. But I've now been down 
> this road a couple of times and I'm beginning to think that I'd spend less 
> time tracking down mysterious bugs if I could avoid laziness more easily.
> 
> In case anybody is motivated to look into the specific bug that I was just 
> dealing with, I've put the project at 
> http://hampshire.edu/lspector/temp/world2D.zip. If you do "lein run" in its 
> present state it will run fine, making little balls bounce around. (This is a 
> very early version of some code that I plan to use both for teaching an AI 
> class and for some ALife experiments...) But if you edit 
> src/world2D/vec2D.clj, commenting out the definitions of *v, +v, and -v, and 
> uncommenting the alternatives (which are the same except that they lack the 
> calls to vec) then after running for a few seconds or a minute or so you'll 
> get the stack overflow.
> 
> Thanks for any suggestions,
> 
>  -Lee
> 
> 
> [1] The stack traces I was getting provide no information about where/what 
> the offending lazy sequences are, since they don't show locals etc. I see no 
> references to any of my own code, just a repeating sequence that starts:
> 
> StackOverflowError 
>   clojure.core/seq (core.clj:133)
>   clojure.core/map/fn--4211 (core.clj:2490)
>   clojure.lang.LazySeq.sval (LazySeq.java:42)
>   clojure.lang.LazySeq.seq (LazySeq.java:60)
>   clojure.lang.RT.seq (RT.java:484)
>   clojure.core/seq (core.clj:133)
>   clojure.core/map/fn--4211 (core.clj:2490)
>   clojure.lang.LazySeq.sval (LazySeq.java:42)
>   clojure.lang.LazySeq.seq (LazySeq.java:60)
>   clojure.lang.RT.seq (RT.java:484)
> [etc]
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from 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" gr

RE: non-lazy clojure?

[Phillip Lord]

Funny, I posted an article of my Clojure gotcha's today 
(http://www.russet.org.uk/blog/2991), and this is one of them. I've also had 
very nasty bugs, in addition to the general hassle of wrapping a Java API which 
works through side-effects.

I created a few functions covering the most common ones (domap, dofor and so 
on); having a comprehensive list somewhere in it's own namespace would be quite 
useful.

Phil

From: clojure@googlegroups.com [clojure@googlegroups.com] on behalf of Lee 
Spector [lspec...@hampshire.edu]
Sent: 02 June 2014 21:32
To: clojure@googlegroups.com
Subject: non-lazy clojure?

I've generally liked Clojure's pervasive laziness. It's cute and it sometimes 
permits lovely, elegant approaches to particular programming problems. And 
although I've long known that it can get you into trouble in a few unusual 
cases -- I think I recall seeing a nice blog post on issues related to 
"binding" and laziness by Chas Emerick several years ago -- it has generally 
seemed safe enough for most purposes. I figured that while it may not always 
provide benefits it should at least be mostly harmless.

However, after spending a couple of days tracking down a particularly confusing 
bug, and finding once again (this has happened to me at least a few times) that 
the bug was due to laziness that I never really wanted in the first place, I'm 
reconsidering.

I don't have a pared-down version of the bug that I was just dealing with (see 
below for a pointer to the non-pared-down version), but it goes away when I 
wring out all of the laziness. In this particular case I do so by calling vec 
or doall on the results of all of my calls to map and other functions function 
that produce lazy sequences (none of which I actually want to be lazy in this 
application). I was getting StackOverflowErrors and I have a half-baked 
half-theory that it was due to some bad interaction between laziness and 
garbage collection, with the JVM not realizing that it could reclaim lazy 
things that weren't yet fully evaluated. That doesn't make complete sense to 
me, and maybe that kind of bad interaction is not even possible -- I don't 
know. But I do know that all is well when I wring out all of the laziness.

One possible lesson from this experience (which was particularly frustrating, 
BTW, because the stack backtraces were particularly uninformative [1]) is that 
I should just be careful to surround any call to any function that produces a 
lazy sequence with something like vec that ensures that the laziness will be 
eliminated as soon as it is created -- except in those relatively rare cases 
where I really want the laziness. But this would be a pain, and ugly. I rely 
heavily on Clojure's sequence processing functions and I would hate to clutter 
up every call to every one of them or to have to reimplement my own non-lazy 
versions of everything.

Is there a more elegant way? Maybe somebody has already made non-lazy clones of 
all of the core functions that normally produce lazy sequences? And if so, 
maybe there's some clean way to cause my code to use the non-lazy versions 
unless specifically directed to use the lazy versions?

I realize that this is fighting with a core feature of Clojure, and that the 
idea will probably rub lots of folks the wrong way. But I've now been down this 
road a couple of times and I'm beginning to think that I'd spend less time 
tracking down mysterious bugs if I could avoid laziness more easily.

In case anybody is motivated to look into the specific bug that I was just 
dealing with, I've put the project at 
http://hampshire.edu/lspector/temp/world2D.zip. If you do "lein run" in its 
present state it will run fine, making little balls bounce around. (This is a 
very early version of some code that I plan to use both for teaching an AI 
class and for some ALife experiments...) But if you edit src/world2D/vec2D.clj, 
commenting out the definitions of *v, +v, and -v, and uncommenting the 
alternatives (which are the same except that they lack the calls to vec) then 
after running for a few seconds or a minute or so you'll get the stack overflow.

Thanks for any suggestions,

 -Lee


[1] The stack traces I was getting provide no information about where/what the 
offending lazy sequences are, since they don't show locals etc. I see no 
references to any of my own code, just a repeating sequence that starts:

StackOverflowError
clojure.core/seq (core.clj:133)
clojure.core/map/fn--4211 (core.clj:2490)
clojure.lang.LazySeq.sval (LazySeq.java:42)
clojure.lang.LazySeq.seq (LazySeq.java:60)
clojure.lang.RT.seq (RT.java:484)
clojure.core/seq (core.clj:133)
clojure.core/map/fn--4211 (core.clj:2490)
clojure.lang.LazySeq.sval (LazySeq.java:42)
clojure.lang.LazySeq.seq (LazySeq.java:60)
clojure.lang.RT.seq (RT.java:484)
[etc]

--
You received this message because you are subscribed t

Re: non-lazy clojure?

[Jozef Wagner]

Reducers [1] provide eager variants of some core seq functions (map,
filter, etc.). Note that they do not cache the result, so they recompute it
every time you use their result.

[1] http://clojure.org/reducers


On Mon, Jun 2, 2014 at 10:32 PM, Lee Spector  wrote:

>
> I've generally liked Clojure's pervasive laziness. It's cute and it
> sometimes permits lovely, elegant approaches to particular programming
> problems. And although I've long known that it can get you into trouble in
> a few unusual cases -- I think I recall seeing a nice blog post on issues
> related to "binding" and laziness by Chas Emerick several years ago -- it
> has generally seemed safe enough for most purposes. I figured that while it
> may not always provide benefits it should at least be mostly harmless.
>
> However, after spending a couple of days tracking down a particularly
> confusing bug, and finding once again (this has happened to me at least a
> few times) that the bug was due to laziness that I never really wanted in
> the first place, I'm reconsidering.
>
> I don't have a pared-down version of the bug that I was just dealing with
> (see below for a pointer to the non-pared-down version), but it goes away
> when I wring out all of the laziness. In this particular case I do so by
> calling vec or doall on the results of all of my calls to map and other
> functions function that produce lazy sequences (none of which I actually
> want to be lazy in this application). I was getting StackOverflowErrors and
> I have a half-baked half-theory that it was due to some bad interaction
> between laziness and garbage collection, with the JVM not realizing that it
> could reclaim lazy things that weren't yet fully evaluated. That doesn't
> make complete sense to me, and maybe that kind of bad interaction is not
> even possible -- I don't know. But I do know that all is well when I wring
> out all of the laziness.
>
> One possible lesson from this experience (which was particularly
> frustrating, BTW, because the stack backtraces were particularly
> uninformative [1]) is that I should just be careful to surround any call to
> any function that produces a lazy sequence with something like vec that
> ensures that the laziness will be eliminated as soon as it is created --
> except in those relatively rare cases where I really want the laziness. But
> this would be a pain, and ugly. I rely heavily on Clojure's sequence
> processing functions and I would hate to clutter up every call to every one
> of them or to have to reimplement my own non-lazy versions of everything.
>
> Is there a more elegant way? Maybe somebody has already made non-lazy
> clones of all of the core functions that normally produce lazy sequences?
> And if so, maybe there's some clean way to cause my code to use the
> non-lazy versions unless specifically directed to use the lazy versions?
>
> I realize that this is fighting with a core feature of Clojure, and that
> the idea will probably rub lots of folks the wrong way. But I've now been
> down this road a couple of times and I'm beginning to think that I'd spend
> less time tracking down mysterious bugs if I could avoid laziness more
> easily.
>
> In case anybody is motivated to look into the specific bug that I was just
> dealing with, I've put the project at
> http://hampshire.edu/lspector/temp/world2D.zip. If you do "lein run" in
> its present state it will run fine, making little balls bounce around.
> (This is a very early version of some code that I plan to use both for
> teaching an AI class and for some ALife experiments...) But if you edit
> src/world2D/vec2D.clj, commenting out the definitions of *v, +v, and -v,
> and uncommenting the alternatives (which are the same except that they lack
> the calls to vec) then after running for a few seconds or a minute or so
> you'll get the stack overflow.
>
> Thanks for any suggestions,
>
>  -Lee
>
>
> [1] The stack traces I was getting provide no information about where/what
> the offending lazy sequences are, since they don't show locals etc. I see
> no references to any of my own code, just a repeating sequence that starts:
>
> StackOverflowError
> clojure.core/seq (core.clj:133)
> clojure.core/map/fn--4211 (core.clj:2490)
> clojure.lang.LazySeq.sval (LazySeq.java:42)
> clojure.lang.LazySeq.seq (LazySeq.java:60)
> clojure.lang.RT.seq (RT.java:484)
> clojure.core/seq (core.clj:133)
> clojure.core/map/fn--4211 (core.clj:2490)
> clojure.lang.LazySeq.sval (LazySeq.java:42)
> clojure.lang.LazySeq.seq (LazySeq.java:60)
> clojure.lang.RT.seq (RT.java:484)
> [etc]
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@google

4Clojure exercise 47 question

[Erlis Vidal]

Hi guys,

Quick question about exercise 47, http://www.4clojure.com/problem/47

Here you could find the following

*(not (contains? '(1 2 4)  __)*

If I try to execute it in my REPL it gives the following error:

* contains? not supported on type: clojure.lang.PersistentList*

Was this a change of recent clojure versions? Why?

Thanks,
Erlis

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

Re: non-lazy clojure?

[Lee Spector]

On Jun 2, 2014, at 4:51 PM, Softaddicts  wrote:

> mapv
> 
> a bit shorter :)
> 
> Luc P.

Thanks Luc. I have indeed migrated to mapv for many cases and I could have for 
the specific final fix for the example I posted. But there are lots of other 
"fixes" that I made earlier in the same project, some of which may also have 
been necessary. I also used filterv in some cases... but other places it was 
messier, e.g. with "for".

 -Lee 

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

Advice on implementing atomic read/write socket operations

[Joachim De Beule]

Dear group,

I have the following use case: I have a socket connection to an external 
service. I want several threads to use the same connection. 
Importantly,  in order to get a synchronized response from the external 
service, every write must be followed by a read before another write is 
performed. 

This seems a rather general problem, so I'm guessing there is a "standard" 
solution?

One strategy is to implement a Connection record that implements an atomic 
write/read protocol function. This function, when called from a thread A 
during another, unfinished call from a different thread B, blocks thread A 
and queues it until thread B's write/read call is finished and the 
connection is released. Is this a good strategy? How would it best be 
implemented using clojure's concurrency supporting features?

All advice much appreciated!
Joachim


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

Re: non-lazy clojure?

[Lee Spector]

On Jun 2, 2014, at 4:52 PM, Phillip Lord  wrote:

> Funny, I posted an article of my Clojure gotcha's today 
> (http://www.russet.org.uk/blog/2991), and this is one of them. I've also had 
> very nasty bugs, in addition to the general hassle of wrapping a Java API 
> which works through side-effects.
> 
> I created a few functions covering the most common ones (domap, dofor and so 
> on); having a comprehensive list somewhere in it's own namespace would be 
> quite useful.
> 
> Phil

It'd be nice to have a solid library of non-lazy alternatives to the core 
sequence functions.

FWIW while I've often dealt with this issue by using vectors, either with an 
explicit vec or with mapv or filterv, it's often not necessary or helpful for 
me that my sequences are actually vectors. That is, they could often be lists 
or some other kind of sequence instead. It's hard for me to know for sure, but 
I think that in many cases a "doall" solves the same problem that a "vec" 
would. This seems to be the case, for example, for the code/fix that I posted.

 -Lee

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

Re: non-lazy clojure?

[Lee Spector]

On Jun 2, 2014, at 4:52 PM, Jozef Wagner  wrote:

> Reducers [1] provide eager variants of some core seq functions (map, filter, 
> etc.). Note that they do not cache the result, so they recompute it every 
> time you use their result.
> 
> [1] http://clojure.org/reducers

Thanks Josef. I haven't yet really looked into reducers, but it seems on first 
glance like it may be overkill for just dealing with this issue -- using 
fork/join and getting unneeded parallelism for routine sequence processing, 
just to ensure that one doesn't have laziness-related bugs. The recomputation 
also sounds potentially problematic.

But I do want to look into reducers for other purposes, so thanks for the 
pointer!

 -Lee

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

Re: 4Clojure exercise 47 question

[Stephen Gilardi]

On Jun 2, 2014, at 4:53 PM, Erlis Vidal  wrote:

> Hi guys, 
> 
> Quick question about exercise 47, http://www.4clojure.com/problem/47
> 
> Here you could find the following
> 
> (not (contains? '(1 2 4)  __)
> 
> If I try to execute it in my REPL it gives the following error: 
> 
>  contains? not supported on type: clojure.lang.PersistentList
> 
> Was this a change of recent clojure versions? Why? 

Yes, it changed in Clojure 1.5.

The rationale is here: http://dev.clojure.org/jira/browse/CLJ-932

--Steve

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

Re: Advice on implementing atomic read/write socket operations

[James Reeves]

Since two threads cannot use the connection concurrently, it sounds like
you just need the locking macro:

(locking conn
  (.write conn "blah")
  (.read conn))

- James


On 2 June 2014 22:15, Joachim De Beule  wrote:

> Dear group,
>
> I have the following use case: I have a socket connection to an external
> service. I want several threads to use the same connection.
> Importantly,  in order to get a synchronized response from the external
> service, every write must be followed by a read before another write is
> performed.
>
> This seems a rather general problem, so I'm guessing there is a "standard"
> solution?
>
> One strategy is to implement a Connection record that implements an atomic
> write/read protocol function. This function, when called from a thread A
> during another, unfinished call from a different thread B, blocks thread A
> and queues it until thread B's write/read call is finished and the
> connection is released. Is this a good strategy? How would it best be
> implemented using clojure's concurrency supporting features?
>
> All advice much appreciated!
> Joachim
>
>
>  --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Is it the right Clojure group for a newbie

[sharmabha]

All,
   If this is the right Clojure group for a newbie, I would like to ask for 
the best online resources to begin with. I am new to programming, having 
recently switched from a non technical field.
I have started looking at http://www.braveclojure.com/, but any pointers 
would be useful, especially cookbook styled ones.  
Abha

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

Re: Is it the right Clojure group for a newbie

[Gary Trakhman]

Check out the 'online resources' section: http://clojure.org/getting_started


On Mon, Jun 2, 2014 at 5:36 PM,  wrote:

> All,
>If this is the right Clojure group for a newbie, I would like to ask
> for the best online resources to begin with. I am new to programming,
> having recently switched from a non technical field.
> I have started looking at http://www.braveclojure.com/, but any pointers
> would be useful, especially cookbook styled ones.
> Abha
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: non-lazy clojure?

[Gary Johnson]

Hey Lee,

  I would second Jozef's suggestion that you look into using the reducers 
library when you need non-lazy sequence operations. Although a major 
motivation of Rich's work was clearly to enable easy parallel folding via 
fork/join, the fold function is only one of many in this library. Think 
instead that the main (philosophical) purpose of reducers is to decomplect 
the reducing operation from the data representation it is acting on. And of 
course, since reduce can be used to implement (virtually) any non-lazy 
sequence operation, it stands to reason that reducers should be fully 
capable of providing new implementations of many of these functions on top 
of reduce (which it does).

  Importantly, whenever you will be chaining sequence operations together, 
reducers should be more efficient than both the lazy sequence functions 
(e.g., map, filter) and the eager vector-returning functions (e.g., mapv, 
filterv). This is because a chain of reducing functions generate no 
intermediate representations.


  For example, let's say I wanted to sum the squares of all the even 
numbers in a sequence called samples.

  Using lazy functions: (reduce + (map #(* % %) (filter even? samples)))

  Using non-lazy functions (reduce + (mapv #(* % %) (filterv even? 
samples)))

  Using reducers (aliased as r): (reduce + (r/map #(* % %) (r/filter even? 
samples)))


If you need to collect the results of a sequence operation in a data 
structure rather than reducing them to an atomic value, simply use into 
rather than reduce (since into uses reduce under the hood).

So to collect the squares of all the even numbers in the samples sequence, 
just do this:

  (into [] (r/map #(* % %) (r/filter even? samples)))

As just one sample point, when I updated a statistical fire analysis 
algorithm that I wrote from using the lazy sequence functions to using the 
reducers library, I experience a full order of magnitude speedup. This sped 
up my runtime from ~6 hours to around 20 minutes. So please do yourself a 
favor and give this library a close look. It has made worlds of difference 
for some of my work.

  Good luck,
~Gary

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

Re: non-lazy clojure?

[Lee Spector]

Gary: That's compelling indeed, and I will look into it more!

Thanks,

 -Lee

PS would a call to vec do the same thing as "into []" here?


On Jun 2, 2014, at 7:14 PM, Gary Johnson  wrote:

> Hey Lee,
> 
>   I would second Jozef's suggestion that you look into using the reducers 
> library when you need non-lazy sequence operations. Although a major 
> motivation of Rich's work was clearly to enable easy parallel folding via 
> fork/join, the fold function is only one of many in this library. Think 
> instead that the main (philosophical) purpose of reducers is to decomplect 
> the reducing operation from the data representation it is acting on. And of 
> course, since reduce can be used to implement (virtually) any non-lazy 
> sequence operation, it stands to reason that reducers should be fully capable 
> of providing new implementations of many of these functions on top of reduce 
> (which it does).
> 
>   Importantly, whenever you will be chaining sequence operations together, 
> reducers should be more efficient than both the lazy sequence functions 
> (e.g., map, filter) and the eager vector-returning functions (e.g., mapv, 
> filterv). This is because a chain of reducing functions generate no 
> intermediate representations.
> 
> 
>   For example, let's say I wanted to sum the squares of all the even numbers 
> in a sequence called samples.
> 
>   Using lazy functions: (reduce + (map #(* % %) (filter even? samples)))
> 
>   Using non-lazy functions (reduce + (mapv #(* % %) (filterv even? samples)))
> 
>   Using reducers (aliased as r): (reduce + (r/map #(* % %) (r/filter even? 
> samples)))
> 
> 
> If you need to collect the results of a sequence operation in a data 
> structure rather than reducing them to an atomic value, simply use into 
> rather than reduce (since into uses reduce under the hood).
> 
> So to collect the squares of all the even numbers in the samples sequence, 
> just do this:
> 
>   (into [] (r/map #(* % %) (r/filter even? samples)))
> 
> As just one sample point, when I updated a statistical fire analysis 
> algorithm that I wrote from using the lazy sequence functions to using the 
> reducers library, I experience a full order of magnitude speedup. This sped 
> up my runtime from ~6 hours to around 20 minutes. So please do yourself a 
> favor and give this library a close look. It has made worlds of difference 
> for some of my work.
> 
>   Good luck,
> ~Gary

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

deskewing image

[Glen Rubin]

I am interested in automatically deskewing of a scanned image before ocr 
processing using tesseract.  I found the following, which is some java code 
to do it http://anydoby.com/jblog/en/java/1990
 
Can anyone give some advice on how to make use of this java code using 
clojure?

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

Re: deskewing image

[Atamert Ölçgen]

On Tue, Jun 3, 2014 at 5:14 AM, Glen Rubin  wrote:

> I am interested in automatically deskewing of a scanned image before ocr
> processing using tesseract.  I found the following, which is some java code
> to do it http://anydoby.com/jblog/en/java/1990
>
> Can anyone give some advice on how to make use of this java code using
> clojure?
>

It can be utilized just like any other java code. Here is the primer:
http://clojure.org/java_interop

If you ask more specific questions I believe we can provide better answers.

Also, how good is your clojure-fu? Interfacing with Java modules doesn't
seem like the best way to start learning Clojure IMHO.




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



-- 
Kind Regards,
Atamert Ölçgen

-+-
--+
+++

www.muhuk.com

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

Re: Is it the right Clojure group for a newbie

[Linus Ericsson]

Also check out Kyle Kingsbury's Clojure from the ground up:
http://aphyr.com/posts/301-clojure-from-the-ground-up-welcome

A lot of things in Clojure gets much easier when one understands a bit of
java. Not how to write a for loop, but rather how to use various classes. I
recommend the Oracle Java tutorials. They are really good, given
Java's verbosity.

http://docs.oracle.com/javase/tutorial/

Also, do take the opportunity to really solve some problems, 4clojure is
great!
https://www.4clojure.com/

I have had trendemous help from clojuredocs.org and the many examples there.

There are several great books as well: Programming Clojure and Clojure
Programming are good for starters. Joy of Clojure is a bit more advanced.

Welcome to the fun!

/Linus

On Tuesday, June 3, 2014, Gary Trakhman  wrote:

> Check out the 'online resources' section:
> http://clojure.org/getting_started
>
>
> On Mon, Jun 2, 2014 at 5:36 PM,  > wrote:
>
>> All,
>>If this is the right Clojure group for a newbie, I would like to ask
>> for the best online resources to begin with. I am new to programming,
>> having recently switched from a non technical field.
>> I have started looking at http://www.braveclojure.com/, but any pointers
>> would be useful, especially cookbook styled ones.
>> Abha
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> 
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> 
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+unsubscr...@googlegroups.com
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>  --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> 
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> 
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com
> .
> For more options, visit https://groups.google.com/d/optout.
>

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