Re: [Off-Topic] Does Clojure have relations with this site?

[David Della Costa]

Wow, looks like pretty brazen theft of the Clojure logo.

This company appears to be based in Singapore, but targeting Japanese folks
interested in Chinese-language learning.

http://www.chinese-semi.com/about.php





2017-03-24 10:40 GMT-04:00 Nobuyuki Inaba :

> Hi,
>
> I had just found a site  ( http://www.chinese-semi.com/optin/ ) today.
> This site is Chinese free mail magazine site.
> The site seems to use Clojure logo. Does Clojure have relations with the
> site?
>
> Please let me know if anyone knows about it.
>
> Best regards,
> Nobuyuki Inaba
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: flowchart for choosing the right Clojure parallel primitives?

[David Della Costa]

Just realized that Leon linked to the slides in a comment on the youtube
video itself: http://leon.barrettnexus.com/clojure-west-2015/

2016-03-29 15:52 GMT-04:00 David Della Costa <ddellaco...@gmail.com>:

> Hi Sergey, I don't have a direct answer for you but this talk at
> Clojure/West 2015 by Leon Barrett went over the various options for
> parallelism in Clojure, and I found it pretty educational myself:
>
>
> https://www.youtube.com/watch?v=BzKjIk0vgzE=PLZdCLR02grLrKAOj8FJ1GGmNM5l7Okz0a=2
>
> Hope that is useful!
>
> DD
>
>
> 2016-03-29 9:56 GMT-04:00 Sergey Didenko <sergey.dide...@gmail.com>:
>
>> Hi,
>>
>> Is there a flowchart for choosing the right Clojure parallel primitives?
>>
>> So that you can decide when to just use reducers/fork and when to choose
>> core.async and etc.
>>
>> For example like the flowchart for data types from Chas Emerick -
>> http://cemerick.com/2011/07/05/flowchart-for-choosing-the-right-clojure-type-definition-form/
>>
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

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

Re: flowchart for choosing the right Clojure parallel primitives?

[David Della Costa]

Hi Sergey, I don't have a direct answer for you but this talk at
Clojure/West 2015 by Leon Barrett went over the various options for
parallelism in Clojure, and I found it pretty educational myself:

https://www.youtube.com/watch?v=BzKjIk0vgzE=PLZdCLR02grLrKAOj8FJ1GGmNM5l7Okz0a=2

Hope that is useful!

DD


2016-03-29 9:56 GMT-04:00 Sergey Didenko :

> Hi,
>
> Is there a flowchart for choosing the right Clojure parallel primitives?
>
> So that you can decide when to just use reducers/fork and when to choose
> core.async and etc.
>
> For example like the flowchart for data types from Chas Emerick -
> http://cemerick.com/2011/07/05/flowchart-for-choosing-the-right-clojure-type-definition-form/
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Is there a clojure equivalent of ghc-mod? If not, what are the challenges?

[David Della Costa]

Are you looking for something like CIDER,

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

or maybe fireplace?

https://github.com/tpope/vim-fireplace

Think both those projects' READMEs describe current gotchas/bugs/etc.


2016-02-26 21:45 GMT-05:00 Sam DeSota :

>
> I'm getting to know Clojure and lisps in general and am having a great
> time. I've worked with Haskell before, and using ghc-mod with various tools
> was massively useful. Is there a similar tool for Clojure, and what are the
> challenges if not?
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: what do you think about this code?

[David Della Costa]

Philip, one clarification--re: function with side-effects, I meant to link
here, which I followed up with in a later post, but I think it got lost in
the shuffle:

https://github.com/philipschwarz/diamond-problem-in-clojure/blob/7efbc472632dced5e173084672ad76687e39dd1f/src/diamond_problem_in_clojure/core.clj#L68-L74

The function print-diamond is both generating the diamond data structure
(which is just a series of pure functions) but then at the end it prints
out the diamond via display--this is a side effect.  The function itself
returns nil.

So my point was that I would prefer a separate pure function to handle
generating the entire diamond, which would return that data structure at
the end.  Then I could use this in conjunction with a side-effecting
function to print, to save to a file, etc.

Dave


2014-12-13 13:40 GMT+09:00 Philip Schwarz 
philip.johann.schw...@googlemail.com:

 HI David,


 - you're grouping your side-effecting code w/the code that generates the
 diamond data structure here: https://gist.github.com/ddellacosta/
 ba7e03951ba1bafd3ec9
 While of course the diamond kata is a bit contrived and the point is to
 print stuff out in the end, it also looks like you are trying to be
 thoughtful about how you structure your code.  So I would suggest isolating
 your pure functions from your side-effecting code as a sort of basic
 separation, and avoid monolithic functions like the one I linked to above.
 This gives you the freedom to apply the data structure to other processes
 if need be, rather than having to refactor that code later on as soon as
 you need to do something other than printing to the final diamond data
 structure.  That is a more compositional approach that is good to follow as
 part of functional programming practice in general.  And otherwise it seems
 like you are following this approach--I think you can see this in the shape
 of your code overall.


 Makes perfect sense: isolating your pure functions from your
 side-effecting code as a sort of basic separation
 What do you mean by this: , and avoid monolithic functions like the one I
 linked to above. . I ask because I think there are no side effects in my
 code. Maybe I don't understand because it is 4.30 am and I am not fully
 awake, or maybe you intend a different meaning for side effect.

 Philip


 On Saturday, 6 December 2014 13:36:47 UTC, David Della Costa wrote:

 Hi Philip,

 I read your message and immediately wanted to try it myself--I intended
 to leave it at that but I realized I would be remiss if I did not give you
 a little bit of feedback based on my experience.  I should add that I was
 kind of fast and loose with my solution (that is, I didn't really read the
 instructions), but it does print out the diamond shape according to what I
 saw in the blog post examples.

 First of all, here's what I came up with:

 https://gist.github.com/ddellacosta/ba7e03951ba1bafd3ec9

 As you said, you weren't looking for alternative algorithms and I
 recognize that that's not the point.  But there are a few things that I
 think are good and/or common Clojure practice that I think I've
 internalized, and writing out an alternative solution helped me to see them.

 - I'm assuming you used a TDD process to write this (correct me if
 wrong--basing that on the articles you linked to), but I think a
 repl-driven process may be more common for working through a problem like
 this--i.e. something you can wrap your head around as a whole and solve
 iteratively.  That's not to say I and others don't use TDD in Clojure dev,
 but just that it's also quite common to do a lot of this kind of
 development in the repl.

 - you're grouping your side-effecting code w/the code that generates the
 diamond data structure here: https://gist.github.com/ddellacosta/
 ba7e03951ba1bafd3ec9

 While of course the diamond kata is a bit contrived and the point is to
 print stuff out in the end, it also looks like you are trying to be
 thoughtful about how you structure your code.  So I would suggest isolating
 your pure functions from your side-effecting code as a sort of basic
 separation, and avoid monolithic functions like the one I linked to above.
 This gives you the freedom to apply the data structure to other processes
 if need be, rather than having to refactor that code later on as soon as
 you need to do something other than printing to the final diamond data
 structure.  That is a more compositional approach that is good to follow as
 part of functional programming practice in general.  And otherwise it seems
 like you are following this approach--I think you can see this in the shape
 of your code overall.

 - Stylistically, I found your naming conventions to be too verbose, with
 not enough information about the actual input and output--I would prefer a
 style like I used in my solution which aims for readable conciseness, while
 documenting what is going in and coming out of my functions.  I assume
 Clojure developers reading my code

