date:20131113


I did consider the possibility that it just wasn't funny!



James Reeves ja...@booleanknot.com writes:

 I'm afraid your jokes are a little too subtle for me, Phillip :)

 - James


 On 12 November 2013 17:01, Phillip Lord phillip.l...@newcastle.ac.ukwrote:

 James Reeves ja...@booleanknot.com writes:

  On 12 November 2013 16:26, Phillip Lord phillip.l...@newcastle.ac.uk
 wrote:
 
  While we are talking, does anyone know why (contains? [:a :b :c] :b)
  returns false?
 
 
  This would be better placed in its own thread I think, but it's because
 the
  contains? function checks for the presence of keys, not values. In a
  vector, the keys are the indexes: (contains? [:a :b :c] 1) = true.


 (defn joke?
Returns true if an attempt at humour is present in the given
 collection of words, otherwise returns false. Note that for internet
 based collections of words, 'joke?' operates in polynomial time, and
 often returns the wrong answer anyway.
  {:added 1.6}
  [content]
  (. clojure.lang.RT (joke content)))

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


 -- 

-- 
Phillip Lord,   Phone: +44 (0) 191 222 7827
Lecturer in Bioinformatics, Email: phillip.l...@newcastle.ac.uk
School of Computing Science,
http://homepages.cs.ncl.ac.uk/phillip.lord
Room 914 Claremont Tower,   skype: russet_apples
Newcastle University,   twitter: phillord
NE1 7RU 

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

Re: Regarding Clojure's license

2013-11-13 Thread Marshall Bockrath-Vandegrift

phillip.l...@newcastle.ac.uk (Phillip Lord) writes:

 I did consider the possibility that it just wasn't funny!

Oh, no – it was hilarious. :-)

-Marshall

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

Re: Step by step debugging

Hi Marshall,

Sure. Clojure implements locals clearing, which means that the compiler
will set local variables to null when it knows that the value of those
variables won't be used any more. This allows the garbage collector to
reclaim any values that those variables were pointing to, which is
particularly important in the case of large lazy sequences, which cache the
values they return to ensure that the same sequence always returns the same
values.

What you'll see if this option is not set is that the majority of local
variables (and of course, always the one you actually want to look at),
especially further up the stack frames, will be set to null even if your
code doesn't do so. This can be very confusing and/or frustrating when
debugging.

*compiler-options* is a dynamic var that controls various compiler options,
although I believe disabling locals clearing is the only one at present.
You control locals clearing by setting the value of
:disable-locals-clearing in this map to true. There are various ways to do
this - you could set it explicitly in the REPL, or you can set the system
property clojure.compiler.disable-locals-clearing to the value you would
like it to be set to. You can see the code that does this
herehttps://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/Compile.java#L58,
and if you're really interested the whole change is
herehttps://github.com/clojure/clojure/commit/4036c7720949cb21ccf53c5c7c54ed1daaff2fda.
You would set this system property in your JVM args, so if you're running
an app from the command line using java ... then just add
-Dclojure.compiler.disable-locals-clearing=true to your command line, or
you can add it to your jvm-opts in leiningen as shown elsewhere in this
thread.

However note that the code I linked to above is actually in the main
function of the compiler (I was wrong in my previous message, it's not
clojure.main) so this system property will only apply when AOTing your
code, not running it normally. In that case you'll have to do something
like:

(set! *compiler-options* {:disable-locals-clearing true})

or

(binding [*compiler-options* (assoc *compiler-options*
:disable-locals-clearing true)]
  ... your code here ...)

somewhere right near the start of your code (I'm not on a dev machine so I
haven't tested those, but that's the idea). The problem here is that you'll
have to ensure that this variable is set before the code you're interested
in is compiled! i.e. before its namespace is require'd, in the majority of
cases. This is not too much of a problem in the REPL when you can always
re-evaluate a namespace to recompile it, but it's a PITA in an application.
In Cursive I actually do it in Java before I bootstrap Clojure.

IMO this whole process is a fairly confusing which is unfortunate - I think
a few changes would have made it much easier to work with, but that's how
it currently works. Let me know if you have any more questions!

Cheers,
Colin




On 13 November 2013 18:52, Mars0i marsh...@logical.net wrote:

 Sorry to keep replying to my own posts with corrections: Rereading
 previous posts, I think I understand now that Colin's comments about
 retaining locals were intended to be relevant only to possible future
 facilities (which would go beyond my current knowledge).  But I'm still
 curious about where the -Dblahblah goes, etc.  Thanks.


 On Tuesday, November 12, 2013 11:15:11 PM UTC-6, Mars0i wrote:

 Colin (or anyone), for a Clojure newbie, could you spell out what you're
 saying about *compiler-options* and -Dblahblah a little bit further?  I
 think you're saying that if *compiler-options* is set to
 :disable-locals-clearing , then values of local variables are available,
 somehow.  Can I see them from the lein REPL, somehow?  If not, what do I
 get from :disable-locals-clearing ?

 It also sounds as if the only way to set *compiler-options* to
 :disable-locals-clearing is to use 
 -Dclojure.compile.disable-locals-clearing=true
 .  Where would I put that in a Leiningen project file?  After :jvm-opts or
 :javac-options?  Somewhere else?  (I experimented with both, and with
 trying to set *command-options* in various ways, but I'm not what effect I
 should see.)

 Thanks-
 Marshall

 (Also, another big +1 for Lee's original comments, and thanks for all of
 the debugger suggestions from others.  Locals are especially important when
 there's no state.  I just recently started rewriting a Common Lisp
 application.  The code had gotten too convoluted; parts of it are very old,
 with many layers of accretions.  I've been doing the rewrite in Clojure as
 my first Clojure project.  I'm seriously wondering at this moment, though,
 whether I should stop and do the rewrite in CL instead, despite several
 advantages of Clojure for me.  Being able to easily look at any data
 structure at any time in the CL version of this application has been
 absolutely crucial in the past.)

 On Friday, November 8, 2013 11:13:01 PM UTC-6, Colin Fleming wrote:

Re: Releasing Caribou today: Open Source Clojure Web Ecosystem

2013-11-13 Thread Ryan Spangler

Hi Leonardo,

It seems that on certain default java installs keys are restricted to 16
bytes:
http://stackoverflow.com/questions/6900542/java-security-invalidkeyexception-illegal-key-size

I just released a version that creates 16 byte keys for the cookie store.
Try that! (or edit the key in your src/{project-name}/core.clj and drop
half the chars).

On Wednesday, November 13, 2013 1:20:18 AM UTC-8, Leonardo Borges wrote:

Hi Ryan,

Love the website and the idea. Gave it a try but it gives me this when
trying to browse to the app:

java.security.InvalidKeyException: Illegal key size

It's coming from ring's cookie store. It seems the generated key isn't
valid.

I had a similar problem recently where I had to base64 decode the
string before passing it to the cookie-store. Not sure this is the
case here.

FWIW, I'm running Java 1.7 and Lein 2.3.3

Cheers,
Leonardo Borges
www.leonardoborges.com

On Wed, Nov 13, 2013 at 5:25 PM, Ryan Spangler
ryan.s...@gmail.comjavascript:
wrote:
Justin,

As far as I know, Immutant is not a dependency, but an option. Let me
know
if that is not true however.

On Tuesday, November 12, 2013 10:13:17 PM UTC-8, Justin Smith wrote:

Typically my first step making a caribou app is to remove the immutant
dependency. It's pretty straightforward to take it out.

On Tuesday, November 12, 2013 9:19:27 PM UTC-8, Prasanna Gautam wrote:

This is really cool. Very easy to get up and running for first try. I
have a few questions on the architecture.

Why Immutant instead of plain ring as the default? I think the number
of
dependencies could be much lower with it.

I know it's only alpha.. but I'm asking this on behalf of others who
might be thinking the same.
And, are there plans for NoSQL database support, like MongoDB, MapDB
(http://www.mapdb.org/ - I just found out about it myself but this is
the
only decent in-memory NoSQL solution other than Berkeley DB)?

On Tuesday, November 12, 2013 6:52:10 PM UTC-5, Ryan Spangler wrote:

Hello Clojure,

Excited to announce today the release of Caribou!
http://let-caribou.in/

We have been building web sites and web applications with it for over
two years now and improving it every day. Currently we have four
people
working on it and another ten using it to build things, so it is
getting a
lot of real world testing.

It has been designed as a collection of independent libraries that
could
each be useful on their own, but which come together as a meaningful
whole.

We have been spending the last couple months getting it ready for a
full
open source release, and I am happy to say it is finally ready.
Funded and
supported by Instrument in Portland, OR: http://weareinstrument.com/ We
have four projects using it in production, and several more about to
be
launched (as well as over a dozen internal things).

Documentation is here:
http://caribou.github.io/caribou/docs/outline.html

Source is here: http://github.com/caribou/caribou (use this for
issues,
you don't actually need the source as it is installed through a lein
template).

Some of the independently useful libraries Caribou is built on are:

* Polaris -- Routing with data (not macros) and reverse routing! :
https://github.com/caribou/polaris
* Lichen -- Image resizing to and from s3 or on disk:
https://github.com/caribou/lichen
* Schmetterling -- Debugging Clojure processes from the browser:
https://github.com/prismofeverything/schmetterling
* Antlers -- Useful extensions to mustache templating (helpers and
blocks, among other things): https://github.com/caribou/antlers
* Groundhog -- Replay http requests:
https://github.com/noisesmith/groundhog

And many others.

Basically this is an Alpha release, and I am announcing it here first
in
order to get as much feedback from the community as possible. We
have made
it as useful as we can for our purposes and recognize that for it to
improve
from here, we really need as many people using it and building things
with
it as possible. The documentation also needs to be put through its
paces:
we need to see how well people are able to use it who know nothing
about it,
based only on the existing docs.

All feedback welcome!

Thanks for reading! I hope you find it useful.

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

Re: Regarding Clojure's license

Paul L. Snyder p...@pataprogramming.com writes:

 On Wed, 13 Nov 2013, musicdenotat...@gmail.com wrote:

 spirit and purpose.  It's true that authors of FOSS want to get
 contribution from others, but you can't force others to work for you, or
 to do something that would potentially benefit you. Rich Hickey says that
 it does not make sense to allow the creation of derivative works that he
 can't use. Not so free software. He is like Richard Stallman now.
 Rich Hickey should visit http://copyfree.org/ too

 I am personally a big proponent of the GPL, but this is NOT the way to do
 advocacy. Please stop embarrassing yourself and aggravating others by
 continuing this approach.


I don't think he's an actual fan of GPL.

In the good old days, this sort of argument used to rage across the
usenet, then largely couched in terms of BSD vs GPL license. It used to
be great fun, with the all sorts of people asserting the right to use
the word free, and denying everone elses right to use it. My favorite
answer is this entertainly offensive reply from a little known
developer, with an unpronoucable name.

