Re: ClojureScript Repl -- Swank-like workflow with Emacs?

[Paul Koerbitz]

Hi Volker,

not sure I understand you correctly. You should still be able to type
into the repl and get results, even if it is 'in-browser', right? At
least that works for me if I start the browser repl on the command
line. So it should also work in Emacs, I am pretty sure its something
weird with my setup.

(Btw. My previous shorter reply should have arrived __after__ the
longer (see timestamps), not sure why google groups is mixing up the
order of my emails)

cheers
Paul

On Sep 26, 11:14 pm, Volker Schlecht 
wrote:
> The example given in the wiki uses an in-browser repl. If you want to
> work with the "regular" rhino-repl, replace
>
> (require '[cljs.repl.browser :as browser])
>
> with
>
> (require '[cljs.repl.rhino :as rhino])
>
> And you should be all set.
>
> On Sep 26, 4:28 pm, Paul Koerbitz  wrote:
>
>
>
>
>
>
>
> > Hi David!
>
> > thanks for the fast reply and this solution.
>
> > I haven't gotten it to work yet, but this is more than likely due to me not
> > really understanding how to put all the moving parts together.
>
> > Here is what I did:
>
> > Put your code into 'browser-repl'. Now if I execute this on the command line
> > I get this prompt
>
> > #'user/env
> > "Type: " :cljs/quit " to quit"
> > Starting Server on Port: 9000
> > ClojureScript:cljs.user>
>
> > and when I open up some page with clojure script (e.g.
> > samples/repl/index.html) I can execute sutff in the browser such as
> > (js/alert "hello, world!").
>
> > However, if I run the script as an inferior-lisp process I also get this
> > output in the *inferior-lisp* window
>
> > #'user/env
> > "Type: " :cljs/quit " to quit"
> > Starting Server on Port: 9000
> > ClojureScript:cljs.user>
>
> > but I can't connect the browser. the file still loads but if I enter stuff
> > in the repl the repl just hangs.
>
> > I am sure I am missing something, right now I just don't see what.
>
> > thanks for the help so far.
> > Paul
>
> > On Mon, Sep 26, 2011 at 15:55, David Nolen  wrote:
> > > I've created the following wiki -
> > >https://github.com/clojure/clojurescript/wiki/Emacs-&-inferior-lisp-mode
>
> > > Let me know if this needs more clarification.
>
> > > David
>
> > > On Mon, Sep 26, 2011 at 9:15 AM, Paul Koerbitz 
> > > wrote:
>
> > >> Dear Clojurians,
>
> > >> I was toying with Clojurescript and really like using the Repl as
> > >> described herehttps://github.com/clojure/clojurescript/wikitotry
> > >> things out. (thanks for all the great to everyone involved!!)
>
> > >> Has anyone hooked this into Emacs in a Swank-like fashion? I would love 
> > >> to
> > >> be able to send forms to C-c C-c or ''compile'' a file with C-c C-k.
>
> > >> thanks
> > >> Paul
>
> > >> --
> > >> 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: advantage of dynamic typing

[Paul Koerbitz]

Javier, Nathan +1

I think type systems such as Haskells (and presumably Scala's FP stuff,
don't know anything about that) are really the way to go if you want static
typing. I think the extra safety that it provides you with is really
beneficial and for most things Haskells type system feels pretty light
weight, you basically only have to type the function signature (if that) and
you get algebraic polymorphisms with all the safety and generality.

That said, I read somewhere (can't find the link now, sorry) that
compile-time type checking in Lisps is difficult because they allow code
generation at run time? That would still leave the possibility to apply it
to everything which is evaluated at compile time which I assume is 99.5% of
all clojure code.

cheers
Paul


On Fri, Sep 23, 2011 at 04:47, Nathan Sorenson  wrote:

> Yes I am very hopeful progress is made on that front! I've been having
> great success with 'Constraint Handling Rules' (CHR), which serves as
> my basis for solving type constraints.
> https://github.com/nsorenson/Clojure-CHR
> contains my very preliminary crack at implementing this system.
>
> The trick with dynamic languages such as Clojure is that the functions
> are extremely lax in what they accept--without a fairly advanced
> inference system, you will simply infer every variable to be type
> Object. I've been using CHR disjunctive branches to offer what's
> called "occurrence typing"--a system where you may assign different
> types to variables depending on the structure of the code. For
> instance, if you have a (map? x) as a predicate on an if clause, you
> know in the 'then' branch that x can be typed to Map.
>
> Nothing to show yet, and I'm not sure how well it will work on large
> programs, but my first few little experiments are looking promising.
>
> On Sep 22, 3:28 am, Javier Neira Sanchez  wrote:
> > i am surprised nobody mentioned gradual/optional typing<
> http://lambda-the-ultimate.org/node/1707>,
> > typed racket   and the possible
> type
> > checker to be built by *some clever hacker* on core.logic<
> https://github.com/clojure/core.logic>some day.
>
> --
> 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: advantage of dynamic typing

[Paul Koerbitz]

Hi Nathan!

I am very intrigued by your approach. I would love to contribute, my problem
is that I don't know the first thing about type inference systems (as in how
they work on the inside). Do you have a good reference here? I'll take a
look at what you've done, maybe bother you with some questions  Thanks
for the work!

cheers
Paul

On Fri, Sep 23, 2011 at 04:47, Nathan Sorenson  wrote:

> Yes I am very hopeful progress is made on that front! I've been having
> great success with 'Constraint Handling Rules' (CHR), which serves as
> my basis for solving type constraints.
> https://github.com/nsorenson/Clojure-CHR
> contains my very preliminary crack at implementing this system.
>
> The trick with dynamic languages such as Clojure is that the functions
> are extremely lax in what they accept--without a fairly advanced
> inference system, you will simply infer every variable to be type
> Object. I've been using CHR disjunctive branches to offer what's
> called "occurrence typing"--a system where you may assign different
> types to variables depending on the structure of the code. For
> instance, if you have a (map? x) as a predicate on an if clause, you
> know in the 'then' branch that x can be typed to Map.
>
> Nothing to show yet, and I'm not sure how well it will work on large
> programs, but my first few little experiments are looking promising.
>
> On Sep 22, 3:28 am, Javier Neira Sanchez  wrote:
> > i am surprised nobody mentioned gradual/optional typing<
> http://lambda-the-ultimate.org/node/1707>,
> > typed racket   and the possible
> type
> > checker to be built by *some clever hacker* on core.logic<
> https://github.com/clojure/core.logic>some day.
>
> --
> 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

defrecord and overriding "empty"

[Nathan Sorenson]

I'm using clojure.walk/postwalk to rewrite terms in nested data
structures. However, I am unable to do this with types as defined by
defrecord, because they specify that the function "empty"  throw a not-
implemented exception.

If I were able to over-ride this default implementation of 'empty' I
believe I could still use postwalk to rewrite my custom records (as
they happily implement 'into' which works as expected.)

This was my obvious first attempt:

(defrecord TypeVar [guid name]
  clojure.lang.IPersistentCollection
  (empty [coll] (TypeVar. 0 nil)))

Which fails due to:

"Duplicate method name&signature in class file types/TypeVar"
  [Thrown class java.lang.ClassFormatError]

I would prefer not to fall back on deftype as I do wish these objects
to behave as maps. I also could write my own version of postwalk that
doesn't call 'empty' on my custom-defined records, but it would be
nice to make my types adhere to the contract of IPersistentCollection
as much as possible.

-- 
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: advantage of dynamic typing

[Nathan Sorenson]

I am following the general strategy described in Sam Tobin-Hochstadt's
work. He is the person behind typed-racket. His Phd dissertation[1]
has an overview of the area of gradual/soft/refinement typing in
dynamic languages. It's a good place to start, with a pretty gentle
introduction to the motivations and issues involved (though I'd
imagine you'd need a rough understanding of sequent calculus notation
to follow his description of the semantics of his type system).

[1] http://www.ccs.neu.edu/home/samth/


On Sep 27, 12:43 am, Paul Koerbitz  wrote:
> Hi Nathan!
>
> I am very intrigued by your approach. I would love to contribute, my problem
> is that I don't know the first thing about type inference systems (as in how
> they work on the inside). Do you have a good reference here? I'll take a
> look at what you've done, maybe bother you with some questions  Thanks
> for the work!
>
> cheers
> Paul
>
>
>
>
>
>
>
> On Fri, Sep 23, 2011 at 04:47, Nathan Sorenson  wrote:
> > Yes I am very hopeful progress is made on that front! I've been having
> > great success with 'Constraint Handling Rules' (CHR), which serves as
> > my basis for solving type constraints.
> >https://github.com/nsorenson/Clojure-CHR
> > contains my very preliminary crack at implementing this system.
>
> > The trick with dynamic languages such as Clojure is that the functions
> > are extremely lax in what they accept--without a fairly advanced
> > inference system, you will simply infer every variable to be type
> > Object. I've been using CHR disjunctive branches to offer what's
> > called "occurrence typing"--a system where you may assign different
> > types to variables depending on the structure of the code. For
> > instance, if you have a (map? x) as a predicate on an if clause, you
> > know in the 'then' branch that x can be typed to Map.
>
> > Nothing to show yet, and I'm not sure how well it will work on large
> > programs, but my first few little experiments are looking promising.
>
> > On Sep 22, 3:28 am, Javier Neira Sanchez  wrote:
> > > i am surprised nobody mentioned gradual/optional typing<
> >http://lambda-the-ultimate.org/node/1707>,
> > > typed racket   and the possible
> > type
> > > checker to be built by *some clever hacker* on core.logic<
> >https://github.com/clojure/core.logic>some day.
>
> > --
> > 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: advantage of dynamic typing

[Paul Koerbitz]

Hi Nathan,

thanks for the pointer, this is great! I got his dissertation, this
does seem like a great starting point given that he is the guy behind
typed racket. The wikipedia page on sequent calculus also looks
promising, let's see how far I'll make it ;)

Thanks for the pointer
Paul

On Sep 27, 10:03 am, Nathan Sorenson  wrote:
> I am following the general strategy described in Sam Tobin-Hochstadt's
> work. He is the person behind typed-racket. His Phd dissertation[1]
> has an overview of the area of gradual/soft/refinement typing in
> dynamic languages. It's a good place to start, with a pretty gentle
> introduction to the motivations and issues involved (though I'd
> imagine you'd need a rough understanding of sequent calculus notation
> to follow his description of the semantics of his type system).
>
> [1]http://www.ccs.neu.edu/home/samth/
>
> On Sep 27, 12:43 am, Paul Koerbitz  wrote:
>
>
>
>
>
>
>
> > Hi Nathan!
>
> > I am very intrigued by your approach. I would love to contribute, my problem
> > is that I don't know the first thing about type inference systems (as in how
> > they work on the inside). Do you have a good reference here? I'll take a
> > look at what you've done, maybe bother you with some questions  Thanks
> > for the work!
>
> > cheers
> > Paul
>
> > On Fri, Sep 23, 2011 at 04:47, Nathan Sorenson  wrote:
> > > Yes I am very hopeful progress is made on that front! I've been having
> > > great success with 'Constraint Handling Rules' (CHR), which serves as
> > > my basis for solving type constraints.
> > >https://github.com/nsorenson/Clojure-CHR
> > > contains my very preliminary crack at implementing this system.
>
> > > The trick with dynamic languages such as Clojure is that the functions
> > > are extremely lax in what they accept--without a fairly advanced
> > > inference system, you will simply infer every variable to be type
> > > Object. I've been using CHR disjunctive branches to offer what's
> > > called "occurrence typing"--a system where you may assign different
> > > types to variables depending on the structure of the code. For
> > > instance, if you have a (map? x) as a predicate on an if clause, you
> > > know in the 'then' branch that x can be typed to Map.
>
> > > Nothing to show yet, and I'm not sure how well it will work on large
> > > programs, but my first few little experiments are looking promising.
>
> > > On Sep 22, 3:28 am, Javier Neira Sanchez  wrote:
> > > > i am surprised nobody mentioned gradual/optional typing<
> > >http://lambda-the-ultimate.org/node/1707>,
> > > > typed racket   and the possible
> > > type
> > > > checker to be built by *some clever hacker* on core.logic<
> > >https://github.com/clojure/core.logic>some day.
>
> > > --
> > > 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: Does macros evaluates its arguments before?

