Re: Documentation tools
On Tue, Sep 7, 2010 at 11:10 PM, Mark Engelberg wrote: > What pre-conditions need to be met by the inputs? > What invariants are maintained by the function? > What are the performance guarantees of the function? And this can't be expressed in a single sentence? > Many times there are dozens of functions that are interrelated. Only > one or two of them are the crucially important "entry points" that > provide the high-level API. Then reorganize your files. Each file should have a specific public API. > Good documentation makes > it clear what is "the right way". Fix the code. The "right way" should be the only / obvious way. > The list goes on. I just don't see these questions arising from an agile point of view... > If you want to comment your code for other > people to maintain it, that's even more challenging. Nonsense. That's all about good, descriptive naming. If you can't document your code in a single sentence, it's too complex. I keep hearing FP folks talking about small functions and breaking things down so this issue of documentation runs counter to that... > "Always code as if the guy who ends up maintaining your code will be a > violent psychopath who knows where you live." -- John F. Woods Most people who read my code have said it reads like poetry and they love it. I have almost zero comments in my code. I have literate function / variable names. Comments can get out of sync with code so the fewer comments you have, the better, as far as I'm concerned. The code itself should be literate. -- 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: Documentation tools
As a counterexample to these statements consider proxy, genclass, and
it's ilk ---
I don't think reading the source is good enough to totally understand
the purpose behind those functions.
There's also the issue of providing examples in the doc string.
What's more clear,
"
Associates a value in a nested associative structure, where ks is a
sequence of keys and v is the new value and returns a new nested structure.
If any levels do not exist, hash-maps will be created.
"
---or---
"
Associates a value in a nested associative structure, where ks is a
sequence of keys and v is the new value and returns a new nested structure.
If any levels do not exist, hash-maps will be created.
Example: > (assoc-in {} [:a :B] 5)
{:a {:B 5}}
"
?
--Robert McIntyre
On Wed, Sep 8, 2010 at 3:05 AM, Sean Corfield wrote:
> On Tue, Sep 7, 2010 at 11:10 PM, Mark Engelberg
> wrote:
>> What pre-conditions need to be met by the inputs?
>> What invariants are maintained by the function?
>> What are the performance guarantees of the function?
>
> And this can't be expressed in a single sentence?
>
>> Many times there are dozens of functions that are interrelated. Only
>> one or two of them are the crucially important "entry points" that
>> provide the high-level API.
>
> Then reorganize your files. Each file should have a specific public API.
>
>> Good documentation makes
>> it clear what is "the right way".
>
> Fix the code. The "right way" should be the only / obvious way.
>
>> The list goes on.
>
> I just don't see these questions arising from an agile point of view...
>
>> If you want to comment your code for other
>> people to maintain it, that's even more challenging.
>
> Nonsense. That's all about good, descriptive naming. If you can't
> document your code in a single sentence, it's too complex. I keep
> hearing FP folks talking about small functions and breaking things
> down so this issue of documentation runs counter to that...
>
>> "Always code as if the guy who ends up maintaining your code will be a
>> violent psychopath who knows where you live." -- John F. Woods
>
> Most people who read my code have said it reads like poetry and they
> love it. I have almost zero comments in my code. I have literate
> function / variable names. Comments can get out of sync with code so
> the fewer comments you have, the better, as far as I'm concerned. The
> code itself should be literate.
> --
> 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
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from 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: Documentation tools
On Wed, Sep 8, 2010 at 12:05 AM, Sean Corfield wrote: > Most people who read my code have said it reads like poetry... Poetry takes a complex message and packs it into as few words as possible, resulting in something so cryptic and enigmatic that people bicker endlessly about what subtle meanings the author really intended. I don't know that I'd be flattered by that comparison :) If you ever read an article presenting some new algorithm, data structure, etc. in an academic journal, the published article will certainly contain some actual prose describing what's going on. Code does not, in general, speak for itself (although good code with good naming conventions can certainly be understood by people who use the same conventions and understand the underlying problem and solution approach as well as you do). If code did speak for itself, these journal articles would just be big hunks of code. Now that's dealing with documentation on the level of understanding the code implementation itself. But even API documentation varies considerably in terms of scope and complexity. The Flash API documentation is very well written and it fills two 600+-page volumes. Racket has done a very nice job of documenting the language and the libraries. As I understand it, their team of developers spent nearly a year working primarily on documentation rather than new features. Most features are explained in two separate documents: a "guide" that explains the gist of how a certain library works, and a "reference" that provides the API details. Both documents are extremely useful. The guide is something you can read cover to cover to feel like you really understand what the system is capable of. The reference is something where you can look up specific issues. On the spectrum between "self-documenting code" and Knuth's "literate programming", my personal preference is something about two-thirds of the way towards Knuth. It's always hard to find time to document code, and documenting code that is heavily in flux can potentially be a waste of time, but ideally, I think that spending 20% of one's time on documentation is a good target to aim for. Our preferences are shaped by our experiences, of course, and your mileage may vary. What is the largest body of code you've tried to read and understand and maintain? Were you able to talk with developers about the code, or did you just have to understand it by reading it? What things did you like and dislike about the readability of their code? My experience aligns well with the points raised in this essay (see http://www.joelonsoftware.com/articles/fog69.html for the full article): "There's a subtle reason that programmers always want to throw away the code and start over. The reason is that they think the old code is a mess. And here is the interesting observation: they are probably wrong. The reason that they think the old code is a mess is because of a cardinal, fundamental law of programming: It’s harder to read code than to write it. This is why code reuse is so hard. This is why everybody on your team has a different function they like to use for splitting strings into arrays of strings. They write their own function because it's easier and more fun than figuring out how the old function works." I agree that it is harder to read code than to write it and that readability is the #1 obstacle to code reuse, so I feel an obligation to tilt the balance a bit more in favor of the reader. I think just about our only point of agreement is that I also feel that it is difficult to maintain documentation that is separate from the code. That's why I'm always on the lookout for new tools and techniques to make that process easier. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: JSON lib of choice?
There are some performance numbers on different serialization libraries here: http://wiki.github.com/eishay/jvm-serializers/ Jackson is a Java JSON library and it seems to do pretty well in those benchmarks. On Tue, Sep 7, 2010 at 22:01, Michael Ossareh wrote: > > > On Mon, Sep 6, 2010 at 19:50, Wilson MacGyver wrote: >> >> I figure enough time has passed that I want to bring this up again. >> >> For JSON, are you using clojure.contrib.json or clj-json? Why? > > > We use org.danlarkin.json, because it encodes and decodes (contrib.json > didn't when we made our decision) and it was the first hit in the google > listings for "clojure json". > > If anyone gets around to doing some real world perf analysis and there is a > significant winner then we may switch. > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en -- Venlig hilsen / Kind regards, Christian Vest Hansen. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: giws a window for people using c/c++ into clojure ..
just as a followup .. this is the solution I got from hoek when I reposted
it on the irc
(defn emit-giws-xml [c]
(let [package (.getPackage c)
methods (map #(hash-map :name (.getName %)
:returnType (str (.getName (.getReturnType %)))
:params (map (fn [p] {:name (.getName %)})
(.getParameterTypes %)))
(.getMethods c))]
methods
))
(clojure.pprint/pprint (emit-giws-xml Object))
http://gist.github.com/569861
On Wed, Sep 8, 2010 at 11:01 AM, Sunil S Nandihalli <
sunil.nandiha...@gmail.com> wrote:
> Hello everybody,
> I recently came across giws
>
> http://www.scilab.org/products/other/giws
>
> a tool to call java code from c/c++ all it really needs to generate all the
> jni-wrappers is a simple xml file which indicates the class name and the
> member functions .. some thing as simple as ...
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> given clojure's power of macros .. it should be possible to automate the
> creation of this xml for every clojure-structure and function by redefining
> the *defstruct* and *defn * and other similar macros .. I would like to
> give it a shot .. I am kind of new to all these things .. so would like to
> hear what the clojure community has to say about this...
>
> Thanks in advance,
> Sunil.
>
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from 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: deftype makes no extender?
Hello Stuart, sorry to answer so late, got holidays, happily. I tried to use the function extenders to list the implementations, so to say, of the protocol. That was playing around, not a use case taken from reality. If I try to make a use case up, hm, I may need it in the development environment, to find functions to ponder their use. Regards, alux On 3 Sep., 16:05, Stuart Halloway wrote: > Let's back up: what are you trying to do with 'extenders'? > > Stu > > > Yes, thats what I see. > > I just dont think this is very sensible. > > > Thank you Meikel! > > > Greetings, alux > > > On 3 Sep., 13:10, Meikel Brandmeyer wrote: > >> Hi, > > >> On 3 Sep., 12:49, alux wrote: > > >>> shouldnt the type x be listed a extender of xx here? Or why not? > > >> No. It shows up if you actually use extend to the extend the protocol > >> to the type. > > >> 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
A difficult Metaphor for Macros (especially for Java people)
Hello, I still try to read my way through Paul Grahams "On Lisp", and always think how to motivate this stuff to my fellow Java people. How do I describe what it is all about in this "Code is Data", and "Macros let you grow your own language towards the problem" stuff? [Why? Well, maybe I read to much of Paul Grahams texts. So my current working hypothesis is that this is the one big strength of Lisp that other languages still dont have - so if I want to motivate people to learn a Lisp, I have to at least point to it.] Short answer: Difficult. ;-) Especially if I find formulations like "You can have the language which suits your program, even if it ends up looking quite different from Lisp." Longer Answer: What puzzles me most about this quoted formulation is the words "different from Lisp", as I know: All my Java collegues see Lisp=Parentheses. So, to them, PGs formulation is even misleading. To them it doesn't look quite different at the end. Thus I try to come up with a metaphor, and I want to discuss it here, in the hope I don't tell them rubbish at the end. I want to liken XML to Lisp data. Then, with XSLT, some XML structures are actually programs. Programs that work on XML data. The Lisp parentheses are just like the basic XML syntax - elements, tags, attributes. Obviousely Lisp has a much simpler syntax, but its trees anyway. So XSLT can be likened to Lisp macros then. And the use of it? Well, I currently want to talk to some people who use Maven a lot. So the example I came up with is: Think about when you had Ant, some years ago. Ant is just a programming language for Java builds. After a while you recognise that it'd be better to have something that describes the project declaratively, with opinionated defaults. Well, after some discussions you define something called pom.xml, that does this (congratulation, we just invented Maven). Immediately you see that all these Ant build scripts mentioned above could be generated from this Maven pom.xml. So you might write XSLT to do so (this of course deviates from historical truth). Some step later, you don't generate them anymore as files; the only needed file is the pom.xml, and the transformations of course. So XML and XSLT are data and code, and they can do something that is a) similar to what Lisp macros do, and b) this is something my collegues understand. Hopefully. So, coming back to Paul Grahams quote, what the beginners see is: It was XML and stays XML. The things "looking quite different" are, in this metaphor, the XML schema of the Maven pom.xml versus the XML scheme of the Ant files. I hope that they will understand the power; and agree they will never try and do this in XSLT. The Lisp syntax is just simple enough to be usable for such tasks. So, now you probably understand why I ask this question here, even if it is a general Lisp question. This may be the only group where people understand Lisp and Macros, XML/XSLT, and Ant, and Maven ;-) Now the question: Do you see any problems with this metaphor, is it misleading somewhere? Thank you, alux -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: A difficult Metaphor for Macros (especially for Java people)
Actually, this metaphor has been used before. Check http://www.defmacro.org/ramblings/lisp.html for an other version of your story ;). 2010/9/8 alux : > Hello, > > I still try to read my way through Paul Grahams "On Lisp", and always > think how to motivate this stuff to my fellow Java people. How do I > describe what it is all about in this "Code is Data", and "Macros let > you grow your own language towards the problem" stuff? > [Why? Well, maybe I read to much of Paul Grahams texts. So my current > working hypothesis is that this is the one big strength of Lisp that > other languages still dont have - so if I want to motivate people to > learn a Lisp, I have to at least point to it.] > > Short answer: Difficult. ;-) > > Especially if I find formulations like > "You can have the language which suits your program, even if it ends > up looking quite different from Lisp." > > Longer Answer: > > What puzzles me most about this quoted formulation is the words > "different from Lisp", as I know: All my Java collegues see > Lisp=Parentheses. So, to them, PGs formulation is even misleading. To > them it doesn't look quite different at the end. > > Thus I try to come up with a metaphor, and I want to discuss it here, > in the hope I don't tell them rubbish at the end. > > I want to liken XML to Lisp data. Then, with XSLT, some XML structures > are actually programs. Programs that work on XML data. The Lisp > parentheses are just like the basic XML syntax - elements, tags, > attributes. Obviousely Lisp has a much simpler syntax, but its trees > anyway. So XSLT can be likened to Lisp macros then. > > And the use of it? Well, I currently want to talk to some people who > use Maven a lot. So the example I came up with is: > Think about when you had Ant, some years ago. Ant is just a > programming language for Java builds. > After a while you recognise that it'd be better to have something that > describes the project declaratively, with opinionated defaults. Well, > after some discussions you define something called pom.xml, that does > this (congratulation, we just invented Maven). Immediately you see > that all these Ant build scripts mentioned above could be generated > from this Maven pom.xml. So you might write XSLT to do so (this of > course deviates from historical truth). Some step later, you don't > generate them anymore as files; the only needed file is the pom.xml, > and the transformations of course. > > So XML and XSLT are data and code, and they can do something that is > a) similar to what Lisp macros do, and > b) this is something my collegues understand. > > Hopefully. > > So, coming back to Paul Grahams quote, what the beginners see is: It > was XML and stays XML. The things "looking quite different" are, in > this metaphor, the XML schema of the Maven pom.xml versus the XML > scheme of the Ant files. > > I hope that they will understand the power; and agree they will never > try and do this in XSLT. The Lisp syntax is just simple enough to be > usable for such tasks. > > So, now you probably understand why I ask this question here, even if > it is a general Lisp question. This may be the only group where people > understand Lisp and Macros, XML/XSLT, and Ant, and Maven ;-) > > Now the question: > Do you see any problems with this metaphor, is it misleading > somewhere? > > Thank you, alux > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en -- Linux-user #496644 (http://counter.li.org) - first touch of linux in 2004 Demandoj en aŭ pri Esperanto? Questions about Esperanto? Vragen over Esperanto? Perguntas sobre o Esperanto? - http://demandoj.tk -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: A difficult Metaphor for Macros (especially for Java people)
Hello Joop, thanks for the link. So it seems not to be completely misled ;-) Greetings, alux On 8 Sep., 11:59, Joop Kiefte wrote: > Actually, this metaphor has been used before. > Checkhttp://www.defmacro.org/ramblings/lisp.htmlfor an other version of > your story ;). > > 2010/9/8 alux : > > > > > Hello, > > > I still try to read my way through Paul Grahams "On Lisp", and always > > think how to motivate this stuff to my fellow Java people. How do I > > describe what it is all about in this "Code is Data", and "Macros let > > you grow your own language towards the problem" stuff? > > [Why? Well, maybe I read to much of Paul Grahams texts. So my current > > working hypothesis is that this is the one big strength of Lisp that > > other languages still dont have - so if I want to motivate people to > > learn a Lisp, I have to at least point to it.] > > > Short answer: Difficult. ;-) > > > Especially if I find formulations like > > "You can have the language which suits your program, even if it ends > > up looking quite different from Lisp." > > > Longer Answer: > > > What puzzles me most about this quoted formulation is the words > > "different from Lisp", as I know: All my Java collegues see > > Lisp=Parentheses. So, to them, PGs formulation is even misleading. To > > them it doesn't look quite different at the end. > > > Thus I try to come up with a metaphor, and I want to discuss it here, > > in the hope I don't tell them rubbish at the end. > > > I want to liken XML to Lisp data. Then, with XSLT, some XML structures > > are actually programs. Programs that work on XML data. The Lisp > > parentheses are just like the basic XML syntax - elements, tags, > > attributes. Obviousely Lisp has a much simpler syntax, but its trees > > anyway. So XSLT can be likened to Lisp macros then. > > > And the use of it? Well, I currently want to talk to some people who > > use Maven a lot. So the example I came up with is: > > Think about when you had Ant, some years ago. Ant is just a > > programming language for Java builds. > > After a while you recognise that it'd be better to have something that > > describes the project declaratively, with opinionated defaults. Well, > > after some discussions you define something called pom.xml, that does > > this (congratulation, we just invented Maven). Immediately you see > > that all these Ant build scripts mentioned above could be generated > > from this Maven pom.xml. So you might write XSLT to do so (this of > > course deviates from historical truth). Some step later, you don't > > generate them anymore as files; the only needed file is the pom.xml, > > and the transformations of course. > > > So XML and XSLT are data and code, and they can do something that is > > a) similar to what Lisp macros do, and > > b) this is something my collegues understand. > > > Hopefully. > > > So, coming back to Paul Grahams quote, what the beginners see is: It > > was XML and stays XML. The things "looking quite different" are, in > > this metaphor, the XML schema of the Maven pom.xml versus the XML > > scheme of the Ant files. > > > I hope that they will understand the power; and agree they will never > > try and do this in XSLT. The Lisp syntax is just simple enough to be > > usable for such tasks. > > > So, now you probably understand why I ask this question here, even if > > it is a general Lisp question. This may be the only group where people > > understand Lisp and Macros, XML/XSLT, and Ant, and Maven ;-) > > > Now the question: > > Do you see any problems with this metaphor, is it misleading > > somewhere? > > > Thank you, alux > > > -- > > You received this message because you are subscribed to the Google > > Groups "Clojure" group. > > To post to this group, send email to clojure@googlegroups.com > > Note that posts from new members are moderated - please be patient with > > your first post. > > To unsubscribe from this group, send email to > > clojure+unsubscr...@googlegroups.com > > For more options, visit this group at > >http://groups.google.com/group/clojure?hl=en > > -- > Linux-user #496644 (http://counter.li.org) - first touch of linux in 2004 > > Demandoj en aŭ pri Esperanto? Questions about Esperanto? Vragen over > Esperanto? Perguntas sobre o Esperanto? -http://demandoj.tk -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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 Image/video processing?
> Thank you Mark Downie for recommending OpenCL, I'll start playing > around with it. As for accessing the c libraries directly, I'm afraid > I don't know much about JNI to do it from clojure. Do you or anyone > know of a good way to start with JNI in clojure? If you are going to use a straight C library and not C++ there is probably no need for hand-crafted JNI code unless you need the function calls themselves to be extra-special-super-fast. JNA provides a way to interface to C libraries without touching C code. There are at least two Clojure wrappers for JNA: http://github.com/bagucode/clj-native (http://clojars.org/clj-native) http://github.com/Chouser/clojure-jna clj-native is my creation and it's been a little neglected lately but should work fine with clojure 1.2 both at repl and when using AOT compilation. If you try it and have problems or suggestions for improvement, please let me know. /Markus -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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.contrib.trace not working on 1.2?
I seem to recall that 1.2 is using "chunked" lazy sequences for performance reasons, and fib is a lazy sequence. I wonder if you'd start seeing intermediate steps using (fib 20) instead of (fib 3)? m On Tue, Sep 7, 2010 at 7:32 PM, Scott Jaderholm wrote: > Why does c.c.trace give different output on 1.2 than it did on 1.1? > > From > http://learnclojure.blogspot.com/2010/02/slime-2009-10-31-user-defn-fib-n-if-n-2.html > > On 1.1 > > user> (dotrace (fib) (fib 3)) > > TRACE t1880: (fib 3) > TRACE t1881: | (fib 2) > TRACE t1882: | | (fib 1) > TRACE t1882: | | => 1 > TRACE t1883: | | (fib 0) > TRACE t1883: | | => 0 > TRACE t1881: | => 1 > TRACE t1884: | (fib 1) > TRACE t1884: | => 1 > TRACE t1880: => 2 > 2 > user> > > On 1.2 > > user> dotrace (fib) (fib 3)) > > TRACE t11624: (fib 3) > TRACE t11624: => 2 > > Thanks, > Scott > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from 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: ANN: Indyvon - GUI library
Very interesting concept, thank you for sharing. Francesco On Sep 8, 3:39 am, Mikhail Kryshen wrote: > Hi, > > I have recently published Indyvon -- an experimental multithreaded GUI > library for Clojure. The main idea behind the library is that base UI > element (called "layer") does not define any state (has no location, > size, parent element). Dynamic layout of layers is captured at the > rendering time and remembered for event processing until the next > repaint is complete. Java 2D API is used for rendering. > > Source code:http://bitbucket.org/kryshen/indyvon/src > > See README there for a more detailed description. > src/net/kryshen/indyvon/demo.clj contains runnable example. > > Currently only some basic layers are implemented (no normal widgets) > and I have no plan to build a complete GUI toolkit. I am using the > library in another project for graph visualization. > > Expect bad English style (I am not native speaker) in readme and > docstrings, corrections are welcome. > > -- > Mikhail -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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.contrib.trace not working on 1.2?
On Wed, Sep 8, 2010 at 7:30 AM, Mark Nutter wrote: > I seem to recall that 1.2 is using "chunked" lazy sequences for > performance reasons, and fib is a lazy sequence. I wonder if you'd > start seeing intermediate steps using (fib 20) instead of (fib 3)? This fib doesn't look lazy to me so I don't think that's it. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: deftype makes no extender?
The first rule of open dispatch club is "you never get a complete list of club members." :-) This is also true for e.g. Java interfaces: there is no API call for "reflectively show me all implementers of this interface." The IDE/tools use case is a real one, but it will need to be solved in the same way IDEs currently find all implementers of an interface: the information is in the environment, not in the core of the language. Stu > Hello Stuart, sorry to answer so late, got holidays, happily. > > I tried to use the function extenders to list the implementations, so > to say, of the protocol. > That was playing around, not a use case taken from reality. If I try > to make a use case up, hm, I may need it in the development > environment, to find functions to ponder their use. > > Regards, alux > > On 3 Sep., 16:05, Stuart Halloway wrote: >> Let's back up: what are you trying to do with 'extenders'? >> >> Stu >> >>> Yes, thats what I see. >>> I just dont think this is very sensible. >> >>> Thank you Meikel! >> >>> Greetings, alux >> >>> On 3 Sep., 13:10, Meikel Brandmeyer wrote: Hi, >> On 3 Sep., 12:49, alux wrote: >> > shouldnt the type x be listed a extender of xx here? Or why not? >> No. It shows up if you actually use extend to the extend the protocol to the type. >> 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 -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: A difficult Metaphor for Macros (especially for Java people)
I found the easiest way to introduce macros is just to introduce them as small syntactic sugaring. For example, getting rid of the explicit (fn [] ...) for macros like (with-open file ...). Once people get accustomed to this, they naturally extend it to more and more complicated usages. -Patrick On Sep 8, 6:12 am, alux wrote: > Hello Joop, > > thanks for the link. So it seems not to be completely misled ;-) > > Greetings, alux > > On 8 Sep., 11:59, Joop Kiefte wrote: > > > > > Actually, this metaphor has been used before. > > Checkhttp://www.defmacro.org/ramblings/lisp.htmlforan other version of > > your story ;). > > > 2010/9/8 alux : > > > > Hello, > > > > I still try to read my way through Paul Grahams "On Lisp", and always > > > think how to motivate this stuff to my fellow Java people. How do I > > > describe what it is all about in this "Code is Data", and "Macros let > > > you grow your own language towards the problem" stuff? > > > [Why? Well, maybe I read to much of Paul Grahams texts. So my current > > > working hypothesis is that this is the one big strength of Lisp that > > > other languages still dont have - so if I want to motivate people to > > > learn a Lisp, I have to at least point to it.] > > > > Short answer: Difficult. ;-) > > > > Especially if I find formulations like > > > "You can have the language which suits your program, even if it ends > > > up looking quite different from Lisp." > > > > Longer Answer: > > > > What puzzles me most about this quoted formulation is the words > > > "different from Lisp", as I know: All my Java collegues see > > > Lisp=Parentheses. So, to them, PGs formulation is even misleading. To > > > them it doesn't look quite different at the end. > > > > Thus I try to come up with a metaphor, and I want to discuss it here, > > > in the hope I don't tell them rubbish at the end. > > > > I want to liken XML to Lisp data. Then, with XSLT, some XML structures > > > are actually programs. Programs that work on XML data. The Lisp > > > parentheses are just like the basic XML syntax - elements, tags, > > > attributes. Obviousely Lisp has a much simpler syntax, but its trees > > > anyway. So XSLT can be likened to Lisp macros then. > > > > And the use of it? Well, I currently want to talk to some people who > > > use Maven a lot. So the example I came up with is: > > > Think about when you had Ant, some years ago. Ant is just a > > > programming language for Java builds. > > > After a while you recognise that it'd be better to have something that > > > describes the project declaratively, with opinionated defaults. Well, > > > after some discussions you define something called pom.xml, that does > > > this (congratulation, we just invented Maven). Immediately you see > > > that all these Ant build scripts mentioned above could be generated > > > from this Maven pom.xml. So you might write XSLT to do so (this of > > > course deviates from historical truth). Some step later, you don't > > > generate them anymore as files; the only needed file is the pom.xml, > > > and the transformations of course. > > > > So XML and XSLT are data and code, and they can do something that is > > > a) similar to what Lisp macros do, and > > > b) this is something my collegues understand. > > > > Hopefully. > > > > So, coming back to Paul Grahams quote, what the beginners see is: It > > > was XML and stays XML. The things "looking quite different" are, in > > > this metaphor, the XML schema of the Maven pom.xml versus the XML > > > scheme of the Ant files. > > > > I hope that they will understand the power; and agree they will never > > > try and do this in XSLT. The Lisp syntax is just simple enough to be > > > usable for such tasks. > > > > So, now you probably understand why I ask this question here, even if > > > it is a general Lisp question. This may be the only group where people > > > understand Lisp and Macros, XML/XSLT, and Ant, and Maven ;-) > > > > Now the question: > > > Do you see any problems with this metaphor, is it misleading > > > somewhere? > > > > Thank you, alux > > > > -- > > > You received this message because you are subscribed to the Google > > > Groups "Clojure" group. > > > To post to this group, send email to clojure@googlegroups.com > > > Note that posts from new members are moderated - please be patient with > > > your first post. > > > To unsubscribe from this group, send email to > > > clojure+unsubscr...@googlegroups.com > > > For more options, visit this group at > > >http://groups.google.com/group/clojure?hl=en > > > -- > > Linux-user #496644 (http://counter.li.org) - first touch of linux in 2004 > > > Demandoj en aŭ pri Esperanto? Questions about Esperanto? Vragen over > > Esperanto? Perguntas sobre o Esperanto? -http://demandoj.tk -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be
Re: A difficult Metaphor for Macros (especially for Java people)
Hi Patrick, yes, I think thats the right way to teach this stuff. My problem arises earlier - I still have to motivate my collegues, to get them interested, and, maybe, teach them later ;-) Regards, alux On 8 Sep., 16:28, CuppoJava wrote: > I found the easiest way to introduce macros is just to introduce them > as small syntactic sugaring. For example, getting rid of the explicit > (fn [] ...) for macros like (with-open file ...). > Once people get accustomed to this, they naturally extend it to more > and more complicated usages. > -Patrick > > On Sep 8, 6:12 am, alux wrote: > > > Hello Joop, > > > thanks for the link. So it seems not to be completely misled ;-) > > > Greetings, alux > > > On 8 Sep., 11:59, Joop Kiefte wrote: > > > > Actually, this metaphor has been used before. > > > Checkhttp://www.defmacro.org/ramblings/lisp.htmlforanother version of > > > your story ;). > > > > 2010/9/8 alux : > > > > > Hello, > > > > > I still try to read my way through Paul Grahams "On Lisp", and always > > > > think how to motivate this stuff to my fellow Java people. How do I > > > > describe what it is all about in this "Code is Data", and "Macros let > > > > you grow your own language towards the problem" stuff? > > > > [Why? Well, maybe I read to much of Paul Grahams texts. So my current > > > > working hypothesis is that this is the one big strength of Lisp that > > > > other languages still dont have - so if I want to motivate people to > > > > learn a Lisp, I have to at least point to it.] > > > > > Short answer: Difficult. ;-) > > > > > Especially if I find formulations like > > > > "You can have the language which suits your program, even if it ends > > > > up looking quite different from Lisp." > > > > > Longer Answer: > > > > > What puzzles me most about this quoted formulation is the words > > > > "different from Lisp", as I know: All my Java collegues see > > > > Lisp=Parentheses. So, to them, PGs formulation is even misleading. To > > > > them it doesn't look quite different at the end. > > > > > Thus I try to come up with a metaphor, and I want to discuss it here, > > > > in the hope I don't tell them rubbish at the end. > > > > > I want to liken XML to Lisp data. Then, with XSLT, some XML structures > > > > are actually programs. Programs that work on XML data. The Lisp > > > > parentheses are just like the basic XML syntax - elements, tags, > > > > attributes. Obviousely Lisp has a much simpler syntax, but its trees > > > > anyway. So XSLT can be likened to Lisp macros then. > > > > > And the use of it? Well, I currently want to talk to some people who > > > > use Maven a lot. So the example I came up with is: > > > > Think about when you had Ant, some years ago. Ant is just a > > > > programming language for Java builds. > > > > After a while you recognise that it'd be better to have something that > > > > describes the project declaratively, with opinionated defaults. Well, > > > > after some discussions you define something called pom.xml, that does > > > > this (congratulation, we just invented Maven). Immediately you see > > > > that all these Ant build scripts mentioned above could be generated > > > > from this Maven pom.xml. So you might write XSLT to do so (this of > > > > course deviates from historical truth). Some step later, you don't > > > > generate them anymore as files; the only needed file is the pom.xml, > > > > and the transformations of course. > > > > > So XML and XSLT are data and code, and they can do something that is > > > > a) similar to what Lisp macros do, and > > > > b) this is something my collegues understand. > > > > > Hopefully. > > > > > So, coming back to Paul Grahams quote, what the beginners see is: It > > > > was XML and stays XML. The things "looking quite different" are, in > > > > this metaphor, the XML schema of the Maven pom.xml versus the XML > > > > scheme of the Ant files. > > > > > I hope that they will understand the power; and agree they will never > > > > try and do this in XSLT. The Lisp syntax is just simple enough to be > > > > usable for such tasks. > > > > > So, now you probably understand why I ask this question here, even if > > > > it is a general Lisp question. This may be the only group where people > > > > understand Lisp and Macros, XML/XSLT, and Ant, and Maven ;-) > > > > > Now the question: > > > > Do you see any problems with this metaphor, is it misleading > > > > somewhere? > > > > > Thank you, alux > > > > > -- > > > > You received this message because you are subscribed to the Google > > > > Groups "Clojure" group. > > > > To post to this group, send email to clojure@googlegroups.com > > > > Note that posts from new members are moderated - please be patient with > > > > your first post. > > > > To unsubscribe from this group, send email to > > > > clojure+unsubscr...@googlegroups.com > > > > For more options, visit this group at > > > >http://groups.google.com/group/clojure?hl=en > > > > -- > > > Linux-user #496644 (htt
Re: A difficult Metaphor for Macros (especially for Java people)
Ah I see. Yes, motivation is hard. I don't have any good tips for that. I remember when I was trying to learn Lisp. Even though I desperately *wanted* to like Lisp, it still took a few tries before I started to appreciate it. Good luck! -Patrick On Sep 8, 11:07 am, alux wrote: > Hi Patrick, > > yes, I think thats the right way to teach this stuff. My problem > arises earlier - I still have to motivate my collegues, to get them > interested, and, maybe, teach them later ;-) > > Regards, alux > > On 8 Sep., 16:28, CuppoJava wrote: > > > > > I found the easiest way to introduce macros is just to introduce them > > as small syntactic sugaring. For example, getting rid of the explicit > > (fn [] ...) for macros like (with-open file ...). > > Once people get accustomed to this, they naturally extend it to more > > and more complicated usages. > > -Patrick > > > On Sep 8, 6:12 am, alux wrote: > > > > Hello Joop, > > > > thanks for the link. So it seems not to be completely misled ;-) > > > > Greetings, alux > > > > On 8 Sep., 11:59, Joop Kiefte wrote: > > > > > Actually, this metaphor has been used before. > > > > Checkhttp://www.defmacro.org/ramblings/lisp.htmlforanotherversion of > > > > your story ;). > > > > > 2010/9/8 alux : > > > > > > Hello, > > > > > > I still try to read my way through Paul Grahams "On Lisp", and always > > > > > think how to motivate this stuff to my fellow Java people. How do I > > > > > describe what it is all about in this "Code is Data", and "Macros let > > > > > you grow your own language towards the problem" stuff? > > > > > [Why? Well, maybe I read to much of Paul Grahams texts. So my current > > > > > working hypothesis is that this is the one big strength of Lisp that > > > > > other languages still dont have - so if I want to motivate people to > > > > > learn a Lisp, I have to at least point to it.] > > > > > > Short answer: Difficult. ;-) > > > > > > Especially if I find formulations like > > > > > "You can have the language which suits your program, even if it ends > > > > > up looking quite different from Lisp." > > > > > > Longer Answer: > > > > > > What puzzles me most about this quoted formulation is the words > > > > > "different from Lisp", as I know: All my Java collegues see > > > > > Lisp=Parentheses. So, to them, PGs formulation is even misleading. To > > > > > them it doesn't look quite different at the end. > > > > > > Thus I try to come up with a metaphor, and I want to discuss it here, > > > > > in the hope I don't tell them rubbish at the end. > > > > > > I want to liken XML to Lisp data. Then, with XSLT, some XML structures > > > > > are actually programs. Programs that work on XML data. The Lisp > > > > > parentheses are just like the basic XML syntax - elements, tags, > > > > > attributes. Obviousely Lisp has a much simpler syntax, but its trees > > > > > anyway. So XSLT can be likened to Lisp macros then. > > > > > > And the use of it? Well, I currently want to talk to some people who > > > > > use Maven a lot. So the example I came up with is: > > > > > Think about when you had Ant, some years ago. Ant is just a > > > > > programming language for Java builds. > > > > > After a while you recognise that it'd be better to have something that > > > > > describes the project declaratively, with opinionated defaults. Well, > > > > > after some discussions you define something called pom.xml, that does > > > > > this (congratulation, we just invented Maven). Immediately you see > > > > > that all these Ant build scripts mentioned above could be generated > > > > > from this Maven pom.xml. So you might write XSLT to do so (this of > > > > > course deviates from historical truth). Some step later, you don't > > > > > generate them anymore as files; the only needed file is the pom.xml, > > > > > and the transformations of course. > > > > > > So XML and XSLT are data and code, and they can do something that is > > > > > a) similar to what Lisp macros do, and > > > > > b) this is something my collegues understand. > > > > > > Hopefully. > > > > > > So, coming back to Paul Grahams quote, what the beginners see is: It > > > > > was XML and stays XML. The things "looking quite different" are, in > > > > > this metaphor, the XML schema of the Maven pom.xml versus the XML > > > > > scheme of the Ant files. > > > > > > I hope that they will understand the power; and agree they will never > > > > > try and do this in XSLT. The Lisp syntax is just simple enough to be > > > > > usable for such tasks. > > > > > > So, now you probably understand why I ask this question here, even if > > > > > it is a general Lisp question. This may be the only group where people > > > > > understand Lisp and Macros, XML/XSLT, and Ant, and Maven ;-) > > > > > > Now the question: > > > > > Do you see any problems with this metaphor, is it misleading > > > > > somewhere? > > > > > > Thank you, alux > > > > > > -- > > > > > You received this message because you are subscribed to the Goog
Re: A difficult Metaphor for Macros (especially for Java people)
Hi, On 8 Sep., 17:07, alux wrote: > yes, I think thats the right way to teach this stuff. My problem > arises earlier - I still have to motivate my collegues, to get them > interested, and, maybe, teach them later ;-) Then I wouldn't stress macros at all. Just mention them later on - "Oh! And btw: this is a macro thingy." Clojure's concurrency features, the functional style, the abstractions, the consistency, rapid REPL development cycle - all this is what makes Clojure Clojure. Macros are also part of that, but a small and - IMHO - an overrated one. They have their place - and I don't want to miss them - but they are not one of the main selling point for me. 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: deftype makes no extender?
Hi Stu, I like your "open dispatch club" ;-) Yes, after some thinking this is rather clear - every single something had to be scanned whether it implements a protocol; ehm, and rescanned when a new protocol is defined. Well, I drop that request ;-) Thank you for the illumination, alux On 8 Sep., 16:05, Stuart Halloway wrote: > The first rule of open dispatch club is "you never get a complete list of > club members." :-) This is also true for e.g. Java interfaces: there is no > API call for "reflectively show me all implementers of this interface." > > The IDE/tools use case is a real one, but it will need to be solved in the > same way IDEs currently find all implementers of an interface: the > information is in the environment, not in the core of the language. > > Stu > > > Hello Stuart, sorry to answer so late, got holidays, happily. > > > I tried to use the function extenders to list the implementations, so > > to say, of the protocol. > > That was playing around, not a use case taken from reality. If I try > > to make a use case up, hm, I may need it in the development > > environment, to find functions to ponder their use. > > > Regards, alux > > > On 3 Sep., 16:05, Stuart Halloway wrote: > >> Let's back up: what are you trying to do with 'extenders'? > > >> Stu > > >>> Yes, thats what I see. > >>> I just dont think this is very sensible. > > >>> Thank you Meikel! > > >>> Greetings, alux > > >>> On 3 Sep., 13:10, Meikel Brandmeyer wrote: > Hi, > > On 3 Sep., 12:49, alux wrote: > > > shouldnt the type x be listed a extender of xx here? Or why not? > > No. It shows up if you actually use extend to the extend the protocol > to the type. > > 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 -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: A difficult Metaphor for Macros (especially for Java people)
Hello Meikel, I agree with all the points you suggest to mention, and I do so. Nevertheless I will get (and got, so this is not hypothetic) the question: "But why do they use this intolerable strange syntax? Why cant this be in a usual (C-like) syntax?" And here (thats my state of understanding) is the only reason: We directly write the abstract syntax tree, because this is the way we can introduce new syntax ourself. Thats why I think to need this metaphor. Thank you, and kind regards, alux On 8 Sep., 17:19, Meikel Brandmeyer wrote: > Hi, > > On 8 Sep., 17:07, alux wrote: > > > yes, I think thats the right way to teach this stuff. My problem > > arises earlier - I still have to motivate my collegues, to get them > > interested, and, maybe, teach them later ;-) > > Then I wouldn't stress macros at all. Just mention them later on - > "Oh! And btw: this is a macro thingy." Clojure's concurrency features, > the functional style, the abstractions, the consistency, rapid REPL > development cycle - all this is what makes Clojure Clojure. Macros are > also part of that, but a small and - IMHO - an overrated one. They > have their place - and I don't want to miss them - but they are not > one of the main selling point for me. > > 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: A difficult Metaphor for Macros (especially for Java people)
Hi, My main motivation to get away from Java as much as possible was the code size. I was tired of having to write tons of code lines for what I considered mundane things. Using wizards was not satisfactory to me. The generated code size is significant and still it has to be maintained either by hand or by running again a wizard. Using IDEs like Eclipse solved some of the issues with a huge code size and framework integration with the code if you had the hardware performance on your desktop to run these efficiently. That was not the case until very recently when multi core became affordable on the desktop. The slowness of single core desktop used for development purposes was an absolute Java repellent until 2/3 years ago. Writing tons of XML lines to control behavior of frameworks was also a turn off. We use Spring to create low-level Java beans but the XML describing these beans did not change much over time. That is acceptable. Is there something in the above list that could pull some of your reluctant colleagues on the "dark side" :)) ? If yes then you may want to take an existing chunk of Java code of reasonable size that they work with in everyday life and move that to Clojure or to a Clojure/Java combo... Luc P. alux wrote .. > Hi Patrick, > > yes, I think thats the right way to teach this stuff. My problem > arises earlier - I still have to motivate my collegues, to get them > interested, and, maybe, teach them later ;-) > > Regards, alux > > On 8 Sep., 16:28, CuppoJava wrote: > > I found the easiest way to introduce macros is just to introduce them > > as small syntactic sugaring. For example, getting rid of the explicit > > (fn [] ...) for macros like (with-open file ...). > > Once people get accustomed to this, they naturally extend it to more > > and more complicated usages. > > -Patrick > > > > On Sep 8, 6:12 am, alux wrote: > > > > > Hello Joop, > > > > > thanks for the link. So it seems not to be completely misled ;-) > > > > > Greetings, alux > > > > > On 8 Sep., 11:59, Joop Kiefte wrote: > > > > > > Actually, this metaphor has been used before. Checkhttp://www.defmacro.org/ramblings/lisp.htmlforanother > version of > > > > your story ;). > > > > > > 2010/9/8 alux : > > > > > > > Hello, > > > > > > > I still try to read my way through Paul Grahams "On Lisp", and always > > > > > think how to motivate this stuff to my fellow Java people. How do I > > > > > describe what it is all about in this "Code is Data", and "Macros let > > > > > you grow your own language towards the problem" stuff? > > > > > [Why? Well, maybe I read to much of Paul Grahams texts. So my current > > > > > working hypothesis is that this is the one big strength of Lisp that > > > > > other languages still dont have - so if I want to motivate people to > > > > > learn a Lisp, I have to at least point to it.] > > > > > > > Short answer: Difficult. ;-) > > > > > > > Especially if I find formulations like > > > > > "You can have the language which suits your program, even if it ends > > > > > up looking quite different from Lisp." > > > > > > > Longer Answer: > > > > > > > What puzzles me most about this quoted formulation is the words > > > > > "different from Lisp", as I know: All my Java collegues see > > > > > Lisp=Parentheses. So, to them, PGs formulation is even misleading. To > > > > > them it doesn't look quite different at the end. > > > > > > > Thus I try to come up with a metaphor, and I want to discuss it here, > > > > > in the hope I don't tell them rubbish at the end. > > > > > > > I want to liken XML to Lisp data. Then, with XSLT, some XML structures > > > > > are actually programs. Programs that work on XML data. The Lisp > > > > > parentheses are just like the basic XML syntax - elements, tags, > > > > > attributes. Obviousely Lisp has a much simpler syntax, but its trees > > > > > anyway. So XSLT can be likened to Lisp macros then. > > > > > > > And the use of it? Well, I currently want to talk to some people who > > > > > use Maven a lot. So the example I came up with is: > > > > > Think about when you had Ant, some years ago. Ant is just a > > > > > programming language for Java builds. > > > > > After a while you recognise that it'd be better to have something that > > > > > describes the project declaratively, with opinionated defaults. Well, > > > > > after some discussions you define something called pom.xml, that does > > > > > this (congratulation, we just invented Maven). Immediately you see > > > > > that all these Ant build scripts mentioned above could be generated > > > > > from this Maven pom.xml. So you might write XSLT to do so (this of > > > > > course deviates from historical truth). Some step later, you don't > > > > > generate them anymore as files; the only needed file is the pom.xml, > > > > > and the transformations of course. > > > > > > > So XML and XSLT are data and code, and they can do something that is > > > > > a) similar to what Lisp macros do, and > > > >
Strange bug with mutable fields and try
Dear all,
Clojure 1.2.0
(deftype A [ ^{:unsynchronized-mutable true} foo ]
Object
(hashCode
[x] (set! foo :foo)
5
))
works very nicely.
(deftype A [ ^{:unsynchronized-mutable true} foo ]
Object
(hashCode
[x] (try (set! foo :foo))
))
also works.
(deftype A [ ^{:unsynchronized-mutable true} foo ]
Object
(hashCode
[x] (try (set! foo :foo))
4
))
fails:
Cannot assign to non-mutable: foo
[Thrown class java.lang.IllegalArgumentException]
This is less useless than it seems. (try is called within locking,
which can be useful when setting something unsynchronized)
Is it a known bug? Does it happen to other people than me?
Best regards,
Nicolas.
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: A difficult Metaphor for Macros (especially for Java people)
This was actually the article that finally got me to overcome the inertia and start exploring lisp, as a long-time native Java speaker. I gave up again in a few weeks, but the possibilities excited me, and when I found Clojure I was delighted with the number of things that were better than lisp, as well as the things better than Java. After just two weeks of working with lisp, when I went to write my next Java app, I was flabbergasted to discover that there is no (map). You might want to show them how simple it becomes to process sequences with map/reduce/etc - that was a huge revelation for me. On Sep 8, 2:59 am, Joop Kiefte wrote: > Actually, this metaphor has been used before. > Checkhttp://www.defmacro.org/ramblings/lisp.htmlfor an other version of > your story ;). > > 2010/9/8 alux : > > > > > Hello, > > > I still try to read my way through Paul Grahams "On Lisp", and always > > think how to motivate this stuff to my fellow Java people. How do I > > describe what it is all about in this "Code is Data", and "Macros let > > you grow your own language towards the problem" stuff? > > [Why? Well, maybe I read to much of Paul Grahams texts. So my current > > working hypothesis is that this is the one big strength of Lisp that > > other languages still dont have - so if I want to motivate people to > > learn a Lisp, I have to at least point to it.] > > > Short answer: Difficult. ;-) > > > Especially if I find formulations like > > "You can have the language which suits your program, even if it ends > > up looking quite different from Lisp." > > > Longer Answer: > > > What puzzles me most about this quoted formulation is the words > > "different from Lisp", as I know: All my Java collegues see > > Lisp=Parentheses. So, to them, PGs formulation is even misleading. To > > them it doesn't look quite different at the end. > > > Thus I try to come up with a metaphor, and I want to discuss it here, > > in the hope I don't tell them rubbish at the end. > > > I want to liken XML to Lisp data. Then, with XSLT, some XML structures > > are actually programs. Programs that work on XML data. The Lisp > > parentheses are just like the basic XML syntax - elements, tags, > > attributes. Obviousely Lisp has a much simpler syntax, but its trees > > anyway. So XSLT can be likened to Lisp macros then. > > > And the use of it? Well, I currently want to talk to some people who > > use Maven a lot. So the example I came up with is: > > Think about when you had Ant, some years ago. Ant is just a > > programming language for Java builds. > > After a while you recognise that it'd be better to have something that > > describes the project declaratively, with opinionated defaults. Well, > > after some discussions you define something called pom.xml, that does > > this (congratulation, we just invented Maven). Immediately you see > > that all these Ant build scripts mentioned above could be generated > > from this Maven pom.xml. So you might write XSLT to do so (this of > > course deviates from historical truth). Some step later, you don't > > generate them anymore as files; the only needed file is the pom.xml, > > and the transformations of course. > > > So XML and XSLT are data and code, and they can do something that is > > a) similar to what Lisp macros do, and > > b) this is something my collegues understand. > > > Hopefully. > > > So, coming back to Paul Grahams quote, what the beginners see is: It > > was XML and stays XML. The things "looking quite different" are, in > > this metaphor, the XML schema of the Maven pom.xml versus the XML > > scheme of the Ant files. > > > I hope that they will understand the power; and agree they will never > > try and do this in XSLT. The Lisp syntax is just simple enough to be > > usable for such tasks. > > > So, now you probably understand why I ask this question here, even if > > it is a general Lisp question. This may be the only group where people > > understand Lisp and Macros, XML/XSLT, and Ant, and Maven ;-) > > > Now the question: > > Do you see any problems with this metaphor, is it misleading > > somewhere? > > > Thank you, alux > > > -- > > You received this message because you are subscribed to the Google > > Groups "Clojure" group. > > To post to this group, send email to clojure@googlegroups.com > > Note that posts from new members are moderated - please be patient with > > your first post. > > To unsubscribe from this group, send email to > > clojure+unsubscr...@googlegroups.com > > For more options, visit this group at > >http://groups.google.com/group/clojure?hl=en > > -- > Linux-user #496644 (http://counter.li.org) - first touch of linux in 2004 > > Demandoj en aŭ pri Esperanto? Questions about Esperanto? Vragen over > Esperanto? Perguntas sobre o Esperanto? -http://demandoj.tk -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are mode
Re: Strange bug with mutable fields and try
Are you using the release version of 1.2.0? I get the behavior you
describe when I use a snapshot of 1.2.0 from when I built from source,
but when I use lein repl in a project with a dependency on 1.2.0, all
three forms fail with the same exception.
On Sep 8, 9:44 am, Nicolas Oury wrote:
> Dear all,
>
> Clojure 1.2.0
>
> (deftype A [ ^{:unsynchronized-mutable true} foo ]
> Object
> (hashCode
> [x] (set! foo :foo)
>
> 5
>
> ))
>
> works very nicely.
>
> (deftype A [ ^{:unsynchronized-mutable true} foo ]
> Object
> (hashCode
> [x] (try (set! foo :foo))
>
> ))
>
> also works.
>
> (deftype A [ ^{:unsynchronized-mutable true} foo ]
> Object
> (hashCode
> [x] (try (set! foo :foo))
> 4
> ))
>
> fails:
>
> Cannot assign to non-mutable: foo
> [Thrown class java.lang.IllegalArgumentException]
>
> This is less useless than it seems. (try is called within locking,
> which can be useful when setting something unsynchronized)
>
> Is it a known bug? Does it happen to other people than me?
>
> Best regards,
>
> Nicolas.
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from 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: Strange bug with mutable fields and try
On Wed, Sep 8, 2010 at 6:36 PM, Alan wrote: > Are you using the release version of 1.2.0? I get the behavior you > describe when I use a snapshot of 1.2.0 from when I built from source, > but when I use lein repl in a project with a dependency on 1.2.0, all > three forms fail with the same exception. > > That is strange. From the same project, it fails all 3 within REPL. And only the last with swank. What is it supposed to do? Is there something wrong with what I try? -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Simple question about destructuring
I happened to be looking at the source for clojure.core/juxt, and I was a little surprised by the way it handles 4+ arguments -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Simple question about destructuring
Sorry, Google posted this before I was done. Anyway, it looks like: (defn juxt ([f g h & fs] (let [fs (list* f g h fs)] ...))) Is there a reason to do that instead of the following? (defn juxt ([& fs] ...)) On Sep 8, 11:02 am, Alan wrote: > I happened to be looking at the source for clojure.core/juxt, and I > was a little surprised by the way it handles 4+ arguments -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: A difficult Metaphor for Macros (especially for Java people)
Hello Luc, what you say is of course completely true. Nevertheless it seems true for Scala too. And now I come with a new language again. The curious people in my team (well, or its the one with enough spare time :) already had some look into Scala, and I think I need additional arguments make them to look into Clojure too. But here I'm on a slippery slope. I'm still unable to judge the power of lisp macros compared to the power of Scalas possibilities to write your own control structures. Regards, alux On 8 Sep., 19:29, Alan wrote: > This was actually the article that finally got me to overcome the > inertia and start exploring lisp, as a long-time native Java speaker. > I gave up again in a few weeks, but the possibilities excited me, and > when I found Clojure I was delighted with the number of things that > were better than lisp, as well as the things better than Java. > > After just two weeks of working with lisp, when I went to write my > next Java app, I was flabbergasted to discover that there is no (map). > You might want to show them how simple it becomes to process sequences > with map/reduce/etc - that was a huge revelation for me. > > On Sep 8, 2:59 am, Joop Kiefte wrote: > > > Actually, this metaphor has been used before. > > Checkhttp://www.defmacro.org/ramblings/lisp.htmlforan other version of > > your story ;). > > > 2010/9/8 alux : > > > > Hello, > > > > I still try to read my way through Paul Grahams "On Lisp", and always > > > think how to motivate this stuff to my fellow Java people. How do I > > > describe what it is all about in this "Code is Data", and "Macros let > > > you grow your own language towards the problem" stuff? > > > [Why? Well, maybe I read to much of Paul Grahams texts. So my current > > > working hypothesis is that this is the one big strength of Lisp that > > > other languages still dont have - so if I want to motivate people to > > > learn a Lisp, I have to at least point to it.] > > > > Short answer: Difficult. ;-) > > > > Especially if I find formulations like > > > "You can have the language which suits your program, even if it ends > > > up looking quite different from Lisp." > > > > Longer Answer: > > > > What puzzles me most about this quoted formulation is the words > > > "different from Lisp", as I know: All my Java collegues see > > > Lisp=Parentheses. So, to them, PGs formulation is even misleading. To > > > them it doesn't look quite different at the end. > > > > Thus I try to come up with a metaphor, and I want to discuss it here, > > > in the hope I don't tell them rubbish at the end. > > > > I want to liken XML to Lisp data. Then, with XSLT, some XML structures > > > are actually programs. Programs that work on XML data. The Lisp > > > parentheses are just like the basic XML syntax - elements, tags, > > > attributes. Obviousely Lisp has a much simpler syntax, but its trees > > > anyway. So XSLT can be likened to Lisp macros then. > > > > And the use of it? Well, I currently want to talk to some people who > > > use Maven a lot. So the example I came up with is: > > > Think about when you had Ant, some years ago. Ant is just a > > > programming language for Java builds. > > > After a while you recognise that it'd be better to have something that > > > describes the project declaratively, with opinionated defaults. Well, > > > after some discussions you define something called pom.xml, that does > > > this (congratulation, we just invented Maven). Immediately you see > > > that all these Ant build scripts mentioned above could be generated > > > from this Maven pom.xml. So you might write XSLT to do so (this of > > > course deviates from historical truth). Some step later, you don't > > > generate them anymore as files; the only needed file is the pom.xml, > > > and the transformations of course. > > > > So XML and XSLT are data and code, and they can do something that is > > > a) similar to what Lisp macros do, and > > > b) this is something my collegues understand. > > > > Hopefully. > > > > So, coming back to Paul Grahams quote, what the beginners see is: It > > > was XML and stays XML. The things "looking quite different" are, in > > > this metaphor, the XML schema of the Maven pom.xml versus the XML > > > scheme of the Ant files. > > > > I hope that they will understand the power; and agree they will never > > > try and do this in XSLT. The Lisp syntax is just simple enough to be > > > usable for such tasks. > > > > So, now you probably understand why I ask this question here, even if > > > it is a general Lisp question. This may be the only group where people > > > understand Lisp and Macros, XML/XSLT, and Ant, and Maven ;-) > > > > Now the question: > > > Do you see any problems with this metaphor, is it misleading > > > somewhere? > > > > Thank you, alux > > > > -- > > > You received this message because you are subscribed to the Google > > > Groups "Clojure" group. > > > To post to this group, send email to clojure@googlegroups.com > > >
Re: A difficult Metaphor for Macros (especially for Java people)
Hello Alan, yes, the map function. This is one of the places where you type until ypur fingers bleed in other languages. By the way, http://www.norvig.com/design-patterns/ seems to be a interesting read on the topic. I still havent read it (on the hotlist), but Norvig is said to show that a bunch of the Gang of Four patterns are just not needed in Lisp. Regrads, alux On 8 Sep., 19:29, Alan wrote: > This was actually the article that finally got me to overcome the > inertia and start exploring lisp, as a long-time native Java speaker. > I gave up again in a few weeks, but the possibilities excited me, and > when I found Clojure I was delighted with the number of things that > were better than lisp, as well as the things better than Java. > > After just two weeks of working with lisp, when I went to write my > next Java app, I was flabbergasted to discover that there is no (map). > You might want to show them how simple it becomes to process sequences > with map/reduce/etc - that was a huge revelation for me. > > On Sep 8, 2:59 am, Joop Kiefte wrote: > > > Actually, this metaphor has been used before. > > Checkhttp://www.defmacro.org/ramblings/lisp.htmlforan other version of > > your story ;). > > > 2010/9/8 alux : > > > > Hello, > > > > I still try to read my way through Paul Grahams "On Lisp", and always > > > think how to motivate this stuff to my fellow Java people. How do I > > > describe what it is all about in this "Code is Data", and "Macros let > > > you grow your own language towards the problem" stuff? > > > [Why? Well, maybe I read to much of Paul Grahams texts. So my current > > > working hypothesis is that this is the one big strength of Lisp that > > > other languages still dont have - so if I want to motivate people to > > > learn a Lisp, I have to at least point to it.] > > > > Short answer: Difficult. ;-) > > > > Especially if I find formulations like > > > "You can have the language which suits your program, even if it ends > > > up looking quite different from Lisp." > > > > Longer Answer: > > > > What puzzles me most about this quoted formulation is the words > > > "different from Lisp", as I know: All my Java collegues see > > > Lisp=Parentheses. So, to them, PGs formulation is even misleading. To > > > them it doesn't look quite different at the end. > > > > Thus I try to come up with a metaphor, and I want to discuss it here, > > > in the hope I don't tell them rubbish at the end. > > > > I want to liken XML to Lisp data. Then, with XSLT, some XML structures > > > are actually programs. Programs that work on XML data. The Lisp > > > parentheses are just like the basic XML syntax - elements, tags, > > > attributes. Obviousely Lisp has a much simpler syntax, but its trees > > > anyway. So XSLT can be likened to Lisp macros then. > > > > And the use of it? Well, I currently want to talk to some people who > > > use Maven a lot. So the example I came up with is: > > > Think about when you had Ant, some years ago. Ant is just a > > > programming language for Java builds. > > > After a while you recognise that it'd be better to have something that > > > describes the project declaratively, with opinionated defaults. Well, > > > after some discussions you define something called pom.xml, that does > > > this (congratulation, we just invented Maven). Immediately you see > > > that all these Ant build scripts mentioned above could be generated > > > from this Maven pom.xml. So you might write XSLT to do so (this of > > > course deviates from historical truth). Some step later, you don't > > > generate them anymore as files; the only needed file is the pom.xml, > > > and the transformations of course. > > > > So XML and XSLT are data and code, and they can do something that is > > > a) similar to what Lisp macros do, and > > > b) this is something my collegues understand. > > > > Hopefully. > > > > So, coming back to Paul Grahams quote, what the beginners see is: It > > > was XML and stays XML. The things "looking quite different" are, in > > > this metaphor, the XML schema of the Maven pom.xml versus the XML > > > scheme of the Ant files. > > > > I hope that they will understand the power; and agree they will never > > > try and do this in XSLT. The Lisp syntax is just simple enough to be > > > usable for such tasks. > > > > So, now you probably understand why I ask this question here, even if > > > it is a general Lisp question. This may be the only group where people > > > understand Lisp and Macros, XML/XSLT, and Ant, and Maven ;-) > > > > Now the question: > > > Do you see any problems with this metaphor, is it misleading > > > somewhere? > > > > Thank you, alux > > > > -- > > > You received this message because you are subscribed to the Google > > > Groups "Clojure" group. > > > To post to this group, send email to clojure@googlegroups.com > > > Note that posts from new members are moderated - please be patient with > > > your first post. > > > To unsubscribe from this group, send
Re: Simple question about destructuring
Hi Alan, this is one of the places where clojure.core is not written in what I would called idiomatic Clojure. The reason is speed. Rich Hickey is very eager to speed up the libraries, and what you see in juxt is one of the verbose speedup tricks. Regards, alux On 8 Sep., 20:06, Alan wrote: > Sorry, Google posted this before I was done. Anyway, it looks like: > > (defn juxt > ([f g h & fs] > (let [fs (list* f g h fs)] > ...))) > > Is there a reason to do that instead of the following? > > (defn juxt > ([& fs] > ...)) > > On Sep 8, 11:02 am, Alan wrote: > > > I happened to be looking at the source for clojure.core/juxt, and I > > was a little surprised by the way it handles 4+ arguments -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: A difficult Metaphor for Macros (especially for Java people)
alux wrote .. > Hello Luc, > > what you say is of course completely true. Nevertheless it seems true > for Scala too. And now I come with a new language again. The curious > people in my team (well, or its the one with enough spare time :) > already had some look into Scala, and I think I need additional > arguments make them to look into Clojure too. > > But here I'm on a slippery slope. I'm still unable to judge the power > of lisp macros compared to the power of Scalas possibilities to write > your own control structures. I cannot help you much here. I looked at Scala nearly two years ago while searching for a JVM alternative to Java. I already knew Lisp and wanted a generic macro facility but I was not convinced by Scala even before looking at its extensibility features... sorry. Too OOish for me, I was starting to have skin rashes about the OO approach by then after 7 years of exposure to Java and the Russian puppet syndrome :))) Luc > > Regards, alux > > On 8 Sep., 19:29, Alan wrote: > > This was actually the article that finally got me to overcome the > > inertia and start exploring lisp, as a long-time native Java speaker. > > I gave up again in a few weeks, but the possibilities excited me, and > > when I found Clojure I was delighted with the number of things that > > were better than lisp, as well as the things better than Java. > > > > After just two weeks of working with lisp, when I went to write my > > next Java app, I was flabbergasted to discover that there is no (map). > > You might want to show them how simple it becomes to process sequences > > with map/reduce/etc - that was a huge revelation for me. > > > > On Sep 8, 2:59 am, Joop Kiefte wrote: > > > > > Actually, this metaphor has been used before. Checkhttp://www.defmacro.org/ramblings/lisp.htmlforan > other version of > > > your story ;). > > > > > 2010/9/8 alux : > > > > > > Hello, > > > > > > I still try to read my way through Paul Grahams "On Lisp", and always > > > > think how to motivate this stuff to my fellow Java people. How do I > > > > describe what it is all about in this "Code is Data", and "Macros let > > > > you grow your own language towards the problem" stuff? > > > > [Why? Well, maybe I read to much of Paul Grahams texts. So my current > > > > working hypothesis is that this is the one big strength of Lisp that > > > > other languages still dont have - so if I want to motivate people to > > > > learn a Lisp, I have to at least point to it.] > > > > > > Short answer: Difficult. ;-) > > > > > > Especially if I find formulations like > > > > "You can have the language which suits your program, even if it ends > > > > up looking quite different from Lisp." > > > > > > Longer Answer: > > > > > > What puzzles me most about this quoted formulation is the words > > > > "different from Lisp", as I know: All my Java collegues see > > > > Lisp=Parentheses. So, to them, PGs formulation is even misleading. To > > > > them it doesn't look quite different at the end. > > > > > > Thus I try to come up with a metaphor, and I want to discuss it here, > > > > in the hope I don't tell them rubbish at the end. > > > > > > I want to liken XML to Lisp data. Then, with XSLT, some XML structures > > > > are actually programs. Programs that work on XML data. The Lisp > > > > parentheses are just like the basic XML syntax - elements, tags, > > > > attributes. Obviousely Lisp has a much simpler syntax, but its trees > > > > anyway. So XSLT can be likened to Lisp macros then. > > > > > > And the use of it? Well, I currently want to talk to some people who > > > > use Maven a lot. So the example I came up with is: > > > > Think about when you had Ant, some years ago. Ant is just a > > > > programming language for Java builds. > > > > After a while you recognise that it'd be better to have something that > > > > describes the project declaratively, with opinionated defaults. Well, > > > > after some discussions you define something called pom.xml, that does > > > > this (congratulation, we just invented Maven). Immediately you see > > > > that all these Ant build scripts mentioned above could be generated > > > > from this Maven pom.xml. So you might write XSLT to do so (this of > > > > course deviates from historical truth). Some step later, you don't > > > > generate them anymore as files; the only needed file is the pom.xml, > > > > and the transformations of course. > > > > > > So XML and XSLT are data and code, and they can do something that is > > > > a) similar to what Lisp macros do, and > > > > b) this is something my collegues understand. > > > > > > Hopefully. > > > > > > So, coming back to Paul Grahams quote, what the beginners see is: It > > > > was XML and stays XML. The things "looking quite different" are, in > > > > this metaphor, the XML schema of the Maven pom.xml versus the XML > > > > scheme of the Ant files. > > > > > > I hope that they will understand the power; and agree they will never > > > > try and do this in
Standalone 1.2 contrib
Is there a monolithic standalone contrib jar out there? A download & forget type 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: Standalone 1.2 contrib
Hi, Have you followed the Download link from clojure.org ? 2010/9/8 Sean Devlin : > Is there a monolithic standalone contrib jar out there? A download & > forget type 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 -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Standalone 1.2 contrib
Yep. It downloaded a zip file, which needed built. Maven broke. I really don't want to mess with maven right now. I just want a contrib JAR. On Sep 8, 3:22 pm, Laurent PETIT wrote: > Hi, > > Have you followed the Download link from clojure.org ? > > 2010/9/8 Sean Devlin : > > > Is there a monolithic standalone contrib jar out there? A download & > > forget type 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 -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Standalone 1.2 contrib
look in the target/ dir of the zip ... 2010/9/8 Sean Devlin : > Yep. It downloaded a zip file, which needed built. Maven broke. I > really don't want to mess with maven right now. I just want a contrib > JAR. > > On Sep 8, 3:22 pm, Laurent PETIT wrote: >> Hi, >> >> Have you followed the Download link from clojure.org ? >> >> 2010/9/8 Sean Devlin : >> >> > Is there a monolithic standalone contrib jar out there? A download & >> > forget type 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 > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from 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: Mapping a function to a map
On Sep 7, 9:00 am, Thomas wrote: > I've also been using my own version of a map-to-values function > extensively and it would be really nice to have something like that, > either in contrib or in core. It comes in handy surprisingly often. +1 I find myself writing functions like map-values and filter-values over and over again in different languages because they are so useful. If possible, I would prefer to (:use) a single, canonical version from clojure.contrib (or clojure.core). Daniel -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Standalone 1.2 contrib
Laurent, Thank you for the specific help. Rich/Core This is WAY TOO MUCH WORK. The first entries on the download page should be just .JARs, and then below that you could have the zip files you have now. Also, the simple version should be bigger. Here's the rough idea of what I mean Clojure Contrib Source Clojure Contrib Sean On Sep 8, 3:30 pm, Laurent PETIT wrote: > look in the target/ dir of the zip ... > > 2010/9/8 Sean Devlin : > > > Yep. It downloaded a zip file, which needed built. Maven broke. I > > really don't want to mess with maven right now. I just want a contrib > > JAR. > > > On Sep 8, 3:22 pm, Laurent PETIT wrote: > >> Hi, > > >> Have you followed the Download link from clojure.org ? > > >> 2010/9/8 Sean Devlin : > > >> > Is there a monolithic standalone contrib jar out there? A download & > >> > forget type 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 > > > -- > > You received this message because you are subscribed to the Google > > Groups "Clojure" group. > > To post to this group, send email to clojure@googlegroups.com > > Note that posts from new members are moderated - please be patient with > > your first post. > > To unsubscribe from this group, send email to > > clojure+unsubscr...@googlegroups.com > > For more options, visit this group at > >http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: A difficult Metaphor for Macros (especially for Java people)
On Wed, 08 Sep 2010 15:13:57 -0400 (EDT) lprefonta...@softaddicts.ca wrote: > I cannot help you much here. I looked at Scala nearly two years ago while > searching for a JVM alternative to Java. I already knew Lisp and wanted > a generic macro facility but I was not convinced by Scala even before > looking at its extensibility features... sorry. Too OOish for me, > I was starting to have skin rashes about the OO approach by then after 7 > years > of exposure to Java and the Russian puppet syndrome :))) Hey, I *like* OO programming! I love being able to create whole new classes of functionality by just inheriting from the correct set of classes, with out actually writing a line of code that's more than the class declaration. Not quite as spiffy as real macros, but close. Of course, that I like OO programming and desired to continue doing so is why I never wrote Java or C++ for real. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: matching with wild-cards in clojure multi-methods
On Sep 6, 4:43 pm, Meikel Brandmeyer wrote: > You can use qualified keywords with an hierarchy. > > (def your-hierarchy > (-> (make-hierarchy) > (derive ::hello ::anything) > (derive ::world ::anything) > (derive ::city ::anything) > (derive ::us ::anything))) Building your own hierarchy would make it safe to use unqualified keywords as well -- if I am not mistaken? (-> (make-hierarchy) (derive :hello :anything) ...) Daniel -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
$'s in java class member names and set!
Suppose you have a class projects.test.A:
package projects.test;
public class A
{
public A(){super();}
public boolean y;
public boolean $z;
}
and I want to use set to update both values:
user=> (def m (A.)) ; Create a ref m to new instance of A
#'user/m
user=> (set! (. m y) true) ; No problems updating y.
true
user=> (set! (. m $z) true)
java.lang.IllegalArgumentException: No matching field found:
_DOLLARSIGN_z for class projects.test.A
(NO_SOURCE_FILE:0)
Is there a special syntax for handling java members with $'s in their
names?
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from 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 def m-bind because namespace
So actually it looks like I need to understand type theory to understand this. Thanks, Mohan On Sep 7, 7:04 pm, Nicolas Oury wrote: > > ...and report your findings here or blog somewhere if you don't mind > > :) I've been reading a lot about monads lately and can't get my head > > around it yet so any help appreciated (I'm coming from Java and > > Clojure is my first real functional language - that's why it causes > > headaches, I believe). > > I have no blog so I will try an explanation here. > I think monad are quite difficult to grasp, so the more different > explanations you read, the better. > Monads are made to represent computations in an abstract way. > Sometimes the basic computation laws are not those you want > and then you want to introduce other computation laws. > Monad is one way to do so (among other like applicative functors or > Kieisli arrows) > Monad corresponds to the computations that are best described as an > imperative program. > > So a monad is a type transformer: M for all A , in Java words. > Something of type M is a computation in the world of computation M > that returns values of type A. > > (M for example can be > IO: the computations that do input/outputs to find their results, > State: the computations that use a and update an internal state > List: more surprisingly, the non-deterministic computations: each > computation yeilds a list of possible results) > > There are a few operators you need for a monad: > - return : A -> M . It says that any computation model must be able > to handle the lack of computation. "Do nothing and return this value" > - bind : M -> (A -> M) -> M > "If I give you a computation that gives back values in A and for each > values in A I tell you how to compute a value in B, > then you can compute a value in B. " > That's a strong assumption, because it allows to use the whole power > of Clojure to construct a computation from the result of the first > computation. > Some model of computations are more restrictive than monad on that. > > From this two operators you can define two others: > - map : (A -> B) -> M -> M > "If I give you a function from A to B, then you can transform a > computation that returns value in A in computation that returns values > in B." > (map f compA = (bind compA (fn [x] (return (f x) > > - join : M> -> M > "I can run a subprogram" This is again something quite specific to > monad as computation devices. (Bind can be constructed from join and > map) > They are dynamic programs that can compute a program and run it. > join compMA = (bind compMA identity) > > bind compA f = (join (map f compA)) > > All these operators must respect some laws, that are quite natural. > Like returning a value and starting a computation is the same as starting a > computation directly from the value: > > - (bind (return a) f) = (f a) > > > > To work out an example, the state monad is a computation that can use > and modify a state, so: M = S -> [S, A] . I need a state and return > a new state and a value A. > return a = (fn [s] -> [s a]) > bind compA f = > (fn [s1] -> > ; we give the state to the first comutation > (let [[s2 a] (compA s1) > ; we compute the next computation > compB (f a)] > ; we give the state to the second computation > (compB s2))) > > Hope that helps. > > Nicolas. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: A difficult Metaphor for Macros (especially for Java people)
Rich does a fine job of explaining macros here: http://channel9.msdn.com/shows/Going+Deep/Expert-to-Expert-Rich-Hickey-and-Brian-Beckman-Inside-Clojure See minutes 23 to 25. The macro concept is not complicated, it should not be hard to explain to someone. The benefits of code writing code should be obvious and familiar to everyone. The complexity comes from the particulars of how you write good macros in your lisp. And mastery of that is primarily a function of writing your own and reading good examples. Adam -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: A difficult Metaphor for Macros (especially for Java people)
On Wed, Sep 8, 2010 at 08:17, CuppoJava wrote: > Ah I see. Yes, motivation is hard. I don't have any good tips for > that. I'm still a noob at the evangelising part of Lisp! However, when it comes to clojure, I tell Java people it's a better way of writing Java than Java; it gives you all the things experienced Java programmers wish Java had: + "try the cast, compiler, just trust me on this one" + "must I really declare that to be thrown? When I don't please just treat it like a RuntimeException!" + "no write, save, compile loop - REPL's are amazing" + "concise object literals for the common data structures, list, maps, etc". are amongst a few of my favoured lines. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
REPL
Hi, I'm new to Clojure. This is also my first time posting here. When I use REPL and print something out, I always get a nil printed. For example, (print "Clojure"), I got: clojurenil. Where does the nil come from? Thanks a lot! -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Standalone 1.2 contrib
I felt the same way until I realized that downloading clojure straight from the web page was pretty much me "doing it wrong" or attempting to use the "custom install" that I wasn't ready to do yet (not knowing what I was doing). Leiningen is the "easy" way to get clojure, contrib, everything else, plus properly setup your app to start. Thanks, Peter -Original Message- From: Sean Devlin Sender: clojure@googlegroups.com Date: Wed, 8 Sep 2010 12:38:27 To: Clojure Reply-To: clojure@googlegroups.com Subject: Re: Standalone 1.2 contrib Laurent, Thank you for the specific help. Rich/Core This is WAY TOO MUCH WORK. The first entries on the download page should be just .JARs, and then below that you could have the zip files you have now. Also, the simple version should be bigger. Here's the rough idea of what I mean Clojure Contrib Source Clojure Contrib Sean On Sep 8, 3:30 pm, Laurent PETIT wrote: > look in the target/ dir of the zip ... > > 2010/9/8 Sean Devlin : > > > Yep. It downloaded a zip file, which needed built. Maven broke. I > > really don't want to mess with maven right now. I just want a contrib > > JAR. > > > On Sep 8, 3:22 pm, Laurent PETIT wrote: > >> Hi, > > >> Have you followed the Download link from clojure.org ? > > >> 2010/9/8 Sean Devlin : > > >> > Is there a monolithic standalone contrib jar out there? A download & > >> > forget type 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 > > > -- > > You received this message because you are subscribed to the Google > > Groups "Clojure" group. > > To post to this group, send email to clojure@googlegroups.com > > Note that posts from new members are moderated - please be patient with > > your first post. > > To unsubscribe from 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: REPL
On Wed, Sep 8, 2010 at 2:26 PM, Sean wrote: > Hi, > > I'm new to Clojure. This is also my first time posting here. > When I use REPL and print something out, I always get a nil printed. > For example, (print "Clojure"), I got: clojurenil. Where does the nil > come from? > > Thanks a lot! > Try (println "Clojure") The nil is because the return value of print/println is nil. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: REPL
On Wed, 8 Sep 2010 11:26:38 -0700 (PDT) Sean wrote: > Hi, > > I'm new to Clojure. This is also my first time posting here. > When I use REPL and print something out, I always get a nil printed. > For example, (print "Clojure"), I got: clojurenil. Where does the nil > come from? REPL stands for "Read Eval Print Loop". It reads an expression, evaluates it, then prints that value. The value of (print "Clojure") is nil, and that's what the REPL prints. Try these two: (do (print "Clojure") 1) (identity "Clojure") and compare the results. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: REPL
This. And to clarify, in case it's unclear: every function in Clojure must return a value - there are no "void" functions as in Java. print and println, therefore, in addition to printing their data, must return something (they choose nil), and the REPL always prints out the return value of whatever you evaluate. On Sep 8, 1:33 pm, David Nolen wrote: > On Wed, Sep 8, 2010 at 2:26 PM, Sean wrote: > > Hi, > > > I'm new to Clojure. This is also my first time posting here. > > When I use REPL and print something out, I always get a nil printed. > > For example, (print "Clojure"), I got: clojurenil. Where does the nil > > come from? > > > Thanks a lot! > > Try > > (println "Clojure") > > The nil is because the return value of print/println is nil. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
[ANN] Leiningen 1.3.1
I'm pleased to announce the release of Leiningen 1.3.1. This release fixes a few key bugs and introduces a handful of minor features. Here are the highlights. Bug Fixes: * Performing a standalone install (a new feature of Leiningen 1.3.0) now pulls in all transitive dependencies. * Unreadable input won't cause issues in the repl. * Huge classpaths no longer cause slowdown on boot. * Namespaces for test and help tasks are no longer skipped if their first form is not a call to the ns macro. * Uberjar task will not proceed if compilation fails. New Features: * The shell-wrapper scripts may be customized. * repl task may be used outside the context of a project. * If :min-lein-version is set, users of an older Leiningen version will see a warning. * Dependency jar types may be specified. (test, javadoc, etc.) * Regexes may be used to specify namespaces in :aot list. We also have improved Windows support with a zip file that should get you everything you need: http://github.com/downloads/technomancy/leiningen/lein-win32.zip More details about the changes are at http://bit.ly/lein-news I'm particularly interested in the shell-wrapper functionality since right now it's quite awkward to create Clojure projects that are first-class citizens when it comes to the command-line. I think shell-wrappers have the potential to significantly improve the situation. I'm hoping to write up some more documentation on this, but you can see the basics under "Shell Wrappers" near the bottom of the tutorial: http://github.com/technomancy/leiningen/blob/master/TUTORIAL.md As always, thanks to the contributors who submitted patches for this release: Shantanu Kumar, Colin Jones, Isaac Hodes, Alan Dipert, John Sanda, and Alex Ott, as well as all 47 of you who have contributed in the past: http://www.ohloh.net/p/leiningen/contributors If you'd like to be involved in the next release, I've started a thread with a roadmap for 1.4.0 on the Leiningen mailing list: http://groups.google.com/group/leiningen/browse_thread/thread/8352bbb974034bff Enjoy! -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: JSON lib of choice?
The c.c.json lib was rewritten in January by Stuart Sierra to incorporate the missing features present in Dan Larkin's lib, and make it faster. This was when it switched from c.c.j.read/write to c.c.json. I switched to c.c.json around that time, and I've been happy with it as a substitute. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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] Leiningen 1.3.1
On Wed, Sep 8, 2010 at 2:05 PM, Phil Hagelberg wrote: > I'm pleased to announce the release of Leiningen 1.3.1. Thanx Phil! > * repl task may be used outside the context of a project. Very useful! > * Regexes may be used to specify namespaces in :aot list. Also very useful! -- 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: Standalone 1.2 contrib
Until you don't want to deal with maven, and just need a jar. Like if you're installing Enclojure & just want the stupid jars. On Sep 8, 3:42 pm, buckmeist...@gmail.com wrote: > I felt the same way until I realized that downloading clojure straight from > the web page was pretty much me "doing it wrong" or attempting to use the > "custom install" that I wasn't ready to do yet (not knowing what I was doing). > > Leiningen is the "easy" way to get clojure, contrib, everything else, plus > properly setup your app to start. > > Thanks, > Peter > > > > -Original Message- > From: Sean Devlin > > Sender: clojure@googlegroups.com > Date: Wed, 8 Sep 2010 12:38:27 > To: Clojure > Reply-To: clojure@googlegroups.com > Subject: Re: Standalone 1.2 contrib > > Laurent, > Thank you for the specific help. > > Rich/Core > This is WAY TOO MUCH WORK. The first entries on the download page > should be just .JARs, and then below that you could have the zip files > you have now. Also, the simple version should be bigger. Here's the > rough idea of what I mean > > > Clojure > Contrib > > > Source > > Clojure > Contrib > > > Sean > > On Sep 8, 3:30 pm, Laurent PETIT wrote: > > look in the target/ dir of the zip ... > > > 2010/9/8 Sean Devlin : > > > > Yep. It downloaded a zip file, which needed built. Maven broke. I > > > really don't want to mess with maven right now. I just want a contrib > > > JAR. > > > > On Sep 8, 3:22 pm, Laurent PETIT wrote: > > >> Hi, > > > >> Have you followed the Download link from clojure.org ? > > > >> 2010/9/8 Sean Devlin : > > > >> > Is there a monolithic standalone contrib jar out there? A download & > > >> > forget type 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 > > > > -- > > > You received this message because you are subscribed to the Google > > > Groups "Clojure" group. > > > To post to this group, send email to clojure@googlegroups.com > > > Note that posts from new members are moderated - please be patient with > > > your first post. > > > To unsubscribe from 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 > athttp://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: $'s in java class member names and set!
Try using reflection to print out what the JVM thinks the field's name
is. This might help.
On Sep 8, 1:23 am, Jon Seltzer wrote:
> Suppose you have a class projects.test.A:
>
> package projects.test;
>
> public class A
> {
> public A(){super();}
> public boolean y;
> public boolean $z;
>
> }
>
> and I want to use set to update both values:
>
> user=> (def m (A.)) ; Create a ref m to new instance of A
> #'user/m
>
> user=> (set! (. m y) true) ; No problems updating y.
> true
>
> user=> (set! (. m $z) true)
> java.lang.IllegalArgumentException: No matching field found:
> _DOLLARSIGN_z for class projects.test.A
> (NO_SOURCE_FILE:0)
>
> Is there a special syntax for handling java members with $'s in their
> names?
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from 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: Standalone 1.2 contrib
I strongly support any initiative that does not assume maven is a given. -Rgds, Adrian. On Thu, Sep 9, 2010 at 5:03 AM, Sean Devlin wrote: > Until you don't want to deal with maven, and just need a jar. Like if > you're installing Enclojure & just want the stupid jars. > > On Sep 8, 3:42 pm, buckmeist...@gmail.com wrote: >> I felt the same way until I realized that downloading clojure straight from >> the web page was pretty much me "doing it wrong" or attempting to use the >> "custom install" that I wasn't ready to do yet (not knowing what I was >> doing). >> >> Leiningen is the "easy" way to get clojure, contrib, everything else, plus >> properly setup your app to start. >> >> Thanks, >> Peter >> >> >> >> -Original Message- >> From: Sean Devlin >> >> Sender: clojure@googlegroups.com >> Date: Wed, 8 Sep 2010 12:38:27 >> To: Clojure >> Reply-To: clojure@googlegroups.com >> Subject: Re: Standalone 1.2 contrib >> >> Laurent, >> Thank you for the specific help. >> >> Rich/Core >> This is WAY TOO MUCH WORK. The first entries on the download page >> should be just .JARs, and then below that you could have the zip files >> you have now. Also, the simple version should be bigger. Here's the >> rough idea of what I mean >> >> >> Clojure >> Contrib >> >> >> Source >> >> Clojure >> Contrib >> >> >> Sean >> >> On Sep 8, 3:30 pm, Laurent PETIT wrote: >> > look in the target/ dir of the zip ... >> >> > 2010/9/8 Sean Devlin : >> >> > > Yep. It downloaded a zip file, which needed built. Maven broke. I >> > > really don't want to mess with maven right now. I just want a contrib >> > > JAR. >> >> > > On Sep 8, 3:22 pm, Laurent PETIT wrote: >> > >> Hi, >> >> > >> Have you followed the Download link from clojure.org ? >> >> > >> 2010/9/8 Sean Devlin : >> >> > >> > Is there a monolithic standalone contrib jar out there? A download & >> > >> > forget type 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 >> >> > > -- >> > > You received this message because you are subscribed to the Google >> > > Groups "Clojure" group. >> > > To post to this group, send email to clojure@googlegroups.com >> > > Note that posts from new members are moderated - please be patient with >> > > your first post. >> > > To unsubscribe from 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 >> athttp://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: Documentation tools
On Tue, Sep 7, 2010 at 11:10 PM, Mark Engelberg wrote: > Files: > Many times there are dozens of functions that are interrelated. Only > one or two of them are the crucially important "entry points" that > provide the high-level API. The rest are mostly helper functions that > implement the lower-level details. They are made public because in > some situations, you might want to have access to those lower-level > details, but 99% of the time, you can ignore them. By default, all of > these functions will show up in an auto-generated API listing. Full ack here. There are functions I want to mark private to protect from external use, but I still want to be able to use from different namespaces inside a given library. Perhaps we need a metadata key like :internal to signify that a function should be considered private for purposes of documentation? -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: Standalone 1.2 contrib
On Wed, Sep 8, 2010 at 12:38 PM, Sean Devlin wrote: > Rich/Core > This is WAY TOO MUCH WORK. The first entries on the download page > should be just .JARs, and then below that you could have the zip files > you have now. Also, the simple version should be bigger. Here's the > rough idea of what I mean There's good stuff here: http://build.clojure.org/releases/org/clojure/clojure-contrib/1.2.0/ Seems like an obvious place for the download page to link to. -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: Standalone 1.2 contrib
I think Leiningen does a great job of hiding maven. I initially wanted to avoid Leiningen because of maven and when I was putting together cfmljure (as a way to introduce Clojure to CFML developers :) I initially documented the download ZIP, unzip, copy JARs approach but then I reconsidered and updated cfmljure to work better with Leiningen projects and updated the docs for lein instead. I think it's by far the easiest way to deal with getting Clojure up and running. You download one script, make it executable and run it to install Leiningen and then projects are as easy as 1. lein new myproject, 2. lein deps, 3. lein test - although I pretty much always add lein-run and I'm looking forward to it being built into Leiningen at some future date (hopefully!). On Wed, Sep 8, 2010 at 8:38 PM, Adrian Cuthbertson wrote: > I strongly support any initiative that does not assume maven is a given. > > -Rgds, Adrian. > > On Thu, Sep 9, 2010 at 5:03 AM, Sean Devlin wrote: >> Until you don't want to deal with maven, and just need a jar. Like if >> you're installing Enclojure & just want the stupid jars. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: A difficult Metaphor for Macros (especially for Java people)
Hello all, @Luc I'm not a OO adversary, but no evangelist too ;-) @Mike I think the difference between Scala and Clojure is not OO vs not OO, but rather static vs dynamic typing. Clojure is OO too, but as you see with Luc, you can ignore it ;-) @Adam Cool! A RH-video I want aware of! Thank you! (I read he did a talk just about macros this year, but I dont know whether there is a video or slides of it on the web.) @Michael Yep, again some stuff for the comparison list. Thank you. An interesting discusssion! Thank you all! Regards, alux On 8 Sep., 20:17, Michael Ossareh wrote: > On Wed, Sep 8, 2010 at 08:17, CuppoJava wrote: > > Ah I see. Yes, motivation is hard. I don't have any good tips for > > that. > > I'm still a noob at the evangelising part of Lisp! However, when it comes to > clojure, I tell Java people it's a better way of writing Java than Java; it > gives you all the things experienced Java programmers wish Java had: > > + "try the cast, compiler, just trust me on this one" > + "must I really declare that to be thrown? When I don't please just treat > it like a RuntimeException!" > + "no write, save, compile loop - REPL's are amazing" > + "concise object literals for the common data structures, list, maps, > etc". > > are amongst a few of my favoured lines. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: matching with wild-cards in clojure multi-methods
Hi, On 8 Sep., 21:49, Daniel Werner wrote: > Building your own hierarchy would make it safe to use unqualified > keywords as well -- if I am not mistaken? > > (-> (make-hierarchy) > (derive :hello :anything) > ...) derive works with non-qualified keywords, but the contract disallows that: user=> (doc derive) - clojure.core/derive ([tag parent] [h tag parent]) Establishes a parent/child relationship between parent and tag. Parent must be a *namespace-qualified* symbol or keyword and child can be either a *namespace-qualified* symbol or keyword or a class. h must be a hierarchy obtained from make-hierarchy, if not supplied defaults to, and modifies, the global hierarchy. (*Emphasis* mine) So: no. You cannot use non-qualified keywords. Even for private hierarchies. 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: Standalone 1.2 contrib
Thanks Phil, the release jars address my concerns. Just to elaborate on Sean C's post, I think Leiningen is a great initiative - especially for those new to clojure/java, but for me it and maven are dissonant with my setup. From various comments on the list, I suspect there are others who have a similar view. My particular perspective is; - A long-time Java (Unix) developer who has evolved a rich set of home-grown bash/ant processes for managing dev, test and a number of production servers. - Two-odd years of clojure dev and "melding" that into the above environment - A personal antipathy towards "bloat" and anything that "just gets downloaded" without my fully understanding what it is and why it's there. - A willingness to deal with sorting out dependencies myself. - The above in order to have full control and transparency over an environment in which I have full accountability to a demanding and unforgiving customer base. For me, the ideal is having a set of stable jars from release to release for both clojure and c.c and those third party libs which I use. I am happy with the modularization of c.c as I can "meld" those as well and get a more refined subset. I have no problem bashing (yeah pun) together a utility to build my own c.c jar from the distribution or from github for experimental dev. I simply appeal to other third-party library developers to structure their (preferably github) source so that dependencies are easy to separate out and handle ourselves. - Adrian. On Thu, Sep 9, 2010 at 7:03 AM, Sean Corfield wrote: > I think Leiningen does a great job of hiding maven. I initially wanted > to avoid Leiningen because of maven and when I was putting together > cfmljure (as a way to introduce Clojure to CFML developers :) I > initially documented the download ZIP, unzip, copy JARs approach but > then I reconsidered and updated cfmljure to work better with Leiningen > projects and updated the docs for lein instead. I think it's by far > the easiest way to deal with getting Clojure up and running. You > download one script, make it executable and run it to install > Leiningen and then projects are as easy as 1. lein new myproject, 2. > lein deps, 3. lein test - although I pretty much always add lein-run > and I'm looking forward to it being built into Leiningen at some > future date (hopefully!). > > On Wed, Sep 8, 2010 at 8:38 PM, Adrian Cuthbertson > wrote: >> I strongly support any initiative that does not assume maven is a given. >> >> -Rgds, Adrian. >> >> On Thu, Sep 9, 2010 at 5:03 AM, Sean Devlin wrote: >>> Until you don't want to deal with maven, and just need a jar. Like if >>> you're installing Enclojure & just want the stupid jars. > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from 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: Documentation tools
On Wed, Sep 8, 2010 at 1:18 AM, Mark Engelberg wrote: > I don't know that I'd be flattered by that comparison :) LOL. Point well taken :) > If you ever read an article presenting some new algorithm, data > structure, etc. in an academic journal, the published article will > certainly contain some actual prose describing what's going on. Well, yes, certainly, but that's very different from what I'd normally expect as documentation for code itself. > considerably in terms of scope and complexity. The Flash API > documentation is very well written and it fills two 600+-page volumes. And that's necessary because it's a very complex library that you need to know a lot about it in order to use it (at all). It's complex enough that there are a myriad books about it and week-long courses and so on. But the official Adobe documentation is developed and maintained by a whole team of full-time writers - and it's developed separate from the code itself (which is why sometimes the documentation has errors and omissions in it). [Disclaimer: I worked at Macromedia for six years and then Adobe for a year and for a while was working with the AS3 spec folks and developing the compiler test suite] > Our preferences are shaped by our experiences, of course, and your > mileage may vary. What is the largest body of code you've tried to > read and understand and maintain? Were you able to talk with > developers about the code, or did you just have to understand it by > reading it? What things did you like and dislike about the > readability of their code? The largest in-place code base I've come into as 'the new guy' was about 100k lines. The lead developer left essentially within a few days of me joining so although I had access to two other developers, I mostly had to come to speed by myself by reading the code. Luckily, it was a company with strong coding guidelines and the software itself was source code analysis tools which were used extensively on its own source code to automate compliance. The source code was not heavily commented (that was part of their coding guidelines - on the grounds that code should be simple and clear enough not to need many comments) but good naming conventions and good structure many it easy to navigate and assimilate. That system grew to about 250k lines while I was working with that team and we kept tightening the automated code checking. That was the early 90's and the company is still going and has added new product lines... Most of the other sizable projects I've worked on, I've come in near 'ground zero' and have ended up anywhere between 20k and 200k lines. > My experience aligns well with the points raised in this essay I'm in two minds about Joel. He's a great speaker and a great story teller and a lot of his posts are engaging and have interesting and/or useful observations in. But he plays very heavily on "Fog Creek only hires the best" and the whole thing about rock star developers and that undermines some of the other stuff he says (at least for me). I think that all code can be improved. I really enjoy the opportunity to improve my own code when I have to revisit it. I try to encourage others to improve my code too. But I think the reason a lot of developers want to rewrite other people's code is twofold: * many developers are too lazy to spend the effort to understand other people's code (or learn good practices) * a lot of code really is crap (because we have lots of poor developers in our industry... who are too lazy to learn good practices) > I think just about our only point of agreement is that I also feel > that it is difficult to maintain documentation that is separate from > the code. Yup, definitely agree. Being able to attach doc-strings to function arguments helps a lot, in my experience. I haven't yet seen a really good way to attach extended documentation to code - it's definitely a hard problem to solve. I'm with you on liking tools to automate things tho'... -- 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: Standalone 1.2 contrib
On Wed, Sep 8, 2010 at 10:56 PM, Adrian Cuthbertson wrote: > - A personal antipathy towards "bloat" and anything that "just gets > downloaded" without my fully understanding what it is and why it's > there. Yes, this is my main objection to maven and why I've resolutely stuck with ant and managing things myself over the years. Leiningen makes me feel like I'm in control tho' (even if that's an illusion) and it simplifies the whole maven repository thing (great job Phil!). I like that once I've gotten the libraries downloaded and can use them to test / run code, I can easily push those under version control and update my ant based build/test automation scripts to solidify my processes. -- 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: Documentation tools
2010/9/9 Phil Hagelberg : > On Tue, Sep 7, 2010 at 11:10 PM, Mark Engelberg > wrote: >> Files: >> Many times there are dozens of functions that are interrelated. Only >> one or two of them are the crucially important "entry points" that >> provide the high-level API. The rest are mostly helper functions that >> implement the lower-level details. They are made public because in >> some situations, you might want to have access to those lower-level >> details, but 99% of the time, you can ignore them. By default, all of >> these functions will show up in an auto-generated API listing. > > Full ack here. For the non english speaker I am : is this a pun/playword ? (full ack <-> f..ck all) ? >There are functions I want to mark private to protect > from external use, but I still want to be able to use from different > namespaces inside a given library. Perhaps we need a metadata key like > :internal to signify that a function should be considered private for > purposes of documentation? > > -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
Re: A difficult Metaphor for Macros (especially for Java people)
On Wed, Sep 8, 2010 at 7:28 AM, CuppoJava wrote: > I found the easiest way to introduce macros is just to introduce them > as small syntactic sugaring. For example, getting rid of the explicit > (fn [] ...) for macros like (with-open file ...). Interesting. I don't see any real difference between macros and C preprocessor stuff and C++ templates at a conceptual level. I think Clojure macros are much cleaner, but essentially they are similar. So in the Java world, generics (templates) are not yet widely used outside the libraries and maybe that's why Java devs find macros hard to comprehend? -- 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: Documentation tools
On Wed, Sep 8, 2010 at 11:56 PM, Laurent PETIT wrote: >> Full ack here. > > For the non english speaker I am : is this a pun/playword ? (full ack > <-> f..ck all) ? I assume he meant "full acknowledgment" -- an expression of agreement. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