https://groups.google.com/d/msg/gnu.misc.discuss/ZgAIXRJCQI8/hZJJ76s22oEJ

I wonder what ever happened to him? 

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

Re: cider status

Norman Richards o...@nostacktrace.com writes:

 On Tue, Nov 12, 2013 at 10:22 AM, Phillip Lord phillip.l...@newcastle.ac.uk
 wrote:

 I have tried it a couple of times and keep reverting back to nrepl. One
 of the biggest issues is nrepl-ritz which depends on nrepl and not
 nrepl-client. So switching to cider appears to mean ditching ritz.


 Although I don't understand why anyone thought it was a good idea to change
 package names,

The discussion is here:

https://github.com/clojure-emacs/cider/issues/375

Basically, there was lots of confusion between nrepl.el (the client) and
nREPL (the server). Added to switch nrepl.el had lots of functionality
which wasn't just the client -- all of that's in nrepl-client.el now.

Probably a long term win, but a bit of a pain in the short term.

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

Re: Releasing Caribou today: Open Source Clojure Web Ecosystem

2013-11-13 Thread Leonardo Borges

Thanks for that reference.

I'll give it a try.

Cheers,
Leonardo Borges
www.leonardoborges.com

On Wed, Nov 13, 2013 at 8:46 PM, Ryan Spangler ryan.spang...@gmail.com wrote:
Hi Leonardo,

It seems that on certain default java installs keys are restricted to 16
bytes:
http://stackoverflow.com/questions/6900542/java-security-invalidkeyexception-illegal-key-size

I just released a version that creates 16 byte keys for the cookie store.
Try that! (or edit the key in your src/{project-name}/core.clj and drop
half the chars).

On Wednesday, November 13, 2013 1:20:18 AM UTC-8, Leonardo Borges wrote:

Hi Ryan,

Love the website and the idea. Gave it a try but it gives me this when
trying to browse to the app:

java.security.InvalidKeyException: Illegal key size

It's coming from ring's cookie store. It seems the generated key isn't
valid.

I had a similar problem recently where I had to base64 decode the
string before passing it to the cookie-store. Not sure this is the
case here.

FWIW, I'm running Java 1.7 and Lein 2.3.3

Cheers,
Leonardo Borges
www.leonardoborges.com

On Wed, Nov 13, 2013 at 5:25 PM, Ryan Spangler ryan.s...@gmail.com
wrote:
Justin,

As far as I know, Immutant is not a dependency, but an option. Let me
know
if that is not true however.

On Tuesday, November 12, 2013 10:13:17 PM UTC-8, Justin Smith wrote:

Typically my first step making a caribou app is to remove the immutant
dependency. It's pretty straightforward to take it out.

On Tuesday, November 12, 2013 9:19:27 PM UTC-8, Prasanna Gautam wrote:

This is really cool. Very easy to get up and running for first try. I
have a few questions on the architecture.

Why Immutant instead of plain ring as the default? I think the number
of
dependencies could be much lower with it.

On Tuesday, November 12, 2013 6:52:10 PM UTC-5, Ryan Spangler wrote:

Hello Clojure,

Excited to announce today the release of Caribou!
http://let-caribou.in/

It has been designed as a collection of independent libraries that
could
each be useful on their own, but which come together as a meaningful
whole.

We have been spending the last couple months getting it ready for a
full
open source release, and I am happy to say it is finally ready.
Funded and
supported by Instrument in Portland, OR: http://weareinstrument.com/
We
have four projects using it in production, and several more about to
be
launched (as well as over a dozen internal things).

Documentation is here:
http://caribou.github.io/caribou/docs/outline.html

Source is here: http://github.com/caribou/caribou (use this for
issues,
you don't actually need the source as it is installed through a lein
template).

Some of the independently useful libraries Caribou is built on are:

And many others.

All feedback welcome!

Thanks for reading! I hope you find it useful.

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

Re: [ANN] Troncle: Emacs convenience functions for tracing clojure code



This looks fantastic; while the recent discussion on debugging was going
on, it occurred to me that an instrumenting debugger, edebug style,
might be a good way to go.

Phil


Alex Coventry coven...@gmail.com writes:
 Troncle https://github.com/coventry/troncle is a proof-of-concept 
 integration of clojure's tracing tools with emacs, built around 
 technomancy's innovative 
 nrepl-discoverhttps://github.com/technomancy/nrepl-discover and 
 a robust (very simple) code-walking/wrapping 
 macrohttps://github.com/coventry/troncle/blob/master/src/troncle/macroshka.clj
  I've 
 developed.  It's available for download at 
 https://github.com/coventry/troncle


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

Re: Releasing Caribou today: Open Source Clojure Web Ecosystem

2013-11-13 Thread François De Serres

Beautiful.


Le mercredi 13 novembre 2013 00:52:10 UTC+1, Ryan Spangler a écrit :

 Hello Clojure,

 Excited to announce today the release of Caribou!  http://let-caribou.in/

 We have been building web sites and web applications with it for over two 
 years now and improving it every day.  Currently we have four people 
 working on it and another ten using it to build things, so it is getting a 
 lot of real world testing.

 It has been designed as a collection of independent libraries that could 
 each be useful on their own, but which come together as a meaningful whole.

 We have been spending the last couple months getting it ready for a full 
 open source release, and I am happy to say it is finally ready.  Funded and 
 supported by Instrument in Portland, OR:  http://weareinstrument.com/  We 
 have four projects using it in production, and several more about to be 
 launched (as well as over a dozen internal things).

 Documentation is here:  http://caribou.github.io/caribou/docs/outline.html

 Source is here:  http://github.com/caribou/caribou (use this for issues, 
 you don't actually need the source as it is installed through a lein 
 template).

 Some of the independently useful libraries Caribou is built on are:

 * Polaris -- Routing with data (not macros) and reverse routing! :  
 https://github.com/caribou/polaris
 * Lichen -- Image resizing to and from s3 or on disk: 
 https://github.com/caribou/lichen
 * Schmetterling -- Debugging Clojure processes from the browser:  
 https://github.com/prismofeverything/schmetterling
 * Antlers -- Useful extensions to mustache templating (helpers and blocks, 
 among other things):  https://github.com/caribou/antlers
 * Groundhog -- Replay http requests: 
 https://github.com/noisesmith/groundhog

 And many others.

 Basically this is an Alpha release, and I am announcing it here first in 
 order to get as much feedback from the community as possible.  We have made 
 it as useful as we can for our purposes and recognize that for it to 
 improve from here, we really need as many people using it and building 
 things with it as possible.  The documentation also needs to be put through 
 its paces:  we need to see how well people are able to use it who know 
 nothing about it, based only on the existing docs.

 All feedback welcome!  

 Thanks for reading!  I hope you find it useful.


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

Re: Regarding Clojure's license

2013-11-13 Thread Softaddicts

Hi,

Not only your tone is inappropriate but you seem to really expect
that the license scheme will change after nearly 6 years ?

On what basis ? Your legal advice ? Against what we have all been 
experiencing in the last six years ? 

Please do us a favor, do some readings first before posting
and soften the tone a bit, We will all be grateful :)

Most of the stuff surrounding Clojure has been the subject of some
careful decision process. Keep this in mind.

Thank you,

Luc P.

 I will not be dual licensing with GPL or LGPL. Both licenses allow the 
 creation of derived works under GPL, a license I cannot use in my 
 work. Allowing derived works I cannot use is not reciprocal and make 
 no sense for me.
 
 1. First, the license allow proprietary derivative works anyway.
 2. That's also the point of the GPL. It is intended to make any derivative 
 work available to the author usable to the author.
 
 Thus, Rich Hickey's choice of the EPL has the same rationale as the GPL. 
 That violates the principle of free software. License incompatibilities 
 like this divide the open-source community. Please change.
 
 -- 
 -- 
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clojure@googlegroups.com
 Note that posts from new members are moderated - please be patient with your 
 first post.
 To unsubscribe from this group, send email to
 clojure+unsubscr...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en
 --- 
 You received this message because you are subscribed to the Google Groups 
 Clojure group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to clojure+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/groups/opt_out.
 
--
Softaddictslprefonta...@softaddicts.ca sent by ibisMail from my ipad!

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

Re: Releasing Caribou today: Open Source Clojure Web Ecosystem

2013-11-13 Thread Joe Smith

Very cool, good luck to you!

---
Joseph Smith
j...@uwcreations.com
@solussd






On Nov 12, 2013, at 5:52 PM, Ryan Spangler ryan.spang...@gmail.com wrote:

 Hello Clojure,
 
 Excited to announce today the release of Caribou!  http://let-caribou.in/
 
 We have been building web sites and web applications with it for over two 
 years now and improving it every day.  Currently we have four people working 
 on it and another ten using it to build things, so it is getting a lot of 
 real world testing.
 
 It has been designed as a collection of independent libraries that could each 
 be useful on their own, but which come together as a meaningful whole.
 
 We have been spending the last couple months getting it ready for a full open 
 source release, and I am happy to say it is finally ready.  Funded and 
 supported by Instrument in Portland, OR:  http://weareinstrument.com/  We 
 have four projects using it in production, and several more about to be 
 launched (as well as over a dozen internal things).
 
 Documentation is here:  http://caribou.github.io/caribou/docs/outline.html
 
 Source is here:  http://github.com/caribou/caribou (use this for issues, you 
 don't actually need the source as it is installed through a lein template).
 
 Some of the independently useful libraries Caribou is built on are:
 
 * Polaris -- Routing with data (not macros) and reverse routing! :  
 https://github.com/caribou/polaris
 * Lichen -- Image resizing to and from s3 or on disk: 
 https://github.com/caribou/lichen
 * Schmetterling -- Debugging Clojure processes from the browser:  
 https://github.com/prismofeverything/schmetterling
 * Antlers -- Useful extensions to mustache templating (helpers and blocks, 
 among other things):  https://github.com/caribou/antlers
 * Groundhog -- Replay http requests: https://github.com/noisesmith/groundhog
 
 And many others.
 
 Basically this is an Alpha release, and I am announcing it here first in 
 order to get as much feedback from the community as possible.  We have made 
 it as useful as we can for our purposes and recognize that for it to improve 
 from here, we really need as many people using it and building things with it 
 as possible.  The documentation also needs to be put through its paces:  we 
 need to see how well people are able to use it who know nothing about it, 
 based only on the existing docs.
 
 All feedback welcome!  
 
 Thanks for reading!  I hope you find it useful.
 
 -- 
 -- 
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clojure@googlegroups.com
 Note that posts from new members are moderated - please be patient with your 
 first post.
 To unsubscribe from this group, send email to
 clojure+unsubscr...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en
 --- 
 You received this message because you are subscribed to the Google Groups 
 Clojure group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to clojure+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/groups/opt_out.

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