Re: what do you think about this code?

[David Della Costa]

I think reasonable people can disagree on the details here--I think the
names I chose were good enough and would be understood by Clojure
programmers familiar with the standard data structures and core functions.
I should point out that some of these names are conventional in Clojure
land, for example idx: https://clojuredocs.org/clojure.core/map-indexed,
https://clojuredocs.org/clojure.core/amap, etc.

DD

2014-12-13 15:00 GMT+09:00 Philip Schwarz 
philip.johann.schw...@googlemail.com:

 Hi David,


 a style like I used in my solution which aims for readable conciseness


 When I first looked at your code, just quickly scanning it, I felt that it
 was nice and concise, but I find parameter names like 'len' and 'idx' terse
 rather than concise.

 In Venkat Subramaniam's words (in Functional Programming in Java
 https://pragprog.com/book/vsjava8/functional-programming-in-java)

 *Does concise just mean less code?*
 Concise is short, devoid of noise, and boiled down to its essence to
 convey the intent effectively. The benefits are far reaching.
 Writing code is like throwing ingredients together; making it concise is
 like turning that into a sauce. It often takes more effort to write concise
 code. It’s less code to read, but effective code is transparent. A short
 code listing that’s hard to understand or hides details is terse rather
 than concise.


 I think 'len' and 'idx' are terse (fewer characters), but not concise.
 Every time I read them I can't help translating them into 'length' and
 'index'. This is annoying, especially with 'idx' (with 'len' it is not too
 bad). This translation process is somewhat similar to what Robert Martin
 calls mental mapping (in Clean Code
 http://www.amazon.co.uk/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882
 ):


 *Avoid Mental Mapping*Readers shouldn't have to mentally translate your
 names into other names they already know...


 Philip

 On Saturday, 6 December 2014 13:36:47 UTC, David Della Costa wrote:

 Hi Philip,

 I read your message and immediately wanted to try it myself--I intended
 to leave it at that but I realized I would be remiss if I did not give you
 a little bit of feedback based on my experience.  I should add that I was
 kind of fast and loose with my solution (that is, I didn't really read the
 instructions), but it does print out the diamond shape according to what I
 saw in the blog post examples.

 First of all, here's what I came up with:

 https://gist.github.com/ddellacosta/ba7e03951ba1bafd3ec9

 As you said, you weren't looking for alternative algorithms and I
 recognize that that's not the point.  But there are a few things that I
 think are good and/or common Clojure practice that I think I've
 internalized, and writing out an alternative solution helped me to see them.

 - I'm assuming you used a TDD process to write this (correct me if
 wrong--basing that on the articles you linked to), but I think a
 repl-driven process may be more common for working through a problem like
 this--i.e. something you can wrap your head around as a whole and solve
 iteratively.  That's not to say I and others don't use TDD in Clojure dev,
 but just that it's also quite common to do a lot of this kind of
 development in the repl.

 - you're grouping your side-effecting code w/the code that generates the
 diamond data structure here: https://gist.github.com/ddellacosta/
 ba7e03951ba1bafd3ec9

 While of course the diamond kata is a bit contrived and the point is to
 print stuff out in the end, it also looks like you are trying to be
 thoughtful about how you structure your code.  So I would suggest isolating
 your pure functions from your side-effecting code as a sort of basic
 separation, and avoid monolithic functions like the one I linked to above.
 This gives you the freedom to apply the data structure to other processes
 if need be, rather than having to refactor that code later on as soon as
 you need to do something other than printing to the final diamond data
 structure.  That is a more compositional approach that is good to follow as
 part of functional programming practice in general.  And otherwise it seems
 like you are following this approach--I think you can see this in the shape
 of your code overall.

 - Stylistically, I found your naming conventions to be too verbose, with
 not enough information about the actual input and output--I would prefer a
 style like I used in my solution which aims for readable conciseness, while
 documenting what is going in and coming out of my functions.  I assume
 Clojure developers reading my code will have a good understanding of the
 core data structures and functions available to manipulate them, and so I
 want to leverage that as much as possible in how I write and document my
 code.

 In fact, at this point I prefer using Prismatic's schema (
 https://github.com/Prismatic/schema) to document as well as provide
 further safety for my functions, and am of the opinion that Clojure's one

