ANN: print-foo - a library of print debugging macros

[Alex Baranosky]

print-foo is a small library useful when debugging code, or at the REPL
when writing your code.

https://github.com/AlexBaranosky/print-foo

It is a collection of macros that mimic basic clojure macros like defn,
let, or ->, but which prints the value of the code at each point in the
transformation.  This is more convenient than printlning.  (See the readme
for a complete list.)

print-> is especially convenient.

user=> (print-> 1 inc dec inc dec)1 1inc 2dec 1inc 2dec 11


The only macro in the bunch that is not simply a clojure macro with
"print-" appended is print-sexp which takes an arbitrary s-expression and
prints out the values of every sub-sexp, like this:

user=> (print-sexp (str (+ 3 4) (+ 5 (* 6 2)) 4))(+ 3 4) 7(* 6 2) 12(+
5 (* 6 2)) 17(str (+ 3 4) (+ 5 (* 6 2)) 4) "7174""7174"

Enjoy :)
Alex

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

ANN: Lambda Jam - Chicago - July 8-10

[Alex Miller]

Lambda Jam (http://lambdajam.com) is a new conference for functional 
programmers, particularly those working in Clojure, Scala, Erlang, Haskell, 
F#, etc. The conference format is a mix of traditional sessions (morning) 
and hands-on workshops and "jams" in the afternoon.

We have three excellent keynotes:
* Gerald Sussman (MIT) - co-author of Structure and Interpretation of 
Computer Programs and an inventor of Scheme
* Joe Armstrong - an inventor of Erlang and author of Programming Erlang 
Software for a Concurrent World
* David Nolen (NY Times) - Clojure's core.logic and ClojureScript 
development

Other session and workshop speakers (http://lambdajam.com/sessions) 
announced so far include:
* Carin Meier - flying drones with Clojure
* Robby Findler - domain-specific languages with Redex and Racket
* Bartosz Milewski - intro to Haskell
* Dean Wampler - author of Programming Scala and Functional Programming for 
Java Developers
* Brian Marick - author of Functional Programming for the Object-Oriented 
Programmer
* Sam Ritchie - co-author of Big Data, developer at Twitter

Be part of Lambda Jam!
* CFP open till April 5th - http://lambdajam.com/cfp
* Early registration open now for $350 - http://regonline.com/lambdajam2013
* Sponsorship available - http://lambdajam.com/sponsorship

Hope you can make it!
Alex Miller

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

Re: ClojureScript crossovers

[Evan Mezeske]

> Right, but if the crossover namespace for my library is defined in its 
project.clj, and I'm importing that library as a dependency into another 
project, it's sort of redundant to repeat information already specified. I 
guess what I hoped for was that crossover namespaces would automatically be 
inherited from dependencies.

Hmm, carrying over those settings to dependent projects is an interesting 
idea.  Worth more thought.

> When I change ":crossovers [libtest.core]" to ":crossovers [libtest]" and 
compile, I get:
> 
*> WARNING: Unable to find crossover:  libtest*
*> WARNING: Unable to find crossover:  libtest*
> 
> Any ideas why?

Ahh, after looking into this a bit I found the problem.  The recursive 
namespace thing will only work in the original project, not the JAR file -- 
see this comment for the 
explanation: 
https://github.com/emezeske/lein-cljsbuild/blob/master/support/src/cljsbuild/crossover.clj#L46

I think that it might be possible to add support for recursive crossovers 
in JARs... maybe, based on some code I saw in the ClojureScript compiler 
itself that unzips JARs to look inside 
them: 
https://github.com/clojure/clojurescript/blob/master/src/clj/cljs/closure.clj#L115

I'd accept a pull request to make that work (if it's possible), but I don't 
have it on the roadmap of things to work on soon.

Maybe a possible solution to your problems is to just make sure the output 
from the crossovers is included in the first project's JAR file?  E.g. add 
something like :resource-paths ["src/libtest"] to the original project, so 
the *.cljs files will get included in the JAR.  There's probably a good 
reason not to do this (although I'm not sure what it is offhand)... 
 Definitely a bit of a hack.

-- 
-- 
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: Problem installing Pedestal libraries

[Jean Niklas L'orange]

If you upgrade leiningen to 2.1.1 (`lein upgrade 2.1.1`) , it may be that 
the issue will be resolved as if by magic :)

If you still get some issues, report it at 
https://github.com/technomancy/leiningen or join #leiningen on freenode, 
and we should be able to help you out.

-- JN

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

Re: ClojureScript crossovers

[Matthew Hill]

^ To be clear, that's in the project dependent upon the library, where I'm 
trying to use it, not the library itself.

On Thursday, 28 March 2013 02:03:38 UTC, Matthew Hill wrote:
>
> Hi Evan. Thanks for the response.
>
> The ClojureScript compiler looks for *.cljs files to compile as 
>> ClojureScript.  Hence, at a minimum, the *.clj files that you want to also 
>> use from ClojureScript need to be copied (or perhaps symlinked, but that's 
>> not what lein-cljsbuild does) to *.cljs files.
>>
>> A list of namespaces to copy is necessary because not all valid Clojure 
>> code is valid ClojureScript code.  There are some fairly substantial 
>> differences, and trying to interpret certain Clojure forms as ClojureScript 
>> will cause compiler crashes.
>>
>
> Right, but if the crossover namespace for my library is defined in its 
> project.clj, and I'm importing that library as a dependency into another 
> project, it's sort of redundant to repeat information already specified. I 
> guess what I hoped for was that crossover namespaces would automatically be 
> inherited from dependencies.
>
> On Thursday, 28 March 2013 01:48:48 UTC, Evan Mezeske wrote:
>>
>>
>>> [...] This can't scale well if I need to use dozens of namespaces, some 
>>> of which will reference other namespaces and etc.
>>
>>
>> The standard solution here is to just organize all the crossover code 
>> into one namespace.  For instance, if you have mycrossover.foo, 
>> mycrossover.bar, and mycrossover.bar.baz namespaces, you can use them all 
>> with :crossovers [mycrossover].
>>
>
> That would be much better — to just have to specify the "root" namespace 
> of the crossover code — but for me it doesn't work.
>
>  When I change ":crossovers [libtest.core]" to ":crossovers [libtest]" and 
> compile, I get:
>
> *WARNING: Unable to find crossover:  libtest*
> *WARNING: Unable to find crossover:  libtest*
>
> Any ideas why?
>

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

Re: ClojureScript crossovers

[Matthew Hill]

Hi Evan. Thanks for the response.

The ClojureScript compiler looks for *.cljs files to compile as 
> ClojureScript.  Hence, at a minimum, the *.clj files that you want to also 
> use from ClojureScript need to be copied (or perhaps symlinked, but that's 
> not what lein-cljsbuild does) to *.cljs files.
>
> A list of namespaces to copy is necessary because not all valid Clojure 
> code is valid ClojureScript code.  There are some fairly substantial 
> differences, and trying to interpret certain Clojure forms as ClojureScript 
> will cause compiler crashes.
>

Right, but if the crossover namespace for my library is defined in its 
project.clj, and I'm importing that library as a dependency into another 
project, it's sort of redundant to repeat information already specified. I 
guess what I hoped for was that crossover namespaces would automatically be 
inherited from dependencies.

On Thursday, 28 March 2013 01:48:48 UTC, Evan Mezeske wrote:
>
>
>> [...] This can't scale well if I need to use dozens of namespaces, some 
>> of which will reference other namespaces and etc.
>
>
> The standard solution here is to just organize all the crossover code into 
> one namespace.  For instance, if you have mycrossover.foo, mycrossover.bar, 
> and mycrossover.bar.baz namespaces, you can use them all with :crossovers 
> [mycrossover].
>

That would be much better — to just have to specify the "root" namespace of 
the crossover code — but for me it doesn't work.

 When I change ":crossovers [libtest.core]" to ":crossovers [libtest]" and 
compile, I get:

*WARNING: Unable to find crossover:  libtest*
*WARNING: Unable to find crossover:  libtest*

Any ideas why?

-- 
-- 
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: What is the status of Clojure on LLVM or C?

[Mikera]

On Thursday, 28 March 2013 04:05:03 UTC+8, Joe Graham wrote:

> Hi Group,
> Good afternoon I hope everyone is well.  I just wanted to reach out to 
> this group and get the current status of Clojure today on the LLVM compiler 
> or C based implementation?  Has anyone looked into a Julia implementation? 
>  Just trying to get a roadmap on the main forks before searching on every 
> permutation of this question.  Thanks so much for your help and valuable 
> input of this group.
>
> BR_joe
>

You may be interested in mjolnir: https://github.com/halgari/mjolnir 

I haven't used it yet, but it appears to be a pretty well designed library 
that enables Clojure to compile and run native code via LLVM.

It addresses what is probably the best use case for native code compilation 
in Clojure - i.e. run on the JVM to get the benefits of the JVM 
infrastructure and library ecosystem but generate native code where needed 
to achieve specific objectives (presumably performance or direct hardware 
access...).


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

Re: ClojureScript crossovers

[Evan Mezeske]

>
>
> My question is, is this necessary? If it's on the classpath, why must I 
> specifically tell it what namespaces I'm going to use? [...]
>

The ClojureScript compiler looks for *.cljs files to compile as 
ClojureScript.  Hence, at a minimum, the *.clj files that you want to also 
use from ClojureScript need to be copied (or perhaps symlinked, but that's 
not what lein-cljsbuild does) to *.cljs files.

A list of namespaces to copy is necessary because not all valid Clojure 
code is valid ClojureScript code.  There are some fairly substantial 
differences, and trying to interpret certain Clojure forms as ClojureScript 
will cause compiler crashes.

[...] This can't scale well if I need to use dozens of namespaces, some of 
> which will reference other namespaces and etc.


The standard solution here is to just organize all the crossover code into 
one namespace.  For instance, if you have mycrossover.foo, mycrossover.bar, 
and mycrossover.bar.baz namespaces, you can use them all with :crossovers 
[mycrossover].

If you don't like the way crossovers work, you might want to look into 
cljx: https://github.com/lynaghk/cljx .

-- 
-- 
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: Working with a huge graph - how can I make Clojure performant?

[Stephen Compall]

On Mon, 2013-03-11 at 10:37 -0700, Balint Erdi wrote:
>   (let [neighbors (persistent!
>(reduce
> (fn [c u] (if (explored u) c (conj! c u)))
> (transient [])
> (G v)))]

What happens if you do ^^^ *after* vvv?

>  (explored v) (recur vs explored lhalf rhalf (inc iter-cnt))

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


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

core.logic: simple question

[JvJ]

The function i wrote below isn't working.  (is-drink q) returns all drinks 
(I tested it), but hates-drink, which should return all drinks that aren't 
liked, doesn't return anything
what am I doing wrong?

Thanks

(defn hates-drink
  [d]
  (fresh [d2]
 (is-drink d)
 (likes-drink d2)
 (!= d d2)))

-- 
-- 
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: What is the status of Clojure on LLVM or C?

[Mark Rathwell]

A previous thread that covers a lot of ground, but should give you a lot of
the information you are looking for [1].  There aren't too many use cases
that couldn't be covered with ClojureScript+V8 or some of the other
suggestions.

[1] https://groups.google.com/forum/?fromgroups=#!topic/clojure/UWBpyHndluA



On Wed, Mar 27, 2013 at 4:05 PM, Joe Graham  wrote:

> Hi Group,
> Good afternoon I hope everyone is well.  I just wanted to reach out to
> this group and get the current status of Clojure today on the LLVM compiler
> or C based implementation?  Has anyone looked into a Julia implementation?
>  Just trying to get a roadmap on the main forks before searching on every
> permutation of this question.  Thanks so much for your help and valuable
> input of this group.
>
> BR_joe
>
> --
> --
> 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: What is the status of Clojure on LLVM or C?

[Timothy Baldridge]

What use-case do you have for such an implementation? Is there something
that Clojure on LLVM will give you that Clojure on the JVM or on V8 won't
allow you to do?

Timothy


On Wed, Mar 27, 2013 at 2:05 PM, Joe Graham  wrote:

> Hi Group,
> Good afternoon I hope everyone is well.  I just wanted to reach out to
> this group and get the current status of Clojure today on the LLVM compiler
> or C based implementation?  Has anyone looked into a Julia implementation?
>  Just trying to get a roadmap on the main forks before searching on every
> permutation of this question.  Thanks so much for your help and valuable
> input of this group.
>
> BR_joe
>
> --
> --
> 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.
>
>
>



-- 
“One of the main causes of the fall of the Roman Empire was that–lacking
zero–they had no way to indicate successful termination of their C
programs.”
(Robert Firth)

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

What is the status of Clojure on LLVM or C?

[Joe Graham]

Hi Group,
Good afternoon I hope everyone is well.  I just wanted to reach out to this 
group and get the current status of Clojure today on the LLVM compiler or C 
based implementation?  Has anyone looked into a Julia implementation?  Just 
trying to get a roadmap on the main forks before searching on every 
permutation of this question.  Thanks so much for your help and valuable 
input of this group.

BR_joe

-- 
-- 
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 can I count lines of code?

[larry google groups]

Thank you, all. 


On Wednesday, March 27, 2013 4:01:31 PM UTC-4, Michael Gardner wrote:
>
> On Mar 27, 2013, at 14:36 , larry google groups 
> > 
> wrote: 
>
> > I am curious, is there a simple command line script I could use to count 
> lines of code? Or is there some trick in emacs that I can do? I'd like to 
> know how many lines there are, minus the comments and white space. 
>
> On Linux or Mac, try `wc' (the first number printed is the one you want). 
> To omit whitespace and comments, you could pipe the file through grep -v 
> first: 
>
> $ grep -vxE '[[:space:]]*(;.*)?' file.clj | wc 
> 117 4493567 
>
> That regular expression matches any line that consists of zero or more 
> whitespace characters, followed by an optional suffix that starts with a 
> semicolon. Not perfect, but should be good enough for most purposes. 
>
> (Cue the old "now you have two problems" joke about regexes…) 
>
>

-- 
-- 
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 can I count lines of code?

[Michael Gardner]

On Mar 27, 2013, at 14:36 , larry google groups  
wrote:

> I am curious, is there a simple command line script I could use to count 
> lines of code? Or is there some trick in emacs that I can do? I'd like to 
> know how many lines there are, minus the comments and white space. 

On Linux or Mac, try `wc' (the first number printed is the one you want). To 
omit whitespace and comments, you could pipe the file through grep -v first:

$ grep -vxE '[[:space:]]*(;.*)?' file.clj | wc
117 4493567

That regular expression matches any line that consists of zero or more 
whitespace characters, followed by an optional suffix that starts with a 
semicolon. Not perfect, but should be good enough for most purposes.

(Cue the old "now you have two problems" joke about regexes…)

-- 
-- 
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 can I count lines of code?

[Haim Ashkenazi]

Hi

I know of two tools. Both of them however count docstrings as code:


   - cloc - http://cloc.sourceforge.net
   - lein-vanity - A leiningen plugin (
   https://github.com/dgtized/lein-vanity).

HTH

On Wed, Mar 27, 2013 at 9:36 PM, larry google groups <
lawrencecloj...@gmail.com> wrote:

> I am curious, is there a simple command line script I could use to count
> lines of code? Or is there some trick in emacs that I can do? I'd like to
> know how many lines there are, minus the comments and white space.
>
> --
> --
> 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.
>
>
>



-- 
Haim

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

[Timothy Baldridge]

Yeah, I realized that after you sent the link it's probably because my copy
of lein is using a higher stack size than the OP.

I agree with the link you posted though. It's a known issue with lazy seqs.

Timothy


On Wed, Mar 27, 2013 at 1:58 PM, Jonathan Fischer Friberg <
odysso...@gmail.com> wrote:

> I don't think it's fixed in 1.5.1.
>
> In both 1.5.0 and 1.5.1, (range 1500) is not enough to cause
> the overflow for me. However, (range 2000) "successfully"
> overflows in both versions.
>
> Jonathan
>
>
> On Wed, Mar 27, 2013 at 8:53 PM, Timothy Baldridge 
> wrote:
>
>> Holding on to the head would result in a out of memory error, not a stack
>> overflow. IIRC this was a bug that was fixed in 1.5 (I'll try to find the
>> JIRA ticket). Anyways, it works in 1.5.1:
>>
>> user=> (clojure-version)
>> "1.5.1"
>> user=> (reduce (fn [a b] (map + [1 1] a)) [1 1] (range 1500))
>> (1501 1501)
>> user=>
>>
>>
>> On Wed, Mar 27, 2013 at 1:48 PM, Michael Klishin <
>> michael.s.klis...@gmail.com> wrote:
>>
>>>
>>> 2013/3/27 larry google groups 
>>>
 The error says the type is clojure.lang.PersistentVector and not lazyseq

>>>
>>> The error says it is clojure.lang.PersistentVector$ChunkedSeq. You can
>>> learn
>>> more about what chunking is for in
>>> http://clojure-doc.org/articles/language/laziness.html.
>>>
>>> Something in this code holds on to the seq's head.
>>> --
>>> MK
>>>
>>> http://github.com/michaelklishin
>>> http://twitter.com/michaelklishin
>>>
>>> --
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To post to this group, send email to clojure@googlegroups.com
>>> Note that posts from new members are moderated - please be patient with
>>> your first post.
>>> To unsubscribe from this group, send email to
>>> clojure+unsubscr...@googlegroups.com
>>> For more options, visit this group at
>>> http://groups.google.com/group/clojure?hl=en
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to clojure+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>
>>>
>>>
>>
>>
>>
>> --
>> “One of the main causes of the fall of the Roman Empire was that–lacking
>> zero–they had no way to indicate successful termination of their C
>> programs.”
>> (Robert Firth)
>>
>> --
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/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.
>
>
>



-- 
“One of the main causes of the fall of the Roman Empire was that–lacking
zero–they had no way to indicate successful termination of their C
programs.”
(Robert Firth)

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

Re: how can I count lines of code?

[Nick Ward]

Not sure if this is the correct place to be asking this, but

sed '/^\s*$/d;/^\s*;/d' path/to/your/file | wc -l

On Wed, Mar 27, 2013 at 7:36 PM, larry google groups
 wrote:
> I am curious, is there a simple command line script I could use to count
> lines of code? Or is there some trick in emacs that I can do? I'd like to
> know how many lines there are, minus the comments and white space.
>
> --
> --
> 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 bug?

[Jonathan Fischer Friberg]

I don't think it's fixed in 1.5.1.

In both 1.5.0 and 1.5.1, (range 1500) is not enough to cause
the overflow for me. However, (range 2000) "successfully"
overflows in both versions.

Jonathan


On Wed, Mar 27, 2013 at 8:53 PM, Timothy Baldridge wrote:

> Holding on to the head would result in a out of memory error, not a stack
> overflow. IIRC this was a bug that was fixed in 1.5 (I'll try to find the
> JIRA ticket). Anyways, it works in 1.5.1:
>
> user=> (clojure-version)
> "1.5.1"
> user=> (reduce (fn [a b] (map + [1 1] a)) [1 1] (range 1500))
> (1501 1501)
> user=>
>
>
> On Wed, Mar 27, 2013 at 1:48 PM, Michael Klishin <
> michael.s.klis...@gmail.com> wrote:
>
>>
>> 2013/3/27 larry google groups 
>>
>>> The error says the type is clojure.lang.PersistentVector and not lazyseq
>>>
>>
>> The error says it is clojure.lang.PersistentVector$ChunkedSeq. You can
>> learn
>> more about what chunking is for in
>> http://clojure-doc.org/articles/language/laziness.html.
>>
>> Something in this code holds on to the seq's head.
>> --
>> MK
>>
>> http://github.com/michaelklishin
>> http://twitter.com/michaelklishin
>>
>> --
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>>
>
>
>
> --
> “One of the main causes of the fall of the Roman Empire was that–lacking
> zero–they had no way to indicate successful termination of their C
> programs.”
> (Robert Firth)
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/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 bug?

[Jonathan Fischer Friberg]

The problem is probably too much nested laziness.

Try:
(reduce (fn [a b] (doall (map + [1 1] a))) [1 1] (range 1500))

Related:
https://groups.google.com/d/msg/clojure/-d8m7ooa4c8/pmaO7QubhosJ

Jonathan



On Wed, Mar 27, 2013 at 8:48 PM, Michael Klishin <
michael.s.klis...@gmail.com> wrote:

>
> 2013/3/27 larry google groups 
>
>> The error says the type is clojure.lang.PersistentVector and not lazyseq
>>
>
> The error says it is clojure.lang.PersistentVector$ChunkedSeq. You can
> learn
> more about what chunking is for in
> http://clojure-doc.org/articles/language/laziness.html.
>
> Something in this code holds on to the seq's head.
> --
> MK
>
> http://github.com/michaelklishin
> http://twitter.com/michaelklishin
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

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

[Timothy Baldridge]

Holding on to the head would result in a out of memory error, not a stack
overflow. IIRC this was a bug that was fixed in 1.5 (I'll try to find the
JIRA ticket). Anyways, it works in 1.5.1:

user=> (clojure-version)
"1.5.1"
user=> (reduce (fn [a b] (map + [1 1] a)) [1 1] (range 1500))
(1501 1501)
user=>


On Wed, Mar 27, 2013 at 1:48 PM, Michael Klishin <
michael.s.klis...@gmail.com> wrote:

>
> 2013/3/27 larry google groups 
>
>> The error says the type is clojure.lang.PersistentVector and not lazyseq
>>
>
> The error says it is clojure.lang.PersistentVector$ChunkedSeq. You can
> learn
> more about what chunking is for in
> http://clojure-doc.org/articles/language/laziness.html.
>
> Something in this code holds on to the seq's head.
> --
> MK
>
> http://github.com/michaelklishin
> http://twitter.com/michaelklishin
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>



-- 
“One of the main causes of the fall of the Roman Empire was that–lacking
zero–they had no way to indicate successful termination of their C
programs.”
(Robert Firth)

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

Re: a bug?

[Michael Klishin]

2013/3/27 larry google groups 

> The error says the type is clojure.lang.PersistentVector and not lazyseq
>

The error says it is clojure.lang.PersistentVector$ChunkedSeq. You can learn
more about what chunking is for in
http://clojure-doc.org/articles/language/laziness.html.

Something in this code holds on to the seq's head.
-- 
MK

http://github.com/michaelklishin
http://twitter.com/michaelklishin

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

how can I count lines of code?

[larry google groups]

I am curious, is there a simple command line script I could use to count 
lines of code? Or is there some trick in emacs that I can do? I'd like to 
know how many lines there are, minus the comments and white space. 

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

[larry google groups]

The error says the type is clojure.lang.PersistentVector and not lazyseq. I 
know very little about this, but I think (map) is returning a lazyseq, but 
the anonymous function inside of reduce is returning 
a clojure.lang.PersistentVector. 


On Wednesday, March 27, 2013 3:23:21 PM UTC-4, John Lawrence Aspden wrote:
>
> Hi, 
>
> Laziness makes my head hurt. 
>
> Is there any reason this is desirable behaviour?: 
>
> user=> (clojure-version) 
> "1.4.0" 
>
> user=> (reduce (fn [a b] (map + [1 1] a)) [1 1] (range 1000)) 
> (1001 1001) 
>
> user=> (reduce (fn [a b] (map + [1 1] a)) [1 1] (range 1500)) 
> StackOverflowError   clojure.lang.PersistentVector$ChunkedSeq. 
> (PersistentVector.java:257) 
>
>
> 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.

a bug?

[John Lawrence Aspden]

Hi,

Laziness makes my head hurt.

Is there any reason this is desirable behaviour?:

user=> (clojure-version)
"1.4.0"

user=> (reduce (fn [a b] (map + [1 1] a)) [1 1] (range 1000))
(1001 1001)

user=> (reduce (fn [a b] (map + [1 1] a)) [1 1] (range 1500))
StackOverflowError   clojure.lang.PersistentVector$ChunkedSeq.
(PersistentVector.java:257)


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: GSoC 2013: Only three days left to submit project ideas

[Mikera]

Hi Daniel,

Here's some GSoC suggestions for core.matrix. I'm happy to mentor any one 
of these.

NDArray Implementation in Clojure

*Brief explanation:* core.matrix provides a general purpose API for vector 
/ matrix computation in Clojure. A key innovation is support for multiple 
back-end implementations (e.g. optimised native libraries or various 
existing Java libraries). However, there would be considerable value in 
having a N-Dimensional array (NDArray) implementation as part of 
core.matrix itself. This would likely become the de-facto standard 
implementation for numerical computing in Clojure.

*Expected results: *A working NDArray implementation merged into 
core.matrix, with relevant documentation and tests. The implementation 
should support the full core.matrix API (i.e. it should work as a fully 
functioning, general purpose N-dimensional matrix implementation), and have 
good efficiency / performance characteristics.

*Knowledge prerequisites:* Linear Algebra, Experience of Clojure (including 
protocols and macros)

*Difficulty: *Medium / Hard

*Mentor:* Mike Anderson (core.matrix maintainer)


Incanter Integration with core.matrix

*Brief explanation:* core.matrix provides a general purpose API for vector 
/ matrix computation in Clojure. Incanter is a Clojure-based R-like 
platform for statistical computing and graphics. Historically these have 
developed separately, but there would be considerable value in extending 
core.matrix so that it supports everything Incanter needs and converting 
Incanter to use core.matrix directly, rather than it's own custom matrix 
wrapper functionality. This combination would offer substantial new 
capabilities to users, and harmonise two of the major numerical computing 
projects in the Clojure ecosystem.

*Expected results: *core.matrix extended to provide full support for all 
Incanter functionality, and Incanter patched to use core.matrix. Ideally 
the Incanter changes would be merged into the next release of Incanter 
(subject to agreement of Incanter project leads)

*Knowledge prerequisites:* Linear Algebra, Statistics, Experience of Clojure

*Difficulty: *Medium 

*Mentor:* Mike Anderson (core.matrix maintainer), TBC (Incanter maintainer 
/ mentor)



Algebraic Expressions

*Brief explanation:* core.matrix provides a general purpose API for vector 
/ matrix computation in Clojure. There would be considerable value to 
creating a module that is able to represent algebraic expressions 
containing matrix computations, and optimise these for execution using 
core.matrix. Logic Programming (via core.logic) could be used to perform 
manipulation / simplification of expressions (e.g. using tree rewriting 
rules). An obvious application of this module would be to create numerical 
equation solvers in Clojure. Some experimental ideas exist in the 
repository: https://github.com/clojure-numerics/expresso

*Expected results: *A system of expressing algebraic expressions, 
transforming these into optimised forms and executing these on core.matrix. 
This should be supported by a documented sample application that 
demonstrates applying this system to an example problem.

*Knowledge prerequisites:* Advanced Linear Algebra / Theorem Proving, Logic 
Programming (ideally core.logic), Experience of Clojure

*Difficulty: *Hard 

*Mentor:* Mike Anderson (core.matrix maintainer)


API Contract Validation

*Brief explanation:* core.matrix provides a general purpose API for vector 
/ matrix computation in Clojure. A key innovation is support for multiple 
back-end implementations (e.g. optimised native libraries or various Java 
libraries). However, it is necessary for testing and correctness purposes 
to validate that the implementations conform to the contracts represented 
in the core.matrix API. This validation is complicated by the fact that 
different implementations may support a different subset of core.matrix 
features (e.g. only supporting 1D and 2D arrays, double types vs. int 
types, support for mutability etc.)

*Expected results: *A validation framework that is able to represent the 
contracts in the core.matrix API, and validate these against any 
core.matrix implementation. Successful validation should be demonstrated 
against all the standard implementations present in core.matrix itself, and 
against at least one external implementation (e.g. vectorz-clj). 

*Knowledge prerequisites:* API Design, Design by Contract methodologies, 
Experience of Clojure

*Difficulty: *Medium/Hard

*Mentor:* Mike Anderson (core.matrix maintainer)



On Tuesday, 26 March 2013 22:02:24 UTC+8, Daniel Solano Gómez wrote:
>
> Hello, all, 
>
> There are just three days left to prepare our application for GSoC 2013. 
> Although we have a number of really good ideas up on our Project Ideas 
> page , we really 
> need to do a lot more in order to strengthen our application. 
>
> By submitting ideas to the project page, you ne

ClojureScript crossovers

[Matthew Hill]

Hello, I'm working on a library that works with both Clojure and 
ClojureScript.

Here's the project.clj for the library:

(defproject libtest "0.1.0-SNAPSHOT"
  :description "FIXME: write description"
  :url "http://example.com/FIXME";
  :license {:name "Eclipse Public License"
:url "http://www.eclipse.org/legal/epl-v10.html"}
  :dependencies [[org.clojure/clojure "1.4.0"]]
  :plugins [[lein-cljsbuild "0.3.0"]]
  :cljsbuild
{:crossovers [libtest],
 :crossover-jar true
 :jar true
:builds
[{:source-paths ["src/libtest"], :crossover-path "src/libtest"}]})

And I'm including it as a dependency in another project. To get it to work 
from the ClojureScript side of my project, I had to add the exact namespace 
as a crossover under the cljsbuild key of my project.clj:

:cljsbuild {
:builds [{
...
:crossovers [libtest.core]
...

My question is, is this necessary? If it's on the classpath, why must I 
specifically tell it what namespaces I'm going to use? This can't scale 
well if I need to use dozens of namespaces, some of which will reference 
other namespaces and etc.

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

Re: (load "hello") can't see hello.clj in the current directory.

[Michael Klishin]

Leif:

> I works for me if I run 'lein repl' *outside* of a project.  In that 
> case, "" is on the classpath, so "." looks in the current directory.
>
> When you run 'lein repl' *inside* of a project, however, the top-level 
> project directory is not on the classpath.  "." in this case probably means 
> "look in the root of all directories on the classpath."  (I'm guessing; 
> Java experts speak up.)
>

But nobody keeps sources files in the repository root (and if they do, they 
should not).

Outside of project it makes sense to add . to the classpath because there 
is basically nothing else to add.

If you don't like the src/ location or need more than one source root, you 
can add them via project.clj.

MK 

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

ANN metrics-clojure 1.0.1 is released

[Michael Klishin]

metrics-clojure is a Clojure library by Steve Losh that provides a
Clojure-friendly API for
the Metrics library by Coda Hale [1].

1.0.1 is initial stable release. The library is now feature complete,
provides some
additional batteries (Ring middleware for exposing metrics as JSON) and
has documentation guides.

Please check it out and start collecting data about how your service
operates in production.

Repository on GitHub:
https://github.com/sjl/metrics-clojure

Documentation:
http://metrics-clojure.readthedocs.org/en/latest/

If you are not familiar with the Metrics library, this talk should
introduce you to why gathering metrics in your apps matters:

http://pivotallabs.com/139-metrics-metrics-everywhere/

1. http://metrics.codahale.com/
-- 
MK

http://github.com/michaelklishin
http://twitter.com/michaelklishin

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

Re: (load "hello") can't see hello.clj in the current directory.

[Michael Wood]

On 27 March 2013 15:14, Alf Kristian Støyle  wrote:
[...]

> Pretty easy to inspect the classpath in the repl, e.g: (filter #(= (key
> %) "java.class.path") (System/getProperties))
>

Or:

(get (System/getProperties) "java.class.path")

-- 
Michael Wood 

-- 
-- 
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: Seeking advice on a safe way to mock/stub fns

[Shantanu Kumar]

On Wednesday, 27 March 2013 17:54:01 UTC+5:30, John Hume wrote:
>
> On Mar 27, 2013 1:56 AM, "Shantanu Kumar" > 
> wrote:
> >
> > Sorry, in the last illustration, the (binding [*deps* deps] ...) cannot 
> be useful for Compojure route handlers because dynamic vars are bound at a 
> thread-local level; you will probably have to `alter-var-root` it to some 
> var and have the handlers use that static var instead. In the code I write 
> personally, I use a static var that I `alter-var-root` so I couldn't see 
> the error in dynamic var immediately.
>
> If that thread-local binding is done in a middleware, that should work 
> fine for ring, which handles each request synchronously on a thread. 
> (Whereas alter-var-root would be visible across threads and defeat the OP's 
> goal of running tests concurrently.)
>
I consider application initialization would be an expensive operation 
(reading the config, setting up dependencies etc) so I wouldn't recommend 
to carry that out in the handler. Rather the initialization should be done 
only once while setting up the middleware, and simply used by the HTTP 
request threads. As shown below:

(defn ensure-init [handler]
  (let [app-deps (init-deps)]
(alter-var-root #'deps (constantly app-deps)))
  handler)  ; handler is unchanged

The `deps` var should be used only during prod/staging etc, not for unit 
testing where you want to mock certain things out. I know the 
initialization can made to work with dynamic var too, but the dynamic var 
lookup is not buying us anything here. I WOULD NOT recommend the following:

(defn ensure-init [handler]
  (let [app-deps (init-deps)]
(fn [request]
  (binding [*deps* app-deps]
(handler request)

Shantanu

>

-- 
-- 
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: Best way of doing clojure / clojurescript development

[Steven Obua]

This looks very useful, thanks!

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

Re: [ANN] Amazonica: Clojure client for the entire AWS api

[Herwig Hochleitner]

2013/3/26 Hugo Duncan 

>
> Or can the cost be confined to compile time...
>

That would be nice to have!
Generating type-hinted clojure code from the reflection result and emitting
that with macros would be an option.

I think the dynamic use of reflection would be enough to put me off
> using this in something like pallet, for example.
>

I agree with Michael on this: Any reflection overhead should pale next to
the context switch and network communication, that AWS commands do.
OTOH, I also agree that driving a generated java api via reflection, to
generate xml seems a bit heavy handed.
Still, first priority should be to get the interface right.

Regarding that: I think the first context argument should be mandatory.
We are just saw clojure.java.jdbc painstakenly deprecate a lot of API, to
get rid of the dynamic *db* var.
The reasons against passing context in a dynamic var go double against a
global atom: A function parameter can be set at from any data model in
every callsite. Everything that's less flexible constrains your users for
little gain (in the case of passing context).

Also, my experience with ClojureQL showed me, that with multiple sources of
a context arg, it's hard to get the ordering right.
E.g. the new implementation seems to prefer dynamically bound credentials
over credentials passed as argument.

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

[ANN] quit-yo-jibber 0.4.3 (Jabber library)

[Adam Clements]

Quit-yo-jibber is a fork of xmpp-clj based less around direct-response 
chatbots. It allows you to listen for presence changes, set availability 
and status messages and send messages unprompted among other things.

It is stable and auto-reconnects if the network should drop. I use it in 
two projects which have been running 24/7 for 6 months now without any 
issues.

https://github.com/AdamClements/quit-yo-jibber

Available on clojars as *[quit-yo-jibber "0.4.3"]*

*Changelog:*

0.4.3
Set sent message type to chat - this means that asterisk *bold*, underbar 
_underline_ formatting and smileys are properly formatted by the gtalk 
client
Filter out only messages which contain a body, rather than chat type 
messages which were actually typing notifications causing extra events to 
fire in previous versions

0.4.2
Fix presence listeners
Added experimental ability to set-availability (experimental - not in core 
namespace but accessible in quit-yo-jibber.presence)

0.4.1
Add in API for detecting whether users are active on their android phone or 
a PC

0.4.0
API revision - major release


-- 
-- 
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: (load "hello") can't see hello.clj in the current directory.

[Alf Kristian Støyle]

MC Andre, if you put hello.clj in the src folder you should be able to do
(load "hello"). (load-file )  should work for files not on the
classpath, so (load-file "hello.clj") means look for hello.clj in the
current working dir.

Pretty easy to inspect the classpath in the repl, e.g: (filter #(= (key %)
"java.class.path") (System/getProperties))

The project relative folders on my classpath is:
*  /test
*  /src
*  /dev-resources
*  /resources
*  /target/classes

"." is not on the classpath, and shouldn't normally be imo. "." just means
the working dir though.

Cheers,
Alf


On 27 March 2013 03:06, Leif  wrote:

> I works for me if I run 'lein repl' *outside* of a project.  In that
> case, "" is on the classpath, so "." looks in the current directory.
>
> When you run 'lein repl' *inside* of a project, however, the top-level
> project directory is not on the classpath.  "." in this case probably means
> "look in the root of all directories on the classpath."  (I'm guessing;
> Java experts speak up.)
>
> --Leif
>
>
> On Tuesday, March 26, 2013 12:25:43 PM UTC-4, MC Andre wrote:
>>
>> I tried setting *compile-path* to ".", but Clojure still can't find
>> hello.clj.
>>
>> Trace:
>>
>> $ cat hello.clj
>> (ns hello
>>   (:gen-class))
>>
>> (defn -main [& args]
>>   (println "Hello World!\n"))
>>
>> $ lein repl
>> nREPL server started on port 4902
>> REPL-y 0.1.0-beta10
>> Clojure 1.4.0
>> Exit: Control+D or (exit) or (quit)
>> Commands: (user/help)
>> Docs: (doc function-name-here)
>>   (find-doc "part-of-name-here")
>>   Source: (source function-name-here)
>>   (user/sourcery function-name-here)
>>  Javadoc: (javadoc java-object-or-class-here)
>> Examples from clojuredocs.org: [clojuredocs or cdoc]
>>   (user/clojuredocs name-here)
>>   (user/clojuredocs "ns-here" "name-here")
>> user=> (load "hello")
>> FileNotFoundException Could not locate hello__init.class or hello.clj on
>> classpath:   clojure.lang.RT.load (RT.java:432)
>>
>> System:
>>
>> * Leiningen 2.0.0-preview10
>> * Clojure 1.4.0
>> * Java Java 1.7.0_17 Java HotSpot(TM) Client VM
>> * Windows XP
>>
>  --
> --
> 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: Best way of doing clojure / clojurescript development

[John D. Hume]

https://github.com/emezeske/lein-cljsbuild/blob/0.3.0/doc/CROSSOVERS.md
 On Mar 27, 2013 6:40 AM, "Steven Obua"  wrote:

> Hi,
>
> I have thought long which language to use for my current project. My main
> choices were Scala and Clojure, and I decided on Clojure mainly because I
> need to run substantial amounts of my code to run on both the JVM and in
> the browser.
>
> So now I am approaching the parts of my project that need to run in both
> environments. Are there any best practices for setting up my environment so
> that I can compile to both the JVM and to Javascript from the same
> codebase? I am aware that Clojure and Clojurescript are different
> languages, but for those pieces of my code that are shared I will make sure
> that the code looks the same, and I don't want to maintain different
> codebases for the same code.
>
> Thanks for any pointers,
>
> Steven
>
> --
> --
> 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: [GSoC Idea] Program analysis suite, based on Rich Hickey's Codeq

[Daniel Solano Gómez]

Thank you, Rich, for the idea.  And thanks to Tom, the idea is now up on
the project ideas page.

Sincerely,

Daniel


On Tue Mar 26 13:41 2013, Rich Morin wrote:
>   Category:  Tooling
> 
>   Name:  Program analysis suite, based on Rich Hickey's Codeq
> 
>   Brief explanation:
>   
> Rich Hickey, inventor of Clojure and Datomic, created Codeq as a
> prototype framework for program analysis.  It harvests multiple
> information sources (eg, Git metadata, source code), and stores
> the results in a graph database (eg, Datomic).  The results are
> thus available for querying, processing, visualization, etc.
> 
> Although Codeq is very promising, it is only a proof of concept,
> lacking analyzers, a control framework, and presentation tools.
> Turning Codeq into a production suite would be a substantial
> software engineering effort, with corresponding visibility.  The
> student would extend the base that Codeq provides, producing a
> compelling and robust example of the power of this approach.
> 
>   Expected results:
> 
> The suite should be ready for "drop-in" installation in typical
> Clojure shops.  It should do continuous harvesting of code bases.
> It should extend the current Clojure analyzer to harvest names of
> called functions and methods, use of global state, etc.
> 
> Stretch goals might include other analyzers (eg, Java), queries
> for common use cases, analysis and visualization software, etc.
> 
>   Knowledge prerequisites:
> 
> Interest in mechanized program analysis.  Experience with Clojure.
> 
>   Difficulty:  Medium
> 
>   Mentor:  Rich Morin (mechanized documentation enthusiast),
>Tom Faulhaber (author of Autodoc, cl-format, etc.)
> 
>  -- 
> http://www.cfcl.com/rdmRich Morin
> http://www.cfcl.com/rdm/resume r...@cfcl.com
> http://www.cfcl.com/rdm/weblog +1 650-873-7841
> 
> Software system design, development, and documentation
> 
> 
> -- 
> -- 
> 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.
> 
> 


signature.asc
Description: Digital signature

Re: Seeking advice on a safe way to mock/stub fns

[John D. Hume]

On Mar 27, 2013 1:56 AM, "Shantanu Kumar"  wrote:
>
> Sorry, in the last illustration, the (binding [*deps* deps] ...) cannot
be useful for Compojure route handlers because dynamic vars are bound at a
thread-local level; you will probably have to `alter-var-root` it to some
var and have the handlers use that static var instead. In the code I write
personally, I use a static var that I `alter-var-root` so I couldn't see
the error in dynamic var immediately.

If that thread-local binding is done in a middleware, that should work fine
for ring, which handles each request synchronously on a thread. (Whereas
alter-var-root would be visible across threads and defeat the OP's goal of
running tests concurrently.)

Do note, however, that the premise of this advice, that with-redefs doesn't
play nicely with concurrency, is too broadly stated.
• It doesn't play nicely with running tests that mock the same vars across
multiple threads.
• It doesn't play nicely with running tests in one thread while running
your app in another, if your app does things w/o user interaction. (This is
a pain for me.)
• BUT it does play nicely, more so than binding, with testing code that
does work across multiple threads, for example in futures, agents, or
hand-rolled threading.

So if you're testing concurrent code and can stand to run just one test at
a time, it allows you to avoid the verbosity of injecting all your
dependencies.

-hume.

-- 
-- 
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: Apply elements in a vector as arguments to function

[Marko Topolnik]

On Wednesday, March 27, 2013 12:42:43 PM UTC+1, Ryan wrote:

> If a developer cannot figure out how to do X from the docs, she should 
>> complain about it
>> instead of assuming it's perfectly normal to spend time reading the 
>> source to figure out
>> how to use something.
>
>
> I generally agree with this, but not all code authors are willing to 
> listen to you, either because they are bored or because their ego doesn't 
> let them (to accept that they had a flaw in docs/code)so, most of the 
> time I just look at the source, even if i do make a post about the lack of 
> documentation. It's faster in most cases :) 
>

I'd say Michael's comment was in fact directed at the behavior of said 
authors :)

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

Re: Apply elements in a vector as arguments to function

[Ryan]

>
> If a developer cannot figure out how to do X from the docs, she should 
> complain about it
> instead of assuming it's perfectly normal to spend time reading the source 
> to figure out
> how to use something.


I generally agree with this, but not all code authors are willing to listen 
to you, either because they are bored or because their ego doesn't let them 
(to accept that they had a flaw in docs/code)so, most of the time I 
just look at the source, even if i do make a post about the lack of 
documentation. It's faster in most cases :) 

@Jim, no worries, I understood that you didn't mean "read the code before 
you post next time" :)

On Wednesday, March 27, 2013 12:37:28 PM UTC+2, Michael Klishin wrote:
>
>
> 2013/3/27 Ryan >
>
>> I believe Jim meant to check the source to figure out how does it work, 
>> not that the way it's implemented is the most proper way to implement it.
>> If that's not what you wanted to point out can you please explain?
>>
>
> If a developer cannot figure out how to do X from the docs, she should 
> complain about it
> instead of assuming it's perfectly normal to spend time reading the source 
> to figure out
> how to use something.
> -- 
> MK
>
> http://github.com/michaelklishin
> http://twitter.com/michaelklishin
>  

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

Best way of doing clojure / clojurescript development

[Steven Obua]

Hi,

I have thought long which language to use for my current project. My main 
choices were Scala and Clojure, and I decided on Clojure mainly because I 
need to run substantial amounts of my code to run on both the JVM and in 
the browser. 

So now I am approaching the parts of my project that need to run in both 
environments. Are there any best practices for setting up my environment so 
that I can compile to both the JVM and to Javascript from the same 
codebase? I am aware that Clojure and Clojurescript are different 
languages, but for those pieces of my code that are shared I will make sure 
that the code looks the same, and I don't want to maintain different 
codebases for the same code.

Thanks for any pointers,

Steven

-- 
-- 
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: Apply elements in a vector as arguments to function

[Jim foo.bar]

On 27/03/13 03:13, Michael Klishin wrote:
Complain loudly to maintainers on this list that their documentation 
has gaps and they should
clarify this and that. The idea that people should read the source to 
get reasonably straightforward

stuff done is wrong and does a lot of long term damage to the community.



what I really meant was that both of us (Ryan and me) would have 
benefited by looking at the sources. It would have been immediately 
clear that 'fields' expects a vector argumentI even rushed to infer 
what the fn expects which proved wrong 2 minutes later!


In any case, for me, reading the sources has always helped...in fact, 
unless you read/study the sources there is no way to make meaningful 
comments/corrections about a library. Yes, the docs should always be 
clear with regards to usage but being able to consult the source 
relatively easily, is invaluable (at least for me)...


Jim

ps: by no means I meant "read the source before posting here"...my 
comment was closer to "read the sources - it's good for you - you'll 
learn stuff and potentially save time & effort" :)


--
--
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: Apply elements in a vector as arguments to function

[Michael Klishin]

2013/3/27 Ryan 

> I believe Jim meant to check the source to figure out how does it work,
> not that the way it's implemented is the most proper way to implement it.
> If that's not what you wanted to point out can you please explain?
>

If a developer cannot figure out how to do X from the docs, she should
complain about it
instead of assuming it's perfectly normal to spend time reading the source
to figure out
how to use something.
-- 
MK

http://github.com/michaelklishin
http://twitter.com/michaelklishin

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

Re: Apply elements in a vector as arguments to function

[Marko Topolnik]

Now that Michael mentioned it, the docstring of *apply* says

Applies fn f to the argument list formed by prepending intervening 
> arguments to args.


I challenge any Clojure newbie to decipher this Hickeyism for me. This is 
of course no exception; most of clojure.core is like that.

I can personally testify to having learned (and *had to* learn) much more 
from source code than from docstrings. M-. has always been my best friend; C-d 
C-d came merely as a hint from Rich while solving the "compile me in your 
head" puzzle.

-marko

On Wednesday, March 27, 2013 11:17:05 AM UTC+1, Ryan wrote:
>
> The idea that people should read the source to get reasonably 
>> straightforward stuff done is wrong and does a lot of long term damage to 
>> the community.
>
>
> I believe Jim meant to check the source to figure out how does it work, 
> not that the way it's implemented is the most proper way to implement it.
> If that's not what you wanted to point out can you please explain?
>
> On Wednesday, March 27, 2013 5:13:35 AM UTC+2, Michael Klishin wrote:
>>
>>
>> 2013/3/27 Jim - FooBar(); 
>>
>>> aaa see? always check the docs first and the sources second (if 
>>> available)...I should have done that as well :)
>>
>>
>> Definitely don't just check the sources and think it's something normal.
>>
>> Complain loudly to maintainers on this list that their documentation has 
>> gaps and they should
>> clarify this and that. The idea that people should read the source to get 
>> reasonably straightforward
>> stuff done is wrong and does a lot of long term damage to the community.
>> -- 
>> MK
>>
>> http://github.com/michaelklishin
>> http://twitter.com/michaelklishin
>>  
>

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

Re: Apply elements in a vector as arguments to function

[Ryan]

>
> The idea that people should read the source to get reasonably 
> straightforward stuff done is wrong and does a lot of long term damage to 
> the community.


I believe Jim meant to check the source to figure out how does it work, not 
that the way it's implemented is the most proper way to implement it.
If that's not what you wanted to point out can you please explain?

On Wednesday, March 27, 2013 5:13:35 AM UTC+2, Michael Klishin wrote:
>
>
> 2013/3/27 Jim - FooBar(); >
>
>> aaa see? always check the docs first and the sources second (if 
>> available)...I should have done that as well :)
>
>
> Definitely don't just check the sources and think it's something normal.
>
> Complain loudly to maintainers on this list that their documentation has 
> gaps and they should
> clarify this and that. The idea that people should read the source to get 
> reasonably straightforward
> stuff done is wrong and does a lot of long term damage to the community.
> -- 
> MK
>
> http://github.com/michaelklishin
> http://twitter.com/michaelklishin
>  

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