Re: Regarding Clojure's license

2013-11-13 Thread Paul L. Snyder

On Wed, 13 Nov 2013, Phillip Lord wrote:

 Paul L. Snyder p...@pataprogramming.com writes:
 
  On Wed, 13 Nov 2013, musicdenotat...@gmail.com wrote:
 
  spirit and purpose.  It's true that authors of FOSS want to get
  contribution from others, but you can't force others to work for you, or
  to do something that would potentially benefit you. Rich Hickey says that
  it does not make sense to allow the creation of derivative works that he
  can't use. Not so free software. He is like Richard Stallman now.
  Rich Hickey should visit http://copyfree.org/ too
 
  I am personally a big proponent of the GPL, but this is NOT the way to do
  advocacy. Please stop embarrassing yourself and aggravating others by
  continuing this approach.
 
 I don't think he's an actual fan of GPL.

Huh, I guess you're right, and my attempt at dousing the flames may just
have been pouring gasoline. I just took a look at the copyfree website, and
it appears to be advocating licenses that approximate a public domain
approach. It also appears to need a copy editor.

I should have gone with my first reaction, which is that any suffienctly
poorly worded argument is indistinguishable from trolling.

 In the good old days, this sort of argument used to rage across the
 usenet, then largely couched in terms of BSD vs GPL license. It used to
 be great fun, with the all sorts of people asserting the right to use
 the word free, and denying everone elses right to use it. My favorite
 answer is this entertainly offensive reply from a little known
 developer, with an unpronoucable name.
 
 https://groups.google.com/d/msg/gnu.misc.discuss/ZgAIXRJCQI8/hZJJ76s22oEJ
 
 I wonder what ever happened to him? 

Whatever it may be, I don't think he's mellowing with age.

  http://lkml.indiana.edu/hypermail/linux/kernel/1309.1/00905.html

Paul Snyder

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

Re: Releasing Caribou today: Open Source Clojure Web Ecosystem

2013-11-13 Thread Baishampayan Ghose

This is brilliant! Many thanks Ryan. Looking forward to trying these
out and contributing back. ~BG

On Wed, Nov 13, 2013 at 5:22 AM, Ryan Spangler ryan.spang...@gmail.com wrote:
 Hello Clojure,

 Excited to announce today the release of Caribou!  http://let-caribou.in/

 We have been building web sites and web applications with it for over two
 years now and improving it every day.  Currently we have four people working
 on it and another ten using it to build things, so it is getting a lot of
 real world testing.

 It has been designed as a collection of independent libraries that could
 each be useful on their own, but which come together as a meaningful whole.

 We have been spending the last couple months getting it ready for a full
 open source release, and I am happy to say it is finally ready.  Funded and
 supported by Instrument in Portland, OR:  http://weareinstrument.com/  We
 have four projects using it in production, and several more about to be
 launched (as well as over a dozen internal things).

 Documentation is here:  http://caribou.github.io/caribou/docs/outline.html

 Source is here:  http://github.com/caribou/caribou (use this for issues, you
 don't actually need the source as it is installed through a lein template).

 Some of the independently useful libraries Caribou is built on are:

 * Polaris -- Routing with data (not macros) and reverse routing! :
 https://github.com/caribou/polaris
 * Lichen -- Image resizing to and from s3 or on disk:
 https://github.com/caribou/lichen
 * Schmetterling -- Debugging Clojure processes from the browser:
 https://github.com/prismofeverything/schmetterling
 * Antlers -- Useful extensions to mustache templating (helpers and blocks,
 among other things):  https://github.com/caribou/antlers
 * Groundhog -- Replay http requests: https://github.com/noisesmith/groundhog

 And many others.

 Basically this is an Alpha release, and I am announcing it here first in
 order to get as much feedback from the community as possible.  We have made
 it as useful as we can for our purposes and recognize that for it to improve
 from here, we really need as many people using it and building things with
 it as possible.  The documentation also needs to be put through its paces:
 we need to see how well people are able to use it who know nothing about it,
 based only on the existing docs.

 All feedback welcome!

 Thanks for reading!  I hope you find it useful.

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



-- 
Baishampayan Ghose
b.ghose at gmail.com

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

Re: Releasing Caribou today: Open Source Clojure Web Ecosystem

2013-11-13 Thread Brian Craft

Looks very cool. I'm happy to see that data modeling is taken seriously, 
which in my experience is the biggest piece lacking in other clojure web 
tools.

The docs have a lot of layout problems with words running together, like 
so: data from oneenvironment. Looks like a string joining operation 
that's not quite right.

On Tuesday, November 12, 2013 3:52:10 PM UTC-8, Ryan Spangler wrote:

 Hello Clojure,

 Excited to announce today the release of Caribou!  http://let-caribou.in/

 We have been building web sites and web applications with it for over two 
 years now and improving it every day.  Currently we have four people 
 working on it and another ten using it to build things, so it is getting a 
 lot of real world testing.

 It has been designed as a collection of independent libraries that could 
 each be useful on their own, but which come together as a meaningful whole.

 We have been spending the last couple months getting it ready for a full 
 open source release, and I am happy to say it is finally ready.  Funded and 
 supported by Instrument in Portland, OR:  http://weareinstrument.com/  We 
 have four projects using it in production, and several more about to be 
 launched (as well as over a dozen internal things).

 Documentation is here:  http://caribou.github.io/caribou/docs/outline.html

 Source is here:  http://github.com/caribou/caribou (use this for issues, 
 you don't actually need the source as it is installed through a lein 
 template).

 Some of the independently useful libraries Caribou is built on are:

 * Polaris -- Routing with data (not macros) and reverse routing! :  
 https://github.com/caribou/polaris
 * Lichen -- Image resizing to and from s3 or on disk: 
 https://github.com/caribou/lichen
 * Schmetterling -- Debugging Clojure processes from the browser:  
 https://github.com/prismofeverything/schmetterling
 * Antlers -- Useful extensions to mustache templating (helpers and blocks, 
 among other things):  https://github.com/caribou/antlers
 * Groundhog -- Replay http requests: 
 https://github.com/noisesmith/groundhog

 And many others.

 Basically this is an Alpha release, and I am announcing it here first in 
 order to get as much feedback from the community as possible.  We have made 
 it as useful as we can for our purposes and recognize that for it to 
 improve from here, we really need as many people using it and building 
 things with it as possible.  The documentation also needs to be put through 
 its paces:  we need to see how well people are able to use it who know 
 nothing about it, based only on the existing docs.

 All feedback welcome!  

 Thanks for reading!  I hope you find it useful.


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

A Design (Simplification) Problem

2013-11-13 Thread Oskar Kvist

Hi!

I'm making an MMORPG. For those of you not into games, MMORPG is short
for massively multiplayer online role-playing game. That means that
hundreds of players can connect to the same server and play a role
playing game simultaneously. There is of course a big game state on the
server that changes all the time, and the clients need to be aware of at
least some of the changes.

My problem is the following: It's inefficient to send the whole new
state each frame to the clients. So the server needs to send changes,
updates about events, to the clients. For example, if the server's game
logic decides that a monster should spawn somewhere, the server needs to
somehow remember that event so it can notify the clients about it.

What I do now is: Do something to the state (e.g. spawn a new monster),
then generate an event (piece of data) that describes what happened (a
monster spawned), that can be passed to other parts of the system (e.g.
the networking part) so that those other parts can react to what
happened. But that seems stupid. Once something happens, the events
should ideally be implicitly generated and taken care of without me
writing code that explicitly handles events.

It could be done by comparing the new state to the old one, but that is
also inefficient.

To make it a little more concrete: I don't want to write (in code) when
a player is attacked, update the players health, and generate a
'modified-health-event' and when a monster spawns, insert the new
monster into the game state, and generate a 'monster-spawned-event'. If
the functions are pure, not only do I need to generate all these events,
which are not really part of the core logic of the game, but I also need
to pass them around: Say the main loop calls `let-characters-attack`,
and that function calls `take-damage` (several times), and `take-damage`
generates an event, then that event needs to be passed through
`let-characters-attack` back to the game loop so that the networking
system knows what updates need to be sent to the clients.

I thought about some ideas:

Instead of returning events, and having to pass them through calling
functions, I could just put them on a queue somewhere. That results in
less code (that pass events around) but make the functions impure. And
ideally I don't even want to have to explicitly generate events.

Maybe I could make a macro or use something similar to the state monad,
i.e. something that takes care of the plumbing behind the scenes, but
I'm not sure how that would work. A problem with that is that the
functions that generate events can be very dissimilar to each other.
`take-damage` for example only operaters on one single character, while
other functions may operate on a larger portion of the game state, or
the terrain, or whatever. The events can be dissimilar to each other
too. This heterogeneousness seems like somewhat of a problem. 

Let's say, for the sake of argument, that `take-damage` does essentially
`(update-in character [:health] - damage)` and the event that should be
generated is `[:damage id-of-character amount-of-damage]`; and
`spawn-monster` is essentially `(assoc-in game-state [:characters]
(new-id) (new-monster))` and the event is `[:new-monster id monster]`.
It's kind of hard to make a general function f: what happened to the
game state - event, that is called implicitly when something happens to
the game state.

justin_smith suggested spatial partitioning to make things more
efficient. But even if partitioned, sending the whole partition or
comparting the previous partition of the state to the new one is still
way less efficient than having these events, and of course it does not
take care of (make more implicit) the events stuff. Of course, when I
say make more implicit, what that really means is that I want to
separate, decomplect, the updating of the game state from the generation
of events so I don't have to care about events when updating the game
state.

Any ideas?

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

How to convert this simple (and inefficient) fibonacci function to # format

2013-11-13 Thread Angus

I know this fibonacci function is not optimal but I want to learn one step 
at a time.  I want to be able to apply this approach to 4clojure which 
disallows a lot of things including defn. 

This is my implementation so far: 