Re: what do you think about this code?

[David Della Costa]

Hi Philip,

I read your message and immediately wanted to try it myself--I intended to
leave it at that but I realized I would be remiss if I did not give you a
little bit of feedback based on my experience.  I should add that I was
kind of fast and loose with my solution (that is, I didn't really read the
instructions), but it does print out the diamond shape according to what I
saw in the blog post examples.

First of all, here's what I came up with:

https://gist.github.com/ddellacosta/ba7e03951ba1bafd3ec9

As you said, you weren't looking for alternative algorithms and I recognize
that that's not the point.  But there are a few things that I think are
good and/or common Clojure practice that I think I've internalized, and
writing out an alternative solution helped me to see them.

- I'm assuming you used a TDD process to write this (correct me if
wrong--basing that on the articles you linked to), but I think a
repl-driven process may be more common for working through a problem like
this--i.e. something you can wrap your head around as a whole and solve
iteratively.  That's not to say I and others don't use TDD in Clojure dev,
but just that it's also quite common to do a lot of this kind of
development in the repl.

- you're grouping your side-effecting code w/the code that generates the
diamond data structure here:
https://gist.github.com/ddellacosta/ba7e03951ba1bafd3ec9

While of course the diamond kata is a bit contrived and the point is to
print stuff out in the end, it also looks like you are trying to be
thoughtful about how you structure your code.  So I would suggest isolating
your pure functions from your side-effecting code as a sort of basic
separation, and avoid monolithic functions like the one I linked to above.
This gives you the freedom to apply the data structure to other processes
if need be, rather than having to refactor that code later on as soon as
you need to do something other than printing to the final diamond data
structure.  That is a more compositional approach that is good to follow as
part of functional programming practice in general.  And otherwise it seems
like you are following this approach--I think you can see this in the shape
of your code overall.

- Stylistically, I found your naming conventions to be too verbose, with
not enough information about the actual input and output--I would prefer a
style like I used in my solution which aims for readable conciseness, while
documenting what is going in and coming out of my functions.  I assume
Clojure developers reading my code will have a good understanding of the
core data structures and functions available to manipulate them, and so I
want to leverage that as much as possible in how I write and document my
code.

In fact, at this point I prefer using Prismatic's schema (
https://github.com/Prismatic/schema) to document as well as provide further
safety for my functions, and am of the opinion that Clojure's one glaring
weakness is its approach to typing--but that's another discussion and I
recognize this is not necessarily a widely-held opinion.

More generally, I think reasonable people could disagree on naming
conventions and so I would hesitate to say you're doing something wrong
here--I would rather say: the more Clojure code you read the more you'll
get a sense of how people tend to write.  You'll figure out what you want
to adopt in your own style, and what Clojure devs are going to expect.

- I don't want to get too deep into the algorithm itself but I think you
would find it more natural to work line by line vs. the way you constructed
blocks and flipped them right/left, and you'd have less code overall.  I
will boldly claim that my solution may be closer to how other developers
familiar with Clojure (or functional programming in general) may approach
it--not that I'm claiming it's the best approach.  I do think it is more
concise without sacrificing readability (which is subjective, I fully
appreciate).

- I don't know if I've ever once used a main function, and you don't see
them in libraries, certainly.  But that is minor--there's no reason *not*
to use it, just that I wouldn't expect to see it.

I hope this is useful feedback--good luck in your journey and enjoy Clojure!

Dave


2014-12-06 19:48 GMT+09:00 Philip Schwarz 
philip.johann.schw...@googlemail.com:

 Hello,

 can you please review my first solution to the diamond kata [1] and tear
 it to bits: let me know all the ways in which YOU would improve the code.

 I am not so interested in a better algorithm for solving the kata. I am
 learning Clojure and what I want to know is what YOU would do to make the
 code more readable/understandable/maintainable, or just to make it follow
 Clojure idioms and/or conventions that YOU find effective, or to follow a
 coding style that YOU find more effective.

 Thanks,

 Philip

 [1] https://github.com/philipschwarz/diamond-problem-in-clojure

 --
 You received this message because you are subscribed to the Google
 

