Re: Implementing multimethods in pure Clojure
Hi, Am 13.12.2010 um 23:52 schrieb Ken Wesson: > That's not what I meant. I figure all of us have tabs permanently open > to there (I have two actually). What we don't have is the whole thing > memorized, or the time to read it all rather than use it for reference […] My solution to this problem is actually quite simple: I took the time to read it. Not all at one day, but slowly function after function. If I saw a function in other people's code, which I didn't know, I looked it up. Or I read through the overview list and thought „WTF does alter-var-root do?“ Then it was either something „Dang! I need this twice a day. Why don't I know about it?“. Then I would certainly not forget it anymore. Otherwise I would at least remember „There was something.“ and know where to search in the documentation to find the details again if needed. Of course there are also functions, which I constantly forget. for is such a candidate. When it was new I *always* forgot about it. I built complicated mapcat-reduce-map combinations, which where a simple, short for. Even nowadays I have to remind myself about for every now and then. Such things trickle in slowly. However, this process is called „learning“ and there is no short-cut to it. This process takes time. There is no „I know Kung-Fu.“ in the real world. cf. http://norvig.com/21-days.html Sincerely Meikel -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: aliasing symbols from clojure core
Hi,
Am 14.12.2010 um 04:25 schrieb Sunil S Nandihalli:
> yeah cool I can do that.. thx. But I remember seeing a syntax for it in the
> ns macro...
(ns name.space
(:refer-clojure :rename {+ core+}))
Please note that / is a special case symbol. Slashes are not allowed in
symbols, and I'm not sure you can redefine it (haven't tested it). At least I
would be very suspicious on its future-safeness.
Sincerely
Meikel
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from 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: Implementing multimethods in pure Clojure
On 14 December 2010 09:22, Meikel Brandmeyer wrote: > > Am 13.12.2010 um 23:52 schrieb Ken Wesson: > >> That's not what I meant. I figure all of us have tabs permanently open >> to there (I have two actually). What we don't have is the whole thing >> memorized, or the time to read it all rather than use it for reference […] > > My solution to this problem is actually quite simple: I took the time to read > it. One can also apply a measure of common sense. If you're writing a function that has a general use, such as changing the metadata, you may very well consider the possibility it has already been written. If you then open the API page and search for a function that contains "meta", you'd soon run across vary-meta. - James -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Implementing multimethods in pure Clojure
On Tue, Dec 14, 2010 at 4:52 AM, James Reeves wrote: > On 14 December 2010 09:22, Meikel Brandmeyer wrote: >> >> Am 13.12.2010 um 23:52 schrieb Ken Wesson: >> >>> That's not what I meant. I figure all of us have tabs permanently open >>> to there (I have two actually). What we don't have is the whole thing >>> memorized, or the time to read it all rather than use it for reference […] >> >> My solution to this problem is actually quite simple: I took the time to >> read it. > > One can also apply a measure of common sense. I resent the implication that I didn't. > If you're writing a function that has a general use, such as changing > the metadata, you may very well consider the possibility it has already > been written. If you then open the API page and search for a function > that contains "meta", you'd soon run across vary-meta. Yes, but if you look for functions that work on atoms you won't, and someone looking for functionality like swap-meta! is at least as likely to think "atoms" as "metadata" when formulating a search. I don't think there's any point in endlessly rehashing this and trying to point a finger of blame. Nobody has actually done anything wrong here, as near as I can tell, OTHER than trying to turn this into a blame game by getting critical. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Moderately off-topic: installing emacs on OSX
javajosh writes: > Ok, I decided to nuke ports, fink, and delete every package they ever > installed. I successfully installed emacs 23.2 via homebrew (there's a > good overview of homebrew here > http://ascarter.net/2010/02/22/homebrew-for-os-x.html). I'm coming late to this game, and I see that you've already figured things out, but I thought I'd chime in for anyone else listening. Since I'm too lazy to build emacs for myself, I've been using Vincent Goulet's build, http://vgoulet.act.ulaval.ca/en/ressources/emacs/mac , with success. I've not tried to run it with -nw, though. > Also tried the elpa self-install script in Aquamacs (where the scratch > buffer comes up first thing), but C-j (the 'eval' keystroke) had no > discernible effect. I tried M-x package-list-packages but it said [No > Match]. So I assume nothing happened. Yes. Aquamacs's scratch buffer is in text-mode, not in lisp-interaction-mode. Plus, it comes with old versions of SLIME that I couldn't figure out how to remove. Partly based on tricks like that, partly due to strange font behavior, I don't like Aquamacs. Regards, 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: Clojure 1.3 Alpha 4
There has been much thought lately around build and release processes. See http://dev.clojure.org/display/design/Common+Contrib+Build The goal is to to have more libraries under the umbrella of "contrib" without requiring them to keep to the same release schedule. Each library can have its own release schedule and version numbers. The current "clojure-contrib", the monolithic repository with 60+ modules, will be phased out. All 1.3.0-alpha* releases of the "clojure-contrib" module JARs are source-code-only (except for the 4 modules that require AOT) so they are compatible with any Clojure release. For example, you can use Clojure "1.3.0-alpha4" and org.clojure.contrib/logging "1.3.0-alpha3" in the same project. -Stuart Sierra 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
Rebinding a var in a Lazytest test -- beginner
Howdy,
I asked this on #clojure and posted a question on Stackoverflow
(http://stackoverflow.com/questions/4424220/how-do-i-rebind-a-var-in-a-
lazytest-describe-test), but no dice. I'm assuming that it's because
this is so simple and I'm doing it so incorrectly that nobody can even
begin to formulate a response. Feel free to tell me to go back and re-
R all TFMs ;)
First of all, sorry if I am screwing up some terminology; I'm pretty
new to Clojure. I am trying to write a very simple test using Lazytest
that depends on a var binding. I can not seem to rebind a var in the
test file and have the code under test use that binding.
Here is the code I am trying to test:
(ns liar-liar.core
(:gen-class))
(def *input-file-name*)
(defn parse-input
"Just print return a var for now..."
[]
*input-file-name*)
(defn -main [& args]
(binding [*input-file-name* (first args)]
(println (parse-input
And here is the test:
(ns liar-liar.test.core
(:use lazytest.describe)
(:use liar-liar.core))
(binding [*input-file-name* "my-input-file"]
(describe parse-input "Just returns a var"
(it "returns a var"
(= "my-input-file" (parse-input)
When I try to run this test, I get this error:
java.lang.IllegalStateException: Var liar-liar.core/*input-file-name*
is unbound.
Interestingly enough, if I move the binding form:
(ns liar-liar.test.core
(:use lazytest.describe)
(:use liar-liar.core))
(describe parse-input "Just returns a var"
(it "returns a var"
(binding [*input-file-name* "my-input-file"]
(= "FAIL" (parse-input)
The test works as it should, but the reporting isn't ideal, as it
doesn't print the value of the (parse-input) expression (the test
passes if I replace "FAIL" with "my-input-file" though):
FAILURE: Namespaces liar-liar.test.core #'liar-liar.core/parse-input
Just returns a var returns a var
at liar_liar/test/core.clj line 7
Expression: (binding [*input-file-name* my-input-file] (= FAIL (parse-
input)))
Result: false
Local bindings:
{}
Is there some other way I should be going about doing this kind of
testing?
Thanks! Dan
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Fwd: [Sbcl-devel] [CfP] 4th European Lisp Symposium, March 31 - April 1, 2010, Hamburg
I am currently working on an MPI package for Clojure. This crossed my mailbox and may be of interest to the clojure community. Tim Daly ~~ 4th European Lisp Symposium Special Focus on Parallelism& Efficiency March 31 - April 1st, 2011 TUHH, Hamburg University of Technology Hamburg, Germany http://www.european-lisp-symposium.org/ Sponsored by EPITA, Lispworks, Franz Inc. and Nova Sparks ~~ Invited Speakers: ~ Marc Battyani (Nova Sparks) Craig Zilles (University of Illinois) Important Dates + Submission Deadline: January 09, 2011 + Author Notification: February 06, 2011 + Final Paper Due: February 28, 2011 + Symposium: March 31 - April 1st, 2011 Authors of accepted research contributions will be invited to submit an extended version of their papers for journal publication. Scope ~~ The purpose of the European Lisp Symposium is to provide a forum for the discussion and dissemination of all aspects of design, implementation and application of any of the Lisp dialects, including Common Lisp, Scheme, Emacs Lisp, AutoLisp, ISLISP, Dylan, Clojure, ACL2, ECMAScript, Racket and so on. We encourage everyone interested in Lisp to participate. The European Lisp Symposium 2011 invites high quality papers about novel research results, insights and lessons learned from practical applications, and educational perspectives. We also encourage submissions about known ideas as long as they are presented in a new setting and/or in a highly elegant way. This year's focus will be directed towards "Parallelism& Efficiency". We especially invite submissions in the following areas: + Parallel and distributed computing + Code generation for multi-core architectures + Code generation for HTM + Large and ultra-large systems + Optimization techniques + Embedded applications Contributions are also welcome in other areas, including but not limited to: + Context-, aspect-, domain-oriented and generative programming + Macro-, reflective-, meta- and/or rule-based development approaches + Language design and implementation + Language integration, inter-operation and deployment + Development methodologies, support and environments + Educational approaches and perspectives + Experience reports and case studies Technical Program: ~~ We invite submissions in the following forms: * Papers: Technical papers of up to 15 pages that describe original results or explain known ideas in new and elegant ways. * Demonstrations: Abstracts of up to 4 pages for demonstrations of tools, libraries, and applications. * Tutorials: Abstracts of up to 4 pages for in-depth presentations about topics of special interest for at least 90 minutes and up to 180 minutes. * Lightning talks: Abstracts of up to one page for talks to last for no more than 5 minutes. All submissions should be formatted following the ACM SIGS guidelines and include ACM classification categories and terms. For more information on the submission guidelines and the ACM keywords, see: http://www.acm.org/sigs/publications/proceedings-templates http://www.acm.org/about/class/1998 Submissions should be uploaded to Easy Chair, at the following address: http://www.easychair.org/conferences/?conf=els2011 Programme Chair Didier Verna - EPITA Research and Development Laboratory, France Local Chair Ralf Moeller - Hamburg University of Technology, Germany Programme Committee Antonio Leitao - Instituto Superior Tecnico/INESC-ID, Portugal Christophe Rhodes - Goldsmiths College, University of London, UK David Edgar Liebke - Relevance Inc., USA Didier Verna - EPITA Research and Development Laboratory, France Henry Lieberman - MIT Media Laboratory, USA Jay McCarthy - Brigham Young University, USA Jose Luis Ruiz Reina - Universidad de Sevilla, Spain Marco Antoniotti - Universita Milano Bicocca, Italy Manuel Serrano - INRIA, France Michael Sperber - DeinProgramm, Germany Pascal Costanza - Vrije Universiteit of Brussel, Belgium Scott McKay - ITA Software, USA -- Resistance is futile. You will be jazzimilated. Scientific site: http://www.lrde.epita.fr/~didier Music (Jazz) site: http://www.didierverna.com -- Lotusphere 2011 Register now for Lotusphere 2011 and learn how to connect the dots, take your collaborative environment to the next level, and enter the era of Social Business. http://p.sf.net/sfu/lotusphere-d2d ___ Sbcl-devel mailing list sbcl-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sbcl-devel -- You received this message because you are sub
Doc string removed from clojure.xml/emit
Any reason why the doc string has been removed from clojure.xml/emit (and emit-element)? Are these functions deprecated? -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Doc string removed from clojure.xml/emit
On Dec 14, 2010, at 18:00 , Ralph wrote: > Any reason why the doc string has been removed from clojure.xml/emit > (and emit-element)? Are these functions deprecated? > Well, they're buggy. http://www.assembla.com/spaces/clojure/search?q=clojure.xml+emit On issue 412 Stuart Halloway explains: If a var is (a) public (b) has a docstring and (c) has :added metadata, then the Clojure team is committed to supporting it. These vars don't meet the criteria. In the context of a broader overhaul of XML support these might become official APIs. On issue 410 Chris Houser suggests: Please consider the solution provided by clojure.contrib.lazy-xml/emit which uses javax.xml.transform classes to fix not only these bugs (#410 and #408) but also support indent, xml-declaration, and encoding options. // ben -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: aliasing symbols from clojure core
Not to sound like a one track record here, but you should look at
clojure.contrib.generic.arithemetic to see how to redefine /
have a great day,
--Robert McIntyre
On Tue, Dec 14, 2010 at 4:26 AM, Meikel Brandmeyer wrote:
> Hi,
>
> Am 14.12.2010 um 04:25 schrieb Sunil S Nandihalli:
>
>> yeah cool I can do that.. thx. But I remember seeing a syntax for it in the
>> ns macro...
>
> (ns name.space
> (:refer-clojure :rename {+ core+}))
>
> Please note that / is a special case symbol. Slashes are not allowed in
> symbols, and I'm not sure you can redefine it (haven't tested it). At least I
> would be very suspicious on its future-safeness.
>
> Sincerely
> Meikel
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your
> first post.
> To unsubscribe from 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: Rebinding a var in a Lazytest test -- beginner
Both `describe` and `it` create functions. That is, they expand out
to `(fn [] ...)`. Wrapping `binding` around the creation of a fn has
no effect.
For finer control over where the fn gets created and how failures get
reported, you can use `do-it` and `expect`.
(describe ...
(do-it ...
(binding ...
(expect ...)))
This will produce the results you're looking for.
-Stuart Sierra
clojure.com
On Dec 14, 11:13 am, fuchsd wrote:
> Howdy,
>
> I asked this on #clojure and posted a question on Stackoverflow
> (http://stackoverflow.com/questions/4424220/how-do-i-rebind-a-var-in-a-
> lazytest-describe-test), but no dice. I'm assuming that it's because
> this is so simple and I'm doing it so incorrectly that nobody can even
> begin to formulate a response. Feel free to tell me to go back and re-
> R all TFMs ;)
>
> First of all, sorry if I am screwing up some terminology; I'm pretty
> new to Clojure. I am trying to write a very simple test using Lazytest
> that depends on a var binding. I can not seem to rebind a var in the
> test file and have the code under test use that binding.
>
> Here is the code I am trying to test:
>
> (ns liar-liar.core
> (:gen-class))
>
> (def *input-file-name*)
>
> (defn parse-input
> "Just print return a var for now..."
> []
> *input-file-name*)
>
> (defn -main [& args]
> (binding [*input-file-name* (first args)]
> (println (parse-input
>
> And here is the test:
>
> (ns liar-liar.test.core
> (:use lazytest.describe)
> (:use liar-liar.core))
>
> (binding [*input-file-name* "my-input-file"]
> (describe parse-input "Just returns a var"
> (it "returns a var"
> (= "my-input-file" (parse-input)
>
> When I try to run this test, I get this error:
>
> java.lang.IllegalStateException: Var liar-liar.core/*input-file-name*
> is unbound.
>
> Interestingly enough, if I move the binding form:
>
> (ns liar-liar.test.core
> (:use lazytest.describe)
> (:use liar-liar.core))
>
> (describe parse-input "Just returns a var"
> (it "returns a var"
> (binding [*input-file-name* "my-input-file"]
> (= "FAIL" (parse-input)
>
> The test works as it should, but the reporting isn't ideal, as it
> doesn't print the value of the (parse-input) expression (the test
> passes if I replace "FAIL" with "my-input-file" though):
>
> FAILURE: Namespaces liar-liar.test.core #'liar-liar.core/parse-input
> Just returns a var returns a var
> at liar_liar/test/core.clj line 7
> Expression: (binding [*input-file-name* my-input-file] (= FAIL (parse-
> input)))
> Result: false
> Local bindings:
> {}
>
> Is there some other way I should be going about doing this kind of
> testing?
>
> Thanks! Dan
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from 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: aliasing symbols from clojure core
Hi, Am 14.12.2010 um 19:04 schrieb Robert McIntyre: > Not to sound like a one track record here, but you should look at > clojure.contrib.generic.arithemetic to see how to redefine / Which does not make / a legal symbol. Slashes are not allowed in Symbols and the future of this code is not guaranteed. I just say this as a warning. Sincerely Meikel -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: complex number library
On Dec 14, 2:31 am, Konrad Hinsen wrote: > That's actually what clojure.contrib.complex-numbers already uses! And > it's based on multimethods, not protocols, because of all those binary > operations. It is possible, though not trivial, to do 2-argument dispatch with protocols. See http://paste.lisp.org/+2023 for an example. I have no idea how well this performs compared to multimethods. -Stuart Sierra -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Implementing multimethods in pure Clojure
I wouldn't worry too much about your reputation. Your posts are top notch, and you obviously know the language better than 90% of most clojure users. Have confidence and laugh if you think someone is disparaging: actions speak far louder than words. On Dec 14, 4:42 am, Ken Wesson wrote: > On Tue, Dec 14, 2010 at 4:52 AM, James Reeves wrote: > > On 14 December 2010 09:22, Meikel Brandmeyer wrote: > > >> Am 13.12.2010 um 23:52 schrieb Ken Wesson: > > >>> That's not what I meant. I figure all of us have tabs permanently open > >>> to there (I have two actually). What we don't have is the whole thing > >>> memorized, or the time to read it all rather than use it for reference […] > > >> My solution to this problem is actually quite simple: I took the time to > >> read it. > > > One can also apply a measure of common sense. > > I resent the implication that I didn't. > > > If you're writing a function that has a general use, such as changing > > the metadata, you may very well consider the possibility it has already > > been written. If you then open the API page and search for a function > > that contains "meta", you'd soon run across vary-meta. > > Yes, but if you look for functions that work on atoms you won't, and > someone looking for functionality like swap-meta! is at least as > likely to think "atoms" as "metadata" when formulating a search. > > I don't think there's any point in endlessly rehashing this and trying > to point a finger of blame. Nobody has actually done anything wrong > here, as near as I can tell, OTHER than trying to turn this into a > blame game by getting critical. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Implementing multimethods in pure Clojure
On Tue, Dec 14, 2010 at 2:23 PM, javajosh wrote: > I wouldn't worry too much about your reputation. Your posts are top > notch, and you obviously know the language better than 90% of most > clojure users. Thank you. > Have confidence and laugh if you think someone is > disparaging: actions speak far louder than words. Yeah, perhaps I should. I just worry that the same attitude aimed at another user might provoke escalation, even a flamewar. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Erlang-esque bit syntax in Clojure?
Hi all, My apologies for resurrecting a dead thread of discussion if this has already been put to bed, but I was wondering if anyone has been working on implementing a bit syntax for Clojure in the rough conceptual style of Erlang's bit syntax. I say conceptual because I'm not necessarily looking for exactly the same syntax per se, I'm looking for a Clojure adaptation of the core concept and tool as it exists in Erlang (though, to be honest, something that can consume Erlang's exact syntax and either transform it into the Clojure-ish version of same, or consume Erlang's syntax in addition to the Clojure version, both ultimately becoming JVM bytecode, natch, would be *handy*, just not required, at least not now). In some exceedingly cursory searching, I found a message from Kyle Schaffrick[1] in which he makes mention of his "bits" macro, but that's been about all. I've also seen Zach Tellman's Gloss[2], but I'm not sure it's what I want. It is highly likely I've missed something, so please do send me pointers on more recent work if you know of them. Otherwise I'm also interested in who else wants something like this, as a rough gauge of interest. Thanks in advance. Footnotes: [1] http://groups.google.com/group/clojure/msg/5b3cfa77f8231b79?hl=en [2] https://github.com/ztellman/gloss -- Daniel Moniz [http://pobox.com/~dnm/] -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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 1.3 Alpha 4
On Tue, Dec 14, 2010 at 8:02 AM, Stuart Sierra wrote: > There has been much thought lately around build and release processes. > See http://dev.clojure.org/display/design/Common+Contrib+Build Thanx. > The goal is to to have more libraries under the umbrella of "contrib" > without requiring them to keep to the same release schedule. Each library > can have its own release schedule and version numbers. Makes sense (although it sounds like a recipe for confusion until the transition is completed - at 1.3.0 final, yes?). I suspect it will get easier - or at least look a little less confusing - when the current contrib libs actually do start having separate version numbers :) > For example, you can use Clojure "1.3.0-alpha4" and > org.clojure.contrib/logging "1.3.0-alpha3" in the same project. Is there an easy way to lookup whether a given lib has an alpha4 version (or, more generally, what the latest reasonably stable build is)? (should I take this to the -dev list?) -- Sean A Corfield -- (904) 302-SEAN Railo Technologies, Inc. -- http://getrailo.com/ An Architect's View -- http://corfield.org/ "If you're not annoying somebody, you're not really alive." -- Margaret Atwood -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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 1.3 Alpha 4
For now, you can just look at the repository at http://build.clojure.org/releases/org/clojure/ Once we get automated releases from Hudson/Maven (real soon now) the JARs will be deployed to the Maven Central repository, where they will be automatically indexed by search engines like jarvana.com. -S On Tuesday, December 14, 2010 4:27:21 PM UTC-5, seancorfield wrote: > > > Is there an easy way to lookup whether a given lib has an alpha4 > version (or, more generally, what the latest reasonably stable build > is)? > > > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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 1.3 Alpha 4
(defn fact [n] (reduce * (range 1 (inc n (fact 100) This produces the right result on 1.2 but "ArithmeticException integer overflow" on 1.3-alpha4. Is this intentional? -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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 1.3 Alpha 4
On Dec 14, 6:30 pm, Miki wrote: > (defn fact [n] (reduce * (range 1 (inc n > (fact 100) > > This produces the right result on 1.2 but "ArithmeticException integer > overflow" on 1.3-alpha4. > Is this intentional? Primitive math is the default in 1.3 -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Downloadable Clojure mp3s
Hi guys, I love to listen to mp3's that I've downloaded, on my way to work. I think it would be great to compile a list of links to Clojure-based mp3's. I love InfoQ, but not all of the videos are downloadable. Here are my first two: Stuart Halloway on "Clojure and Functional Programming" http://www.infoq.com/interviews/stuart_holloway_clojure "Are We There Yet" by Rich Hickey http://www.infoq.com/presentations/Are-We-There-Yet-Rich-Hickey -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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 1.3 Alpha 4
As Brian said, primitive math is now the default in 1.3. If auto- promotion on overflow is desired, you can use the +', -', *', inc', dec' functions (note the single quote suffix). http://dev.clojure.org/display/doc/Enhanced+Primitive+Support On Dec 14, 5:36 pm, Brian Goslinga wrote: > On Dec 14, 6:30 pm, Miki wrote:> (defn fact [n] > (reduce * (range 1 (inc n > > (fact 100) > > > This produces the right result on 1.2 but "ArithmeticException integer > > overflow" on 1.3-alpha4. > > Is this intentional? > > Primitive math is the default in 1.3 -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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 1.3 Alpha 4
Of course, TANSTAAFL: the auto-promoting version of the functions will be slower than their primitive counterparts. On Dec 14, 6:23 pm, Benny Tsai wrote: > As Brian said, primitive math is now the default in 1.3. If auto- > promotion on overflow is desired, you can use the +', -', *', inc', > dec' functions (note the single quote suffix). > > http://dev.clojure.org/display/doc/Enhanced+Primitive+Support > > On Dec 14, 5:36 pm, Brian Goslinga wrote: > > > > > > > > > On Dec 14, 6:30 pm, Miki wrote:> (defn fact [n] > > (reduce * (range 1 (inc n > > > (fact 100) > > > > This produces the right result on 1.2 but "ArithmeticException integer > > > overflow" on 1.3-alpha4. > > > Is this intentional? > > > Primitive math is the default in 1.3 -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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 1.3 Alpha 4
On Tue, Dec 14, 2010 at 8:23 PM, Benny Tsai wrote: > As Brian said, primitive math is now the default in 1.3. If auto- > promotion on overflow is desired, you can use the +', -', *', inc', > dec' functions (note the single quote suffix). Why was this done? I preferred having +, -, etc. DTRT in general and unchecked-+, etc. for when you really needed efficient primitive math. My code is littered with + but has few unchecked-+s. Which means I'll have to go through it all adding little tick-marks everywhere and making the math look funny to keep its behavior the same whenever 1.3 is released. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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 1.3 Alpha 4
On Tue, Dec 14, 2010 at 9:04 PM, Ken Wesson wrote: > On Tue, Dec 14, 2010 at 8:23 PM, Benny Tsai wrote: > > As Brian said, primitive math is now the default in 1.3. If auto- > > promotion on overflow is desired, you can use the +', -', *', inc', > > dec' functions (note the single quote suffix). > > Why was this done? I preferred having +, -, etc. DTRT in general and > unchecked-+, etc. for when you really needed efficient primitive math. > My code is littered with + but has few unchecked-+s. Which means I'll > have to go through it all adding little tick-marks everywhere and > making the math look funny to keep its behavior the same whenever 1.3 > is released. For quite a few good reasons, the most important being that it makes Rich Hickey's life a lot easier, and ours as well as a result of that. Best to read over the very, very long thread on the subject. 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: Clojure 1.3 Alpha 4
On Dec 14, 8:04 pm, Ken Wesson wrote: > On Tue, Dec 14, 2010 at 8:23 PM, Benny Tsai wrote: > > As Brian said, primitive math is now the default in 1.3. If auto- > > promotion on overflow is desired, you can use the +', -', *', inc', > > dec' functions (note the single quote suffix). > > Why was this done? I preferred having +, -, etc. DTRT in general and > unchecked-+, etc. for when you really needed efficient primitive math. > My code is littered with + but has few unchecked-+s. Which means I'll > have to go through it all adding little tick-marks everywhere and > making the math look funny to keep its behavior the same whenever 1.3 > is released. This topic has been discussed to death before on this group. Short version: Doing the right thing is actually harder than you might first think: methods in Java must choose between returning a primitive and returning in reference type. This means that you have to choose between fast primitive math or slow reference type math. To advance the goal of writing Clojure in Clojure, it is necessary for it be easy to write high-performance Clojure code (although you might not care about how hard photosynthesis is, the plants do). Since it is generally the case that longs are sufficient for most purposes and it generally known ahead of time when they are not (Project Euler problems for example), primitive math is being made default in 1.3 Another change in 1.3 is that BigInteger math will not auto-reduce and will be contagious. This means that the prime versions of operations (+', -', etc.) are almost never necessary as one can use a BigInteger literal to ensure the operation will not overflow. Your example will work correctly if you change 1 to 1N. (Since java.lang.BigInteger is slow on small numbers, clojure.lang.BigInt is also being introduced (which is the type of 1N) that should be as fast as math was in 1.2 when the numbers fit into a long) For better or worse (hopefully for better), Clojure is increasingly adopting C++'s philosophy of pay for what you need. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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 1.3 Alpha 4
On Tue, Dec 14, 2010 at 9:56 PM, David Nolen wrote: > On Tue, Dec 14, 2010 at 9:04 PM, Ken Wesson wrote: >> >> On Tue, Dec 14, 2010 at 8:23 PM, Benny Tsai wrote: >> > As Brian said, primitive math is now the default in 1.3. If auto- >> > promotion on overflow is desired, you can use the +', -', *', inc', >> > dec' functions (note the single quote suffix). >> >> Why was this done? I preferred having +, -, etc. DTRT in general and >> unchecked-+, etc. for when you really needed efficient primitive math. >> My code is littered with + but has few unchecked-+s. Which means I'll >> have to go through it all adding little tick-marks everywhere and >> making the math look funny to keep its behavior the same whenever 1.3 >> is released. > > For quite a few good reasons, the most important being that it makes Rich > Hickey's life a lot easier, and ours as well as a result of that. Breaking source compatibility with just about every single preexisting line of Clojure code out there is supposed to make our lives *easier*? I'd dearly love to know how -- my cousin is a stage magician and he's always on the lookout for new tricks, so this would make a nearly perfect Christmas present for him. :) -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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 1.3 Alpha 4
On Tue, Dec 14, 2010 at 10:02 PM, Brian Goslinga wrote: > This topic has been discussed to death before on this group. If so, it was before I joined. > Doing the right thing is actually harder than you might first think But it's also already being done by Clojure 1.2 so I don't see how that's relevant. If someone proposed a novel behavior, it being "harder than you might first think" would be a point against that proposal. However it cannot logically ever be a point against keeping current behavior. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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 1.3 Alpha 4
On Dec 14, 2010, at 9:26 PM, Ken Wesson wrote: > On Tue, Dec 14, 2010 at 10:02 PM, Brian Goslinga > wrote: >> This topic has been discussed to death before on this group. > > If so, it was before I joined. That's what archives are for: http://groups.google.com/group/clojure/search?group=clojure&q=primitive+math See in particular the threads "Enhanced primitive support" and "Enhanced primitive support - redux". >> Doing the right thing is actually harder than you might first think > > But it's also already being done by Clojure 1.2 so I don't see how > that's relevant. If someone proposed a novel behavior, it being > "harder than you might first think" would be a point against that > proposal. However it cannot logically ever be a point against keeping > current behavior. Are you saying that simplifying existing code provides no benefit? -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Yegge's "Lisp is not an acceptable Lisp" - was he talking about Clojure?
Just ran across: http://steve-yegge.blogspot.com/2006/04/lisp-is-not-acceptable-lisp.html Whoah! I had no idea there was so much, uh, 'intricacy' going on behind Lisp. :) Anyway, it was interesting to read it having a bit of Clojure under my belt. With the exception of types, it seems like Clojure addresses most, if not all, of the concerns he brings up. What do you think? -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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 1.3 Alpha 4
On Dec 14, 9:24 pm, Ken Wesson wrote: > Breaking source compatibility with just about every single preexisting > line of Clojure code out there is supposed to make our lives *easier*? Actually, it appears that the majority of the lines of code out there use integers that fit inside a long, so the change doesn't affect them. On Dec 14, 9:26 pm, Ken Wesson wrote: > But it's also already being done by Clojure 1.2 so I don't see how > that's relevant. If someone proposed a novel behavior, it being > "harder than you might first think" would be a point against that > proposal. However it cannot logically ever be a point against keeping > current behavior. There exists a difference in the behavior of primitive and reference type math in 1.2; Clojure 1.3 will unify the behavior of the two. The auto promoting operators need to return an Object currently even if they take in primitives because the operation might overflow. This means that the auto promoting operators are incompatible with fast math (blame the JVM). It would be nice if there wasn't a trade-off to make, but there is one. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Yegge's "Lisp is not an acceptable Lisp" - was he talking about Clojure?
javajosh writes: > Just ran across: > > http://steve-yegge.blogspot.com/2006/04/lisp-is-not-acceptable-lisp.html > > Whoah! I had no idea there was so much, uh, 'intricacy' going on > behind Lisp. :) > > Anyway, it was interesting to read it having a bit of Clojure under my > belt. With the exception of types, it seems like Clojure addresses > most, if not all, of the concerns he brings up. > > What do you think? There's a hint about it in one of his recent posts: http://steve-yegge.blogspot.com/2010/07/blogger-finger.html "I used to have lot of open, long-standing concerns about the future of programming and productivity, but my sabbatical last year finally brought me some clojure." -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure 1.3 Alpha 4
On Tue, Dec 14, 2010 at 6:04 PM, Ken Wesson wrote: > On Tue, Dec 14, 2010 at 8:23 PM, Benny Tsai wrote: > > As Brian said, primitive math is now the default in 1.3. If auto- > > promotion on overflow is desired, you can use the +', -', *', inc', > > dec' functions (note the single quote suffix). > > Why was this done? I preferred having +, -, etc. DTRT in general and > unchecked-+, etc. for when you really needed efficient primitive math. > My code is littered with + but has few unchecked-+s. Which means I'll > have to go through it all adding little tick-marks everywhere and > making the math look funny to keep its behavior the same whenever 1.3 > is released. > > Search the archives for "enhanced primitive support". There was a big battle back in June. People like you and me, who don't want to have to think about whether their code might crash with certain inputs from arithmetic overflow, lost the battle to those who want to get more speed out of Clojure without having to specifically annotate tight loops with special primitive math ops. The theory is that most programs work perfectly fine with longs. If yours doesn't, you'll hopefully find out when it throws an error, and go annotate your code accordingly. In exchange, Clojure will supposedly get faster for the common case. In practice, I haven't seen a significant speed improvement in the new branch of Clojure (except on specific benchmarks that intentionally test Clojure's new default primitive math). In my day-to-day code, all my numbers, despite being perfectly small enough to fit in a long, end up getting stored and retrieved from Clojure's various data structures - vectors, maps, sets, etc. and thus lose their primitiveness. So I presumably haven't seen any speed improvement because all the numbers are boxed by the time I do math on them. Fortunately, I also don't seem to run into arithmetic overflows because my production code isn't particularly math intensive, but I still end up feeling stressed out trying to convince myself that it can't ever overflow for any input. It will be interesting to see how this all shakes out -- whether there are more ways to exploit the default of primitive math for better speed, and whether people still like the new direction after trying it more. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Yegge's "Lisp is not an acceptable Lisp" - was he talking about Clojure?
Steve is trolling with that Lisp post. There is so much noise in what he says, there is no point beginning to reply. And all of it would be off-topic. Ignore it. Tim Daly On 12/14/2010 11:23 PM, Alex Osborne wrote: javajosh writes: Just ran across: http://steve-yegge.blogspot.com/2006/04/lisp-is-not-acceptable-lisp.html Whoah! I had no idea there was so much, uh, 'intricacy' going on behind Lisp. :) Anyway, it was interesting to read it having a bit of Clojure under my belt. With the exception of types, it seems like Clojure addresses most, if not all, of the concerns he brings up. What do you think? There's a hint about it in one of his recent posts: http://steve-yegge.blogspot.com/2010/07/blogger-finger.html "I used to have lot of open, long-standing concerns about the future of programming and productivity, but my sabbatical last year finally brought me some clojure." -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure 1.3 Alpha 4
On Tue, Dec 14, 2010 at 7:02 PM, Brian Goslinga wrote: > (Since java.lang.BigInteger is > slow on small numbers, clojure.lang.BigInt is also being introduced > (which is the type of 1N) that should be as fast as math was in 1.2 > when the numbers fit into a long) > AFAIK, this hasn't been done yet, and clojure.lang.BigInt is just a stub that is as slow as java.lang.BigInteger. Is this correct? -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
The 'in' family
The functions get-in, assoc-in, update-in are really useful. Just
wanted to share a thoughts.
user=> (def m {:a {:b {:c 10 :c1 20} :b1 90} :a1 100})
#'user/m
1. Lets see the behavior of these functions in the corner case of
empty keyseq:
user=> (get-in m [])
{:a {:b {:c 10, :c1 20}, :b1 90}, :a1 100}
user=> (assoc-in m [] 42)
{nil 42, :a {:b {:c 10, :c1 20}, :b1 90}, :a1 100}
user=> (update-in m [] assoc :a2 42)
{nil {:a2 42}, :a {:b {:c 10, :c1 20}, :b1 90}, :a1 100}
get-in, assoc-in pretty much behave the way I would expect them to but
update-in is wierd especially considering get-in's output.
How about this:
user=> (update-in-2 m [] assoc :a2 42)
{:a2 42, :a {:b {:c 10, :c1 20}, :b1 90}, :a1 100}
(defn update-in-2
[m ks f & args]
(if (= 0 (count ks))
(apply f m args)
(let [[k & ks] ks]
(assoc m k
(apply update-in-2 (get m k) ks f args)
2. There's no dissoc-in ! With the above definition of update-in-2,
dissoc-in is simply:
(defn dissoc-in [m ks] (update-in-2 m (butlast ks) dissoc (last ks)))
Even assoc-in is simply:
(defn assoc-in [m ks v] (update-in-2 m (butlast ks) assoc (last ks)
v))
Can we please have dissoc-in in core.
- Thanks
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Debugging with IntelliJ Idea 10 and La Closure Plugin version 0.3.15
I'm using IntelliJ Idea 10 with the La Closure plugin version 0.3.15 and Java 6 I've added Clojure 1.2 to a project. The breakpoints I put on Java code get hit, but the ones I put on Clojure do not. in fact, if the debugger is stopped on a Java breakpoint, the breakpoints on Clojure code have an x in them and they have a warning that says, for example, No executable code found at line 4 in class at debugland$eval3. I've tried putting breakpoints in Clojure core functions like println, but I still get the red x's. Would really, really appreciate any help on this. I've tried Idea 9 with both Clojure 1.1 and 1.2 with similar results. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: The 'in' family
One thing I've argued for in the past, but got no traction: We have: get-in, get assoc-in, assoc update-in, ? Let's add update to go with update-in. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: The 'in' family
On Wed, Dec 15, 2010 at 12:12 AM, Mark Engelberg wrote: > One thing I've argued for in the past, but got no traction: > We have: > get-in, get > assoc-in, assoc > update-in, ? > Let's add update to go with update-in. Let's give them absolutely no excuse like "we don't have time to write the code because so much else is on our plates right now!" as well: (defn update [m k f args] (assoc m k (apply f (get m k) args))) -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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 1.3 Alpha 4
On Tue, Dec 14, 2010 at 10:37 PM, Michael Gardner wrote: > On Dec 14, 2010, at 9:26 PM, Ken Wesson wrote: > >> On Tue, Dec 14, 2010 at 10:02 PM, Brian Goslinga >> wrote: >>> This topic has been discussed to death before on this group. >> >> If so, it was before I joined. > > That's what archives are for Are you honestly suggesting I search the archives for every word of every thought that it ever occurs to me to post here? I don't have that kind of time and I doubt anyone else does. If anyone started to actually enforce such a rule, participation here would drop to practically zero overnight. >>> Doing the right thing is actually harder than you might first think >> >> But it's also already being done by Clojure 1.2 so I don't see how >> that's relevant. If someone proposed a novel behavior, it being >> "harder than you might first think" would be a point against that >> proposal. However it cannot logically ever be a point against keeping >> current behavior. > > Are you saying that simplifying existing code provides no benefit? If it breaks existing client code then yes. Simplifying internals without altering API semantics is generally a good thing; when the API semantics start changing, though, an unequivocal improvement becomes a tradeoff that might tip either way. Changing the behavior of arithmetic operators that are found in virtually every extant source file is going to have a very big downside in broken backward compatibility. If there's an upside, it would have to be staggeringly enormous to make such a change worthwhile. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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 1.3 Alpha 4
On Tue, Dec 14, 2010 at 10:57 PM, Brian Goslinga wrote: > On Dec 14, 9:24 pm, Ken Wesson wrote: >> Breaking source compatibility with just about every single preexisting >> line of Clojure code out there is supposed to make our lives *easier*? > Actually, it appears that the majority of the lines of code out there > use integers that fit inside a long, so the change doesn't affect > them. You could as well argue that dosync be changed to simply lock all the things that are altered or assured instead of doing the whole STM thing. Most things wouldn't break ... but a few things would, with the odd deadlock here and there. And that too would simplify the implementation. A lot. > There exists a difference in the behavior of primitive and reference > type math in 1.2; Clojure 1.3 will unify the behavior of the two. The > auto promoting operators need to return an Object currently even if > they take in primitives because the operation might overflow. This > means that the auto promoting operators are incompatible with fast > math (blame the JVM). But we have the unchecked-foo operators for when we need fast math. We have the longer, more awkward name in the rare case and plain old +, -, etc. in the common case. Now you're proposing to reverse that. Worse, from the sounds of it the new + isn't exactly the old unchecked-+; it still checks for overflow rather than allowing wrapping. That's going to add a compare-and-branch to every add instruction and halve the speed of those operators on typical hardware. Compare-and-throw-exception is hardly superior to compare-and-box-in-BigInteger, since it's still slow AND now some arithmetic code that used to work but be slow will now explode in your face. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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 1.3 Alpha 4
On Wed, Dec 15, 2010 at 12:22 AM, Ken Wesson wrote: > > Are you honestly suggesting I search the archives for every word of > every thought that it ever occurs to me to post here? > With all due respect, the topic has already been bike shedded into the ground by many members in the community. Which isn't to say you don't have a valid point, but that ground has already been covered at great, great length. If you want to know why the decision was made read the thread. If you don't want to read the thread, well there's not much too talk about that hasn't been talked about before. Such decisions aren't not made lightly and it would be fair to at least go read what Rich Hickey had to say on the matter. 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
Writing apps in clojure and/or java : Binary Search Trees
My main question is, what tasks/apps is clojure ideally suited for? I've been playing with implementing Binary Search Trees in clojure and Java as a way to learn clojure and compare the two languages. My original thought was to implement some basic data types and algorithms in a handful of interesting languages and compare the experience. For me, the list includes clojure, java, scala, and erlang. So far, my experience implementing basic BST functionality in clojure has felt contrived, and was definitely easier in java. Code: https://github.com/ToddG/experimental/tree/master/clojure/algorithms 1. TreeNode (defrecord TreeNode [left right key] ... I played with writing this basic TreeNode, but it has the disadvantage of requiring rebuilding the ancestor nodes back up to the root. It's also not clear to me how to write various traversals (inorder,postorder,preorder) for this. A thread on stacktrace suggested that instead of writing one's own implementation of a balanced tree, one could just use clojure's sorted map. It's based on clojure.lang.PersistentTreeMap, a balanced (red-black) tree implemented in java. Great idea, and in practice, that's exactly what I'd do, just like in java land I'd use java.util.TreeMap. But, I'm plodding along, b/c I want to see this exercise through. 2. HashTree (defrecord Node [key data] ... (defrecord HashTree [table] ... My next try was to create a BST based on clojure's hash-map (clojure.lang.PersistentHashMap). Node and HashTree use calculated values for the left and right child nodes rather than maintaining pointers within the Node record. Next up, I plan to try and extend my Traversal protocol to these record types. I've already tried with TreeNode, and that stumped me: (defprotocol TRAVERSAL (inorder [this tree visitor]) ... At the end of the day, I'm not sure how valid this exercise is. I'm certainly slowly learning clojure...but perhaps learning by way of what not do do. At this point, I think I'd prefer to write interesting algorithms/datatypes in java and then surface them to clojure. BTW - I've documented the links I've found useful along the way in the README. I've ordered 'Land of Lisp', so I'll report back how that works w/ Clojure. -Todd -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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 1.3 Alpha 4
On Wed, Dec 15, 2010 at 12:38 AM, David Nolen wrote: > On Wed, Dec 15, 2010 at 12:22 AM, Ken Wesson wrote: >> >> Are you honestly suggesting I search the archives for every word of >> every thought that it ever occurs to me to post here? > > With all due respect, the topic has already been bike shedded into the > ground by many members in the community. Fascinating. Your point being? That statement of yours does not, after all, magically make searching the archive for every word in every post you ever think of posting suddenly become practical. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Writing apps in clojure and/or java : Binary Search Trees
On Wed, Dec 15, 2010 at 12:49 AM, Todd wrote: > My main question is, what tasks/apps is clojure ideally suited for? > > I've been playing with implementing Binary Search Trees in clojure and Java > as a way to learn clojure and compare the two languages. My original thought > was to implement some basic data types and algorithms in a handful of > interesting languages and compare the experience. For me, the list includes > clojure, java, scala, and erlang. > > So far, my experience implementing basic BST functionality in clojure has > felt contrived, and was definitely easier in java. > > Code: https://github.com/ToddG/experimental/tree/master/clojure/algorithms > > 1. TreeNode > > (defrecord TreeNode [left right key] ... Perhaps instead of emulating a Java-esque approach you should use Clojure's native data structures. E.g. a vector [key left right] for a node. In-order traversal is then just (defn in-order-seq [node] (let [left (node 1) right (node 2)] (cons (node 0) (concat (if left (in-order-seq left)) (if right (in-order-seq right) "Inserting" a node is (assoc-in node [1 2 2 1 2] some-new-node) or similar; in this case, from the root it goes left, right, right, and left to reach the parent node of the new node, and inserts or replaces the right child of that parent node; the sequence of 1s and 2s could itself be a generated seq. Finding the correct position in the tree for something, as such a seq, is then: (defn pos-of [node k] (if-not (= (node 0) k) (let [left (node 1) right (node 2)] (if (and left (<= k (left 0))) (cons 1 (pos-of left k)) (if right (cons 2 (pos-of right k)) (if left [2] [1])) Then you can do an insert with a modified pos-of (one traversal) or with (assoc-in node (pos-of node k) [k nil nil]) and a query with (get-in node (pos-of node k)) which should produce the node containing k, if any, or nil if there is none. Of course using just the above won't generally create a *balanced* tree but it is a start and shows one way to use Clojure's native data structures to do this kind of thing. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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 1.3 Alpha 4
On Wed, Dec 15, 2010 at 12:50 AM, Ken Wesson wrote: > On Wed, Dec 15, 2010 at 12:38 AM, David Nolen > wrote: > > On Wed, Dec 15, 2010 at 12:22 AM, Ken Wesson wrote: > >> > >> Are you honestly suggesting I search the archives for every word of > >> every thought that it ever occurs to me to post here? > > > > With all due respect, the topic has already been bike shedded into the > > ground by many members in the community. > > Fascinating. Your point being? That statement of yours does not, after > all, magically make searching the archive for every word in every post > you ever think of posting suddenly become practical. I wasn't suggesting you do that. People earlier in the post gave links to the thread. 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: Writing apps in clojure and/or java : Binary Search Trees
Clojure's getting better all the time at implementing Java-like things without dropping down to Java. But the whole point of programming Clojure is to be "more functional", using and creating persistent data structures that work well with its STM. Coding an imperative, mutable BST in Clojure isn't going to be its strong suit. I recommend reading Okasaki's Purely Functional Data Structures to build a better understanding of what kind of data structures you'd want to create in Clojure (if you need something beyond the built-ins), and how to implement them. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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 1.3 Alpha 4
On Dec 14, 2010, at 11:22 PM, Ken Wesson wrote: > On Tue, Dec 14, 2010 at 10:37 PM, Michael Gardner wrote: >> That's what archives are for > > Are you honestly suggesting I search the archives for every word of > every thought that it ever occurs to me to post here? > > I don't have that kind of time and I doubt anyone else does. If anyone > started to actually enforce such a rule, participation here would drop > to practically zero overnight. That's a mighty fine straw man you have there. And how deftly you knock it down! >> Are you saying that simplifying existing code provides no benefit? > > If it breaks existing client code then yes. Simplifying internals > without altering API semantics is generally a good thing; when the API > semantics start changing, though, an unequivocal improvement becomes a > tradeoff that might tip either way. > > Changing the behavior of arithmetic operators that are found in > virtually every extant source file is going to have a very big > downside in broken backward compatibility. If there's an upside, it > would have to be staggeringly enormous to make such a change > worthwhile. The claim I responded to was: "it cannot logically ever be a point against keeping current behavior". You are now arguing a much weaker claim, that the upside of simplifying existing code is unlikely to outweigh the drawbacks of breaking existing code. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Writing apps in clojure and/or java : Binary Search Trees
On Tue, Dec 14, 2010 at 10:08 PM, Mark Engelberg wrote: > Coding an imperative, mutable BST in Clojure isn't going to be its strong > suit. > > Maybe you didn't do this though. I didn't read your code carefully. I just saw the "delete" in your protocol and assumed it was mutable. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Writing apps in clojure and/or java : Binary Search Trees
On Wed, Dec 15, 2010 at 1:08 AM, Mark Engelberg wrote: > Clojure's getting better all the time at implementing Java-like things > without dropping down to Java. But the whole point of programming Clojure > is to be "more functional", using and creating persistent data structures > that work well with its STM. Coding an imperative, mutable BST in Clojure > isn't going to be its strong suit. > In fact it'll probably just be discouraging. > I recommend reading Okasaki's Purely Functional Data Structures to build a > better understanding of what kind of data structures you'd want to create in > Clojure (if you need something beyond the built-ins), and how to implement > them. +1 -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Debugging with IntelliJ Idea 10 and La Closure Plugin version 0.3.15
you may want to also post this on the jetbrains la clojure forum http://devnet.jetbrains.net/community/idea/clojure?view=discussions On Wed, Dec 15, 2010 at 12:00 AM, HiHeelHottie wrote: > > I'm using IntelliJ Idea 10 with the La Closure plugin version 0.3.15 > and Java 6 I've added Clojure 1.2 to a project. > > The breakpoints I put on Java code get hit, but the ones I put on > Clojure do not. in fact, if the debugger is stopped on a Java > breakpoint, the breakpoints on Clojure code have an x in them and they > have a warning that says, for example, No executable code found at > line 4 in class at debugland$eval3. > > I've tried putting breakpoints in Clojure core functions like println, > but I still get the red x's. Would really, really appreciate any help > on this. I've tried Idea 9 with both Clojure 1.1 and 1.2 with similar > results. > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en -- Omnem crede diem tibi diluxisse supremum. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: The 'in' family
On Dec 14, 8:52 pm, ka wrote:
> user=> (get-in m [])
> {:a {:b {:c 10, :c1 20}, :b1 90}, :a1 100}
This seems strange to me. I would expect Clojure to return nil, as
there is no key in there that is nil. Assuming that an empty vector is
the same as asking for a nil key, that is.
(I suppose it makes sense in a "peel the layers away" sense - if you
don't say which layer to peel, then you get the whole onion).
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from 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: The 'in' family
On Dec 15, 6:12 am, Mark Engelberg wrote: > One thing I've argued for in the past, but got no traction: > We have: > get-in, get > assoc-in, assoc > update-in, ? > Let's add update to go with update-in. update should really be in there. I always try to write update then i remember that I have to use update-in. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Yegge's "Lisp is not an acceptable Lisp" - was he talking about Clojure?
Lisp is Not an Acceptable Lisp Friday, April 14, 2006 Clojure wasn't out then. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