(defn fib [x] 
   (cond 
  (= x 0) 0 
  (= x 1) 1 
  :else 
 (+ (fib (- x 1)) (fib (- x 2)


So I thought about something like this:

(#(fn fib [x] 
   (cond 
  (= x 0) 0 
  (= x 1) 1 
  :else 
 (+ (fib (- x 1)) (fib (- x 2)
  8)

But trying that in a REPL I get error:

clojure.lang.ArityException: Wrong number of args (1) passed to: 
sandbox28956$eval28971$fn

So how can I call this as a one line REPL?

I though using apply with a one element list might work, but no.

(apply #(fn fib [x](cond (= x 0) 0 (= x 1) 1  :else  (+ (fib (- x 1)) (fib 
(- x 2) '(8))


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

Re: How to convert this simple (and inefficient) fibonacci function to # format

2013-11-13 Thread Ben Wolfson

#(fn fib [x] ... ) creates a zero-arity function which, when called, will
return a one-arity function. Just get rid of the #.


On Wed, Nov 13, 2013 at 9:41 AM, Angus anguscom...@gmail.com wrote:

 I know this fibonacci function is not optimal but I want to learn one step
 at a time.  I want to be able to apply this approach to 4clojure which
 disallows a lot of things including defn.

 This is my implementation so far:

 (defn fib [x]
(cond
   (= x 0) 0
   (= x 1) 1
   :else
  (+ (fib (- x 1)) (fib (- x 2)


 So I thought about something like this:

 (#(fn fib [x]
(cond
   (= x 0) 0
   (= x 1) 1
   :else
  (+ (fib (- x 1)) (fib (- x 2)
   8)

 But trying that in a REPL I get error:

 clojure.lang.ArityException: Wrong number of args (1) passed to:
 sandbox28956$eval28971$fn

 So how can I call this as a one line REPL?

 I though using apply with a one element list might work, but no.

 (apply #(fn fib [x](cond (= x 0) 0 (= x 1) 1  :else  (+ (fib (- x 1)) (fib
 (- x 2) '(8))


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




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

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

Re: How to convert this simple (and inefficient) fibonacci function to # format

2013-11-13 Thread Jim - FooBar();

you don't need 'fn' when you're using #(...) - that is the whole point. 
To not have to declare a function and its args explicitly.


this particular example you cannot write using #() syntax though because 
it is recursing at 2 points and you cannot use 'recur'.


Jim

wOn 13/11/13 17:41, Angus wrote:
I know this fibonacci function is not optimal but I want to learn one 
step at a time.  I want to be able to apply this approach to 4clojure 
which disallows a lot of things including defn.


This is my implementation so far:

(defn fib [x]
   (cond
  (= x 0) 0
  (= x 1) 1
  :else
 (+ (fib (- x 1)) (fib (- x 2)


So I thought about something like this:

(#(fn fib [x]
   (cond
  (= x 0) 0
  (= x 1) 1
  :else
 (+ (fib (- x 1)) (fib (- x 2)
  8)

But trying that in a REPL I get error:

clojure.lang.ArityException: Wrong number of args (1) passed to: 
sandbox28956$eval28971$fn


So how can I call this as a one line REPL?

I though using apply with a one element list might work, but no.

(apply #(fn fib [x](cond (= x 0) 0 (= x 1) 1  :else  (+ (fib (- x 1)) 
(fib (- x 2) '(8))



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

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

For more options, visit https://groups.google.com/groups/opt_out.


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

To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: A Design (Simplification) Problem

2013-11-13 Thread James Reeves

Hi Oskar,

I've recently been working on a similar problem. I've had some success with
FRP (functional reactive programming), and I've written a library,
Reagihttps://github.com/weavejester/reagi,
to implement what is hopefully a style of FRP that remains true to
Clojure's ideology.

First, let's represent an event that causes damage as a data structure.

{:type :damage
 :amount 10
 :target player-id}


I'll leave the player identifier as a symbol for the purposes of this
example. When coded for real, this could be anything that uniquely
identifies the target. A UUID might be a reasonable choice.

In Reagi, we can represent a stream of events in an area like so:

(def area-events (r/events))


We can then filter out only the damage events that apply to the player:

(def player-damage-events

  (- area-events

   (r/filter #(= (:type %) :damage))

   (r/filter #{= (:target %) player-id


Once we have a stream of damage events, we can represent the health of the
player by subtracting the damage from an initial value:

(def player
  {:id player-id
   :hp (- player-damage-events
(r/map :damage)
(r/reduce - max-hp))})


To get the current health of the player, we can just deref:

@(:hp player)


This approach is thread-safe and asynchronous, relying on core.async behind
the scenes. It's also declarative, and you can handle all game logic
without requiring a central loop. Instead you can just rely on a render
loop that derefs your game state every time it needs to display.

Another advantage is that once you have a game set up around this
principle, making it multiplayer is a matter of hooking up your main event
stream to a TCP socket.

- James



On 13 November 2013 17:16, Oskar Kvist oskar.kv...@gmail.com wrote:

 Hi!

 I'm making an MMORPG. For those of you not into games, MMORPG is short
 for massively multiplayer online role-playing game. That means that
 hundreds of players can connect to the same server and play a role
 playing game simultaneously. There is of course a big game state on the
 server that changes all the time, and the clients need to be aware of at
 least some of the changes.

 My problem is the following: It's inefficient to send the whole new
 state each frame to the clients. So the server needs to send changes,
 updates about events, to the clients. For example, if the server's game
 logic decides that a monster should spawn somewhere, the server needs to
 somehow remember that event so it can notify the clients about it.

 What I do now is: Do something to the state (e.g. spawn a new monster),
 then generate an event (piece of data) that describes what happened (a
 monster spawned), that can be passed to other parts of the system (e.g.
 the networking part) so that those other parts can react to what
 happened. But that seems stupid. Once something happens, the events
 should ideally be implicitly generated and taken care of without me
 writing code that explicitly handles events.

 It could be done by comparing the new state to the old one, but that is
 also inefficient.

 To make it a little more concrete: I don't want to write (in code) when
 a player is attacked, update the players health, and generate a
 'modified-health-event' and when a monster spawns, insert the new
 monster into the game state, and generate a 'monster-spawned-event'. If
 the functions are pure, not only do I need to generate all these events,
 which are not really part of the core logic of the game, but I also need
 to pass them around: Say the main loop calls `let-characters-attack`,
 and that function calls `take-damage` (several times), and `take-damage`
 generates an event, then that event needs to be passed through
 `let-characters-attack` back to the game loop so that the networking
 system knows what updates need to be sent to the clients.

 I thought about some ideas:

 Instead of returning events, and having to pass them through calling
 functions, I could just put them on a queue somewhere. That results in
 less code (that pass events around) but make the functions impure. And
 ideally I don't even want to have to explicitly generate events.

 Maybe I could make a macro or use something similar to the state monad,
 i.e. something that takes care of the plumbing behind the scenes, but
 I'm not sure how that would work. A problem with that is that the
 functions that generate events can be very dissimilar to each other.
 `take-damage` for example only operaters on one single character, while
 other functions may operate on a larger portion of the game state, or
 the terrain, or whatever. The events can be dissimilar to each other
 too. This heterogeneousness seems like somewhat of a problem.

 Let's say, for the sake of argument, that `take-damage` does essentially
 `(update-in character [:health] - damage)` and the event that should be
 generated is `[:damage id-of-character amount-of-damage]`; and
 `spawn-monster` is essentially `(assoc-in game-state [:characters]

Re: A Design (Simplification) Problem

2013-11-13 Thread Phlex

Instead of making changes to your data structure, then creating an 
event, you could :
-create a modification command as a data structure {:type :move 
:character-id 12 :move-to {some coords..}}
-apply it to your data structure (each and every modification to the 
data structure would have to be done via those commands)

-send it to the client as an event (some filtering might be in order)

This way you have a clear way to channel all your commands to your 
world, a clean separation between command, world and client. A clean 
interface to your world and finally a clean wire protocol  ! (and easy 
logging, replay from save point etc...)


Sacha


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

To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: How to convert this simple (and inefficient) fibonacci function to # format

2013-11-13 Thread Angus

Ah, as in:

 ((fn fib [x](cond (= x 0) 0 (= x 1) 1  :else  (+ (fib (- x 1)) (fib (- x 
2) 8))
21

Many thanks.



On Wednesday, 13 November 2013 17:46:57 UTC, Jim foo.bar wrote:

 you don't need 'fn' when you're using #(...) - that is the whole point. 
 To not have to declare a function and its args explicitly. 

 this particular example you cannot write using #() syntax though because 
 it is recursing at 2 points and you cannot use 'recur'. 

 Jim 

 wOn 13/11/13 17:41, Angus wrote: 
  I know this fibonacci function is not optimal but I want to learn one 
  step at a time.  I want to be able to apply this approach to 4clojure 
  which disallows a lot of things including defn. 
  
  This is my implementation so far: 
  
  (defn fib [x] 
 (cond 
(= x 0) 0 
(= x 1) 1 
:else 
   (+ (fib (- x 1)) (fib (- x 2) 
  
  
  So I thought about something like this: 
  
  (#(fn fib [x] 
 (cond 
(= x 0) 0 
(= x 1) 1 
:else 
   (+ (fib (- x 1)) (fib (- x 2) 
8) 
  
  But trying that in a REPL I get error: 
  
  clojure.lang.ArityException: Wrong number of args (1) passed to: 
  sandbox28956$eval28971$fn 
  
  So how can I call this as a one line REPL? 
  
  I though using apply with a one element list might work, but no. 
  
  (apply #(fn fib [x](cond (= x 0) 0 (= x 1) 1  :else  (+ (fib (- x 1)) 
  (fib (- x 2) '(8)) 
  
  
  -- 
  -- 
  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 unsubscribe from this group and stop receiving emails from it, send 
  an email to clojure+u...@googlegroups.com javascript:. 
  For more options, visit https://groups.google.com/groups/opt_out. 



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

Re: Releasing Caribou today: Open Source Clojure Web Ecosystem

2013-11-13 Thread Ryan Spangler

Brian,

Thanks for the heads up!  I fixed some of the formatting issues I found, 
I'll keep a lookout for this issue (using a md-html converter which 
apparently requires spaces at the end of lines in lists?)

And yes, data modeling is one of our main concerns.  All models are also 
data, which means they can be manipulated like any other data structure. 
 This is what enables us to generate the admin and api automatically!  (as 
well as a host of other benefits)

On Wednesday, November 13, 2013 8:07:52 AM UTC-8, Brian Craft wrote:

 Looks very cool. I'm happy to see that data modeling is taken seriously, 
 which in my experience is the biggest piece lacking in other clojure web 
 tools.

 The docs have a lot of layout problems with words running together, like 
 so: data from oneenvironment. Looks like a string joining operation 
 that's not quite right.

 On Tuesday, November 12, 2013 3:52:10 PM UTC-8, Ryan Spangler wrote:

 Hello Clojure,

 Excited to announce today the release of Caribou!  http://let-caribou.in/

 We have been building web sites and web applications with it for over two 
 years now and improving it every day.  Currently we have four people 
 working on it and another ten using it to build things, so it is getting a 
 lot of real world testing.

 It has been designed as a collection of independent libraries that could 
 each be useful on their own, but which come together as a meaningful whole.

 We have been spending the last couple months getting it ready for a full 
 open source release, and I am happy to say it is finally ready.  Funded and 
 supported by Instrument in Portland, OR:  http://weareinstrument.com/ We 
 have four projects using it in production, and several more about to be 
 launched (as well as over a dozen internal things).

 Documentation is here:  
 http://caribou.github.io/caribou/docs/outline.html

 Source is here:  http://github.com/caribou/caribou (use this for issues, 
 you don't actually need the source as it is installed through a lein 
 template).

 Some of the independently useful libraries Caribou is built on are:

 * Polaris -- Routing with data (not macros) and reverse routing! :  
 https://github.com/caribou/polaris
 * Lichen -- Image resizing to and from s3 or on disk: 
 https://github.com/caribou/lichen
 * Schmetterling -- Debugging Clojure processes from the browser:  
 https://github.com/prismofeverything/schmetterling
 * Antlers -- Useful extensions to mustache templating (helpers and 
 blocks, among other things):  https://github.com/caribou/antlers
 * Groundhog -- Replay http requests: 
 https://github.com/noisesmith/groundhog

 And many others.

 Basically this is an Alpha release, and I am announcing it here first in 
 order to get as much feedback from the community as possible.  We have made 
 it as useful as we can for our purposes and recognize that for it to 
 improve from here, we really need as many people using it and building 
 things with it as possible.  The documentation also needs to be put through 
 its paces:  we need to see how well people are able to use it who know 
 nothing about it, based only on the existing docs.

 All feedback welcome!  

 Thanks for reading!  I hope you find it useful.



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

Re: A Design (Simplification) Problem

2013-11-13 Thread Cedric Greevey

One might also wish to consider a pull model, in which clients explicitly
request information they need from the server. A client could ask for an
object's health, given its ID; or for the current ids and positions of
monsters in a particular small geographical area (which the server would
look up using interval trees).


On Wed, Nov 13, 2013 at 1:46 PM, Phlex ph...@telenet.be wrote:

 Instead of making changes to your data structure, then creating an event,
 you could :
 -create a modification command as a data structure {:type :move
 :character-id 12 :move-to {some coords..}}
 -apply it to your data structure (each and every modification to the data
 structure would have to be done via those commands)
 -send it to the client as an event (some filtering might be in order)

 This way you have a clear way to channel all your commands to your world,
 a clean separation between command, world and client. A clean interface to
 your world and finally a clean wire protocol  ! (and easy logging, replay
 from save point etc...)

 Sacha



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


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

Re: Step by step debugging

2013-11-13 Thread Mars0i

Thanks Colin!  Wow--that's extremely helpful.  The concepts are very clear 
now, and I now understand that it's a map *compiler-options* is supposed to 
be set to.  What I was trying before wasn't right.

No matter what I do, I am not seeing an effect on the value of 
*compiler-options* from the command line option.  Tried
   :jvm-opts [-Dclojure.compiler.disable-locals-clearing=true]
in a Leiningen project.clj, both with and without compiling to class files 
ahead of time.  Tried it starting Clojure with a java command line from the 
prompt.

I can't set the value of *compiler-options* with set!, but I'm able to set 
*compiler-options* with binding, and see that it's bound to 
{:disable-locals-clearing true} inside the binding form (of course).

I'm still not clear on what effect this should have.  I can refer to a 
local variable inside its scope, but that's nothing special.  Is 
:disable-locals-clearing = true supposed to allow me to be able to 
reference a local outside of its scope?  (A bad thing in general, but good, 
sometimes, for debugging?)  For example, if I compile this:

(defn yo [n] 
  (if (= n 15) 
(throw (Exception. (format Yow!))) 
(if (= n 0) 
  Done! 
  (yo (dec n)

with *compiler-options* set to {:disable-locals-clearing true}, is there a 
way to see, after the exception is thrown, that n had the value 15?

Thanks-

Marshall

On Wednesday, November 13, 2013 3:45:27 AM UTC-6, Colin Fleming wrote:

 Hi Marshall,

 Sure. Clojure implements locals clearing, which means that the compiler 
 will set local variables to null when it knows that the value of those 
 variables won't be used any more. This allows the garbage collector to 
 reclaim any values that those variables were pointing to, which is 
 particularly important in the case of large lazy sequences, which cache the 
 values they return to ensure that the same sequence always returns the same 
 values.

 What you'll see if this option is not set is that the majority of local 
 variables (and of course, always the one you actually want to look at), 
 especially further up the stack frames, will be set to null even if your 
 code doesn't do so. This can be very confusing and/or frustrating when 
 debugging.

 *compiler-options* is a dynamic var that controls various compiler 
 options, although I believe disabling locals clearing is the only one at 
 present. You control locals clearing by setting the value of 
 :disable-locals-clearing in this map to true. There are various ways to do 
 this - you could set it explicitly in the REPL, or you can set the system 
 property clojure.compiler.disable-locals-clearing to the value you would 
 like it to be set to. You can see the code that does this 
 herehttps://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/Compile.java#L58,
  
 and if you're really interested the whole change is 
 herehttps://github.com/clojure/clojure/commit/4036c7720949cb21ccf53c5c7c54ed1daaff2fda.
  
 You would set this system property in your JVM args, so if you're running 
 an app from the command line using java ... then just add 
 -Dclojure.compiler.disable-locals-clearing=true to your command line, or 
 you can add it to your jvm-opts in leiningen as shown elsewhere in this 
 thread. 

 However note that the code I linked to above is actually in the main 
 function of the compiler (I was wrong in my previous message, it's not 
 clojure.main) so this system property will only apply when AOTing your 
 code, not running it normally. In that case you'll have to do something 
 like:

 (set! *compiler-options* {:disable-locals-clearing true})

 or 

 (binding [*compiler-options* (assoc *compiler-options* 
 :disable-locals-clearing true)]
   ... your code here ...)

 somewhere right near the start of your code (I'm not on a dev machine so I 
 haven't tested those, but that's the idea). The problem here is that you'll 
 have to ensure that this variable is set before the code you're interested 
 in is compiled! i.e. before its namespace is require'd, in the majority of 
 cases. This is not too much of a problem in the REPL when you can always 
 re-evaluate a namespace to recompile it, but it's a PITA in an application. 
 In Cursive I actually do it in Java before I bootstrap Clojure.

 IMO this whole process is a fairly confusing which is unfortunate - I 
 think a few changes would have made it much easier to work with, but that's 
 how it currently works. Let me know if you have any more questions!

 Cheers,
 Colin


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

Re: Releasing Caribou today: Open Source Clojure Web Ecosystem

2013-11-13 Thread Dmitri

I notice you're using a fairly old version of markdown-clj [markdown-clj 
0.9.19]

The current version is [markdown-clj 0.9.35] so that should address a lot 
of formatting issues. :)

On Wednesday, November 13, 2013 2:09:10 PM UTC-5, Ryan Spangler wrote:

 Brian,

 Thanks for the heads up!  I fixed some of the formatting issues I found, 
 I'll keep a lookout for this issue (using a md-html converter which 
 apparently requires spaces at the end of lines in lists?)

 And yes, data modeling is one of our main concerns.  All models are also 
 data, which means they can be manipulated like any other data structure. 
  This is what enables us to generate the admin and api automatically!  (as 
 well as a host of other benefits)

 On Wednesday, November 13, 2013 8:07:52 AM UTC-8, Brian Craft wrote:

 Looks very cool. I'm happy to see that data modeling is taken seriously, 
 which in my experience is the biggest piece lacking in other clojure web 
 tools.

 The docs have a lot of layout problems with words running together, like 
 so: data from oneenvironment. Looks like a string joining operation 
 that's not quite right.

 On Tuesday, November 12, 2013 3:52:10 PM UTC-8, Ryan Spangler wrote:

 Hello Clojure,

 Excited to announce today the release of Caribou!  
 http://let-caribou.in/

 We have been building web sites and web applications with it for over 
 two years now and improving it every day.  Currently we have four people 
 working on it and another ten using it to build things, so it is getting a 
 lot of real world testing.

 It has been designed as a collection of independent libraries that could 
 each be useful on their own, but which come together as a meaningful whole.

 We have been spending the last couple months getting it ready for a full 
 open source release, and I am happy to say it is finally ready.  Funded and 
 supported by Instrument in Portland, OR:  http://weareinstrument.com/ We 
 have four projects using it in production, and several more about to be 
 launched (as well as over a dozen internal things).

 Documentation is here:  
 http://caribou.github.io/caribou/docs/outline.html

 Source is here:  http://github.com/caribou/caribou (use this for 
 issues, you don't actually need the source as it is installed through a 
 lein template).

 Some of the independently useful libraries Caribou is built on are:

 * Polaris -- Routing with data (not macros) and reverse routing! :  
 https://github.com/caribou/polaris
 * Lichen -- Image resizing to and from s3 or on disk: 
 https://github.com/caribou/lichen
 * Schmetterling -- Debugging Clojure processes from the browser:  
 https://github.com/prismofeverything/schmetterling
 * Antlers -- Useful extensions to mustache templating (helpers and 
 blocks, among other things):  https://github.com/caribou/antlers
 * Groundhog -- Replay http requests: 
 https://github.com/noisesmith/groundhog

 And many others.

 Basically this is an Alpha release, and I am announcing it here first in 
 order to get as much feedback from the community as possible.  We have made 
 it as useful as we can for our purposes and recognize that for it to 
 improve from here, we really need as many people using it and building 
 things with it as possible.  The documentation also needs to be put through 
 its paces:  we need to see how well people are able to use it who know 
 nothing about it, based only on the existing docs.

 All feedback welcome!  

 Thanks for reading!  I hope you find it useful.



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

Do web apps need Clojure?

Hi Folks,

We’re a Python / Django shop, and some folks are getting excited about using 
Clojure for building web apps.  Certainly there are numerous open-source 
options to assist us (Pedastal, Ring, Compojure, Caribou, etc), but I think it 
begs a larger question: as a rule, do web applications need the power that 
Clojure brings to the table?

Other folks on my team are telling me that solutions built with Python / Django 
(or even RubyOnRails) fully satisfy the needs of 99% of the web apps we have 
built, and that Clojure offers nothing new to this problem space.  

So, here’s the question: How are you are actually using Clojure, and why did 
you choose to use it, particularly in the “web application” space?  

Thanks,
Marcus



marcus blankenship
\\\ Partner, Problem Solver, Linear Thinker
\\\ 541.805.2736 \ @justzeros \ skype:marcuscreo

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

Re: Regarding Clojure's license

At least one company (mine at the time) had a problem with using LGPL
software because of the clause where you explicitly allow reverse
engineering of your product in order to use a different version of the LGPL
library. That's enough to give any corporate lawyer the screaming heebie
jeebies, not to mention the possibility of having to support your product
with users running random versions of some of the libraries you depend on.
A ridiculous prospect? Maybe, but the LGPL very explicitly allows it and
forces acceptance of those terms, so clearly someone is anticipating doing
it.


On 13 November 2013 11:25, John Gabriele jmg3...@gmail.com wrote:

 On Tuesday, November 12, 2013 11:30:23 AM UTC-5, Sean Corfield wrote:

 It's also worth
 pointing out that a lot of US companies won't use GPL-licensed
 software (and won't pay for a closed source version), and many aren't
 comfortable with LGPL either.


 I don't see why a company would have any problem at all with *using*
 LGPL'd software, even in a product. However, I can see the possible
 complaints if they wanted to *modify* it and then distribute their modified
 version (since that would then require distributing the modified source
 along with it).

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


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

Re: Step by step debugging

Hi Marshall,

You'll only see a difference due to locals clearing if you're stepping with
a debugger and looking at locals in your local stack frame or in the frames
above it. In your example, the ability to pause when an exception is thrown
is a capability your debugger provides. Cursive does provide this (although
I need to test it thoroughly, most of the functionality is provided by
IntelliJ and I haven't tested it all with Clojure yet), I'm not sure about
other debuggers. So if your debugger provides that capability, when you
pause on the thrown exception, if you didn't have locals clearing disabled
when that code was compiled you'll see the value of n as null since the
compiler has inferred that the value is never used in the branch you took
(the branch throwing the exception) and has nulled it out. If you had
locals clearing disabled when that code was compiled, then you will
correctly see the value of n as 15, yes.

Cheers,
Colin

On 14 November 2013 08:53, Mars0i marsh...@logical.net wrote:

Thanks Colin! Wow--that's extremely helpful. The concepts are very clear
now, and I now understand that it's a map *compiler-options* is supposed to
be set to. What I was trying before wasn't right.

No matter what I do, I am not seeing an effect on the value of
*compiler-options* from the command line option. Tried
:jvm-opts [-Dclojure.compiler.disable-locals-clearing=true]
in a Leiningen project.clj, both with and without compiling to class files
ahead of time. Tried it starting Clojure with a java command line from the
prompt.

I can't set the value of *compiler-options* with set!, but I'm able to set
*compiler-options* with binding, and see that it's bound to
{:disable-locals-clearing true} inside the binding form (of course).

I'm still not clear on what effect this should have. I can refer to a
local variable inside its scope, but that's nothing special. Is
:disable-locals-clearing = true supposed to allow me to be able to
reference a local outside of its scope? (A bad thing in general, but good,
sometimes, for debugging?) For example, if I compile this:

(defn yo [n]
(if (= n 15)
(throw (Exception. (format Yow!)))
(if (= n 0)
Done!
(yo (dec n)

with *compiler-options* set to {:disable-locals-clearing true}, is there a
way to see, after the exception is thrown, that n had the value 15?

Thanks-

Marshall

On Wednesday, November 13, 2013 3:45:27 AM UTC-6, Colin Fleming wrote:

Hi Marshall,

Sure. Clojure implements locals clearing, which means that the compiler
will set local variables to null when it knows that the value of those
variables won't be used any more. This allows the garbage collector to
reclaim any values that those variables were pointing to, which is
particularly important in the case of large lazy sequences, which cache the
values they return to ensure that the same sequence always returns the same
values.

What you'll see if this option is not set is that the majority of local
variables (and of course, always the one you actually want to look at),
especially further up the stack frames, will be set to null even if your
code doesn't do so. This can be very confusing and/or frustrating when
debugging.

*compiler-options* is a dynamic var that controls various compiler
options, although I believe disabling locals clearing is the only one at
present. You control locals clearing by setting the value of
:disable-locals-clearing in this map to true. There are various ways to do
this - you could set it explicitly in the REPL, or you can set the system
property clojure.compiler.disable-locals-clearing to the value you
would like it to be set to. You can see the code that does this
herehttps://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/Compile.java#L58,
and if you're really interested the whole change is
herehttps://github.com/clojure/clojure/commit/4036c7720949cb21ccf53c5c7c54ed1daaff2fda.
You would set this system property in your JVM args, so if you're running
an app from the command line using java ... then just add
-Dclojure.compiler.disable-locals-clearing=true to your command line, or
you can add it to your jvm-opts in leiningen as shown elsewhere in this
thread.

However note that the code I linked to above is actually in the main
function of the compiler (I was wrong in my previous message, it's not
clojure.main) so this system property will only apply when AOTing your
code, not running it normally. In that case you'll have to do something
like:

(set! *compiler-options* {:disable-locals-clearing true})

(binding [*compiler-options* (assoc *compiler-options*
:disable-locals-clearing true)]
... your code here ...)

somewhere right near the start of your code (I'm not on a dev machine so
I haven't tested those, but that's the idea). The problem here is that
you'll have to ensure that this variable is set before the code you're
interested in is compiled! i.e.

Re: Do web apps need Clojure?

2013-11-13 Thread Justin Smith

Hi. I'm part of the Caribou team, which started as an in-house tool (and 
continues to serve that purpose).

A few advantages of clojure in the webapp space, off the top of my head:

Clojure provides execution efficiency that Ruby or Python cannot match. 
This translates to lowered hosting costs.

The lein tool provides very clean and isolated dependency management, that 
makes setting up dev environments and deployment very straightforward.

Targeting the JVM means that each deploy can be a single jar or war file 
that you upload to the server.

The ring middleware system is a very clean way of including functionality 
in an app.

Working with immutable data structures and threadsafe bindings as a 
pervasive default does a lot for stability, and rules out many of the round 
about ways one of heisenbugs end up in the system.

On Wednesday, November 13, 2013 2:38:49 PM UTC-8, Marcus Blankenship wrote:

 Hi Folks,

 We’re a Python / Django shop, and some folks are getting excited about 
 using Clojure for building web apps.  Certainly there are numerous 
 open-source options to assist us (Pedastal, Ring, Compojure, Caribou, etc), 
 but I think it begs a larger question: *as a rule, do web applications 
 need the power that Clojure brings to the table?*

 Other folks on my team are telling me that solutions built with Python / 
 Django (or even RubyOnRails) fully satisfy the needs of 99% of the web apps 
 we have built, and that Clojure offers nothing new to this problem space.  

 So, here’s the question: *How are you are actually using Clojure, and why 
 did you choose to use it, particularly in the “web application” space? * 

 Thanks,
 Marcus



 marcus blankenship
 \\\ Partner, Problem Solver, Linear Thinker
 \\\ 541.805.2736 \ @justzeros \ skype:marcuscreo
  


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

Re: Step by step debugging

2013-11-13 Thread Mars0i

Colin,

Got it--this setting is relevant to use of a debugger.  I was trying to see 
something from vanilla and Leiningen repls.  Thank you for taking so much 
time to explain.  (My current debugger is (print (format ...)).  Have to 
upgrade.)

-Marshall 

On Wednesday, November 13, 2013 5:16:27 PM UTC-6, Colin Fleming wrote:

 Hi Marshall,

 You'll only see a difference due to locals clearing if you're stepping 
 with a debugger and looking at locals in your local stack frame or in the 
 frames above it. In your example, the ability to pause when an exception is 
 thrown is a capability your debugger provides. Cursive does provide this 
 (although I need to test it thoroughly, most of the functionality is 
 provided by IntelliJ and I haven't tested it all with Clojure yet), I'm not 
 sure about other debuggers. So if your debugger provides that capability, 
 when you pause on the thrown exception, if you didn't have locals clearing 
 disabled when that code was compiled you'll see the value of n as null 
 since the compiler has inferred that the value is never used in the branch 
 you took (the branch throwing the exception) and has nulled it out. If you 
 had locals clearing disabled when that code was compiled, then you will 
 correctly see the value of n as 15, yes.

 Cheers,
 Colin 


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

Re: Do web apps need Clojure?

Thanks, Justin.  These are great points!  I especially like the simplicity of 
deployment.  Do you folks use Heroku, AWS, or some other hosting service?


On Nov 13, 2013, at 3:23 PM, Justin Smith noisesm...@gmail.com wrote:

 Hi. I'm part of the Caribou team, which started as an in-house tool (and 
 continues to serve that purpose).
 
 A few advantages of clojure in the webapp space, off the top of my head:
 
 Clojure provides execution efficiency that Ruby or Python cannot match. This 
 translates to lowered hosting costs.
 
 The lein tool provides very clean and isolated dependency management, that 
 makes setting up dev environments and deployment very straightforward.
 
 Targeting the JVM means that each deploy can be a single jar or war file that 
 you upload to the server.
 
 The ring middleware system is a very clean way of including functionality in 
 an app.
 
 Working with immutable data structures and threadsafe bindings as a pervasive 
 default does a lot for stability, and rules out many of the round about ways 
 one of heisenbugs end up in the system.
 
 On Wednesday, November 13, 2013 2:38:49 PM UTC-8, Marcus Blankenship wrote:
 Hi Folks,
 
 We’re a Python / Django shop, and some folks are getting excited about using 
 Clojure for building web apps.  Certainly there are numerous open-source 
 options to assist us (Pedastal, Ring, Compojure, Caribou, etc), but I think 
 it begs a larger question: as a rule, do web applications need the power that 
 Clojure brings to the table?
 
 Other folks on my team are telling me that solutions built with Python / 
 Django (or even RubyOnRails) fully satisfy the needs of 99% of the web apps 
 we have built, and that Clojure offers nothing new to this problem space.  
 
 So, here’s the question: How are you are actually using Clojure, and why did 
 you choose to use it, particularly in the “web application” space?  
 
 Thanks,
 Marcus
 
 
 
 marcus blankenship
 \\\ Partner, Problem Solver, Linear Thinker
 \\\ 541.805.2736 \ @justzeros \ skype:marcuscreo
 
 
 -- 
 -- 
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clojure@googlegroups.com
 Note that posts from new members are moderated - please be patient with your 
 first post.
 To unsubscribe from this group, send email to
 clojure+unsubscr...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en
 --- 
 You received this message because you are subscribed to the Google Groups 
 Clojure group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to clojure+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/groups/opt_out.

marcus blankenship
\\\ Partner, Problem Solver, Linear Thinker
\\\ 541.805.2736 \ @justzeros \ skype:marcuscreo

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

Re: Do web apps need Clojure?

2013-11-13 Thread Bastien

Hi Marcus,

Marcus Blankenship mar...@creoagency.com writes:

 Thanks, Justin.  These are great points!  I especially like the
 simplicity of deployment.  Do you folks use Heroku, AWS, or some
 other hosting service?

I started with Heroku but then switched to using a VM with Immutant.
Immutant is great, you should have a look!

-- 
 Bastien

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

Re: Do web apps need Clojure?

2013-11-13 Thread Justin Smith

Usually elastic beanstalk or ec2 (beanstalk is simpler and trivial to make 
scale, but less flexible so sometimes we need to fall back on using an ec2 
instance). In either case we typically a clojure war into a tomcat 
container. As long as you remember to keep your permgen large enough it is 
pretty simple.

On Wednesday, November 13, 2013 3:49:16 PM UTC-8, Marcus Blankenship wrote:

 Thanks, Justin.  These are great points!  I especially like the simplicity 
 of deployment.  Do you folks use Heroku, AWS, or some other hosting service?


 On Nov 13, 2013, at 3:23 PM, Justin Smith noise...@gmail.comjavascript: 
 wrote:

 Hi. I'm part of the Caribou team, which started as an in-house tool (and 
 continues to serve that purpose).

 A few advantages of clojure in the webapp space, off the top of my head:

 Clojure provides execution efficiency that Ruby or Python cannot match. 
 This translates to lowered hosting costs.

 The lein tool provides very clean and isolated dependency management, that 
 makes setting up dev environments and deployment very straightforward.

 Targeting the JVM means that each deploy can be a single jar or war file 
 that you upload to the server.

 The ring middleware system is a very clean way of including functionality 
 in an app.

 Working with immutable data structures and threadsafe bindings as a 
 pervasive default does a lot for stability, and rules out many of the round 
 about ways one of heisenbugs end up in the system.

 On Wednesday, November 13, 2013 2:38:49 PM UTC-8, Marcus Blankenship wrote:

 Hi Folks,

 We’re a Python / Django shop, and some folks are getting excited about 
 using Clojure for building web apps.  Certainly there are numerous 
 open-source options to assist us (Pedastal, Ring, Compojure, Caribou, etc), 
 but I think it begs a larger question: *as a rule, do web applications 
 need the power that Clojure brings to the table?*

 Other folks on my team are telling me that solutions built with Python / 
 Django (or even RubyOnRails) fully satisfy the needs of 99% of the web apps 
 we have built, and that Clojure offers nothing new to this problem space.  

 So, here’s the question: *How are you are actually using Clojure, and 
 why did you choose to use it, particularly in the “web application” space? *
  

 Thanks,
 Marcus



 marcus blankenship
 \\\ Partner, Problem Solver, Linear Thinker
 \\\ 541.805.2736 \ @justzeros \ skype:marcuscreo
  

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


 marcus blankenship
 \\\ Partner, Problem Solver, Linear Thinker
 \\\ 541.805.2736 \ @justzeros \ skype:marcuscreo
  


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

Re: Do web apps need Clojure?

Ah, thanks!  I’ll check it out!


On Nov 13, 2013, at 3:59 PM, Bastien bastiengue...@gmail.com wrote:

 Hi Marcus,
 
 Marcus Blankenship mar...@creoagency.com writes:
 
 Thanks, Justin.  These are great points!  I especially like the
 simplicity of deployment.  Do you folks use Heroku, AWS, or some
 other hosting service?
 
 I started with Heroku but then switched to using a VM with Immutant.
 Immutant is great, you should have a look!
 
 -- 
 Bastien

marcus blankenship
\\\ Partner, Problem Solver, Linear Thinker
\\\ 541.805.2736 \ @justzeros \ skype:marcuscreo

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

Re: Do web apps need Clojure?

2013-11-13 Thread James Reeves

On 13 November 2013 22:38, Marcus Blankenship mar...@creoagency.com wrote:


 We’re a Python / Django shop, and some folks are getting excited about
 using Clojure for building web apps.  Certainly there are numerous
 open-source options to assist us (Pedastal, Ring, Compojure, Caribou, etc),
 but I think it begs a larger question: *as a rule, do web applications
 need the power that Clojure brings to the table?*


Surely that depends on the web application? The internal architecture
between web applications varies enormously, perhaps more than any other
class of system.

You mention your team works with Django, so presumably your applications
tend to be backed by a single SQL database, and are form-based to some
degree. Django has some excellent tools for generating web applications
based around that structure.

However, I've run into a number of situations where that structure becomes
a hindrance. For instance, maintaining an immutable history of events in
SQL is a pain in the ass, which is a requirement for some systems,
particularly those that record clinical data. Another problem with clinical
data is that you can't discard invalid data, even if it fails something as
basic as a type check. This subverts a lot of assumptions web frameworks
(and databases) typically make.

There's also a lot of interesting research going on in Clojure right now,
some of which affects web development. For example, core.async can be used
on the client and server side to great effect, and support for Ring request
and response data structures is, I believe, planned for core.typed.

- James

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

Re: Do web apps need Clojure?

Hi James,

Good points, and I figured someone would say “Well, what kind of web app are 
you creating?”  Just like you, we’ve built a huge variety of web apps, and they 
each have different requirements.  Some of what we have done would have 
benefited from it, and others probably would have been a wash.

Thanks for chiming in!
Marcus


On Nov 13, 2013, at 4:03 PM, James Reeves ja...@booleanknot.com wrote:

 On 13 November 2013 22:38, Marcus Blankenship mar...@creoagency.com wrote:
 
 We’re a Python / Django shop, and some folks are getting excited about using 
 Clojure for building web apps.  Certainly there are numerous open-source 
 options to assist us (Pedastal, Ring, Compojure, Caribou, etc), but I think 
 it begs a larger question: as a rule, do web applications need the power that 
 Clojure brings to the table?
 
 Surely that depends on the web application? The internal architecture between 
 web applications varies enormously, perhaps more than any other class of 
 system.
 
 You mention your team works with Django, so presumably your applications tend 
 to be backed by a single SQL database, and are form-based to some degree. 
 Django has some excellent tools for generating web applications based around 
 that structure.
 
 However, I've run into a number of situations where that structure becomes a 
 hindrance. For instance, maintaining an immutable history of events in SQL is 
 a pain in the ass, which is a requirement for some systems, particularly 
 those that record clinical data. Another problem with clinical data is that 
 you can't discard invalid data, even if it fails something as basic as a type 
 check. This subverts a lot of assumptions web frameworks (and databases) 
 typically make.
 
 There's also a lot of interesting research going on in Clojure right now, 
 some of which affects web development. For example, core.async can be used on 
 the client and server side to great effect, and support for Ring request and 
 response data structures is, I believe, planned for core.typed.
 
 - James
 
 -- 
 -- 
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clojure@googlegroups.com
 Note that posts from new members are moderated - please be patient with your 
 first post.
 To unsubscribe from this group, send email to
 clojure+unsubscr...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en
 --- 
 You received this message because you are subscribed to the Google Groups 
 Clojure group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to clojure+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/groups/opt_out.

marcus blankenship
\\\ Partner, Problem Solver, Linear Thinker
\\\ 541.805.2736 \ @justzeros \ skype:marcuscreo

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

Re: Do web apps need Clojure?

Got it, thanks!  I’ve always wanted to use Beanstalk, but figured it would have 
some limitations…

On Nov 13, 2013, at 4:00 PM, Justin Smith noisesm...@gmail.com wrote:

 Usually elastic beanstalk or ec2 (beanstalk is simpler and trivial to make 
 scale, but less flexible so sometimes we need to fall back on using an ec2 
 instance). In either case we typically a clojure war into a tomcat container. 
 As long as you remember to keep your permgen large enough it is pretty simple.
 
 On Wednesday, November 13, 2013 3:49:16 PM UTC-8, Marcus Blankenship wrote:
 Thanks, Justin.  These are great points!  I especially like the simplicity of 
 deployment.  Do you folks use Heroku, AWS, or some other hosting service?
 
 
 On Nov 13, 2013, at 3:23 PM, Justin Smith noise...@gmail.com wrote:
 
 Hi. I'm part of the Caribou team, which started as an in-house tool (and 
 continues to serve that purpose).
 
 A few advantages of clojure in the webapp space, off the top of my head:
 
 Clojure provides execution efficiency that Ruby or Python cannot match. This 
 translates to lowered hosting costs.
 
 The lein tool provides very clean and isolated dependency management, that 
 makes setting up dev environments and deployment very straightforward.
 
 Targeting the JVM means that each deploy can be a single jar or war file 
 that you upload to the server.
 
 The ring middleware system is a very clean way of including functionality in 
 an app.
 
 Working with immutable data structures and threadsafe bindings as a 
 pervasive default does a lot for stability, and rules out many of the round 
 about ways one of heisenbugs end up in the system.
 
 On Wednesday, November 13, 2013 2:38:49 PM UTC-8, Marcus Blankenship wrote:
 Hi Folks,
 
 We’re a Python / Django shop, and some folks are getting excited about using 
 Clojure for building web apps.  Certainly there are numerous open-source 
 options to assist us (Pedastal, Ring, Compojure, Caribou, etc), but I think 
 it begs a larger question: as a rule, do web applications need the power 
 that Clojure brings to the table?
 
 Other folks on my team are telling me that solutions built with Python / 
 Django (or even RubyOnRails) fully satisfy the needs of 99% of the web apps 
 we have built, and that Clojure offers nothing new to this problem space.  
 
 So, here’s the question: How are you are actually using Clojure, and why did 
 you choose to use it, particularly in the “web application” space?  
 
 Thanks,
 Marcus
 
 
 
 marcus blankenship
 \\\ Partner, Problem Solver, Linear Thinker
 \\\ 541.805.2736 \ @justzeros \ skype:marcuscreo
 
 
 -- 
 -- 
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clo...@googlegroups.com
 Note that posts from new members are moderated - please be patient with your 
 first post.
 To unsubscribe from this group, send email to
 clojure+u...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en
 --- 
 You received this message because you are subscribed to the Google Groups 
 Clojure group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to clojure+u...@googlegroups.com.
 For more options, visit https://groups.google.com/groups/opt_out.
 
 marcus blankenship
 \\\ Partner, Problem Solver, Linear Thinker
 \\\ 541.805.2736 \ @justzeros \ skype:marcuscreo
 
 
 -- 
 -- 
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clojure@googlegroups.com
 Note that posts from new members are moderated - please be patient with your 
 first post.
 To unsubscribe from this group, send email to
 clojure+unsubscr...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en
 --- 
 You received this message because you are subscribed to the Google Groups 
 Clojure group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to clojure+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/groups/opt_out.

marcus blankenship
\\\ Partner, Problem Solver, Linear Thinker
\\\ 541.805.2736 \ @justzeros \ skype:marcuscreo

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

Re: Do web apps need Clojure?

2013-11-13 Thread Brian Craft



On Wednesday, November 13, 2013 3:23:52 PM UTC-8, Justin Smith wrote:


 Clojure provides execution efficiency that Ruby or Python cannot match. 
 This translates to lowered hosting costs.



It should be noted that the go-to solution for performance in python is to 
drop to native code for bottlenecks, which is pretty easy, and which still 
out-performs the jvm. Whether clojure runs faster than python in a 
particular application is not a given.

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

Re: Do web apps need Clojure?

2013-11-13 Thread Brian Craft

I also work in a python/django shop, and have been experimenting with 
clojure for about nine months. Before yesterday I would have told you that 
clojure web tooling does not come remotely close to the power of django. 
With a large amount of effort in piecing different libraries together, you 
might cover 30 or 40% of what django provides out of the box. I will have 
to reevaluate that with the announcement of Caribou, which looks good at 
first glance.

As a language, clojure is much more enjoyable. Python may seem clumsy and 
ineffective after writing clojure for awhile.


On Wednesday, November 13, 2013 2:38:49 PM UTC-8, Marcus Blankenship wrote:

 Hi Folks,

 We’re a Python / Django shop, and some folks are getting excited about 
 using Clojure for building web apps.  Certainly there are numerous 
 open-source options to assist us (Pedastal, Ring, Compojure, Caribou, etc), 
 but I think it begs a larger question: *as a rule, do web applications 
 need the power that Clojure brings to the table?*

 Other folks on my team are telling me that solutions built with Python / 
 Django (or even RubyOnRails) fully satisfy the needs of 99% of the web apps 
 we have built, and that Clojure offers nothing new to this problem space.  

 So, here’s the question: *How are you are actually using Clojure, and why 
 did you choose to use it, particularly in the “web application” space? * 

 Thanks,
 Marcus



 marcus blankenship
 \\\ Partner, Problem Solver, Linear Thinker
 \\\ 541.805.2736 \ @justzeros \ skype:marcuscreo
  


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

Re: Do web apps need Clojure?

2013-11-13 Thread Adrian Mouat



On Wednesday, 13 November 2013 23:23:52 UTC, Justin Smith wrote:

 Hi. I'm part of the Caribou team, which started as an in-house tool (and 
 continues to serve that purpose).

 A few advantages of clojure in the webapp space, off the top of my head:


Another nice advantage is being able to use the same language on the 
backend and frontend, if you are willing to embrace Clojurescript.
 

 Clojure provides execution efficiency that Ruby or Python cannot match. 
 This translates to lowered hosting costs.

 The lein tool provides very clean and isolated dependency management, that 
 makes setting up dev environments and deployment very straightforward.

 Targeting the JVM means that each deploy can be a single jar or war file 
 that you upload to the server.

 The ring middleware system is a very clean way of including functionality 
 in an app.

 Working with immutable data structures and threadsafe bindings as a 
 pervasive default does a lot for stability, and rules out many of the round 
 about ways one of heisenbugs end up in the system.

 On Wednesday, November 13, 2013 2:38:49 PM UTC-8, Marcus Blankenship wrote:

 Hi Folks,

 We’re a Python / Django shop, and some folks are getting excited about 
 using Clojure for building web apps.  Certainly there are numerous 
 open-source options to assist us (Pedastal, Ring, Compojure, Caribou, etc), 
 but I think it begs a larger question: *as a rule, do web applications 
 need the power that Clojure brings to the table?*

 Other folks on my team are telling me that solutions built with Python / 
 Django (or even RubyOnRails) fully satisfy the needs of 99% of the web apps 
 we have built, and that Clojure offers nothing new to this problem space.  

 So, here’s the question: *How are you are actually using Clojure, and 
 why did you choose to use it, particularly in the “web application” space? *
  

 Thanks,
 Marcus



 marcus blankenship
 \\\ Partner, Problem Solver, Linear Thinker
 \\\ 541.805.2736 \ @justzeros \ skype:marcuscreo
  


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

Re: Want to translate the ClojureCheetSheet in Japanese.

2013-11-13 Thread 竹内景太郎

Thank you for reply.
I think Yes, and let's alter-meta! Doc of the Japanese to fork the 
repository of Clojure for the time being.
I'm sorry question is complicated.

Keitaro Takeuchi

2013年11月11日月曜日 13時08分35秒 UTC+9 Andy Fingerhut:

 I am the current maintainer of the Clojure Cheat Sheet, and certainly have 
 no objections if anyone wishes to translate it into other languages.

 Most of the content of the cheat sheet are the Clojure symbols themselves, 
 the documentation strings that come with Clojure 1.5.1, and links to the 
 ClojureDocs.org web site for examples.

 At the very least, you would probably want to translate the documentation 
 strings into another language, and perhaps the names of the symbols 
 themselves.  If you would like to do that translation, I am now looking 
 into a straightforward way to change all built-in doc strings of a running 
 Clojure process to alternate doc strings (it is simply doing alter-meta! on 
 the Clojure symbols of the functions and macros, which is easy).  If you do 
 that, I could generate a version of the Clojure cheat sheet web page with 
 those translated doc strings and either link to it from my Github web page, 
 or perhaps even from clojure.org/cheatsheet.

 Andy


 On Sun, Nov 10, 2013 at 5:28 PM, 竹内景太郎 tiyot...@gmail.com 
 javascript:wrote:

 Hello everyone,I am a Clojure user in Japan.

 I think for beginners Clojure in Japan, you want published on the site 
 ClojureCheetSheet you have Japanese translation, but I would be all right.

 Thanks in advance.

 Keitaro Takeuchi


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




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

Re: Regarding Clojure's license

2013-11-13 Thread Korny Sietsma

 any sufficiently poorly worded argument is indistinguishable from
trolling.

Is that original? I want to quote it. A lot.

- Korny
On 14 Nov 2013 01:42, Paul L. Snyder p...@pataprogramming.com wrote:

 On Wed, 13 Nov 2013, Phillip Lord wrote:

  Paul L. Snyder p...@pataprogramming.com writes:
 
   On Wed, 13 Nov 2013, musicdenotat...@gmail.com wrote:
  
   spirit and purpose.  It's true that authors of FOSS want to get
   contribution from others, but you can't force others to work for you,
 or
   to do something that would potentially benefit you. Rich Hickey says
 that
   it does not make sense to allow the creation of derivative works that
 he
   can't use. Not so free software. He is like Richard Stallman now.
   Rich Hickey should visit http://copyfree.org/ too
  
   I am personally a big proponent of the GPL, but this is NOT the way to
 do
   advocacy. Please stop embarrassing yourself and aggravating others by
   continuing this approach.
 
  I don't think he's an actual fan of GPL.

 Huh, I guess you're right, and my attempt at dousing the flames may just
 have been pouring gasoline. I just took a look at the copyfree website, and
 it appears to be advocating licenses that approximate a public domain
 approach. It also appears to need a copy editor.

 I should have gone with my first reaction, which is that any suffienctly
 poorly worded argument is indistinguishable from trolling.

  In the good old days, this sort of argument used to rage across the
  usenet, then largely couched in terms of BSD vs GPL license. It used to
  be great fun, with the all sorts of people asserting the right to use
  the word free, and denying everone elses right to use it. My favorite
  answer is this entertainly offensive reply from a little known
  developer, with an unpronoucable name.
 
 
 https://groups.google.com/d/msg/gnu.misc.discuss/ZgAIXRJCQI8/hZJJ76s22oEJ
 
  I wonder what ever happened to him?

 Whatever it may be, I don't think he's mellowing with age.

   http://lkml.indiana.edu/hypermail/linux/kernel/1309.1/00905.html

 Paul Snyder

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


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

Re: Regarding Clojure's license

2013-11-13 Thread John Gabriele

On Wednesday, November 13, 2013 6:06:02 PM UTC-5, Colin Fleming wrote:

  I don't see why a company would have any problem at all with *using*
  LGPL'd software, even in a product. However, I can see the possible
  complaints if they wanted to *modify* it and then distribute their 
modified
  version (since that would then require distributing the modified source
  along with it).

At least one company (mine at the time) had a problem with using LGPL 
 software because of the clause where you explicitly allow reverse 
 engineering of your product in order to use a different version of the LGPL 
 library. {snip}


For what it's worth, I find that passage of the LGPL (4. Combined Works) 
somewhat difficult to understand. It *seems* to me that it's saying: 
although your combined work may be non-free,

  * you can't restrict modification of the LGPL library contained therein, 
and
  * you can't restrict users from reverse engineering any modifications 
you've made to the LGPL library contained therein.

Where that 2nd point seems redundant to me, since, if you're distributing a 
modified version of an LGPL'd lib, you're already required to also 
distribute the modified source of it as well.

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

Re: Regarding Clojure's license

Although it's definitely difficult to understand, it says You may convey a
Combined Work under terms of your choice that, taken together, effectively
do not restrict modification of the portions of the Library contained in
the Combined Work and reverse engineering for debugging such
modifications, which sounds to me like you have to let users swap the
library out, and you accept that they may reverse engineer to allow them to
do so.

Section 4 d) (in the LGPL3 https://www.gnu.org/licenses/lgpl.html) also
says that, assuming you don't want to distribute any source (option 0) then
you must use a dynamic linking mechanism which uses a library already
present on the user's system (option 1) which rules out a Java app shipping
a library as a jar file with the main application.

Either way, the fine detail is fairly moot since the uncertainty alone is
enough to make most corporations (especially in the US) unwilling to risk
it. If I were running a US corp I'd need to be really, really sure that I
needed that library and that there were no viable alternatives and that I
couldn't reimplement in order to risk it. In my last company no LGPL
library ever made that cut.


On 14 November 2013 16:46, John Gabriele jmg3...@gmail.com wrote:

 On Wednesday, November 13, 2013 6:06:02 PM UTC-5, Colin Fleming wrote:

   I don't see why a company would have any problem at all with *using*
   LGPL'd software, even in a product. However, I can see the possible
   complaints if they wanted to *modify* it and then distribute their
 modified
   version (since that would then require distributing the modified source
   along with it).

 At least one company (mine at the time) had a problem with using LGPL
 software because of the clause where you explicitly allow reverse
 engineering of your product in order to use a different version of the LGPL
 library. {snip}


 For what it's worth, I find that passage of the LGPL (4. Combined Works)
 somewhat difficult to understand. It *seems* to me that it's saying:
 although your combined work may be non-free,

   * you can't restrict modification of the LGPL library contained therein,
 and
   * you can't restrict users from reverse engineering any modifications
 you've made to the LGPL library contained therein.

 Where that 2nd point seems redundant to me, since, if you're distributing
 a modified version of an LGPL'd lib, you're already required to also
 distribute the modified source of it as well.

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


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

Re: Step by step debugging

2013-11-13 Thread Daniel

I would imagine that cinc could side-step any jvm-imposed limitations on 
developing a reference debugger for 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/groups/opt_out.

Re: Do web apps need Clojure?