Re: what do you think about this code?

[David Della Costa]

Whoops, re-reading my post I realized that I simply linked to my own gist
again when talking about separating out pure from side-effecting code.  I
meant to link here:
https://github.com/philipschwarz/diamond-problem-in-clojure/blob/7efbc472632dced5e173084672ad76687e39dd1f/src/diamond_problem_in_clojure/core.clj#L68-L74

2014-12-06 22:36 GMT+09:00 David Della Costa ddellaco...@gmail.com:

 Hi Philip,

 I read your message and immediately wanted to try it myself--I intended to
 leave it at that but I realized I would be remiss if I did not give you a
 little bit of feedback based on my experience.  I should add that I was
 kind of fast and loose with my solution (that is, I didn't really read the
 instructions), but it does print out the diamond shape according to what I
 saw in the blog post examples.

 First of all, here's what I came up with:

 https://gist.github.com/ddellacosta/ba7e03951ba1bafd3ec9

 As you said, you weren't looking for alternative algorithms and I
 recognize that that's not the point.  But there are a few things that I
 think are good and/or common Clojure practice that I think I've
 internalized, and writing out an alternative solution helped me to see them.

 - I'm assuming you used a TDD process to write this (correct me if
 wrong--basing that on the articles you linked to), but I think a
 repl-driven process may be more common for working through a problem like
 this--i.e. something you can wrap your head around as a whole and solve
 iteratively.  That's not to say I and others don't use TDD in Clojure dev,
 but just that it's also quite common to do a lot of this kind of
 development in the repl.

 - you're grouping your side-effecting code w/the code that generates the
 diamond data structure here:
 https://gist.github.com/ddellacosta/ba7e03951ba1bafd3ec9

 While of course the diamond kata is a bit contrived and the point is to
 print stuff out in the end, it also looks like you are trying to be
 thoughtful about how you structure your code.  So I would suggest isolating
 your pure functions from your side-effecting code as a sort of basic
 separation, and avoid monolithic functions like the one I linked to above.
 This gives you the freedom to apply the data structure to other processes
 if need be, rather than having to refactor that code later on as soon as
 you need to do something other than printing to the final diamond data
 structure.  That is a more compositional approach that is good to follow as
 part of functional programming practice in general.  And otherwise it seems
 like you are following this approach--I think you can see this in the shape
 of your code overall.

 - Stylistically, I found your naming conventions to be too verbose, with
 not enough information about the actual input and output--I would prefer a
 style like I used in my solution which aims for readable conciseness, while
 documenting what is going in and coming out of my functions.  I assume
 Clojure developers reading my code will have a good understanding of the
 core data structures and functions available to manipulate them, and so I
 want to leverage that as much as possible in how I write and document my
 code.

 In fact, at this point I prefer using Prismatic's schema (
 https://github.com/Prismatic/schema) to document as well as provide
 further safety for my functions, and am of the opinion that Clojure's one
 glaring weakness is its approach to typing--but that's another discussion
 and I recognize this is not necessarily a widely-held opinion.

 More generally, I think reasonable people could disagree on naming
 conventions and so I would hesitate to say you're doing something wrong
 here--I would rather say: the more Clojure code you read the more you'll
 get a sense of how people tend to write.  You'll figure out what you want
 to adopt in your own style, and what Clojure devs are going to expect.

 - I don't want to get too deep into the algorithm itself but I think you
 would find it more natural to work line by line vs. the way you constructed
 blocks and flipped them right/left, and you'd have less code overall.  I
 will boldly claim that my solution may be closer to how other developers
 familiar with Clojure (or functional programming in general) may approach
 it--not that I'm claiming it's the best approach.  I do think it is more
 concise without sacrificing readability (which is subjective, I fully
 appreciate).

 - I don't know if I've ever once used a main function, and you don't see
 them in libraries, certainly.  But that is minor--there's no reason *not*
 to use it, just that I wouldn't expect to see it.

 I hope this is useful feedback--good luck in your journey and enjoy
 Clojure!

 Dave


 2014-12-06 19:48 GMT+09:00 Philip Schwarz 
 philip.johann.schw...@googlemail.com:

 Hello,

 can you please review my first solution to the diamond kata [1] and tear
 it to bits: let me know all the ways in which YOU would improve the code.

 I am not so interested in a better

Re: Setting content type in a resouce response

[David Della Costa]

Hi Josh, you should post Ring-related questions here:

https://groups.google.com/forum/?fromgroups#!forum/ring-clojure

To answer your question, it's hard to say without seeing your code.  In
fact, I'm having a hard time reproducing the problem without explicitly
telling ring to serve an HTML file as text/plain--it's showing up as
text/html without me explicitly setting it.

