better error messages > smaller stack traces
This conversation began on Twitter [1] but I want to continue it on the mailing list as it may be of broader interest. The core team is very interested in improving error messages, and relatively less interested in more code to manipulate stack traces, for the following reasons: (1) The language sits at the bottom, and must solve the problems nobody higher up can solve. Error messages are created at the point of an error, and if the language gets it wrong you may not have the information to fix it later. OTOH, any old library code can reduce a stacktrace. (2) Better error messages are easy to implement [2]. Most oddball errors are in macroexpansion, so there is no runtime cost to doing extra work to improve error messages. These can be implemented as pure functions, so even a relative beginner could contribute a patch. (3) The clojure.repl/pst macro in 1.3 already provides better control of stack trace spewage at the REPL. Please let us know when you get a misleading error message from a macroexpansion, so we can make it better. Or contribute a patch along the lines of [2]. Thanks, Stu Stuart Halloway Clojure/core http://clojure.com [1] http://twitter.com/marick/statuses/33760838540070912 [2] https://github.com/clojure/clojure/commit/d694d6d45fb46195ae4de01aab9a2b9f9c06355f -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Records implementing IFn
Thank you. That seems to do the trick.
-Mark
On Feb 7, 11:55 pm, Alex Osborne wrote:
> Mark Fredrickson writes:
> > Is the following behavior correct or a bug:
>
> > user> (defrecord Example [data] clojure.lang.IFn (invoke [this] this)
> > (invoke [this n] (repeat n this)))
> > user.Example
> > user> (def e (Example. "I am e"))
> > #'user/e
> > user> (e 2)
> > (#:user.Example{:data "I am e"} #:user.Example{:data "I am e"})
> > user> (def some-es (e 5))
> > ; Throws java.lang.AbstractMethodError
>
> > I can't tell if I am doing something wrong with respect to the IFn
> > definition, or if I am encountering a bug.
>
> I think you need to implement applyTo for a properly working IFn
> implementation:
>
> (defrecord Example [data] clojure.lang.IFn
> (invoke [this] this)
> (invoke [this n] (repeat n this))
> (applyTo [this args] (clojure.lang.AFn/applyToHelper this args)))
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: better error messages > smaller stack traces
Hello Stuart One of problem, that sometime arise (at least for me) - errors in code that is performed lazily - stack trace contains data about point where it's evaluated, not where it's created: for example, let look to something like: I have a function that combines several functions (defn make-funcs [& funcs] (fn [data] (flatten (map #(% data) funcs and function that use these data, something like: (defn do-something [data] ((make-funcs [func1 func2]) data)) if I omit 'funcs' in map call in 'make-funcs', then I'll get following trace when data will evaluated in do-something, but it will contain no pointer to make-funcs: XXX core [ERROR] - java.lang.RuntimeException: java.lang.RuntimeException: java.util.concurrent.ExecutionException: java.lang.IllegalArgumentException: Wrong number of args (1) passed to: core$map at clojure.lang.LazySeq.sval (LazySeq.java:47) clojure.lang.LazySeq.seq (LazySeq.java:63) clojure.lang.RT.seq (RT.java:450) clojure.core$seq.invoke (core.clj:122) clojure.core$dorun.invoke (core.clj:2450) clojure.core$doall.invoke (core.clj:2465) my_ns$do_something.invoke (my_ns.clj:189) Maybe it's possible to keep information about where this lazy seq was created? On Tue, Feb 8, 2011 at 3:01 PM, Stuart Halloway wrote: > This conversation began on Twitter [1] but I want to continue it on the > mailing list as it may be of broader interest. > The core team is very interested in improving error messages, and relatively > less interested in more code to manipulate stack traces, for the following > reasons: > (1) The language sits at the bottom, and must solve the problems nobody > higher up can solve. Error messages are created at the point of an error, > and if the language gets it wrong you may not have the information to fix it > later. OTOH, any old library code can reduce a stacktrace. > (2) Better error messages are easy to implement [2]. Most oddball errors are > in macroexpansion, so there is no runtime cost to doing extra work to > improve error messages. These can be implemented as pure functions, so even > a relative beginner could contribute a patch. > (3) The clojure.repl/pst macro in 1.3 already provides better control of > stack trace spewage at the REPL. > Please let us know when you get a misleading error message from a > macroexpansion, so we can make it better. Or contribute a patch along the > lines of [2]. > Thanks, > Stu > Stuart Halloway > Clojure/core > http://clojure.com > [1] http://twitter.com/marick/statuses/33760838540070912 > [2] https://github.com/clojure/clojure/commit/d694d6d45fb46195ae4de01aab9a2b9f9c06355f > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en -- With best wishes, Alex Ott, MBA http://alexott.net/ Tiwtter: alexott_en (English), alexott (Russian) Skype: alex.ott -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: better error messages > smaller stack traces
On Tue, 2011-02-08 at 09:01 -0500, Stuart Halloway wrote: > This conversation began on Twitter [1] but I want to continue it on > the mailing list as it may be of broader interest. > > > The core team is very interested in improving error messages, and > relatively less interested in more code to manipulate stack traces, > for the following reasons: > > > (1) The language sits at the bottom, and must solve the problems > nobody higher up can solve. Error messages are created at the point of > an error, and if the language gets it wrong you may not have the > information to fix it later. OTOH, any old library code can reduce a > stacktrace. > > > (2) Better error messages are easy to implement [2]. This seems questionable to me. My car will post a 27B/6 error to the diagnostic interface which tells my mechanic that the oxygen sensor has failed. For my mechanic that is a good error message. However, when my car stalls it would be useless to display 27B/6. A more useful error message might be "Call a tow truck". "Good" error messages are extremely context sensitive and are relative to the mindset of the person. There are times when a null pointer exception is very precise and times when it is completely content-free. The null pointer could happen because there was missing input somewhere else in the program. So even for a specific programmer the exception might have no meaning. So my question is: What is the audience for the error message? In my experience the Symbolics machines had great error messages. They would throw you into emacs editing the failing source with the cursor pointed at the specific failing line. You could fix the failing line and continue from the point of the error. So a good error message would contain information that would allow Slime to do the same thing. That would probably be the filename and source line of the failure. This could be automated by the compiler. The compiler could see a class of symbols, such as 'error' or 'blather' or 'opine' and automatically lay down code to output (file . line) pairs. Slime could then use this information to open the file@line. > Most oddball errors are in macroexpansion, so there is no runtime cost > to doing extra work to improve error messages. These can be > implemented as pure functions, so even a relative beginner could > contribute a patch. > > > (3) The clojure.repl/pst macro in 1.3 already provides better control > of stack trace spewage at the REPL. > > > Please let us know when you get a misleading error message from a > macroexpansion, so we can make it better. Or contribute a patch along > the lines of [2]. > > > Thanks, > Stu > > > Stuart Halloway > Clojure/core > http://clojure.com > > > [1] http://twitter.com/marick/statuses/33760838540070912 > [2] > https://github.com/clojure/clojure/commit/d694d6d45fb46195ae4de01aab9a2b9f9c06355f > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient > with your first post. > To unsubscribe from 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: Textmash - another IDE for Clojure
+1 Checked the code on GitHub. It's pretty exciting to note that TextMash is being developed entirely in Clojure. Regards, Shantanu On Feb 8, 3:45 am, Olek wrote: > Hi, > > Yes, I would like to replace Java version with Clojure. For the > shorter startup time, I will try to do some threading (for menu > building and configuration reading) and compile clj files of boostrap > module (not existing yet) to .class. If the problem would lay in > clojure itself then I hope that some smart people of Clojure would > help. > > Try to hack Clojure branch, Java version is not suitable for > modifications (has been written fast with poor design in mind). > > Now I will move project to github (search for textmash of naleksander > user). > > I have checked leiningen, the performance is very poor, so I will > stick with traditional way of developing app (especially that textmash > won't depend on other jars than clojure and contrib), but feel free to > branch project and use leiningen. > > I hope that with Clojure version of TextMash, it will be pleasure to > write extensions. > > Cheers > > On 7 Lut, 00:01, Laurent PETIT wrote: > > > > > > > > > Hi Olek, > > > I haven't found time to work more on it lately, but checked the > > current status of the codebase today. > > It appears that all new work is going into Textmash2, a rewrite in > > Clojure, if I understand it correctly ? > > > I have some questions: > > > * Is your intent to replace eventually the java version with the > > clojure version ? If so, how do you deal with the concern of "quick > > startup time" ? > > * If I find time to try to add paredit.clj support for it, is it worth > > continuing what I've started on the java branch, or should I hack on > > the clojure branch ? > > > Cheers, > > > -- > > Laurent > > > 2011/1/23 Olek : > > > > Yes, make a branch. > > > I seen many people are using "leiningened", so it is a good (main > > > stream) choice, especially that your parts of code are written in > > > Clojure. > > > > The layout of menus is made in pl/olek/textmash/menu/ > > > WorkspaceMenu.java. > > > > I have also started TextMash2 which is going to be entirely written in > > > Clojure, it is going to be written - 20 minutes a day, mainly in > > > fundamental (proof of concept) parts so It will be easier to other to > > > add/fullfill project with new features. > > > > On 23 Sty, 20:49, Laurent PETIT wrote: > > >> 2011/1/23 Olek > > > >> > I have added you to committers group, so you can commit your work. > > >> > Later I will switch to github since SVN with its "central repository" > > >> > scenario is not very useful in situation where I'm lack of time. > > > >> OK, thanks. > > > >> What I've achieved is more a "proof of concept" right now. Maybe I should > > >> put it in a branch. > > >> I'll quickly describe what I'm talking about, so you can choose: > > > >> * I've "leiningened" the project. Maybe I could "mavenize" it instead. > > >> What are your guts here ? > > >> * I've "leiningened" it to test the "mavenization", on my side, of > > >> paredit.clj. > > >> * paredit.clj uses clojure and clojure contrib. So the feature > > >> currently > > >> shows a delay when it is first invoked. Since the point of my demo was > > >> not > > >> clojure integration but paredit.clj integration, I've not tried to make > > >> this > > >> happen in the background, etc. To the contrary, I've tried to compact the > > >> "proof of concept" code as much as possible in one place, so it can be > > >> easily spotted and reviewed. > > >> * Currently, I've just demonstrated the "raise over sexpr" command I > > >> described in an earlier post in this same thread. > > > >> What I've not been able to achieve (but I admit I haven't spent too much > > >> time right now on it) is how to make the command appear in the menu. I > > >> thought at first that it was derived from the "actions" map in the > > >> TextEditor class, but the layout of the menus must live somewhere else > > >> ... > > >> If you can help me spot the right place ? > > > >> I also still have to finish proper bundling of paredit.clj in the first > > >> place, half done and should not last 'til the end of this week. > > > >> Cheers, > > > >> -- > > >> Laurent > > > > -- > > > You received this message because you are subscribed to the Google > > > Groups "Clojure" group. > > > To post to this group, send email to clojure@googlegroups.com > > > Note that posts from new members are moderated - please be patient with > > > your first post. > > > To unsubscribe from 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,
Re: ANN: Textmash - another IDE for Clojure
2011/2/8 Shantanu Kumar > +1 > Checked the code on GitHub. It's pretty exciting to note that TextMash > is being developed entirely in Clojure. > There was once another attempt at bringing a full clojure text editor, it supported plugins, its author had written a long email explaining how he had managed the state inside the editor ... I remember now, "waterfront" it was named: http://groups.google.com/group/clojure/browse_thread/thread/d5ce5ddb679cb8f9 http://sourceforge.net/projects/waterfront FWIW -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Lazy seq from input
See also Jeff Palmucci's clj-yield. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: better error messages > smaller stack traces
On Feb 8, 2011, at 8:01 AM, Stuart Halloway wrote: > > Please let us know when you get a misleading error message from a > macroexpansion, so we can make it better. Or contribute a patch along the > lines of [2]. > What medium is best? - Brian Marick, Artisanal Labrador Contract programming in Ruby and Clojure Author of /Ring/ (forthcoming; sample: http://exampler.com/tmp/ring.pdf) www.exampler.com, www.exampler.com/blog, www.twitter.com/marick -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: better error messages > smaller stack traces
>> Please let us know when you get a misleading error message from a >> macroexpansion, so we can make it better. Or contribute a patch along the >> lines of [2]. >> > > What medium is best? Discussion here on the mailing list is fine, or a JIRA ticket [1]. We follow both. Thanks! Stu [1] http://dev.clojure.org/jira Stuart Halloway Clojure/core http://clojure.com -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: better error messages > smaller stack traces
I have been working on a fork of Clojure to explore what can be done w.r.t. error messages: https://github.com/qbg/clojure Currently it fixes a misleading error message generated by (int [5]), it aligns the IndexOutOfBoundsExceptions with those thrown by the collections classes, and it explores the possibility of rewriting ClassCastExceptions so they are a bit more friendly. Brian -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Textmash - another IDE for Clojure
2011/1/23 Olek : > Pros: > 1. Yes, it uses Swing. I have even stared writting it in Clojure, but > startup time was too long, not acceptable for lightweight text editor. > 2. Yes, it is. I've carefully studied Mac's TextEdit, NetBeans and > Eclipse and merged theirs ideas. > > Cons: > 1. Yeah, I haven't implemented highligting yet. The cost (time and > work) of implementation would be higher than profits I would get. For > me more important were brackets matching and highlighting occurences > of selected word. In Fiji's script editor, we use RSyntaxTextArea (an extended JTextArea) with an extended TokenMaker to support clojure. Basically, all the hard work is already done by RSyntaxTextArea from the rsyntaxtextarea.jar library. Comes with parenthesis matching, labeling of white space, etc. Albert -- http://albert.rierol.net -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: searching for a good name thread-let, thread-with, thread-thru
How about
(%->
starting-value
(foo 3 %)
(bar % arg2 arg3))
This combines the standard shorthand argument form from the inline
function with the threading. I also like be because the '%' stands
out.
On Feb 4, 3:05 pm, B Smith-Mannschott wrote:
> Clojure's threading macros -> and ->> to be quite a win. It breaks
> down when the expression to be chained together are not consistent in
> nesting the threaded expression second or last. An idiomatic way to
> gain the necessary flexibility seems to be via let:
>
> (let [x (line-seq x)
> x (sort x)
> ...]
> x)
>
> I've never been very happy with that solution. The same variable
> appears multiple times in the same let. Maybe that just confuses my
> Scheme sensibilities. (I know there are previously been discussions
> about a variant of -> which allows the threading position to be marked
> in some way, though these never really went anywhere. I also rejected
> the alternative of using an anaphoric macro which always uses 'it or
> '$ or some such as the name to thread through. That didn't seem very
> Clojuresque.)
>
> I came up with this macro, but I'm unsure what to call it:
>
> (defmacro thread-let [[varname init-expression :as binding] & expressions]
> {:pre [(symbol? varname)
> (not (namespace varname))
> (vector? binding)
> (= 2 (count binding))]}
> `(let [~@(interleave (repeat varname) (cons init-expression expressions))]
> ~varname))
>
> usage example:
>
> (thread-let [x (initial-value)]
> (foo x 3)
> (bar 1 2 x))
>
> which is equivalent to:
>
> (let [x (initial-value)
> x (foo x 3)
> x (bar 1 2 x)]
> x)
>
> What should I name this thing? I'm concerned that "thread" is
> confusing due to its dual meaning. let seems in line with clojure
> conventions.
>
> (thread-let [x ...] ...)
> (thread-with [x ...] ...)
> (thread-through [x ...] ...)
> (let-> [x ...] ...)
>
> thoughts?
>
> // Ben
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Clojure job posting
Hi All! There's a Clojure job available with one of the fastest growing service companies in India. You will have to coordinate and work with one of our European clients. This is a full time job requiring some minimum level of expertise in Clojure (and other technologies). Job highlights: * Server side development for a real time Web application. * Cool technologies like Clojure, MongoDB, JSON. * Attractive renumeration. * Small team, minimal hierarchy. Minimal requirements: * Sound problem solving skills. * Good ability to write code in Clojure. * Experience with web development is a plus. Note that you will be required to travel client side as per the requirements. Please email me at dev...@gatewaytechnolabs.com if you're interested. With below details CTC: ECTC: Notice period: Regards, Devika Koneru Manager-Recruitment. Gateway TechnoLabs Pvt. Ltd. B-81, Corporate House, Judges Bungalow Cross Roads, Bodakdev, Ahmedabad. Phone: 079-40223000– Ext. 46 Skype: devikakoneru-gtl Fax: +91-79-26858591 MSN: dev...@gatewaytechnolabs.com -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Any news on pull requests?
On 05/02/2011 18:23, Mike Meyer wrote: On Sat, 5 Feb 2011 00:09:41 -0500 Christopher Petrilli wrote: For example, the following projects REQUIRE contributor agreements, in writing, signed and either scanned or on paper, prior to accepting any patches or commits: - Free Software Foundation - Apache, and everything under it - Python - Perl - Django - MySQL - Node.js - Fedora Linux - Neo4j - Sun (now Oracle) I'm sorry, I'm going to call foul on this. I've contributed to Python without ever signing a CA. And the current developers guide page doesn't have anything on it about needing to sign a CA. Unfortunately, it's not listed under the developer's guide but it is a requirement for contributions now: http://www.python.org/psf/contrib/ Not sure how long ago it was introduced, but I had to sign one recently to get a patch included in Python 3.2. How strictly the PSF enforces it is another matter... Not sure why a physical copy needs to be sent (for Clojure), rather than a scan - this is the 21st Century after all! John -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: searching for a good name thread-let, thread-with, thread-thru
Ah. A classic: http://groups.google.com/group/clojure/browse_thread/thread/66ff0b89229be894/c3d4a6dae45d4852 Some more names in this old thread. 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: searching for a good name thread-let, thread-with, thread-thru
On Sat, Feb 5, 2011 at 16:36, Jason wrote: > How about > > (%-> > starting-value > (foo 3 %) > (bar % arg2 arg3)) > > This combines the standard shorthand argument form from the inline > function with the threading. I also like be because the '%' stands > out. This, or something very like it, has been discussed previously using $ in place of %. At the time it didn't find much traction. // ben -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: searching for a good name thread-let, thread-with, thread-thru
On Tue, Feb 8, 2011 at 22:05, Meikel Brandmeyer wrote: > Ah. A classic: > http://groups.google.com/group/clojure/browse_thread/thread/66ff0b89229be894/c3d4a6dae45d4852 > > Some more names in this old thread. > > Sincerely > Meikel Ah. Indeed. And Mark Fredrickson's "let->" is equivalent to my thread-with macro. I even considered the name let->. I guess there's no wheel that can't be reinvented. ;-) // Ben -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Using maven with clojure-contrib 1.3
Can you give example steps to reproduce this problem? Thanks, -Stuart Sierra clojure.com -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Which branch of clojure-hadoop to use?
Glad to see there's still interest in this. Sorry I don't have time to maintain clojure-hadoop (I haven't used Hadoop at all in the past year, so I'd be a poor choice) but I will help where I can. If somebody wants to take on maintenance I'll link to it from my github repository. -Stuart Sierra clojure.com -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Importing defprotocol and deftype
`defprotocol` creates a real Var, which you can `use` or `refer` just like a function. `deftype` and `defrecord` both create classes, which you must `import` using the class name. Class names have to be compatible with Java, so dashes are converted to underscores. -Stuart Sierra clojure.com -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: searching for a good name thread-let, thread-with, thread-thru
Hi, Am 08.02.2011 um 22:11 schrieb B Smith-Mannschott: > Ah. Indeed. And Mark Fredrickson's "let->" is equivalent to my > thread-with macro. I even considered the name let->. I guess there's > no wheel that can't be reinvented. ;-) Yeah. Once per year or so. ;) 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
Help with a ClassCastException
So I've put together a small genetic algorithm simulation that I've written in Java which I have recently ported to Clojure. While the code looks sound from my perspective, yet I get the following exception when I run my uberjar: Exception in thread "main" java.lang.RuntimeException: java.lang.ClassCastException: clojure.lang.Cons cannot be cast to clojure.lang.Associative at clojure.lang.LazySeq.sval(LazySeq.java:47) at clojure.lang.LazySeq.seq(LazySeq.java:56) at clojure.lang.RT.seq(RT.java:450) at clojure.core$seq.invoke(core.clj:122) at clojure.core$r.invoke(core.clj:793) at clojure.core$into.invoke(core.clj:2615) at net.auxesia.population$evolve.invoke(population.clj:87) at net.auxesia.core$_main.doInvoke(core.clj:49) at clojure.lang.RestFn.invoke(RestFn.java:398) at clojure.lang.AFn.applyToHelper(AFn.java:159) at clojure.lang.RestFn.applyTo(RestFn.java:133) at net.auxesia.core.main(Unknown Source) Caused by: java.lang.ClassCastException: clojure.lang.Cons cannot be cast to clojure.lang.Associative at clojure.lang.RT.assoc(RT.java:664) at clojure.core$assoc.invoke(core.clj:170) at net.auxesia.chromosome$mutate.invoke(chromosome.clj:58) at net.auxesia.population$evolve $r_mutate__29.invoke(population.clj:76) at net.auxesia.population$evolve$fn__33.invoke(population.clj: 87) at clojure.core$map$fn__3695.invoke(core.clj:2094) at clojure.lang.LazySeq.sval(LazySeq.java:42) ... 11 more The source can be found at: https://github.com/jsvazic/GAHelloWorld/tree/master/clojure I've narrowed it down to the call: (map #(r-mutate %) (chromosome/mate c1 c2)) which essentially takes two "chromosomes" and generates two new ones, returning them in a vector. Each element of the vector is a map, and the r-mutate function simply updates one of the KVPs for the given map (randomly, depending on a threshold being hit), and returns a new "chromosome". If the threshold isn't hit, it simply returns the same chromosome it was provided. Any ideas from anyone? -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Help with a ClassCastException
John Svazic writes: Snipping to the relevant portion of the exception (always look at the last "Caused by"): > Caused by: java.lang.ClassCastException: clojure.lang.Cons cannot be > cast to clojure.lang.Associative > at clojure.lang.RT.assoc(RT.java:664) > at net.auxesia.chromosome$mutate.invoke(chromosome.clj:58) So what that means is that a call to the "assoc" function on line 58 of chromosome.clj is being passed a "Cons" object (a list cell) instead of an "Associative" object (a vector or map). The assoc call in question is this: (let [old (:gene c) idx (rand-int (count old)) new (assoc old idx (char (mod (+ (int (nth old idx)) (+ 32 (rand-int 90))) 122)))] So "old" must be a list when you're expecting a vector. Looking around at places you assign (:gene c) we come to the "mate" function, specifically: (let [... child1 (into (drop pivot gene2) (reverse (take pivot gene1))) child2 (into (drop pivot gene1) (reverse (take pivot gene2)))] ... (hash-map :gene child1 :fitness (fitness child1)) ...) 'drop is lazy so returns a seq, calling 'into on a seq produces a list. So try calling vec on each child to convert it into a vector. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: searching for a good name thread-let, thread-with, thread-thru
I wanted to see how long this thread would go before someone linked to the old stuff. :-) Despite turning up repeatedly, the issue has never been put to bed. I suspect it is the name. There has been no consensus, as this thread demonstrates. I vote for one I haven't seen yet. `=>`. It's two characters and in the style of the other threaders. I'm torn on the binding form. On one hand, it is misleading because [x 1 y 2] is illegal. But something [[x y] (function-that-returns-a- pair ...)] could be handy for threading through a series of functions that return pairs. -M On Feb 8, 3:52 pm, Meikel Brandmeyer wrote: > Hi, > > Am 08.02.2011 um 22:11 schrieb B Smith-Mannschott: > > > Ah. Indeed. And Mark Fredrickson's "let->" is equivalent to my > > thread-with macro. I even considered the name let->. I guess there's > > no wheel that can't be reinvented. ;-) > > Yeah. Once per year or so. ;) > > 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: searching for a good name thread-let, thread-with, thread-thru
On Sat, Feb 5, 2011 at 10:36 AM, Jason wrote: > How about > > (%-> > starting-value > (foo 3 %) > (bar % arg2 arg3)) > > This combines the standard shorthand argument form from the inline > function with the threading. I also like be because the '%' stands > out. And this also presumably precludes using a #(anonymous-fn % :foo 42) in there. Thanks, but no thanks. :) -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Help with a ClassCastException
That was it, thanks! On Feb 8, 5:01 pm, Alex Osborne wrote: > John Svazic writes: > > Snipping to the relevant portion of the exception (always look at the > last "Caused by"): > > > Caused by: java.lang.ClassCastException: clojure.lang.Cons cannot be > > cast to clojure.lang.Associative > > at clojure.lang.RT.assoc(RT.java:664) > > at net.auxesia.chromosome$mutate.invoke(chromosome.clj:58) > > So what that means is that a call to the "assoc" function on line 58 of > chromosome.clj is being passed a "Cons" object (a list cell) instead of > an "Associative" object (a vector or map). > > The assoc call in question is this: > > (let [old (:gene c) > idx (rand-int (count old)) > new (assoc old idx (char (mod (+ (int (nth old idx)) > (+ 32 (rand-int 90))) 122)))] > > So "old" must be a list when you're expecting a vector. Looking around > at places you assign (:gene c) we come to the "mate" function, > specifically: > > (let [... > child1 (into (drop pivot gene2) (reverse (take pivot gene1))) > child2 (into (drop pivot gene1) (reverse (take pivot gene2)))] > ... > (hash-map :gene child1 :fitness (fitness child1)) > ...) > > 'drop is lazy so returns a seq, calling 'into on a seq produces a list. > So try calling vec on each child to convert it into a vector. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: http.async.client v0.2.2 released
Hi, Thank you for the introduction. Here is my little feed back: 1. I want to see a example using callbacks. 2. Is RequestBuilderWrapper.java necessary? Why not simply use RequestBuilder? 3. I prefer reify or defrecord to proxy for performance reason, when implement interface. 4. I think hash-map is more suitable rather than cond in convert- method function. Thanks. On 2月8日, 午前3:30, Hubert Iwaniuk wrote: > Hi All, > > Just released v0.2.2 of HTTP Asynchronous Client. > > Featuring following changeloghttp://bit.ly/hc9dxt > > - get-encoding helper works w/o Content-Type header > - upgrade async-http-client to v1.5.0 > - exposed more configuration options > - zero byte copy mode > - allow providing your own poll > - allow Asynchronous Connect > - fix seq streaming API > - lots of performance improvements from async-http-client to v1.5.0 > > Uploaded to clojarshttp://bit.ly/hVAY8z > > Documentation is here:http://bit.ly/epmcMw > > Enjoy fresh release, > Hubert. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