[ru]

You are right, Alan!

And in this case Closure compiler behave itself also unpredictably and
quite the contrary:
Where it must evaluate a symbol (like in this case), it doesn't.
Where it mustn't evaluate a symbol (argument of macro), it does.
So, need to have comprehensive and profound knowledge about its
behavior, including subtleties, even in very simple use cases.
Your explanation show this quite clearly.

On 27 сен, 02:42, Alan Malloy  wrote:
> I suspect your repl was stale, since this doesn't work at all. By an
> amusing coincidence, though, it doesn't break, just returns the wrong
> answer:
>
> user=> (defmacro infix [e] `(let [[x# f# y#] '~e] (f# x# y#)))
> #'user/infix
> user=> (infix (5 + 4))
> 4
>
> That is, the *symbol* +, not the function +, is called as a function.
> Symbols act like keywords in that they look themselves up in maps. The
> "map" 5 does not contain the symbol '+, so the not-found value of 4 is
> returned.
>
> On Sep 26, 10:22 am, ru  wrote:
>
>
>
>
>
>
>
> > Thanks to all!
>
> > With your help I have found the solution that coincide with Bronsa's
> > (my special respect to Bronsa):
>
> > user=> (defmacro infix [e] `(let [[x# f# y#] '~e] (f# x# y#)))
> > #'user/infix
> > user=> (infix (5 + 4))
> > 9
>
> > But, this solution seems to me awkward and showing that Clojure
> > compiler does not handling quite strictly language specification
> > requirements. I.e., this single quote compiler should substitute
> > itself to fulfill requirement of unevaluation arguments of macro.
>
> > Sincerely,
> >   Ru

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

docs for 1.3

[Sergey Didenko]

Is the README file from Clojure on github the best 1.3 documentation
for the moment?

For example, I can't find a mention of "Factory function taking a map"
, e.g. map->MyRecord on the main clojure.org

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

Clojure v1.4 - what is new, changed and in development

[Michael Jaaka]

Hi!

I would be nice If after entering on 
http://clojure.github.com/clojure/branch-master/index.html I could see what 
is new, what has changed (just bold new methods, cross the removed one and 
skew the changed one) links and what new concepts are in progress. I think 
that it is easy to do.
For two first things all you have to do is to make diff on functions set (by 
name for what is new and what is removed, and by its content for what has 
changed).
What is in progress unfortunately must be managed manually, because it is 
developed in terms of concept, not of functions.

I really would like to hear what is going on in my favorite language.

-- 
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: Clojure v1.4 - what is new, changed and in development

[Michael Jaaka]

Btw. Cheat Sheet doesn't look good on iPad. Some columns are shifted

-- 
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: Clojure v1.4 - what is new, changed and in development

[Michael Jaaka]

Ohh... And it would be nice if hovering with mouse pointer on function name 
in cheetsheet would show tool tip (made with AJAX; the results would be 
cached; thought about clojurescript - its a high time to proof its 
usability) with functions description and signature and after clicking link 
"more" in it, it would also show the implementation (again AJAX with 
clojurescript), it would be very useful for newbees, like me.

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

New Clojure Brush for Alex Gorbatchev's SyntaxHighlighter

[J . Pablo Fernández]

Hello,

I took Travis Whitton's brush for Clojure[1] for Alex Gorbatchev's 
SyntaxHighlighter[2] and put it in a git repo in GitHub, with an index file 
to easy development and trying it out. I also fixed some bugs and did some 
improvements. The new code is here:

https://github.com/pupeno/clojure_brush

Cheers!

[1] 
http://travis-whitton.blogspot.com/2009/06/syntaxhighlighter-for-clojure.html?showComment=1317124626851#c3205000945287389700

[2] http://alexgorbatchev.com/SyntaxHighlighter/

-- 
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: Does macros evaluates its arguments before?

[Mark Rathwell]

> And in this case Closure compiler behave itself also unpredictably and
> quite the contrary:
> Where it must evaluate a symbol (like in this case), it doesn't.

Symbols need to be namespace resolved in order to be evaluated
properly.  This is something you need to be aware of, but it is not
unpredictable or contrary to any documentation.  And again, in this
case, the evaluation of the plus symbol does not happen at macro
expansion, it happens at run time.  The behavior here is the same
inside of and outside of a macro:

user=> (def e '(5 + 2))
#'user/e
user=> (eval `((nth '~e 1) (nth e 0) (nth e 2)))
2
user=> (eval `((nth (list ~@e) 1) (nth e 0) (nth e 2)))
7

> Where it mustn't evaluate a symbol (argument of macro), it does.

This has already been shown in several responses, the argument is not
being evaluated in macro expansion, it is being evaluated at runtime.
Using macroexpand will help you to see what the expanded forms look
like and what namespace symbols are resolved to.

-- 
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: trace-forms macro

[Michał Marczyk]

On 26 September 2011 18:46, Jonathan Fischer Friberg
 wrote:
> To Marczyk:
> Sure, where to?

Great, thanks!

The relevant details are available on this page:

http://clojure.org/contributing

There's a one-page form to print out, sign and send off to Rich by
snail mail. Once it's processed, your name will be put on the list of
contributors and you can sign up for the clojure-dev ggroup and JIRA
(see http://dev.clojure.org/).

Sincerely,
Michał

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

Shameless self promotion - JavaOne

[Dennis]

Hey guys,

I will be giving a talk at JavaOne (it is Clojure related).  Here is
the information.

Title:  Monitoring a Large-Scale Infrastructure with Clojure
Time Tuesday, 07:30 PM, Parc 55 - Embarcadero
Length  45 Minutes
Abstract:   Monitoring a large infrastructure brings unique 
challenges
that require blending development and operations concepts. This
session discusses how Dell Inc. used Clojure to develop a
data-flow-based monitoring system that stores, evaluates, and acts on
hundreds of thousands of metrics.

It covers
• Real-world applications of Clojure's parallel programming constructs
to take advantage of multiple cores available in today's systems
• Using Clojure's homoiconic nature to create DSLs
• Taking advantage of Clojure running on the JVM to use the Java ecosystem
• How DevOps takes advantage of the JVM dynamic languages to develop
new monitoring tools
Track   Emerging Languages, Tools, and Techniques
Optional Track  The Java Frontier

-- Dennis

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

statistics library?

[Lee Spector]

I need to do some pretty simple statistics in a Clojure program and Incanter 
produces results that I think must be wrong (details below). So I don't think I 
can trust it.

Is there other code for statistical testing out there? Or maybe somebody could 
explain to me how to interpret the seemingly anomalous Incanter results? (I 
received no reply on the Incanter list). I only need a t-test at the moment, 
but this is a bit of a pain to code from scratch (because of the table that it 
uses).

I'm trying to use an un-paired, two-tailed t-test to tell whether the means of 
two sets of numbers differ significantly. (Whether or not this is the right 
test for my application -- e.g. whether the assumptions of normal distributions 
are valid -- is another matter. I just want to know it the tests are being 
calculated correctly.)

If I understand correctly the t-test should produce a p-value which ranges from 
0 to 1. If it's less than 0.05 we can say that the means differ. (Again, there 
would be more to say here about what's statistically meaningful, but that 
discussion isn't relevant to my question).

Again, if I understand correctly, under no circumstances should the p-value 
ever be outside of the range from 0 to 1. It's a probability, and no value 
outside of that range makes any sense. But Incanter sometimes returns p-values 
greater than 1.

Sometimes it seems to give reasonable results:

=> (use 'incanter.stats)
nil

=> (t-test [2 3 4 3 2 3] :y [3 4 5 6 5 4 3])
{:conf-int [-2.6129722457891322 -0.2917896589727722],
 :x-mean 2.8335,
 :t-stat -2.7883256115163184,
 :p-value 0.018335366451909547,
 :n1 6,
 :df 10.519255193727584,
 :n2 7,
 :y-var 1.2380952380952408,
 :x-var 0.5658,
 :y-mean 4.285714285714286}

But in other cases the :p-value is over 1. Here's an example from Incanter's 
own documentation:

=> (t-test (range 1 11) :mu 0)
{:conf-int [3.33414941027723 7.66585058972277],
:x-mean 5.5,
:t-stat 5.744562646538029,
:p-value 1.9997218039889517,
:n1 10,
:df 9,
:n2 nil,
:y-var nil,
:x-var 9.166,
:y-mean nil}

Here's an example that's closer to what can arise in my application, and again 
I just don't see how the calculation can be right if it's producing this kind 
of p-value:

=> (t-test '(40 5 2) :y '(1 5 1))
{:conf-int [-39.46068349230474 66.12735015897141],
 :x-mean 15.666,
 :t-stat 1.0866516498483223,
 :p-value 1.6115506955016772,
 :n1 3,
 :df 2.0477900396893336,
 :n2 3,
 :y-var 5.332,
 :x-var 446.37,
 :y-mean 2.3335}

Am I missing something that would rationalize these results? 

If not, then does anyone have a pointer to more reliable statistics code in 
Clojure? Or pointers to using a Java library? I see that there are libraries 
out there -- e.g. 
http://commons.apache.org/math/api-1.2/org/apache/commons/math/stat/inference/TTest.html
 -- but Java interop is not my strong suit and I'm not sure how to call this 
from my Clojure code.

Any pointers would be appreciated.

Thanks,

 -Lee

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

Re: Clojure v1.4 - what is new, changed and in development

[Andy Fingerhut]

Pardon my ignorance -- I've not done anything with AJAX before.  Is there a
way to do this in a single HTML file, and include all of the tooltips in
that file?

If so, do you have an example of this I could use to learn from?  Just two
or three links each with different tooltips would be enough to get me
started.

Thanks,
Andy

On Tue, Sep 27, 2011 at 4:23 AM, Michael Jaaka  wrote:

> Ohh... And it would be nice if hovering with mouse pointer on function name
> in cheetsheet would show tool tip (made with AJAX; the results would be
> cached; thought about clojurescript - its a high time to proof its
> usability) with functions description and signature and after clicking link
> "more" in it, it would also show the implementation (again AJAX with
> clojurescript), it would be very useful for newbees, like me.
>
> --
> 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: Clojure v1.4 - what is new, changed and in development

[tmountain]

> Is there a
> way to do this in a single HTML file, and include all of the tooltips in
> that file?

Yes, there is. There are a lot of options out there, but I've found
qTip to be pretty simple.

http://craigsworks.com/projects/qtip/demos/content/basic

If you don't want to use any third-party libraries, you could cache
the tooltips in hidden  elements and then display them as
needed.

On Sep 27, 12:51 pm, Andy Fingerhut  wrote:
> Pardon my ignorance -- I've not done anything with AJAX before.  Is there a
> way to do this in a single HTML file, and include all of the tooltips in
> that file?
>
> If so, do you have an example of this I could use to learn from?  Just two
> or three links each with different tooltips would be enough to get me
> started.
>
> Thanks,
> Andy
>
> On Tue, Sep 27, 2011 at 4:23 AM, Michael Jaaka 
>
>
>
>
>
>
> > wrote:
> > Ohh... And it would be nice if hovering with mouse pointer on function name
> > in cheetsheet would show tool tip (made with AJAX; the results would be
> > cached; thought about clojurescript - its a high time to proof its
> > usability) with functions description and signature and after clicking link
> > "more" in it, it would also show the implementation (again AJAX with
> > clojurescript), it would be very useful for newbees, like me.
>
> > --
> > 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: defrecord and overriding "empty"

[David Nolen]

The problem is what does empty mean in the context of defrecord? A new
instance of a defrecord is not "empty", it has those fields and they are set
to nil.

David

On Tue, Sep 27, 2011 at 3:48 AM, Nathan Sorenson  wrote:

> I'm using clojure.walk/postwalk to rewrite terms in nested data
> structures. However, I am unable to do this with types as defined by
> defrecord, because they specify that the function "empty"  throw a not-
> implemented exception.
>
> If I were able to over-ride this default implementation of 'empty' I
> believe I could still use postwalk to rewrite my custom records (as
> they happily implement 'into' which works as expected.)
>
> This was my obvious first attempt:
>
> (defrecord TypeVar [guid name]
>  clojure.lang.IPersistentCollection
>  (empty [coll] (TypeVar. 0 nil)))
>
> Which fails due to:
>
> "Duplicate method name&signature in class file types/TypeVar"
>  [Thrown class java.lang.ClassFormatError]
>
> I would prefer not to fall back on deftype as I do wish these objects
> to behave as maps. I also could write my own version of postwalk that
> doesn't call 'empty' on my custom-defined records, but it would be
> nice to make my types adhere to the contract of IPersistentCollection
> as much as possible.

-- 
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: Shameless self promotion - JavaOne

[Aaron Bedra]

On a similar note, I will also be at J1 representing Clojure in the 
script bowl.  It is wednesday morning at 8:30.  The audience chooses the 
winner, so if you are at J1 and want to support Clojure, you have your 
chance!


Cheers,

Aaron Bedra
--
Clojure/core
http://clojure.com


On 09/27/2011 11:50 AM, Dennis wrote:

Hey guys,

I will be giving a talk at JavaOne (it is Clojure related).  Here is
the information.

Title:  Monitoring a Large-Scale Infrastructure with Clojure
Time Tuesday, 07:30 PM, Parc 55 - Embarcadero
Length  45 Minutes
Abstract:   Monitoring a large infrastructure brings unique 
challenges
that require blending development and operations concepts. This
session discusses how Dell Inc. used Clojure to develop a
data-flow-based monitoring system that stores, evaluates, and acts on
hundreds of thousands of metrics.

It covers
• Real-world applications of Clojure's parallel programming constructs
to take advantage of multiple cores available in today's systems
• Using Clojure's homoiconic nature to create DSLs
• Taking advantage of Clojure running on the JVM to use the Java ecosystem
• How DevOps takes advantage of the JVM dynamic languages to develop
new monitoring tools
Track   Emerging Languages, Tools, and Techniques
Optional Track  The Java Frontier

-- Dennis



--
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: statistics library?

[Johann Hibschman]

Lee Spector  writes:

> I need to do some pretty simple statistics in a Clojure program and
> Incanter produces results that I think must be wrong (details
> below). So I don't think I can trust it.

I agree, those all look weird to me.

> Is there other code for statistical testing out there?

I'd reach for commons-math, but I don't have much experience.

> If I understand correctly the t-test should produce a p-value which
> ranges from 0 to 1. If it's less than 0.05 we can say that the means
> differ. (Again, there would be more to say here about what's
> statistically meaningful, but that discussion isn't relevant to my
> question).

This is true.

> => (t-test (range 1 11) :mu 0)
> {:conf-int [3.33414941027723 7.66585058972277],
> :x-mean 5.5,
> :t-stat 5.744562646538029,
> :p-value 1.9997218039889517,
> :n1 10,
> :df 9,
> :n2 nil,
> :y-var nil,
> :x-var 9.166,
> :y-mean nil}

This looks wrong to me.  At least according to R, the p-value is
0.00278.  Interestingly, this is 2 - [incanter's p].

> => (t-test '(40 5 2) :y '(1 5 1))
> {:conf-int [-39.46068349230474 66.12735015897141],
>  :x-mean 15.666,
>  :t-stat 1.0866516498483223,
>  :p-value 1.6115506955016772,
>  :n1 3,
>  :df 2.0477900396893336,
>  :n2 3,
>  :y-var 5.332,
>  :x-var 446.37,
>  :y-mean 2.3335}

R gives 0.3884, which is again 2 - [incanter's p].  Fishy.

I would say that there's a bug in Incanter's distribution function, at
least when calculating values in the tails.

> If not, then does anyone have a pointer to more reliable statistics
> code in Clojure? Or pointers to using a Java library? I see that there
> are libraries out there --
> e.g. 
> http://commons.apache.org/math/api-1.2/org/apache/commons/math/stat/inference/TTest.html
> -- but Java interop is not my strong suit and I'm not sure how to call
> this from my Clojure code.

There may be an easier way to do this, but this worked for me:

  user=> (org.apache.commons.math.stat.inference.TestUtils/tTest
(into-array Double/TYPE [40 5 2]) (into-array Double/TYPE [1 5 1]))
  0.3884493044983227

Hope that helps,
Johann

-- 
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: Does macros evaluates its arguments before?

[ru]

On 27 сен, 16:45, Mark Rathwell  wrote:
> > And in this case Closure compiler behave itself also unpredictably and
> > quite the contrary:
> > Where it must evaluate a symbol (like in this case), it doesn't.
>
> Symbols need to be namespace resolved in order to be evaluated
> properly.  This is something you need to be aware of, but it is not
> unpredictable or contrary to any documentation.  And again, in this
> case, the evaluation of the plus symbol does not happen at macro
> expansion, it happens at run time.  The behavior here is the same
> inside of and outside of a macro:
>
> user=> (def e '(5 + 2))
> #'user/e
> user=> (eval `((nth '~e 1) (nth e 0) (nth e 2)))
> 2
> user=> (eval `((nth (list ~@e) 1) (nth e 0) (nth e 2)))
> 7
>
> > Where it mustn't evaluate a symbol (argument of macro), it does.
>
> This has already been shown in several responses, the argument is not
> being evaluated in macro expansion, it is being evaluated at runtime.

In this point I want to cite Clojure doc, that say nothing about
expansion and runtime,  once more: "..If the operator of a call is a
symbol that names a global var that is a macro function, that macro
function is called and is passed the /unevaluated/ operand forms. "
So, when I write the macro function body, I expect that operands are
unevaluated when my body is executed to get an expanded form (finally
expanded), that will be executed afterward to get a result (at
runtime, as you say). But this is not the case in the very first
example:

user=> (defmacro infix [e] `(let [[x# f# y#] ~e] (f# x# y#)))
#'user/infix
user=> (infix (5 + 4))
java.lang.ClassCastException: java.lang.Integer cannot be cast to
clojure.lang.IFn (NO_SOURCE_FILE:0)

I insist that expansion is not quite correct. Am I right?

> Using macroexpand will help you to see what the expanded forms look
> like and what namespace symbols are resolved to.

-- 
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: statistics library?

[Johann Hibschman]

Johann Hibschman  writes:

> There may be an easier way to do this, but this worked for me:
>
>   user=> (org.apache.commons.math.stat.inference.TestUtils/tTest
> (into-array Double/TYPE [40 5 2]) (into-array Double/TYPE [1 5 1]))
>   0.3884493044983227

I should have used (double-array [40 5 2]) here, but for some reason I
couldn't remember it until I hit send.

-- 
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: Does macros evaluates its arguments before?

[David Nolen]

2011/9/27 ru 

>
> user=> (defmacro infix [e] `(let [[x# f# y#] ~e] (f# x# y#)))
> #'user/infix
> user=> (infix (5 + 4))
> java.lang.ClassCastException: java.lang.Integer cannot be cast to
> clojure.lang.IFn (NO_SOURCE_FILE:0)
>
> I insist that expansion is not quite correct. Am I right?


Your macro expands the source into an incorrect form. Better versions have
already been given.

David

-- 
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: Does macros evaluates its arguments before?

[Mark Rathwell]

> In this point I want to cite Clojure doc, that say nothing about
> expansion and runtime,  once more: "..If the operator of a call is a
> symbol that names a global var that is a macro function, that macro
> function is called and is passed the /unevaluated/ operand forms. "
> So, when I write the macro function body, I expect that operands are
> unevaluated when my body is executed to get an expanded form (finally
> expanded), that will be executed afterward to get a result (at
> runtime, as you say). But this is not the case in the very first
> example:

Yes, it is the case.  The operands are not evaluated in the expansion
of the macro call, they are evaluated when that expanded code is
executed at run time.

> user=> (defmacro infix [e] `(let [[x# f# y#] ~e] (f# x# y#)))
> #'user/infix
> user=> (infix (5 + 4))
> java.lang.ClassCastException: java.lang.Integer cannot be cast to
> clojure.lang.IFn (NO_SOURCE_FILE:0)
>
> I insist that expansion is not quite correct. Am I right?

No, you are incorrect.  The expansion happens as would be expected,
and is completely consistent with the documentation.  If you use
macroexpand here, it is clear what is going on.  The expansion of your
macro contains a call to a function '5', which is an integer, and
cannot be cast to a function.  As I stated previously, you want a list
here, not a function call.

-- 
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: defrecord and overriding "empty"

[Nathan Sorenson]

You're right that my use isn't strictly returning a collection with a size 
of zero-- I'm treating empty more like 'default'. I'm thinking of its use in 
clojure.walk, which simply creates a "blank" version of an arbitrary 
collection in which to place the altered sub-forms. I can't find any other 
usages of 'empty' in the std lib.

I agree it's a bit of a mismatch, as 'walk' won't be able to alter the 
built-in keys of a record, but you wouldn't expect that to happen if you 
were using records.

Should IPersistentCollection even be defining 'empty', if one of the 
language's key data types doesn't support it? I think it would be better to 
either pull 'empty' into it's own protocol so clojure.walk doesn't match on 
IPersistentCollection when walking a data structure with the false 
expectation that it can create an empty version, or rename 'empty' it to 
something that records can implement, like 'default.' 

-- 
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: defrecord and overriding "empty"

[David Nolen]

On Tue, Sep 27, 2011 at 1:54 PM, Nathan Sorenson  wrote:

> Should IPersistentCollection even be defining 'empty', if one of the
> language's key data types doesn't support it? I think it would be better to
> either pull 'empty' into it's own protocol so clojure.walk doesn't match on
> IPersistentCollection when walking a data structure with the false
> expectation that it can create an empty version, or rename 'empty' it to
> something that records can implement, like 'default.'


This is a fair point. ClojureScript fixes this by providing
IEmptyableCollection.

David

-- 
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: statistics library?

[Lee Spector]

On Sep 27, 2011, at 1:37 PM, Johann Hibschman wrote:

> Johann Hibschman  writes:
> 
>> There may be an easier way to do this, but this worked for me:
>> 
>>  user=> (org.apache.commons.math.stat.inference.TestUtils/tTest
>>(into-array Double/TYPE [40 5 2]) (into-array Double/TYPE [1 5 1]))
>>  0.3884493044983227
> 
> I should have used (double-array [40 5 2]) here, but for some reason I
> couldn't remember it until I hit send.

Hooray! This is beautiful.

I had to tinker a bit to find/download the library jars and get my runtime 
environment to find them, but then this did exactly what I wanted.

Thanks so much for the confirmation and solution!

 -Lee

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

Re: Does macros evaluates its arguments before?

[ru]

  i i i i i i i   ooooo   o   o
  I I I I I I I  8 8   8   8 8 o  88
  I  \ `+' /  I  8 8   8 888
   \  `-+-'  /   8 8   8  o   8
`-__|__-'8 8   8   8  8
|8 o   8   8 o 8  8
  --+--   o8oo  ooo8ooo   o   8

Добро пожаловать GNU CLISP 2.46 (2008-07-02) 

Copyright (c) Bruno Haible, Michael Stoll 1992, 1993
Copyright (c) Bruno Haible, Marcus Daniels 1994-1997
Copyright (c) Bruno Haible, Pierpaolo Bernardi, Sam Steingold 1998
Copyright (c) Bruno Haible, Sam Steingold 1999-2000
Copyright (c) Sam Steingold, Bruno Haible 2001-2008

Напечатайте :h и нажмите Ввод для получения справки.

[1]> (defmacro infix (e)
 `(destructuring-bind (x f y) ,e
 (funcall f x y)))
INFIX
[2]> (infix (5 + 4))

*** - EVAL: 5 не является именем функции, попробуйте какой-нибудь
символ
Имеются следующие варианты продолжения:
USE-VALUE  :R1  Вы можете ввести новое значение для
использования.
ABORT  :R2  Прервать главный цикл
Break 1 [3]> :r2
[4]> (infix '(5 + 4))
9
[5]>

All, I give up! :)

On 27 сен, 21:44, Mark Rathwell  wrote:
> > In this point I want to cite Clojure doc, that say nothing about
> > expansion and runtime,  once more: "..If the operator of a call is a
> > symbol that names a global var that is a macro function, that macro
> > function is called and is passed the /unevaluated/ operand forms. "
> > So, when I write the macro function body, I expect that operands are
> > unevaluated when my body is executed to get an expanded form (finally
> > expanded), that will be executed afterward to get a result (at
> > runtime, as you say). But this is not the case in the very first
> > example:
>
> Yes, it is the case.  The operands are not evaluated in the expansion
> of the macro call, they are evaluated when that expanded code is
> executed at run time.
>
> > user=> (defmacro infix [e] `(let [[x# f# y#] ~e] (f# x# y#)))
> > #'user/infix
> > user=> (infix (5 + 4))
> > java.lang.ClassCastException: java.lang.Integer cannot be cast to
> > clojure.lang.IFn (NO_SOURCE_FILE:0)
>
> > I insist that expansion is not quite correct. Am I right?
>
> No, you are incorrect.  The expansion happens as would be expected,
> and is completely consistent with the documentation.  If you use
> macroexpand here, it is clear what is going on.  The expansion of your
> macro contains a call to a function '5', which is an integer, and
> cannot be cast to a function.  As I stated previously, you want a list
> here, not a function call.

-- 
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: Does macros evaluates its arguments before?

[David Nolen]

2011/9/27 ru 

> All, I give up! :)


You're macro will still be incorrect in CLISP, SBCL, CMUCL, Clozure MCL,
ABCL, MIT Scheme, Gambit Scheme, Chicken, Ikarus, Racket etc. ;)

David

-- 
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: can't see the error

[Dennis Haupt]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Am 27.09.2011 06:27, schrieb Baishampayan Ghose:
>> i wasn't really trying to achieve anything useful - just messing 
>> around and see where i get.
>> 
>> now i'm here: (defrecord point [x y z]) (defn genPoints [n] (let
>> [random (new Random) randomInt #(.nextInt random) randomPoint
>> #(new point (randomInt) (randomInt) (randomInt))] (repeatedly n
>> randomPoint)))
>> 
>> is there a way to avoid writing (randomInt)(randomInt)(randomInt)
>> and instead something like (magic (repeatedly 3 randomInt))?
> 
> This is how I would write it -
> 
> (defrecord Point [x y z])
> 
> ;;; Only needed in pre Clojure 1.3.0 ;;; In Clojure 1.3.0, ->Point
> will be generated automatically ;; (defn ->Point ;;   [x y z] ;;
> (Point. x y z))
> 
> (defn gen-points [n] (let [random (java.util.Random.) random-int
> #(.nextInt random) random-point #(apply ->Point (repeatedly 3
> random-int))] (repeatedly n random-point)))
> 
> Hope this helps.
> 
> Regards, BG
> 

yes it does :)

- -- 

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJOght3AAoJENRtux+h35aG+AIP/j3ufGpS74wSSDv1RyAJjx2V
S7cdRuF4U00tanW1OAn/PYY93iT0wcXBgKowuo/jD9+C0TV5K7/he33KeSRrJCnb
vLEq8B1Um4JOc1V7MZZBaqtIfJcaQ3s5fcPtPdITX97dX79A3WSItU3/Fc+UYC2i
eF7p99dNLToF2KQhQPZ0Wb37gyIit/XExWiuTx8FIkNzLsL/cPQFMJpcG5Thw9pF
6EKImZOH2A6zOgO68nbynxV4D2vOW7VKkJb7B61XgRILf9bfLqspg/GmEeXaBTrp
gNXSbE7AFAHp6bA08nvydfr9H68z1H53i79mLxlDVXsq3MjGiHVddDa1SaG9SwwV
Vt7K0IndKqFonoI5WUj9CRnxWDoDhy35zwSolJOZhAjSSBHDdZCa9fa0BUU5HXu6
15z3RTG9nOk6OIQJeJiKNGaHtPdplJ0ugHFCDhLpsQZoG8z6QWT6n6BxDwRU9w3i
bEobBms8PqEsTWf1MmwJxLPyA/UC0wVKNiMdqheyydVZ/siGJzXN6fgJYFFUXPhT
KElmSJPeV6Ee56GG2ttDFSSblP+At2Kv3zJZQqUnbEhiu6a3L6ofrybTkaUjASWK
KXcnTYEy/ARi2lc+lD39pgM9YKJOOvgX9f3cGFe8mi4B1nZ5nlzrciyN3eJy8QaL
/MJvl1yQRxdWqQX1xLsQ
=vR6l
-END PGP SIGNATURE-

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

suggestion for clojure development

[Arthur Edelstein]

Dear Everyone,

I would like to make a suggestion for the future of Clojure, and
hopefully prompt a discussion. My comment comes as a result of my
experience trying to port code to 1.3. I have run into numerous
problems, most of which come from 1.3's incompatibilities with my 1.2-
targeted code and the libraries I am using.

While I hope and expect that none of the problems I'm encountering are
insurmountable, they are requiring substantial time and effort. It
raises the question of what happens to all of the many existing
Clojure 1.2-based libraries in Clojars and on github. Many of these
are very useful, but not necessarily actively maintained. A lot of
effort will need to go into porting this code and much of it may be
effectively lost. That seems like an unfortunate waste and it
undermines the growing ecosystem of Clojure libraries.

So my request for Clojure's future development, is that backwards
compatibility not be broken. This means that Clojure code needs a way
of designating what Clojure version it is targeted for. Then, for
example, the Clojure 1.4 jar should be able to "drop down" into
backwards compatibility mode to compile and run 1.3-code, or invoke a
1.3-script's vars from a 1.4 script. It would also be super-cool if
someone can figure out how to do this for existing 1.2 libraries.

I love that Clojure is being constantly improved and developed, and I
thank everyone who has been working so hard on it. In my opinion,
though, third-party libraries are as important as the core language.
Clojure 1.3 interoperates with java libraries very well -- so why not
with Clojure 1.2 libraries?

Best regards,
Arthur

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

Re: [ANN] Clojure 1.3 Released

[Sean Corfield]

On Fri, Sep 23, 2011 at 2:44 PM, Christopher Redinger
 wrote:
> We are pleased to announce today the release of Clojure 1.3:

We took Clojure 1.3 into production today, along with a lot more
Clojure code compared to our previous production release. We've
converted all of our profile publishing and searching code to Clojure
now (from Scala and CFML respectively) and we're liking the initial
results we're seeing (improved stability and performance).

> The number of Clojure contributors continues to grow. Thanks to all
> the people whose code is included in this release:

Great work folks - thank you!
-- 
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/
Railo Technologies, Inc. -- http://www.getrailo.com/

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

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

Re: [ANN] Clojure 1.3 Released

[Bruce Durling]

Sean,

On Tue, Sep 27, 2011 at 20:17, Sean Corfield  wrote:
> On Fri, Sep 23, 2011 at 2:44 PM, Christopher Redinger
>  wrote:
>> We are pleased to announce today the release of Clojure 1.3:
>
> We took Clojure 1.3 into production today, along with a lot more
> Clojure code compared to our previous production release. We've
> converted all of our profile publishing and searching code to Clojure
> now (from Scala and CFML respectively) and we're liking the initial
> results we're seeing (improved stability and performance).

That is great to hear. So happy to see someone use a lot of clojure in
production. Congrats on the release.

cheers,
Bruce

-- 
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: Does macros evaluates its arguments before?

[Alan Malloy]

It seems you are enjoying spewing accusations at Clojure, but if your
goal is to actually get something done, you would get a lot more out
of this discussion if your attitude were "Huh, I expected x but see y!
Is that a bug or am I wrong? Oh I see, it's not a bug? I still don't
understand, please explain". You are behaving like "OMG this is such a
bug how come nobody but me sees this obvious error in Clojure?" when
respected and experienced members of the community try to help you, an
apparent novice, with an interesting topic. This does nothing to
advance your knowledge, and frustrates the people who would otherwise
be eager to help.

On Sep 27, 2:13 am, ru  wrote:
> You are right, Alan!
>
> And in this case Closure compiler behave itself also unpredictably and
> quite the contrary:
> Where it must evaluate a symbol (like in this case), it doesn't.
> Where it mustn't evaluate a symbol (argument of macro), it does.
> So, need to have comprehensive and profound knowledge about its
> behavior, including subtleties, even in very simple use cases.
> Your explanation show this quite clearly.
>
> On 27 сен, 02:42, Alan Malloy  wrote:
>
>
>
>
>
>
>
> > I suspect your repl was stale, since this doesn't work at all. By an
> > amusing coincidence, though, it doesn't break, just returns the wrong
> > answer:
>
> > user=> (defmacro infix [e] `(let [[x# f# y#] '~e] (f# x# y#)))
> > #'user/infix
> > user=> (infix (5 + 4))
> > 4
>
> > That is, the *symbol* +, not the function +, is called as a function.
> > Symbols act like keywords in that they look themselves up in maps. The
> > "map" 5 does not contain the symbol '+, so the not-found value of 4 is
> > returned.
>
> > On Sep 26, 10:22 am, ru  wrote:
>
> > > Thanks to all!
>
> > > With your help I have found the solution that coincide with Bronsa's
> > > (my special respect to Bronsa):
>
> > > user=> (defmacro infix [e] `(let [[x# f# y#] '~e] (f# x# y#)))
> > > #'user/infix
> > > user=> (infix (5 + 4))
> > > 9
>
> > > But, this solution seems to me awkward and showing that Clojure
> > > compiler does not handling quite strictly language specification
> > > requirements. I.e., this single quote compiler should substitute
> > > itself to fulfill requirement of unevaluation arguments of macro.
>
> > > Sincerely,
> > >   Ru

-- 
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: ClojureScript Repl -- Swank-like workflow with Emacs?

[Volker Schlecht]

Hi Paul,

sorry, I was blindly assuming you were starting a browser repl without
hooking it up with a browser :)

Reversing your posts, that becomes clear ...

What happens when you do the following

M-x set-variable

enter: inferior-lisp-program

enter: "/path/to/repl/script"

M-x inferior-lisp

?

regards,
Volker
On Sep 27, 9:02 am, Paul Koerbitz  wrote:
> Hi Volker,
>
> not sure I understand you correctly. You should still be able to type
> into the repl and get results, even if it is 'in-browser', right? At
> least that works for me if I start the browser repl on the command
> line. So it should also work in Emacs, I am pretty sure its something
> weird with my setup.
>
> (Btw. My previous shorter reply should have arrived __after__ the
> longer (see timestamps), not sure why google groups is mixing up the
> order of my emails)
>
> cheers
> Paul
>
> On Sep 26, 11:14 pm, Volker Schlecht 
> wrote:
>
>
>
>
>
>
>
> > The example given in the wiki uses an in-browser repl. If you want to
> > work with the "regular" rhino-repl, replace
>
> > (require '[cljs.repl.browser :as browser])
>
> > with
>
> > (require '[cljs.repl.rhino :as rhino])
>
> > And you should be all set.
>
> > On Sep 26, 4:28 pm, Paul Koerbitz  wrote:
>
> > > Hi David!
>
> > > thanks for the fast reply and this solution.
>
> > > I haven't gotten it to work yet, but this is more than likely due to me 
> > > not
> > > really understanding how to put all the moving parts together.
>
> > > Here is what I did:
>
> > > Put your code into 'browser-repl'. Now if I execute this on the command 
> > > line
> > > I get this prompt
>
> > > #'user/env
> > > "Type: " :cljs/quit " to quit"
> > > Starting Server on Port: 9000
> > > ClojureScript:cljs.user>
>
> > > and when I open up some page with clojure script (e.g.
> > > samples/repl/index.html) I can execute sutff in the browser such as
> > > (js/alert "hello, world!").
>
> > > However, if I run the script as an inferior-lisp process I also get this
> > > output in the *inferior-lisp* window
>
> > > #'user/env
> > > "Type: " :cljs/quit " to quit"
> > > Starting Server on Port: 9000
> > > ClojureScript:cljs.user>
>
> > > but I can't connect the browser. the file still loads but if I enter stuff
> > > in the repl the repl just hangs.
>
> > > I am sure I am missing something, right now I just don't see what.
>
> > > thanks for the help so far.
> > > Paul
>
> > > On Mon, Sep 26, 2011 at 15:55, David Nolen  wrote:
> > > > I've created the following wiki -
> > > >https://github.com/clojure/clojurescript/wiki/Emacs-&-inferior-lisp-mode
>
> > > > Let me know if this needs more clarification.
>
> > > > David
>
> > > > On Mon, Sep 26, 2011 at 9:15 AM, Paul Koerbitz 
> > > > wrote:
>
> > > >> Dear Clojurians,
>
> > > >> I was toying with Clojurescript and really like using the Repl as
> > > >> described herehttps://github.com/clojure/clojurescript/wikitotry
> > > >> things out. (thanks for all the great to everyone involved!!)
>
> > > >> Has anyone hooked this into Emacs in a Swank-like fashion? I would 
> > > >> love to
> > > >> be able to send forms to C-c C-c or ''compile'' a file with C-c C-k.
>
> > > >> thanks
> > > >> Paul
>
> > > >> --
> > > >> 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: ClojureScript Repl -- Swank-like workflow with Emacs?

[Volker Schlecht]

s/repl/repljs/

-- 
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: Does macros evaluates its arguments before?

[ru]

Alan,

Please forgive me. I am very sorry. May be my English is not so good.
Simply, I stupidly kept the idea that macro differs from the function
in that is evaluated twice, the first time with the unevaluated
arguments. When I saw that even in Lisp it is not the case, I gave up :
(

Sincerely,
  Ru

On 27 сен, 23:23, Alan Malloy  wrote:
> It seems you are enjoying spewing accusations at Clojure, but if your
> goal is to actually get something done, you would get a lot more out
> of this discussion if your attitude were "Huh, I expected x but see y!
> Is that a bug or am I wrong? Oh I see, it's not a bug? I still don't
> understand, please explain". You are behaving like "OMG this is such a
> bug how come nobody but me sees this obvious error in Clojure?" when
> respected and experienced members of the community try to help you, an
> apparent novice, with an interesting topic. This does nothing to
> advance your knowledge, and frustrates the people who would otherwise
> be eager to help.
>
> On Sep 27, 2:13 am, ru  wrote:
>
>
>
>
>
>
>
> > You are right, Alan!
>
> > And in this case Closure compiler behave itself also unpredictably and
> > quite the contrary:
> > Where it must evaluate a symbol (like in this case), it doesn't.
> > Where it mustn't evaluate a symbol (argument of macro), it does.
> > So, need to have comprehensive and profound knowledge about its
> > behavior, including subtleties, even in very simple use cases.
> > Your explanation show this quite clearly.
>
> > On 27 сен, 02:42, Alan Malloy  wrote:
>
> > > I suspect your repl was stale, since this doesn't work at all. By an
> > > amusing coincidence, though, it doesn't break, just returns the wrong
> > > answer:
>
> > > user=> (defmacro infix [e] `(let [[x# f# y#] '~e] (f# x# y#)))
> > > #'user/infix
> > > user=> (infix (5 + 4))
> > > 4
>
> > > That is, the *symbol* +, not the function +, is called as a function.
> > > Symbols act like keywords in that they look themselves up in maps. The
> > > "map" 5 does not contain the symbol '+, so the not-found value of 4 is
> > > returned.
>
> > > On Sep 26, 10:22 am, ru  wrote:
>
> > > > Thanks to all!
>
> > > > With your help I have found the solution that coincide with Bronsa's
> > > > (my special respect to Bronsa):
>
> > > > user=> (defmacro infix [e] `(let [[x# f# y#] '~e] (f# x# y#)))
> > > > #'user/infix
> > > > user=> (infix (5 + 4))
> > > > 9
>
> > > > But, this solution seems to me awkward and showing that Clojure
> > > > compiler does not handling quite strictly language specification
> > > > requirements. I.e., this single quote compiler should substitute
> > > > itself to fulfill requirement of unevaluation arguments of macro.
>
> > > > Sincerely,
> > > >   Ru

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

Re: [ANN] Clojure 1.3 Released

[Sean Corfield]

On Tue, Sep 27, 2011 at 12:22 PM, Bruce Durling  wrote:
> That is great to hear. So happy to see someone use a lot of clojure in
> production. Congrats on the release.

Thanx. You can get a lot done with just a little Clojure. We stand at
1,829 lines of production Clojure code and 448 lines of unit tests so
far (and a lot of non-Clojure code - but that is slowly migrating to
Clojure as we do any substantial work on the backend of our system).
-- 
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/
Railo Technologies, Inc. -- http://www.getrailo.com/

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

-- 
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: Does macros evaluates its arguments before?

[Michał Marczyk]

Hi Ru,

let's input your macro definition at the REPL:

user> (defmacro infix [e] `(let [[x# f# y#] ~e] (f# x# y#)))
#'user/infix

So far so good. Now let's try use it in a function:

user> (defn foo [] (infix (5 + 4)))
#'user/foo

Well now -- it compiled! So, there's no exception being thrown when
the macro is expanded at compile time; otherwise foo would not have
compiled.

How about calling foo?

user> (foo)
; Evaluation aborted.
user> *e
#

There's your exception: at runtime. By this time there is no trace of
your macro in the running code (you could undefine it -- by saying
(ns-unmap 'user 'infix) -- and this would have no effect on foo).


Once again: (5 + 4) *is not evaluated when the macro is expanded*. It
is only evaluated at runtime -- and only then does it explode, as
expected. The key point is that a macro is just a function called upon
by the compiler to transform your program prior to it being compiled
into JVM bytecode (in the case of Clojure, or perhaps native code in
the case of some Common Lisp implementations and execution by the
interpreter in interpreted Lisps); if it generates erroneous code
(like this version of infix!), that erroneous code will be compiled by
the compiler and eventually explode when you run it -- an unpleasant
occurrence completely distinct from a macro-expansion-time exception.

Sincerely,
Michał

-- 
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: suggestion for clojure development

[Phil Hagelberg]

On Tue, Sep 27, 2011 at 11:57 AM, Arthur Edelstein
 wrote:
> So my request for Clojure's future development, is that backwards
> compatibility not be broken. This means that Clojure code needs a way
> of designating what Clojure version it is targeted for. Then, for
> example, the Clojure 1.4 jar should be able to "drop down" into
> backwards compatibility mode to compile and run 1.3-code, or invoke a
> 1.3-script's vars from a 1.4 script. It would also be super-cool if
> someone can figure out how to do this for existing 1.2 libraries.

I'm all for breaking as little as possible, and it's worth pointing
out that before the 1.3 release I have seen a total of two
backwards-incompatible changes to Clojure since starting to use it in
2008, even going a fair ways before 1.0 was released. However, a full
backwards-compatible emulation layer is asking an awful lot of the
Clojure maintainers. I personally would rather see them spend their
time on moving Clojure forward than legacy support.

> I love that Clojure is being constantly improved and developed, and I
> thank everyone who has been working so hard on it. In my opinion,
> though, third-party libraries are as important as the core language.
> Clojure 1.3 interoperates with java libraries very well -- so why not
> with Clojure 1.2 libraries?

You could do this with an independent classloader containing the old
jars. It wouldn't be as seamless as regular method calls, but as long
as the number of places where you cross the version boundary is fairly
small it shouldn't be too heinous. I don't think this belongs in
Clojure itself at all.

-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

October Amsterdam Clojure

[Hubert Iwaniuk]

Good news everyone! *

tl;dr -> http://bit.ly/ams-clj

On Wednesday, October 12th Amsterdam Clojurians is organizing October Amsterdam 
Clojure.

Same as last year, we are proud to have a great speaker: Uncle Bob Martin.

Sourcesense.com is our proud sponsor and made it possible to host the event in 
great venue DeZwijger.nl.

This year we will have 3 talks:
- Cleaner than Java by Cees van Kemenade
- Baking a Clojure webapp in 15m by Pepijn de Vos, Hubert Iwaniuk
- The Case for Clojure by Uncle Bob Martin

Please feel invited and register (we have limited seating) at 
http://bit.ly/ams-clj
 
Looking forward to meeting you on Wednesday, October 12th,
Your hosts.


* http://www.youtube.com/watch?v=1D1cap6yETA

-- 
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: statistics library?

[labwork07]

Yes, those errors in Incanter are unfortunate. I had another weird one  
occurred which David Liebke attributed to the underlying Colt library.

user=> (sd (repeat 9 0.65))
NaN

The sd function calls the variance function, which calls a function in
Colt; the trouble is Colt is returning a number very, very close to
zero, but just a bit under (ie it's negative)

user=> (variance (repeat 9 0.65))
-1.1102230246251565E-16

and the sqrt of a negative number is NaN.

On , Lee Spector  wrote:


I need to do some pretty simple statistics in a Clojure program and  
Incanter produces results that I think must be wrong (details below). So  
I don't think I can trust it.




Is there other code for statistical testing out there? Or maybe somebody  
could explain to me how to interpret the seemingly anomalous Incanter  
results? (I received no reply on the Incanter list). I only need a t-test  
at the moment, but this is a bit of a pain to code from scratch (because  
of the table that it uses).




I'm trying to use an un-paired, two-tailed t-test to tell whether the  
means of two sets of numbers differ significantly. (Whether or not this  
is the right test for my application -- eg whether the assumptions of  
normal distributions are valid -- is another matter. I just want to know  
it the tests are being calculated correctly.)




If I understand correctly the t-test should produce a p-value which  
ranges from 0 to 1. If it's less than 0.05 we can say that the means  
differ. (Again, there would be more to say here about what's  
statistically meaningful, but that discussion isn't relevant to my  
question).




Again, if I understand correctly, under no circumstances should the  
p-value ever be outside of the range from 0 to 1. It's a probability, and  
no value outside of that range makes any sense. But Incanter sometimes  
returns p-values greater than 1.





Sometimes it seems to give reasonable results:





=> (use 'incanter.stats)



nil





=> (t-test [2 3 4 3 2 3] :y [3 4 5 6 5 4 3])



{:conf-int [-2.6129722457891322 -0.2917896589727722],



:x-mean 2.8335,



:t-stat -2.7883256115163184,



:p-value 0.018335366451909547,



:n1 6,



:df 10.519255193727584,



:n2 7,



:y-var 1.2380952380952408,



:x-var 0.5658,



:y-mean 4.285714285714286}




But in other cases the :p-value is over 1. Here's an example from  
Incanter's own documentation:





=> (t-test (range 1 11) :mu 0)



{:conf-int [3.33414941027723 7.66585058972277],



:x-mean 5.5,



:t-stat 5.744562646538029,



:p-value 1.9997218039889517,



:n1 10,



:df 9,



:n2 nil,



:y-var nil,



:x-var 9.166,



:y-mean nil}




Here's an example that's closer to what can arise in my application, and  
again I just don't see how the calculation can be right if it's producing  
this kind of p-value:





=> (t-test '(40 5 2) :y '(1 5 1))



{:conf-int [-39.46068349230474 66.12735015897141],



:x-mean 15.666,



:t-stat 1.0866516498483223,



:p-value 1.6115506955016772,



:n1 3,



:df 2.0477900396893336,



:n2 3,



:y-var 5.332,



:x-var 446.37,



:y-mean 2.3335}





Am I missing something that would rationalize these results?




If not, then does anyone have a pointer to more reliable statistics code  
in Clojure? Or pointers to using a Java library? I see that there are  
libraries out there -- eg  
http://commons.apache.org/math/api-1.2/org/apache/commons/math/stat/inference/TTest.html  
-- but Java interop is not my strong suit and I'm not sure how to call  
this from my Clojure code.





Any pointers would be appreciated.





Thanks,





-Lee





--



You received this message because you are subscribed to the Google



Groups "Clojure" group.



To post to this group, send email to clojure@googlegroups.com


Note that posts from new members are moderated - please be patient with  
your first post.



To unsubscribe from this group, send email to



clojure+unsubscr...@googlegroups.com



For more options, visit this group at



http://groups.google.com/group/clojure?hl=en


--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To 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: suggestion for clojure development

[Andreas Kostler]

I'm with Phil on that one. Legacy support slows or even hinders innovation.
On Sep 28, 2011 6:06 AM, "Phil Hagelberg"  wrote:
> On Tue, Sep 27, 2011 at 11:57 AM, Arthur Edelstein
>  wrote:
>> So my request for Clojure's future development, is that backwards
>> compatibility not be broken. This means that Clojure code needs a way
>> of designating what Clojure version it is targeted for. Then, for
>> example, the Clojure 1.4 jar should be able to "drop down" into
>> backwards compatibility mode to compile and run 1.3-code, or invoke a
>> 1.3-script's vars from a 1.4 script. It would also be super-cool if
>> someone can figure out how to do this for existing 1.2 libraries.
>
> I'm all for breaking as little as possible, and it's worth pointing
> out that before the 1.3 release I have seen a total of two
> backwards-incompatible changes to Clojure since starting to use it in
> 2008, even going a fair ways before 1.0 was released. However, a full
> backwards-compatible emulation layer is asking an awful lot of the
> Clojure maintainers. I personally would rather see them spend their
> time on moving Clojure forward than legacy support.
>
>> I love that Clojure is being constantly improved and developed, and I
>> thank everyone who has been working so hard on it. In my opinion,
>> though, third-party libraries are as important as the core language.
>> Clojure 1.3 interoperates with java libraries very well -- so why not
>> with Clojure 1.2 libraries?
>
> You could do this with an independent classloader containing the old
> jars. It wouldn't be as seamless as regular method calls, but as long
> as the number of places where you cross the version boundary is fairly
> small it shouldn't be too heinous. I don't think this belongs in
> Clojure itself at all.
>
> -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

documentation problem with Atom

[Robert McIntyre]

Just wanted to report that the documentation for atom misspells

"become" as "be come"

--Robert McIntyre

-- 
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: statistics library?

[David Powell]

> Again, if I understand correctly, under no circumstances should the p-value 
> ever be outside of the range from 0 to 1. It's a probability, and no value 
> outside of that range makes any sense. But Incanter sometimes returns 
> p-values greater than 1.

I see that there was a recent fix made to Incanter:

Fixed typo in :lower-tail? keyword.
This was causing the complement of the p-value to be returned.

https://github.com/liebke/incanter/pull/39


Have you tried the latest version in git?  Does this fix the problem?

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

Re: Does macros evaluates its arguments before?

[Andreas Kostler]

This is quite amusing since the first reply to the original post already
provided the correct answer :)
On Sep 28, 2011 6:05 AM, "Michał Marczyk"  wrote:
> Hi Ru,
>
> let's input your macro definition at the REPL:
>
> user> (defmacro infix [e] `(let [[x# f# y#] ~e] (f# x# y#)))
> #'user/infix
>
> So far so good. Now let's try use it in a function:
>
> user> (defn foo [] (infix (5 + 4)))
> #'user/foo
>
> Well now -- it compiled! So, there's no exception being thrown when
> the macro is expanded at compile time; otherwise foo would not have
> compiled.
>
> How about calling foo?
>
> user> (foo)
> ; Evaluation aborted.
> user> *e
> # cannot be cast to clojure.lang.IFn>
>
> There's your exception: at runtime. By this time there is no trace of
> your macro in the running code (you could undefine it -- by saying
> (ns-unmap 'user 'infix) -- and this would have no effect on foo).
>
>
> Once again: (5 + 4) *is not evaluated when the macro is expanded*. It
> is only evaluated at runtime -- and only then does it explode, as
> expected. The key point is that a macro is just a function called upon
> by the compiler to transform your program prior to it being compiled
> into JVM bytecode (in the case of Clojure, or perhaps native code in
> the case of some Common Lisp implementations and execution by the
> interpreter in interpreted Lisps); if it generates erroneous code
> (like this version of infix!), that erroneous code will be compiled by
> the compiler and eventually explode when you run it -- an unpleasant
> occurrence completely distinct from a macro-expansion-time exception.
>
> Sincerely,
> Michał
>
> --
> 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: suggestion for clojure development

[Sean Corfield]

On Tue, Sep 27, 2011 at 11:57 AM, Arthur Edelstein
 wrote:
> raises the question of what happens to all of the many existing
> Clojure 1.2-based libraries in Clojars and on github. Many of these
> are very useful, but not necessarily actively maintained. A lot of

Are therein lies the problem: if they are not actively maintained,
you're not going to get bug fixes even on Clojure 1.2. This was true
of a large number of contrib modules as well and as we can see from
http://dev.clojure.org/display/design/Where+Did+Clojure.Contrib+Go a
lot of the Clojure Contrib 1.2.0 modules are unmaintained and some
won't work with Clojure 1.3.0 :(

> So my request for Clojure's future development, is that backwards
> compatibility not be broken.

I don't think that it's reasonable to expect Clojure to be always
beholden to unmaintained third party libraries.

What I've been doing is approaching the author(s) of a library where I
needed Clojure 1.3.0 compatibility and offered to help them update the
code so it works on Clojure 1.2.x and 1.3.0. This clearly helps me -
and requires surprisingly little time investment - and it also helps
every other user of those libraries.

If a library truly has no maintainer, relying on it - especially for
production code - is a little risky in my opinion.

> I love that Clojure is being constantly improved and developed, and I
> thank everyone who has been working so hard on it. In my opinion,
> though, third-party libraries are as important as the core language.
> Clojure 1.3 interoperates with java libraries very well -- so why not
> with Clojure 1.2 libraries?

I think the better approach is to ensure third party libraries are
updated and available to all Clojure users - instead of placing the
burden on the Clojure/core team, for a bunch of libraries over which
they have no control.
-- 
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/
Railo Technologies, Inc. -- http://www.getrailo.com/

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

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

iterate with side-effect function?

[siyu798]

Hi,
   From clojure doc, it states iterate takes a side-effect free function, 
and what's the implication if the function has side-effect as follow?

(->> 0
  (iterate (fn [cnt]
(prn cnt)
;; save data to csv
(Thread/sleep 6000)
(inc cnt)))
  (take-while (partial > 10))
  last)

Thanks,
siyu

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

Clojurescript output effect

[Brent Millare]

I'm trying to figure out why when I require('cljs.core') in a
javascript file, the hello world example doesn't work.

hello.js
goog.require('cljs.core');   ;;<--- If I delete this line,
then everything works.
goog.require('goog.dom');

function sayHi() {
var myc__2284 = goog.dom.createDom("canvas",
{"width":"300","height":"225","style":"border:1px dotted"});
var context__2285 = myc__2284.getContext("2d");
context__2285.font = "bold 12px sans-serif";
context__2285.fillText("hello wurld",50,50);
return goog.dom.appendChild(document.body,myc__2284);
};

index.html


  


  
  
  



I was trying to cut away at what clojurescript outputs since I was
trying to rule out what line was breaking the code. And oddly enough,
it was the require line. What's going on here?

-- 
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: Clojurescript output effect

[David Nolen]

What was the error and what were your compile options?

On Tuesday, September 27, 2011, Brent Millare 
wrote:
> I'm trying to figure out why when I require('cljs.core') in a
> javascript file, the hello world example doesn't work.
>
> hello.js
> goog.require('cljs.core');   ;;<--- If I delete this line,
> then everything works.
> goog.require('goog.dom');
>
> function sayHi() {
>var myc__2284 = goog.dom.createDom("canvas",
> {"width":"300","height":"225","style":"border:1px dotted"});
>var context__2285 = myc__2284.getContext("2d");
>context__2285.font = "bold 12px sans-serif";
>context__2285.fillText("hello wurld",50,50);
>return goog.dom.appendChild(document.body,myc__2284);
> };
>
> index.html
> 
> 
>  
>
>
>  
>  
>  
> 
>
>
> I was trying to cut away at what clojurescript outputs since I was
> trying to rule out what line was breaking the code. And oddly enough,
> it was the require line. What's going on here?
>
> --
> 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: Clojurescript output effect

[Brent Millare]

You can try out the code I posted, but basically I wanted to create a
hello world canvas. Without the require, I get the canvas. With the
require, I get a blank white page.

There isn't any error message, which is what made this particularly
difficult to narrow.

-Brent

On Sep 27, 7:01 pm, David Nolen  wrote:
> What was the error and what were your compile options?
>
> On Tuesday, September 27, 2011, Brent Millare 
> wrote:
>
>
>
>
>
>
>
> > I'm trying to figure out why when I require('cljs.core') in a
> > javascript file, the hello world example doesn't work.
>
> > hello.js
> > goog.require('cljs.core');               ;;<--- If I delete this line,
> > then everything works.
> > goog.require('goog.dom');
>
> > function sayHi() {
> >    var myc__2284 = goog.dom.createDom("canvas",
> > {"width":"300","height":"225","style":"border:1px dotted"});
> >    var context__2285 = myc__2284.getContext("2d");
> >    context__2285.font = "bold 12px sans-serif";
> >    context__2285.fillText("hello wurld",50,50);
> >    return goog.dom.appendChild(document.body,myc__2284);
> > };
>
> > index.html
> > 
> > 
> >  
> >    
> >    
> >  
> >  
> >  
> > 
>
> > I was trying to cut away at what clojurescript outputs since I was
> > trying to rule out what line was breaking the code. And oddly enough,
> > it was the require line. What's going on here?
>
> > --
> > 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: suggestion for clojure development

[Brian Marick]

On Sep 27, 2011, at 5:18 PM, Sean Corfield wrote:
> Are therein lies the problem: if they are not actively maintained,
> you're not going to get bug fixes even on Clojure 1.2. 


I think "is it actively maintained?" is not a particularly interesting question 
for a community. The question is: "is this a useful library?" Then: "is the 
original author maintaining it?" And then, if not: "who will pick it up?"

What a language community cares about is "Can I easily do X in Clojure?" For a 
community to grow, the answer should be "Why, yes!". That answer shouldn't 
depend on historical details like who first wrote a library.

People matter less than code.

-
Brian Marick, Artisanal Labrador
Now working at http://path11.com
Contract programming in Ruby and Clojure
Occasional consulting on Agile


-- 
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: statistics library?

[Lee Spector]

On Sep 27, 2011, at 5:44 PM, David Powell wrote:

> I see that there was a recent fix made to Incanter:
> 
> Fixed typo in :lower-tail? keyword.
> This was causing the complement of the p-value to be returned.
> 
> https://github.com/liebke/incanter/pull/39
> 
> 
> Have you tried the latest version in git?  Does this fix the problem?

Hmm. I had asked about the version on the Incanter list too. I now see that I 
was using a *newer* version than the newest one at 
https://github.com/liebke/incanter. 

I grabbed what appeared to be the newest on clojars, which is [incanter 
"1.2.3"], while the newest download on that github project page appears to be 
1.2.2 from April 20, 2010.

It does sound like the comment that you quoted might indeed be about the bug 
that I ran into, so maybe it's fixed in some version of Incanter somewhere... 
But for my current purposes I have more faith in 
[org.apache.commons/commons-math "2.0"].

Thanks,

 -Lee

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

Re: suggestion for clojure development

[Sean Corfield]

On Tue, Sep 27, 2011 at 4:28 PM, Brian Marick  wrote:
> I think "is it actively maintained?" is not a particularly interesting 
> question for a community. The question is: "is this a useful library?" Then: 
> "is the original author maintaining it?" And then, if not: "who will pick it 
> up?"

Well, I'd hope that we can find (active) maintainers for libraries
that are actually useful :)

I got an email off-list asking what to do about code that relies on
clojure.contrib.str-utils2 with a link to documentation on the
richhickey.github.com repo. That namespace isn't even in the list of
contrib modules in
https://github.com/clojure/clojure-contrib/tree/master/modules so I
can only assume it was migrated to clojure.string as part of Clojure
1.2.0 (along with c.c.string and c.c.str-utils). For me, that's
"pre-history". As Clojure continues to grow in popularity, that will
be pre-history for the vast majority of Clojure users too - for anyone
who picks up Clojure first via 1.3.0.

Anything we can do to clean up outdated documentation, web pages,
blogs and so on will help all those who come along from this point on.

The pain of migrating from Contrib 1.2.0 (or earlier) to the New
Contrib Libraries (whether you stay on Clojure 1.2.x or move to
Clojure 1.3.0) is a one-time "tax" for early adopters and, as
unpleasant as that may be, I expect future migrations to be easier
even if Clojure introduces breaking changes because the libraries that
make this jump are more likely to continue to be actively maintained
(as long as they remain useful).
-- 
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/
Railo Technologies, Inc. -- http://www.getrailo.com/

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

-- 
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: suggestion for clojure development

[Phil Hagelberg]

On Tue, Sep 27, 2011 at 4:43 PM, Sean Corfield  wrote:
> The pain of migrating from Contrib 1.2.0 (or earlier) to the New
> Contrib Libraries (whether you stay on Clojure 1.2.x or move to
> Clojure 1.3.0) is a one-time "tax" for early adopters and, as
> unpleasant as that may be, I expect future migrations to be easier
> even if Clojure introduces breaking changes because the libraries that
> make this jump are more likely to continue to be actively maintained
> (as long as they remain useful).

I would like to add a  feature to Clojars to indicate whether a
library is designed to work with multiple verisons of Clojure. It
shouldn't be terribly difficult to summarize what versions of Clojure
(and other libraries) that a library explicitly depends upon, but
going further it would be great to check to see whether it's set up to
test against multiple dependency sets and further still tie into
http://travis-ci.org to see whether the tests actually pass for these
various versions.

Of course, if anyone wants to beat me to it I would be thrilled.

-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

Re: iterate with side-effect function?

[Nathan Sorenson]

Because the fn is wrapped in a lazy sequence, the effects won't run if you 
ask for the same value again-- 

For instance:

(def a (iterate (fn [cnt]
(prn cnt)
;; save data to csv
(inc cnt)) 0))

(nth a 5) ... all the effects are fired.
(nth a 5) ... simply returns 5-- no effects are fired because the lazy 
sequence has already been realized up to this point. This may not be what 
you expect.

Also, you shouldn't in general trust effects to be run the 'correct' amount 
of times. For instance, if we were operating on a chunked-sequence, if you 
asked for the 3rd element, you would get the side effects for the next 32 
elements, which may not be what you'd expect. That doesn't happen to be the 
case here but it's something to keep in mind as well.

-- 
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: trace-forms macro

[Luc Prefontaine]

Fine, I merged the new version and I will add a couple of tests related to 
these changes.

Luc

On Mon, 26 Sep 2011 18:46:12 +0200
Jonathan Fischer Friberg  wrote:

> I looked at it today and have updated the macro.
> (same gist: https://gist.github.com/1209498)
> 
> Additions:
> It detects if a form contains (recur ...), and if it does,
> the form isn't wrapped in (try ...).
> 
> trace vectors, maps, and sets.
> 
> trace (fn* ...) & (new ...)
> 
> ---
> 
> The code feels a bit "thrown together" right now, if anyone would
> like to take a look,
> that would be great.
> 
> ---
> 
> To Marczyk:
> Sure, where to?
> 
> Jonathan
> 
> On Sat, Sep 24, 2011 at 10:27 PM, Michał Marczyk
> wrote:
> 
> > Oh, that's a nice idea! Definitely looks like a worthy addition to
> > the trace lib.
> >
> > I believe the process around contributions to contrib involves a CA,
> > though; Jonathan: do you have one in place? Any chance you might be
> > convinced to submit one if not? :-)
> >
> > Sincerely,
> > Michał
> >
> > --
> > 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
> >
> 



-- 
Luc P.


The rabid Muppet

-- 
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: suggestion for clojure development

[Arthur Edelstein]

On Sep 27, 4:43 pm, Sean Corfield  wrote:
> On Tue, Sep 27, 2011 at 4:28 PM, Brian Marick  wrote:
> > I think "is it actively maintained?" is not a particularly interesting 
> > question for a community. The question is: "is this a useful library?" 
> > Then: "is the original author maintaining it?" And then, if not: "who will 
> > pick it up?"
>
> Well, I'd hope that we can find (active) maintainers for libraries
> that are actually useful :)

I hope so, too, but very often this doesn't happen in practice. Much
useful code is not maintained.

If I add a dependency from Clojars or maven central to my project.clj
file, I don't want to pay the tax of deciding what Clojure version it
is and whether it is actively maintained, and waiting for the
maintainer to respond to me, and, if he or she does not, debugging the
library myself and then resubmitting it to clojars. Of course this can
be necessary when there are bugs, but now almost all the 1400+
libraries in Clojars are suspect because of the 1.2 to 1.3 transition.
I consider this to be incidental complexity and I am "tired/old/lazy"/
stupid. I want to simply use the library. Clojure indeed is
brilliantly designed exactly to make libraries easy to use (by using
immutable data and avoiding the OOP pitfall of excessively complex
types) and this breaking transition from 1.2 to 1.3 tends to undermine
that achievement.

I do like Phil's classloader suggestion, but I wonder if there might
be a way for leiningen to automatically provide a transparent wrapper
around 1.2 jars so that they can be called by 1.3 code without local
(eval-in-1.3 ...) macros.

Arthur

-- 
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: Clojurescript output effect

[Brent Millare]

Also as for compile options, there are none. I initially tried
advanced, but again got a blank page. So I tried no args, and it made
the "out" folder. I looked in there and saw the generated js file. I
looked through that, and edited each line to look like my working js
code. In the end, translating the require is what seemed to prevent
the behavior.

-Brent

On Sep 27, 7:26 pm, Brent Millare  wrote:
> You can try out the code I posted, but basically I wanted to create a
> hello world canvas. Without the require, I get the canvas. With the
> require, I get a blank white page.
>
> There isn't any error message, which is what made this particularly
> difficult to narrow.
>
> -Brent
>
> On Sep 27, 7:01 pm, David Nolen  wrote:
>
>
>
>
>
>
>
> > What was the error and what were your compile options?
>
> > On Tuesday, September 27, 2011, Brent Millare 
> > wrote:
>
> > > I'm trying to figure out why when I require('cljs.core') in a
> > > javascript file, the hello world example doesn't work.
>
> > > hello.js
> > > goog.require('cljs.core');               ;;<--- If I delete this line,
> > > then everything works.
> > > goog.require('goog.dom');
>
> > > function sayHi() {
> > >    var myc__2284 = goog.dom.createDom("canvas",
> > > {"width":"300","height":"225","style":"border:1px dotted"});
> > >    var context__2285 = myc__2284.getContext("2d");
> > >    context__2285.font = "bold 12px sans-serif";
> > >    context__2285.fillText("hello wurld",50,50);
> > >    return goog.dom.appendChild(document.body,myc__2284);
> > > };
>
> > > index.html
> > > 
> > > 
> > >  
> > >    
> > >    
> > >  
> > >  
> > >  
> > > 
>
> > > I was trying to cut away at what clojurescript outputs since I was
> > > trying to rule out what line was breaking the code. And oddly enough,
> > > it was the require line. What's going on here?
>
> > > --
> > > 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: suggestion for clojure development

[Stuart Halloway]

> I hope so, too, but very often this doesn't happen in practice. Much
> useful code is not maintained.
> 
> If I add a dependency from Clojars or maven central to my project.clj
> file, I don't want to pay the tax of deciding what Clojure version it
> is and whether it is actively maintained,

Clojars has a super-low barrier to entry. This is great for getting a lot of 
code published, but I don't see how you can use Clojars (or anything like it) 
without having to verify some basic facts about the code you are using.  Better 
metadata would be great, but you would still want to check it.

FWIW, on my commercial work we ban clojars and review the source code of every 
dependency.

> Of course this can
> be necessary when there are bugs, but now almost all the 1400+
> libraries in Clojars are suspect because of the 1.2 to 1.3 transition.

Let's start by fixing the most important ones. Sean Corfield and others are 
leading the way with contribs. Any candidates for a short list of libs that 
need updates ASAP?

> I consider this to be incidental complexity and I am "tired/old/lazy"/
> stupid. I want to simply use the library. Clojure indeed is
> brilliantly designed exactly to make libraries easy to use (by using
> immutable data and avoiding the OOP pitfall of excessively complex
> types) and this breaking transition from 1.2 to 1.3 tends to undermine
> that achievement.
> 
> I do like Phil's classloader suggestion, but I wonder if there might
> be a way for leiningen to automatically provide a transparent wrapper
> around 1.2 jars so that they can be called by 1.3 code without local
> (eval-in-1.3 ...) macros.

This sounds big and hairy compared to simple detect-and-warn or detect-and-fail 
approaches. 

Stu


Stuart Halloway
Clojure/core
http://clojure.com

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

Re: advantage of dynamic typing

[Lee Spector]

On Sep 27, 2011, at 3:40 AM, Paul Koerbitz wrote:

> That said, I read somewhere (can't find the link now, sorry) that 
> compile-time type checking in Lisps is difficult because they allow code 
> generation at run time? That would still leave the possibility to apply it to 
> everything which is evaluated at compile time which I assume is 99.5% of all 
> clojure code.

FWIW I tend to generate a lot of code at runtime. But maybe my stuff is in the 
other 0.5%. 

I do remember Rich Hickey stressing the dynamic nature of the language in one 
of the videos that introduced me to Clojure, and this was a major attraction to 
me and perhaps to others...

 -Lee

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

Re: iterate with side-effect function?

[siyu798]

Nathan,
Thanks for the explanation, what i'm trying to do is to "repeatedly" run 
a side-effect function until the return value of it meets certain criteria. 
 It could have been done using loop/recur as shown below, and wondering if 
there's alternatives.  Is a there general approach to accomplish this?

(loop [ctx (init-ctx)]
  (let [ctx (side-effect-operations)]
 (if (ctx :done?) 
   ctx
   (recur ctx)))


siyu


-- 
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: iterate with side-effect function?

[Nathan Sorenson]

Quite often I convince myself I need state or some effectful trigger, but 
further thought reveals a simpler stateless approach.

That being said--if you absolutely need to be doing something based on 
effects, something that absolutely can't be tracked via values in a purely 
functional way--like polling a queue once per second (functional-reactive 
programming notwithstanding), I personally prefer straight loop/recur to the 
list processing functions. In my mind, usings seq/filter/map suggests you 
are doing something lazy, referentially transparent, and composable. If you 
are not doing that, a loop recur signals to me you are manipulating the 
execution flow in a precise way. 

But again, I always try to find a way to avoid dealing with the messy 
stateful world until the last possible moment. Lots of application logic can 
be completely pure with one small "write to file"-type operation at the end.

-- 
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: suggestion for clojure development

[Sean Corfield]

On Tue, Sep 27, 2011 at 7:33 PM, Arthur Edelstein
 wrote:
> I hope so, too, but very often this doesn't happen in practice. Much
> useful code is not maintained.

My position on free open source software is that if it's that useful
to someone, then that someone has at least some obligation to
contribute back to the community somehow. In the case of useful
software with no active maintainer, that contribution can sometimes be
the path to becoming the new maintainer :)

> If I add a dependency from Clojars or maven central to my project.clj
> file, I don't want to pay the tax of deciding what Clojure version it
> is and whether it is actively maintained

With all due respect, I think that's an unreasonable expectation: this
is free open source software we're talking about, created and
maintained by the community at large. Figuring out those things is the
tax you generally have to pay with free open source software.

When you're selecting a library to solve a particular problem, you
normally have to do some research and evaluate more than one library
so, for me, the activity of the project and software versions
supported are part of that necessary research. I can't imagine "just
using" some random library without doing some legwork...?

Phil's suggestion of adding metadata to Clojars might help - but of
course for libraries not being actively maintained, there will be no
metadata because there will be no one to update it and for libraries
that are actively maintained, they'll likely support both Clojure
1.2.x and Clojure 1.3.0 fairly soon anyway...
-- 
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/
Railo Technologies, Inc. -- http://www.getrailo.com/

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

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

tools.trace (was Re: trace-forms macro on the clojure mailing list)

[Luc Prefontaine]

Hi,

First shot of tools.trace is now available on github:

http://github.com/clojure/tools.trace

As for the traceforms macro, you will notice that when an exception is trapped, 
I recompose
an new exception with the necessary form traceback information instead of using 
print.
The main reason is that I want the form traceback to stay close to the 
exception message.
Otherwise if you run several threads writing to stdout, you may end up with 
split
outputs on standard output (the exception message in one spot and the form 
traceback elsewhere)

Comments/suggestions are welcomed.

The README.MD is on its way and I still need to review the code to see if they 
are
remaining rough edges. Nothing beats a paper output and a coffee...

I expect to work on the build process next week-end and get the first version 
out next week.

Time to go to bed, my eyes are now useless ...

Luc P.

On Mon, 26 Sep 2011 18:46:12 +0200
Jonathan Fischer Friberg  wrote:

> I looked at it today and have updated the macro.
> (same gist: https://gist.github.com/1209498)
> 
> Additions:
> It detects if a form contains (recur ...), and if it does,
> the form isn't wrapped in (try ...).
> 
> trace vectors, maps, and sets.
> 
> trace (fn* ...) & (new ...)
> 
> ---
> 
> The code feels a bit "thrown together" right now, if anyone would
> like to take a look,
> that would be great.
> 
> ---
> 
> To Marczyk:
> Sure, where to?
> 
> Jonathan
> 
> On Sat, Sep 24, 2011 at 10:27 PM, Michał Marczyk
> wrote:
> 
> > Oh, that's a nice idea! Definitely looks like a worthy addition to
> > the trace lib.
> >
> > I believe the process around contributions to contrib involves a CA,
> > though; Jonathan: do you have one in place? Any chance you might be
> > convinced to submit one if not? :-)
> >
> > Sincerely,
> > Michał
> >
> > --
> > 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
> >
> 



-- 
Luc P.


The rabid Muppet

-- 
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: suggestion for clojure development

[Arthur Edelstein]

> When you're selecting a library to solve a particular problem, you
> normally have to do some research and evaluate more than one library
> so, for me, the activity of the project and software versions
> supported are part of that necessary research. I can't imagine "just
> using" some random library without doing some legwork...?

I appreciate what you're saying, and I think it is true to some
extent, but on the other hand, I think in practice many people
experiment with libraries to see if they work, and use the libraries
without being absolutely sure that they work perfectly. You may think
I'm doing it wrong, but I don't think I'm alone at all. I feel that
Flaubert's quote really reflects the situation. For example, I
recently used the Brent function minimization algorithm in commons
math (which admittedly has a decent reputation). I didn't review the
source code of the implementation carefully -- it's too complicated --
but as far as I can tell, the code works well for my application, and
that part of my app passes various tests. The risk of bugs from that
library is nonzero, but acceptable to me.

For clojure to break backwards compatibility is levying an extra cost
beyond these usual risks. I agree, as Andreas suggested, that there is
a cost to the speed of innovation in the language if one maintains
backwards compatibility, but on the other hand I think breaking
backwards compatibility imposes a cost to the community and slows down
library innovation. We are comparing the costs to two different groups
-- the language developers and the users, and I am a user whining
about the pain. I just hope Clojure's re-birthing pains will be
minimized in the future. ;)

> Phil's suggestion of adding metadata to Clojars might help

Yes, I think it will be very helpful to mark which jars are compatible
with 1.2 or 1.3 -- I suppose this can be extracted from the
dependencies vector in the project.clj file. And Stu's suggestion of
detect-and-warn or detect-and-fail are also very valuable, since right
now the situation is that mysterious errors occur without warning.

Arthur

-- 
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: suggestion for clojure development

[Sean Corfield]

On Wed, Sep 28, 2011 at 12:03 AM, Arthur Edelstein
 wrote:
> You may think
> I'm doing it wrong, but I don't think I'm alone at all.

I don't think you're doing anything wrong - and I'm sure many people
only do minimal research on tools they use. I just think your
expectations of Clojure the language are unrealistic, in terms of
maintaining total compatibility with the myriad third party (and
sometimes unmaintained) libraries.

For comparison, Scala went thru a lot of binary compatibility issues
in the transition from 2.7 to 2.8, to the point that even milestone
builds were not always compatible with each other. This meant the
entire tool chain had to be rebuilt on almost every milestone build.
Apparently there were a few similar bumps on the transition to 2.9 (I
don't know for sure: I lived thru the 2.7 to 2.8 debacle and chose not
to go to 2.9).

I hear similar stories for other fast-evolving languages. I think it's
just a fact of life with "new" technologies - and we pay that price
for being early adopters.

> Yes, I think it will be very helpful to mark which jars are compatible
> with 1.2 or 1.3 -- I suppose this can be extracted from the
> dependencies vector in the project.clj file.

Unlikely. Some libraries that depend on contrib 1.2.0 run on Clojure
1.3.0 just fine, some libraries that depend on new contrib modules are
not yet compatible with 1.3.0 (no dynamic metadata on earmuffed
variables is the most common issue I think but the numeric
improvements may also cause incompatibilities).

As I said, even with metadata in Clojars, unmaintained libraries won't
get updates to show what version they're compatible with and actively
maintained libraries should quickly transition to supporting both
Clojure 1.2.x and 1.3.0 so it may be moot anyway...
-- 
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/
Railo Technologies, Inc. -- http://www.getrailo.com/

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

-- 
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: tools.trace (was Re: trace-forms macro on the clojure mailing list)

[Sean Corfield]

Thank you Luc!

On Tue, Sep 27, 2011 at 11:44 PM, Luc Prefontaine
 wrote:
> First shot of tools.trace is now available on github:
>
> http://github.com/clojure/tools.trace
>
> As for the traceforms macro, you will notice that when an exception is 
> trapped, I recompose
> an new exception with the necessary form traceback information instead of 
> using print.
> The main reason is that I want the form traceback to stay close to the 
> exception message.
> Otherwise if you run several threads writing to stdout, you may end up with 
> split
> outputs on standard output (the exception message in one spot and the form 
> traceback elsewhere)
>
> Comments/suggestions are welcomed.
>
> The README.MD is on its way and I still need to review the code to see if 
> they are
> remaining rough edges. Nothing beats a paper output and a coffee...
>
> I expect to work on the build process next week-end and get the first version 
> out next week.
>
> Time to go to bed, my eyes are now useless ...
>
> Luc P.

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