Also, did you mean ring.util.response (
http://ring-clojure.github.io/ring/ring.util.response.html) rather than
ring.util.resource (which doesn't exist as far as I know)?

For a very vanilla example which explicitly sets Content-Type, take a look
at this.  Let's say we had a plain file-response (note again that this is
giving me text/html, but anyways...):


(defn handler [request]
 (resource-response index.html {:root public}))

If we wanted to explicitly set it as text/html, we could wrap it using the
content-type function:

(defn handler [request]
  (-
   (resource-response index.html {:root public})
   (content-type text/html)))

Of course, this is the most basic method--there are smarter ways to do it.
 Check out the Ring wiki for more, especially the section on creating
responses (https://github.com/ring-clojure/ring/wiki/Creating-responses),
static resources (https://github.com/ring-clojure/ring/wiki/Static-Resources)
and Content Types (https://github.com/ring-clojure/ring/wiki/Content-Types).

And again, I would suggest using the Ring list for these questions.

Hope this helps!

Best,
Dave

2013/4/19 Josh Kamau joshnet2...@gmail.com

 Hi there ;

 Please help. How do i set the ContentType header in a
 (ring.util.resouce/resource-response ) ?

 I am serving html file and its being served as plain text.

 Josh

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

[David Della Costa]

Ah, my mistake, apologies for adding noise.  In that case, not sure what to
say...I'll let someone with better knowledge of Clojure internals respond.

2013/4/15 Marko Topolnik marko.topol...@gmail.com

 On Monday, April 15, 2013 2:50:11 AM UTC+2, David Della Costa wrote:

 If you give keyword two arguments the first one is the namespace, and
 you are generating a namespaced keyword.  To expand on your example:

 clojure.core= (in-ns 'm)
 #Namespace m
 m= (clojure.core/keyword m 7)
 :m/7
 m= {::7 foo}
 {:m/7 foo}
 m=


 OP's point here is that *:m/7* produces an error, whereas e.g. *:m/a* or *
 ::7 *doesn't.

 -marko

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

A tutorial on basic Shoreleave usage

[David Della Costa]

Hi folks, after having trouble figuring out how Shoreleave works and what
exactly you can do with it, I wrote a very simple tutorial/example app for
using it:

https://github.com/ddellacosta/barebones-shoreleave

I try to answer the question what do I need in my app to get Shoreleave up
and running.  It borrows heavily from shoreleave-baseline (
https://github.com/shoreleave/shoreleave-baseline), but attempts to be even
more simple and straightforward and of course provide more substantial
documentation.  It represents a very simple use-case, and correspondingly
doesn't use shoreleave-pubsub, shoreleave-services or shoreleave-worker
(I'll get to those next...).

Comments/criticisms/pull-requests welcome!

Cheers,
Dave

-- 
-- 
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 tutorial on basic Shoreleave usage

[David Della Costa]

Thanks Julio!  I'm very happy to hear that.  Let me know if you find any
typos or whatnot, or have any other comments on how it could be improved.

Cheers,
Dave

2013/4/13 Julio Barros ju...@e-string.com

 Dave,

 Wanted to say I enjoyed your cemerick/friend tutorial and am looking
 forward to reading this one.

 Thanks for your efforts.

 Julio

 ju...@e-string.com

 On Apr 12, 2013, at 12:53 AM, David Della Costa ddellaco...@gmail.com
 wrote:

 Hi folks, after having trouble figuring out how Shoreleave works and what
 exactly you can do with it, I wrote a very simple tutorial/example app for
 using it:

 https://github.com/ddellacosta/barebones-shoreleave

 I try to answer the question what do I need in my app to get Shoreleave
 up and running.  It borrows heavily from shoreleave-baseline (
 https://github.com/shoreleave/shoreleave-baseline), but attempts to be
 even more simple and straightforward and of course provide more substantial
 documentation.  It represents a very simple use-case, and correspondingly
 doesn't use shoreleave-pubsub, shoreleave-services or shoreleave-worker
 (I'll get to those next...).

 Comments/criticisms/pull-requests welcome!

 Cheers,
 Dave


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




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




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

Re: Some Friend documentation and regarding documentation in general

[David Della Costa]

Patrik, Pierre, have you folks checked out the mock app that Chas
created in the test directory?  It's not going to give you everything
you're looking for but make it can help.  There is an implementation
of the OpenID workflow in there, including a credential-fn example:

https://github.com/cemerick/friend/blob/master/test/test_friend/mock_app.clj

This may also help, regarding credential functions:

https://github.com/cemerick/friend/blob/master/test/test_friend/credentials.clj

I also highly recommend looking at the bcrypt-credential-fn in the
credentials.clj lib, in the src of the project itself:

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

This is the default credentials function used in the mock app above,
so it should help illustrate some of the concepts.  I've spent a lot
of time poring over the code too, so feel free to ping me with
questions too, I may be able to help.

 IMHO the doc is really lacking and I have to say I was expecting more
 guidance in the code itself.

Yes, it's still hard to wrap your head around the docs.  Friend
scratches an itch I have, and I think it's going to be rather
important if people are trying to web apps quickly in Clojure, so I'm
going to keep working on it and see how much I can clean things up and
make concepts more clear.  And I know Chas is interested in this as
well, from his past comments.  Any help and pull requests are welcome.
;-)

I'm working on some updates to everything I've been working on, I'll
post updates to the list shortly (later this week probably, maybe even
today).

DD

2012/10/24 Pierre R p.radermec...@gmail.com:
 Thanks David for the extra doc.

 I have had a try with OpenID. Everything works kind of expected.

 I had a question about 302 redirection prior to authentication that I
 posted on github.

 Another question is how to link the concept of roles with the openid
 credentials.

 IMHO the doc is really lacking and I have to say I was expecting more
 guidance in the code itself.

 I guess a lot of stuff obvious to an experienced clojure developers are
 still dark magic to me.

 In particular it is rather difficult to understand how to write a
 crendential-fn and this link won't help you ;-)
 https://github.com/cemerick/friend/blob/master/docs/credentials.md

 For OpenId I have blindly used the identity function without much
 understanding ...

 I am using Friend to scratch a little auth server. Not sure it is the best
 fit for that purpose. I will see.

 I hope Friend is going to be reviewed by an extended community of people
 much more qualified than myself to talk about such matter.

 Still docs could be improved and I believe helps could come from pull
 requests to suggest the addition of code comments there and there.

 If I dig far enough in the code, I would be pleased to help.

 Thanks for the hard work.

 Cheers,

 Le mardi 23 octobre 2012 17:50:25 UTC+2, Patrik Sundberg a écrit :

 These are great tutorials. Thanks for publishing.

 Right now I'm looking for something similar using the OpenID workflow. I
 see it's there but how I use to for example create a sign in with google
 setup is less clear to me.

 Has anyone got a good OpenID example out there somewhere?

 On Saturday, October 6, 2012 4:50:05 PM UTC+1, David Della Costa wrote:

 Hi folks,

 I've been pretty slack in communicating via the mailing list, but I
 realized today that there is a lot of important dialogue going on here
 so I have to make more of an effort to take part--I want to be a part of
 this community!

 In any case, I've been using Friend a lot lately, since I come from
 Ruby-on-Rails-land, and it addresses a lot of the pain points that
 Devise does for me.

 But (as has been mentioned in other threads quite recently),
 documentation is definitely the Clojure community's week point: it's
 inconsistent, formatted inconsistently (Ring and Compojure, for example,
 are wonderful exceptions), and updated erratically.  When it's good,
 it's great; but when it's not, it puts me off from using a library.  For
 example, I stayed away from Enlive for months before I realized what a
 useful library it is--so I re-wrote the README to suit my tastes
 (https://github.com/ddellacosta/enlive).

 I think Chas Emerick writes much better docs than much of what
 accompanies most Clojure libraries, but he's quite an advanced Clojure
 developer, and he's moving very fast--so as a newbie, I had difficulty
 even with his relatively good docs for Friend.  And I suspect you'll be
 getting more and more folks from the web development world in the next
 few years like me.  So it will be good to have things from the
 perspective of someone not just trying to grok the libraries that exist,
 but also trying to understand how Clojure works, and how the eco-system
 fits together.

 I've written some material on how to use Friend, including some OAuth2
 resources.  I'd appreciate any feedback you can give, I'm pretty new to
 Clojure (and Lisp

Re: deployment

[David Della Costa]

Hi George,

It's been a few months since I was researching it but I did a similar
investigation.  I'm a web developer, with a bit (but not significant)
Java experience, but mostly coming from the Ruby/Python world.  So I
think we are probably coming from similar places.

What I ended up feeling like was, these are the options more or less:

1) Some kind of hosting which provides out-of-the-box Clojure
support, more or less.  I actually tried Heroku; it was was super easy
to get up and running, and very nice to work with (at least, for the
trivially simple app I set up).  I didn't try AWS but I can't imagine
it'd be that much more difficult.

2) Some people were using the strategy of keeping a REPL running
constantly and running jetty via ring:
https://github.com/ring-clojure/ring/wiki/Interactive-Development

3) Then there is setting up Jetty or Tomcat, buildling a WAR and
running your app that way.

( 4, sort-of...  * libraries like appengine-magic for hosting on GAE

GAE seems to have so many conditions to getting it set up, compared to
Heroku, say, that I didn't even begin to attempt it.  Also having used
GAE for some production sites lately, I'm not super psyched about it,
but YMMV.)

I'm leaving out some ways of approaching this but it kind of sums up
the general strategies for web apps, to the best of my knowledge.

#1 is ideal if you've got some money to throw at it.

#2 to me is crazy, but I'm thinking about things in terms of actually
deploying real web applications with a team of people.

so that leaves #3.  It seems to be the most flexible and cheapest
option, while still being stable.  It has the (perhaps major)
disadvantage of forcing you to run your own version of Tomcat/Jetty
and therefore have a setup where you can host that kind of thing.

I wrote a tutorial explaining my approach, which also has some links
to other approaches, maybe it'll be helpful to you. (I'd also love to
hear any feedback you have about things that are missing or incorrect
or outdated.)

https://github.com/ddellacosta/Clojure-under-Jetty-and-Apache

Cheers,
Dave

2012/8/18 George Oliver georgeolive...@gmail.com:
 hi,

 I'm a Clojure beginner working on a web project and starting to think about
 deployment. Currently I host my project in a local VM and have a small VPS
 for public testing. Looking down the road I'd like a more flexible hosting
 solution.

 It seems like the hosting landscape is changing fast so I'd like to know --
 how do you deploy your projects 'now'?

 So far I've found stuff like:

 * A continuum of Clojure support from cloud providers, with some free tiers
 at AWS, Heroku, Openshift, etc.
 * tools like lein-beanstalk for hosting apps on Elastic Beanstalk
 * libraries like appengine-magic for hosting on GAE
 * libraries like pallet for abstracting deployment to multiple cloud
 providers
 * many more tools depending on how much 'more Java' you're willing to
 incorporate into your project, for example deploying a WAR in a Tomcat
 container (not even sure I have the lingo right there! :) )
 * combining these tools and libraries with CI tools such as Jenkins for a
 complete automatic develop - build - deploy solution.

 From what I've seen, and given that (a) I have a small project (probably not
 more than 5k users eventually) and (b) I'm not a professional programmer,
 but (c) I'd like to manage this in a professional way, it seems like a
 strategy could be:

 1. use a tool like lein-beanstalk for public deployment and use simple
 scripts for building
 2. in the meantime get familiar with pallet for more flexibility in the
 future
 3. eventually deploy using pallet
 4. at this point learn a CI tool to fully automate the process.

 What do you think?


 thanks, George

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

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

Re: A tutorial for how to setup your clojure development environment for: Emacs, Leiningen and Linux.

[David Della Costa]

Just saw this thread.  I went through something similar recently: I'm
a long-time emacs user just getting into Clojure, so naturally I set
it up with emacs.  I set it up with Leiningen (a 2.0.0 preview
version), and while I found it relatively painless, I did have a few
problems mostly with Emacs.  I think the stuff about getting
sidetracked with emacs configuration/package-management is pretty
true; it's very easy to get lost in the emacs wilderness, which is
much hoarier than Clojure.

I also think that, at present, while coming in through Leiningen is
definitely the most painless way to do things (I'm really loving it
actually, as a Ruby dev it kind of seems like rvm + bundler + rake all
wrapped up in one handy package), trying to navigate whether to use
1.x or 2.x preview is a bit confusing--and the variety of docs
available for setting things up is confusing.  Similarly, it's easy to
get lost (as a beginner) between namespace issues with packages and
how to set things up properly with Leiningen.  It'd be good to have
some documentation on that.

Getting testing up and running with midje was also a bit of a
challenge--I still haven't figured out how to get automated testing
going smoothly in emacs with the nice midje stuff Mr. Marick has
added, but I'll go back and tackle that some day.  At the least, I
finally got testing working via lein.

And at the danger of digressing wildly, as a beginner namespace and
file loading stuff is really hard to wrap my head around, but that
could be my own particular weakness.

All of that said, maybe I'll take a look at the docs and see if I can
add anything constructive, since I've set it up now a few times on
Macs.

In any case, I'm really loving playing with Clojure.  I hope to start
sneaking it into some real applications at work this year, and infect
some other devs with the Clojure bug...

Cheers,
Dave D.

2012/6/14 Sean Corfield seancorfi...@gmail.com:
 On Wed, Jun 13, 2012 at 6:27 PM, fenton fenton.trav...@gmail.com wrote:
 I totally understand the value of having a single source of truth (DRY
 principle).  My main problem was that to get from 0-60 for doing clojure
 development is quite challenging.

 Which is why the official documentations needs contributions from
 folks who've gone thru this process recently... It's a bit of a
 chicken and egg situation: if the current docs aren't good enough,
 folks go off into the Internet wilderness and try to piece together
 the experience themselves. And then what they go thru often doesn't
 even come close to what _should_ be in the official documentation as
 the simplest solution. And of course we each typically only set up one
 machine (our own) so we don't have much incentive to repeat the
 process over and over to refine it for the official documentation. I
 sympathize with the process you've gone thru. I went thru it too. I
 created this document for Emacs + Leiningen on Windows -
 http://corfield.org/articles/emacs_win.html - and I have not
 publicized it because it's already out of date. And that was the third
 time I'd been thru the process: first on Mac, then on Ubuntu, then
 Windows XP.

 I had a major piss around trying to get the marmelade repo working.
  Finally, someone suggested emacs 24, which itself is fairly hard to find
 without a link to alpa.

 The kind folks on #clojure on IRC ensured I started with a prerelease
 of Emacs 24 which helped. Emacs 24 is now the current stable version,
 which makes discovery much easier.

 So say I start at: http://marmalade-repo.org/, well then it says: Install
 package.el, it doesn't say how to install package.el, so now I gotta google

 Yup, that was my initial complaint.

 I still don't know if I
 need both clojure and clojure-contrib in my project.clj files or not.  They
 are different versions, should they be in sync?

 Monolithic Clojure Contrib was deprecated when Clojure 1.3 appeared
 and is no longer maintained. See
 http://dev.clojure.org/display/design/Where+Did+Clojure.Contrib+Go

 I did find myself getting a bit angry writing this, because I'd really like
 to see clojure displace java, but I think its fair to say that there is a
 gap in helping people who have little
 emacs/clojure/leiningen/swank/slime/cdt/lisp exposure getting on board.

 Yup. This complaint is very valid and comes up fairly regularly, and
 each time the official documentation gets a bit better (but it still
 has a long way to go).

 I think github is a better place to document this stuff than confluence.

 The Clojure project uses JIRA / Confluence for issue tracking and
 documentation - and Github for code. Pull requests are not allowed.
 See http://clojure.org/contributing and http://clojure.org/patches -
 also see 
 http://dev.clojure.org/display/doc/Guidelines+for+Clojure+Contrib+committers
 for the mechanics of getting onboard as a contributor and getting your
 accounts / permissions set up.

 We definitely need improvements in the official getting started
 documentation. 

Re: Broken Sequences screencast

[David Della Costa]

Hey folks, I see that this was never answered, but it remains a problem. 
 I've tried viewing the video on blip 
(http://blip.tv/clojure/clojure-sequences-740581) as well as downloading 
via iTunes, but no dice--I get about 8 seconds of Rich introducing the 
topic and then nothing.

I'd love to see this video, so if anyone has a copy or can point me to a 
working resource I'd be most appreciative--thank you!

Best,
Dave

2011年9月1日木曜日 17時46分11秒 UTC+9 Irakli Gozalishvili:

 Hi,

 Not sure if this right place to report about this, but I could not thing 
 of any better. I'm in a process of learning Clojure and I found 
 screen-casts linked from clojure.org http://blip.tv/clojure very useful. 
 Unfortunately thought [Clojure Sequences](
 http://blip.tv/clojure/clojure-sequences-740581) video is broken it plays 
 7secs and stops. Would be great if anyone could fixed that!

 Regards


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

Re: Broken Sequences screencast

[David Della Costa]

Kevin, thanks very much!  When I went to load that in a browser, I got
the message This video is only available in the Blip player... but I
was successfully able to download the video via curl.

You're right, there's a buzzing sound throughout, unfortunately...ah well.

Thanks again--

Dave

2012/6/14 Kevin Ilchmann Jørgensen kijm...@gmail.com:
 From the rss.
 http://blip.tv/file/get/Richhickey-ClojureSequences284.mov

 The sound dont get any better thru.
 /Kevin

 On Thu, Jun 14, 2012 at 4:11 AM, David Della Costa
 ddellaco...@gmail.com wrote:
 Hey folks, I see that this was never answered, but it remains a problem.
  I've tried viewing the video on blip
 (http://blip.tv/clojure/clojure-sequences-740581) as well as downloading via
 iTunes, but no dice--I get about 8 seconds of Rich introducing the topic and
 then nothing.

 I'd love to see this video, so if anyone has a copy or can point me to a
 working resource I'd be most appreciative--thank you!

 Best,
 Dave

 2011年9月1日木曜日 17時46分11秒 UTC+9 Irakli Gozalishvili:

 Hi,

 Not sure if this right place to report about this, but I could not thing
 of any better. I'm in a process of learning Clojure and I found screen-casts
 linked from clojure.org http://blip.tv/clojure very useful. Unfortunately
 thought [Clojure
 Sequences](http://blip.tv/clojure/clojure-sequences-740581) video is broken
 it plays 7secs and stops. Would be great if anyone could fixed that!

 Regards

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

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

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

Re: A tutorial for how to setup your clojure development environment for: Emacs, Leiningen and Linux.

[David Della Costa]

Hey Phil, thanks for the response.

 trying to navigate whether to use
 1.x or 2.x preview is a bit confusing--and the variety of docs
 available for setting things up is confusing.

 Yeah, as of the last release we're pretty much advising everyone to go
 with 2.x, but the docs still need to be updated to reflect that. What
 are some of the confusing docs you mention? Most people have said the
 install process is pretty simple.

To be fair, I probably had problems based on how I am used to using
github rather than any failure of the docs.  The actual process is
simple, you are right.  I was trying to set up 2.0.0 preview but the
docs focus(ed) on the 1.x version, and it wasn't quite clear how that
worked at the time I set it up (a few weeks ago)--the link wasn't
obvious, and when pulling from git I wasn't sure what version I was
getting.  And in any case I see that someone updated the Leiningen
readme on github to promote 2.x first and foremost since last time I
checked: nice. That should help if anyone has confusion similar to
mine, so this is probably moot.

The variety of docs just refers to all the random tutorials out there
if you do a Google search.  Again, not really fair to compare to the
official Leiningen docs, which are pretty helpful.

More generally, I think a certain amount of this is unavoidable; newbs
will always be confused, there will always be a variety of conflicting
third-party tutorials available for any framework, and transitioning
from one major version to the next is always painful.  So I expect
this will smooth out as the community continues to grow and get more
folks coming in.

 Similarly, it's easy to
 get lost (as a beginner) between namespace issues with packages and
 how to set things up properly with Leiningen.  It'd be good to have
 some documentation on that.

 Maybe if the Leiningen tutorial linked to
 http://blog.8thlight.com/colin-jones/2010/12/05/clojure-libs-and-namespaces-require-use-import-and-ns.html?


Warning, digression: you know, I read that, and I still find the
differences between use and require confusing. I have to go back and
re-read it, and practice more. But, for example, I had trouble
figuring out how to include new directories so that midje test files
were picked up in my lein projects, with properly named namespaces.
There is probably a smart and Clojure-esque way to handle all of this.
 But I found it hard to figure out at first, and I think I'm still not
doing it right--I'm using the load-file function, which doesn't really
have anything to do with namespaces.

Again, I apologize, I know that was a digression.  In fact, I like
slogging through things and figuring out the best practices in
somewhat indirect ways, getting that aha moment when something I
read a month ago finally clicks, like I expect Mr. Jones' article to
do at some point.  But I also realize not everyone has that level of
patience...or perhaps more accurately, masochism.

 All of that said, maybe I'll take a look at the docs and see if I can
 add anything constructive, since I've set it up now a few times on
 Macs.

 That would be great; thanks. We could also use some help improving
 http://leiningen.org; it's pretty messy right now.

Cool, I'll see what I can contribute!

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