Re: ClojureScript Repl -- Swank-like workflow with Emacs?
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 volker.schle...@gmail.com 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 paul.koerb...@gmail.com 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 dnolen.li...@gmail.com 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 paul.koerb...@gmail.comwrote: 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
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 n...@sfu.ca 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 atreyu@gmail.com wrote: i am surprised nobody mentioned gradual/optional typing http://lambda-the-ultimate.org/node/1707, typed racket http://docs.racket-lang.org/ts-guide/ and the possible type checker to be built by *some clever hacker* on core.logic https://github.com/clojure/core.logicsome 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
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 n...@sfu.ca 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 atreyu@gmail.com wrote: i am surprised nobody mentioned gradual/optional typing http://lambda-the-ultimate.org/node/1707, typed racket http://docs.racket-lang.org/ts-guide/ and the possible type checker to be built by *some clever hacker* on core.logic https://github.com/clojure/core.logicsome 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
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 namesignature 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
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 paul.koerb...@gmail.com 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 n...@sfu.ca 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 atreyu@gmail.com wrote: i am surprised nobody mentioned gradual/optional typing http://lambda-the-ultimate.org/node/1707, typed racket http://docs.racket-lang.org/ts-guide/ and the possible type checker to be built by *some clever hacker* on core.logic https://github.com/clojure/core.logicsome 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
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 n...@sfu.ca 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 paul.koerb...@gmail.com 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 n...@sfu.ca 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 atreyu@gmail.com wrote: i am surprised nobody mentioned gradual/optional typing http://lambda-the-ultimate.org/node/1707, typed racket http://docs.racket-lang.org/ts-guide/ and the possible type checker to be built by *some clever hacker* on core.logic https://github.com/clojure/core.logicsome 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?
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 a...@malloys.org 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 soro...@oogis.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
New Clojure Brush for Alex Gorbatchev's SyntaxHighlighter
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?
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
Shameless self promotion - JavaOne
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?
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
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 michael.ja...@googlemail.com 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
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 div / elements and then display them as needed. On Sep 27, 12:51 pm, Andy Fingerhut andy.finger...@gmail.com 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 michael.ja...@googlemail.com 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
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 n...@sfu.ca 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 namesignature 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: statistics library?
Lee Spector lspec...@hampshire.edu 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?
On 27 сен, 16:45, Mark Rathwell mark.rathw...@gmail.com 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 joha...@gmail.com 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: defrecord and overriding empty
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: statistics library?
On Sep 27, 2011, at 1:37 PM, Johann Hibschman wrote: Johann Hibschman joha...@gmail.com 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?
2011/9/27 ru soro...@oogis.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
-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
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
On Fri, Sep 23, 2011 at 2:44 PM, Christopher Redinger redin...@gmail.com 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
Sean, On Tue, Sep 27, 2011 at 20:17, Sean Corfield seancorfi...@gmail.com wrote: On Fri, Sep 23, 2011 at 2:44 PM, Christopher Redinger redin...@gmail.com 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?
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 soro...@oogis.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 a...@malloys.org 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 soro...@oogis.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?
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 paul.koerb...@gmail.com 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 volker.schle...@gmail.com 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 paul.koerb...@gmail.com 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 dnolen.li...@gmail.com 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 paul.koerb...@gmail.comwrote: 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?
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?
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 a...@malloys.org 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 soro...@oogis.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 a...@malloys.org 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 soro...@oogis.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
On Tue, Sep 27, 2011 at 12:22 PM, Bruce Durling b...@otfrom.com 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?
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 #ClassCastException java.lang.ClassCastException: java.lang.Long 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
Re: suggestion for clojure development
On Tue, Sep 27, 2011 at 11:57 AM, Arthur Edelstein arthuredelst...@gmail.com 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
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?
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 lspec...@hampshire.edu 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
I'm with Phil on that one. Legacy support slows or even hinders innovation. On Sep 28, 2011 6:06 AM, Phil Hagelberg p...@hagelb.org wrote: On Tue, Sep 27, 2011 at 11:57 AM, Arthur Edelstein arthuredelst...@gmail.com 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
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?
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?
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 michal.marc...@gmail.com 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 #ClassCastException java.lang.ClassCastException: java.lang.Long 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
On Tue, Sep 27, 2011 at 11:57 AM, Arthur Edelstein arthuredelst...@gmail.com 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?
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
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
!DOCTYPE html
html
head
script type=text/javascript src=goog/base.js/script
script type=text/javascript src=hello.js/script
/head
body onload=sayHi()
/body
/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
What was the error and what were your compile options?
On Tuesday, September 27, 2011, Brent Millare brent.mill...@gmail.com
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
!DOCTYPE html
html
head
script type=text/javascript src=goog/base.js/script
script type=text/javascript src=hello.js/script
/head
body onload=sayHi()
/body
/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
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 dnolen.li...@gmail.com wrote:
What was the error and what were your compile options?
On Tuesday, September 27, 2011, Brent Millare brent.mill...@gmail.com
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
!DOCTYPE html
html
head
script type=text/javascript src=goog/base.js/script
script type=text/javascript src=hello.js/script
/head
body onload=sayHi()
/body
/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
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?
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
On Tue, Sep 27, 2011 at 4:28 PM, Brian Marick mar...@exampler.com 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
On Tue, Sep 27, 2011 at 4:43 PM, Sean Corfield seancorfi...@gmail.com 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?
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
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 odysso...@gmail.com 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 michal.marc...@gmail.comwrote: 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
On Sep 27, 4:43 pm, Sean Corfield seancorfi...@gmail.com wrote: On Tue, Sep 27, 2011 at 4:28 PM, Brian Marick mar...@exampler.com 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
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 brent.mill...@gmail.com 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 dnolen.li...@gmail.com wrote:
What was the error and what were your compile options?
On Tuesday, September 27, 2011, Brent Millare brent.mill...@gmail.com
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
!DOCTYPE html
html
head
script type=text/javascript src=goog/base.js/script
script type=text/javascript src=hello.js/script
/head
body onload=sayHi()
/body
/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
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
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?
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?
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
On Tue, Sep 27, 2011 at 7:33 PM, Arthur Edelstein arthuredelst...@gmail.com 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)
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 odysso...@gmail.com 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 michal.marc...@gmail.comwrote: 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
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
On Wed, Sep 28, 2011 at 12:03 AM, Arthur Edelstein arthuredelst...@gmail.com 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)
Thank you Luc! On Tue, Sep 27, 2011 at 11:44 PM, Luc Prefontaine lprefonta...@softaddicts.ca 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
